HTTP and DNS 2021

Transcript

1. HTTP と DNS
   サイボウズ株式会社
   

   View Slide

2. 今⽇構築する環境
   DNS
   (NSD)
   172.30.0.3
   DNS cache
   (Unbound)
   172.30.0.4
   L7LB
   (nginx)
   172.30.0.6
   AP
   AP
   Client
   

   View Slide

3. 前提知識
   ▌Docker
   ▌Git
   ▌簡単なLinuxシェル
   

   View Slide

4. 環境のセットアップ
   ▌Docker をインストール
   n https://docs.docker.com/install/linux/docker-
   ce/ubuntu/#install-docker-ce
   ▌docker-compose をインストール
   n https://docs.docker.com/compose/install/
   ▌演習⽤のレポジトリをクローン
   n https://github.dev.cybozu.co.jp/tu-antoine/kaiun-dmz
   

   View Slide

5. DNS
   Domain Name System
   

   View Slide

6. 名前って何︖
   ▌hoge.cybozu.com. は⼈間に読みやすい・覚えやすい名前
   ▌アクセスす際使われているのは IPアドレス
   ▌じゃあ hoge.cybozu.com. の IPアドレスは︖
   

   View Slide

7. 名前解決
   ▌hoge.cybozu.com. = 103.79.14.41, 103.79.14.42
   ▌全部暗記するのは⼤変
   ▌DNSを使ってドメイン名を IPアドレスに紐づける
   n ※IPアドレスだけじゃない
   

   View Slide

8. 誰に聞けば良い︖
   ▌dig コマンドを打ってみましょう
   n ⽤意された環境を使う:
   n docker-compose -p kaiun up --build --scale ap=3
   n (別ターミナル) docker exec -it kaiun_client_1 bash
   ▌$> dig +noall +stats +answer hoge.cybozu.com
   hoge.cybozu.com. 2795 IN A 103.79.14.41
   hoge.cybozu.com. 2795 IN A 103.79.14.42
   ;; Query time: 0 msec
   ;; SERVER: 172.30.0.4#53(172.30.0.4)
   ;; WHEN: Wed May 15 16:13:32 JST 2019
   ;; MSG SIZE rcvd: 79
   

   View Slide

9. Recursive DNS Resolver
   ▌172.30.0.4 は何でも知っている︖
   ▌hoge.cybozu.com の IPアドレスが変わったらどうなる︖
   ▌7億⼈が同時に名前解決したらどうなる︖
   ▌「何でもは知らないわよ。知ってることだけ」
   

   View Slide

10. 名前解決の流れ
    Recursive DNS
    (社内DNS等)
    hoge.cybozu.com
    はどこにありますか︖
    ルートDNS
    「.」
    知ってますか︖
    .comの事は別の管轄
    192.33.14.30に聞け
    権威DNS
    「com.」
    知ってますか︖
    cybozu.comの事は別の管轄
    216.239.32.107に聞け
    権威DNS
    「cybozu.com.」
    知ってますか︖
    103.79.14.42
    103.79.14.41
    103.79.14.42
    103.79.14.41
    こんちゃっす
    hoge.cybozu.com
    

    View Slide

11. 「.」?
    ▌正式的には「hoge.cybozu.com」ではなく「hoge.cybozu.com.」
    ▌名前の読み⽅は右から左
    ▌名前解決のスタート地点はルートDNS(.)
    ▌ルートDNSの居場所だけ暗記すれば良い
    

    View Slide

12. Root Servers
    https://www.iana.org/domains/root/servers
    HOSTNAME IP ADDRESSES OPERATOR
    a.root-servers.net 198.41.0.4, 2001:503:ba3e::2:30 Verisign, Inc.
    b.root-servers.net 199.9.14.201, 2001:500:200::b University of Southern California (ISI)
    c.root-servers.net 192.33.4.12, 2001:500:2::c Cogent Communications
    d.root-servers.net 199.7.91.13, 2001:500:2d::d University of Maryland
    e.root-servers.net 192.203.230.10, 2001:500:a8::e NASA (Ames Research Center)
    f.root-servers.net 192.5.5.241, 2001:500:2f::f Internet Systems Consortium, Inc.
    g.root-servers.net 192.112.36.4, 2001:500:12::d0d US Department of Defense (NIC)
    h.root-servers.net 198.97.190.53, 2001:500:1::53 US Army (Research Lab)
    i.root-servers.net 192.36.148.17, 2001:7fe::53 Netnod
    j.root-servers.net 192.58.128.30, 2001:503:c27::2:30 Verisign, Inc.
    k.root-servers.net 193.0.14.129, 2001:7fd::1 RIPE NCC
    l.root-servers.net 199.7.83.42, 2001:500:9f::42 ICANN
    m.root-servers.net 202.12.27.33, 2001:dc3::35 WIDE Project
    

    View Slide

13. 実際に⾒てみましょう
    ▌$> dig +trace hoge.cybozu.com @1.1.1.1
    ▌$> dig +trace hoge.cybozu.cn @1.1.1.1
    ▌$> dig +trace hogehagehige.com @1.1.1.1
    

    View Slide

14. 名前解決の流れ
    Recursive DNS
    (社内DNS等)
    hoge.cybozu.com
    はどこにありますか︖
    さっき⾔ったろ︖
    103.79.14.42
    103.79.14.41
    こんちゃっす
    hoge.cybozu.com
    

    View Slide

15. DNSレコードの種類
    ▌ SOA
    ▌ NS
    ▌ A
    ▌ AAAA
    ▌ CNAME
    ▌ MX
    ▌ TXT
    ▌ PTR
    ▌ …
    ▌ https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
    

    View Slide

16. SOA
    ▌ Start of Authority
    ▌ DNS Zone の権威情報
    ▌ $> dig SOA +noall +multiline +answer cybozu.com
    cybozu.com. 884 IN SOA ns-627.awsdns-14.net. forest.cybozu.co.jp.(
    1 ; serial
    7200 ; refresh (2 hours)
    900 ; retry (15 minutes)
    1209600 ; expire (2 weeks)
    86400 ; minimum (1 day)
    )
    

    View Slide

17. NS
    ▌ Name Server
    ▌ 対象ドメインの権威 DNSサーバー(達)
    ▌ $> dig NS +noall +answer cybozu.com
    cybozu.com. 86400 IN NS ns-163.awsdns-20.com.
    cybozu.com. 86400 IN NS ns-627.awsdns-14.net.
    cybozu.com. 86400 IN NS ns-cloud-b3.googledomains.com.
    cybozu.com. 86400 IN NS ns-cloud-b2.googledomains.com.
    cybozu.com. 86400 IN NS ns-1904.awsdns-46.co.uk.
    cybozu.com. 86400 IN NS ns-1159.awsdns-16.org.
    cybozu.com. 86400 IN NS ns-cloud-b1.googledomains.com.
    cybozu.com. 86400 IN NS ns-cloud-b4.googledomains.com.
    

    View Slide

18. A
    ▌Address (IPv4)
    ▌$> dig A +noall +answer cybozu.com
    

    View Slide

19. AAAA
    ▌IPv6アドレス(IPv4の4倍のbit数)
    ▌$> dig AAAA +noall +answer cybozu.com
    無い
    ▌$> dig AAAA +noall +answer google.com
    google.com. 299 IN AAAA 2404:6800:4004:80a::200e
    

    View Slide

20. CNAME
    ▌Canonical Name
    ▌ドメインのエイリアス
    ▌DNS レベルのリダイレクト
    ▌$> dig CNAME +noall +answer developers.cybozu.com
    developers.cybozu.com. 3593 IN CNAME d2p8ofl6yvcluu.cloudfront.net.
    

    View Slide

21. MX
    ▌Mail eXchanger
    ▌メールサーバー
    ▌複数ある場合優先度も指定できる
    ▌$> dig MX +noall +answer cybozu.com
    

    View Slide

22. TXT
    ▌Text: 何でもあり
    ▌定義されている特別な TXTレコードがある
    n DMARC, DKIM, SPFなど
    ▌その他クラウドサービスを使う時のドメイン所有者確認など
    ▌$> dig TXT +short cybozu.com
    "v=spf1 +ip4:103.79.12.128/26 +ip4:103.79.14.16 +ip4:103.79.14.17
    include:spf.protection.outlook.com include:fc5038.cuenote.jp -all“
    ▌$> dig TXT +short matsuri.dev
    

    View Slide

23. PTR
    ▌Pointer
    ▌逆名前解決
    n IPアドレスからドメイン名を問い合わせる
    ▌$> dig +noall +answer -x 103.79.14.76
    76.14.79.103.in-addr.arpa. 86394 IN PTR nat.cybozu.com.
    ▌これはcybozu.comではなく、in-addr.arpaと⾔う特殊のゾーン
    

    View Slide

24. Zoneファイル
    ▌DNSのゾーン(例えばcybozu.com)情報の⼊ってるテキストファイル
    ▌DNSレコードを使って⾃分が管理しているゾーンを定義する
    

    View Slide

25. Zone ファイルの中⾝
    $ORIGIN kaiun.lan.
    $TTL 60; 1 min
    @ IN SOA dns contact.kaiun.lan. (
    2019051701; serial
    3600 ; refresh (1h)
    900 ; retry (15m)
    3600 ; expire (1h)
    60 ; min TTL (1m)
    )
    Zoneファイルの始まりを記す。
    末尾の「.」も必要︕
    Time To Live: キャシュされたレコードの
    有効時間
    $ORIGIN の略
    プライマリーDNSサーバーと連絡
    先のメールアドレス
    Zoneのバージョン番号
    他のネームサーバーへのタイミン
    グ指⽰
    

    View Slide

26. Zone ファイルの中⾝(2)
    <$ORIGIN下の名前> IN <レコードタイプ> <レコード値>
    例）hoge IN A 103.79.14.41
    

    View Slide

27. 演習環境構成
    ▌dns: kaiun.lan の権威 DNS (NSD)
    ▌cache: recursive DNS resolver/cache (Unbound)
    n kaiun.lan に関しては dns である 172.30.0.3 に問い合わせる
    ▌client: 外から⾒れないので client コンテナーに⼊って様々なコマンドを打つ
    ▌おまけ︓
    n l7lb: 負荷分散、TLS termination (nginx)
    n 外から⾒えるのは l7lb。裏で実際のウエブサーバーにリクエストを割り当てる
    n web: HTTPサーバー
    

    View Slide

28. 演習: DNSサーバーを触りましょう
    ▌$> docker-compose -p kaiun up --build --scale ap=3
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> dig cybozu.com
    ▌$> dig kaiun.lan
    ▌$> curl kaiun.lan
    

    View Slide

29. 演習: DNSサーバーを使えるようにしましょう
    ▌zoneファイルに DNSレコードを追加 (dnsダイレクトリー下)
    n kaiun.lan -> 172.30.0.6 にしましょう
    n rDNS もやりましょう
    n ついでに www の CNAME も追加しよう (kaiun.lan のアリアス)
    

    View Slide

30. 演習: DNSサーバーをもう1回試す
    ▌$> docker-compose -p kaiun up --build --scale ap=3
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> dig kaiun.lan
    ▌$> curl -v kaiun.lan
    

    View Slide

31. おまけ
    ▌L7LB の挙動も⾒ましょう
    n $> seq 5 | xargs -n1 -P5 bash -c 'curl kaiun.lan'
    

    View Slide

32. 歴史の話
    ▌歴史を知る
    n $> dig chaos txt hostname.bind @172.30.0.3
    n $> dig chaos txt version.bind @172.30.0.3
    ▌今DNSレコードで「IN」(Internet)というクラスが使われている
    ▌CHはChaosnet。恐⻯時代(1970年代)に存在していたネットワーク
    ▌HS(Hesiod)も存在していた
    

    View Slide

33. HTTP
    Hypertext Transfer Protocol
    

    View Slide

34. Hypertext Transfer Protocol
    ▌汎⽤的なテキストベースでやり取りの為のプロトコール
    n やり取りはテキストベースでも送るデータは⾃由
    ▌Google Chrome等のブラウザーは裏でHTTPを使ってる
    n 送られたHTMLを良い感じに解釈してくれるだけ
    ▌恐⻯時代にGopherというプロトコールと競合していた
    

    View Slide

35. 演習︓実際に⽣のHTTPを使ってみよう
    ▌DNSの演習が未完了の場合dnsブランチに切り替えた上で進められる
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> telnet kaiun.lan 80
    GET / HTTP/1.1
    Host: kaiun.lan
    <改⾏>
    

    View Slide

36. HTTPでのやり取りの結果
    GET / HTTP/1.1
    Host: kaiun.lan
    HTTP/1.1 200 OK
    Server: nginx/1.15.8
    Date: Mon, 13 Apr 2020 01:47:00 GMT
    Content-Type: text/plain; charset=utf-8
    Content-Length: 12
    Connection: keep-alive
    7dcd8c134b30
    HTTPリクエスト:
    クライアント側からの要求
    HTTPレスポンス:
    サーバーからの応答
    

    View Slide

37. HTTPリクエスト
    

    View Slide

38. Method
    n GET: リソースを取得
    n POST: リソースを送る、処理を依頼する
    n DELETE: リソースを消す
    n PUT: サーバーが持っているリソースを置き換える
    n PATCH: リソースを部分的に更新する
    n …
    n ※これはあくまでも仕様で、サーバーによってエキゾチックな実装もある
    

    View Slide

39. Target
    ▌サーバーのどのリソース・エンドポイントに対しての要求を指定
    n 単純なファイル(データ)
    n 動的なファイルコンテンツ
    n 等
    

    View Slide

40. Version
    ▌どのHTTPバージョンを使うかを指定
    n HTTP/1.0
    n HTTP/1.1
    n HTTP/2
    n HTTP/3
    

    View Slide

41. ヘッダー
    ▌リクエストに対する追加情報
    ▌Host: 同じIPアドレスで複数サービスを⽴てる時に必要
    ▌他にも
    n User-Agent
    n Accept-Encoding
    n Connection
    ▌独⾃拡張(X-Cybozu-Request-ID)
    

    View Slide

42. Body
    ▌使うHTTP methodによってクライアントからデータを送る場合もある
    n POST/PUT等
    ▌その時はヘッダーの後にリクエストの中⾝(body)を⼊れる
    

    View Slide

43. HTTPレスポンス
    

    View Slide

44. Status code
    ▌リクエストの処理結果
    ▌1xx: コネクション情報
    ▌2xx: 成功系
    ▌3xx: リダイレクト系
    ▌4xx: クライアント側のエラー
    ▌5xx: サーバー側のエラー
    

    View Slide

45. 追加リクエスト
    ▌Status codeによってクライアントに追加処理が発⽣する
    n リダイレクトを追う
    n 認証情報の⼊⼒要求
    n 等
    

    View Slide

46. Reason
    ▌Status codeに合わせて理由がつくこともある
    n 例えば200の場合︓OK
    ▌主に⼈間に読まれるためにある
    ▌Reasonメッセージは⾃由なので、あてにできない
    

    View Slide

47. 動的コンテンツ
    ▌HTTPサーバは，受け取ったHTTPリクエストに対し，反応する
    ▌HTTPレスポンスをどうやって⽣成するか
    n ファイルをそのまま送る
    n 内容を動的に⽣成して送る
    ▌Webアプリ（kintoneやGaroonなど）がやっているのはこれ︕
    

    View Slide

48. 演習︓HTTPサーバーをいじってみよう
    ▌web/server.go の中⾝をいじって Target を追加する
    n 例）/dateで現時刻を出⼒させる、HTMLを返すようにする、等
    ▌編集し終わったら、環境をリロードして試す
    ▌$> docker-compose -p kaiun up --build --scale ap=3
    ▌$> docker exec -it kaiun_client_1 bash
    ▌telnet kaiun.lan 80
    GET /date HTTP/1.1
    Host: kaiun.lan
    

    View Slide

49. HTTPS
    HTTP Secure
    

    View Slide

50. HTTP Secure
    ▌HTTPは平⽂プロトコル = 攻撃者が簡単に情報を盗める
    ▌HTTPS︓HTTPをTLSの上に構築
    n TLS︓Transport Layer Security
    ▌暗号化されるので盗聴されても解読が難しい
    HTTP
    TCP/UDP
    IP
    Ethernet Ethernet
    IP
    TCP/UDP
    TLS
    HTTP
    アプリケーション/プレゼンテーション層
    セッション層
    トランスポート層
    ネットワーク層
    データリンク/物理層
    

    View Slide

51. TLSで守りたいもの・守り⽅
    ▌通信相⼿が本物であること → デジタル署名
    n （クライアント視点で）本物のサーバか︖
    n （サーバ視点で）本物のクライアントか︖
    ▌通信内容が盗聴されないこと → 対称暗号
    n クレジットカード番号などが漏洩しないように
    ▌通信内容が改竄されないこと → メッセージ認証コード
    n 説明は省略
    

    View Slide

52. cybozu.comって結局何者︖
    ▌初対⾯の⼈が「俺の名は⽥中太郎」と⾔われ
    たら本当かどうかをどう確認する︖
    ▌cybozu.comの⾝元確認には⾝分証明書が
    必要
    

    View Slide

53. SSL証明書の発⾏
    ▌公開鍵と⾮公開鍵を使う
    ▌cybozu.comが⾃分の⾝元情報と公開鍵をCSRを発⾏
    n Certificate Signing Request
    ▌CSRを認証局(CA)に送る
    ▌CAが⾃分の⾮公開鍵と⾃分の⾝元情報を使てCSRを承認する
    n →SSL証明書︓「この証明書とセットになっている⾮公開鍵を持った
    ものがcybozu.com」
    

    View Slide

54. ⾮公開鍵の所有確認(ハンドシェイク)
    ▌クライアントがcybozu.comにアクセスするとき、サーバーからSSL証明書
    が送られる
    ▌SSL証明書から認証局情報を読んで、認証局と確認する
    n 認証局が⾃分が発⾏したものかどうかを確認する
    ▌証明書に⼊ってるcybozu.comの公開鍵を使って、cybozu.comの⾮
    公開鍵でしか読み取れないメッセージをcybozu.comに送る
    ▌cybozu.comがそれを読み取れたことで⾮公開鍵を送らずに所有確認
    ができる
    

    View Slide

55. ハンドシェイクで合意を取る
    ▌⾝元確認以外にも実際にHTTP通信を始める前に⾊々決める必要が
    ある
    ▌今後のやり取りでどんな対称暗号を使う︖
    n 公開鍵暗号には演算コストが⾼いので対称暗号を使う
    ▌暗号の秘密を何にします︖
    ▌等
    

    View Slide

56. TLSハンドシェイクの様⼦
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> curl -v https://cybozu-dev.com
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
    

    View Slide

57. TLSハンドシェイクをもっと詳しく⾒る
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> openssl s_client -connect cybozu-dev.com:443
    ▌$> curl -v https://kaiun.lan
    ▌$> openssl s_client -connect kaiun.lan:443
    

    View Slide

58. 信頼されてないCAからの証明書
    ▌kaiun.lanの証明書は事項発⾏証明書
    ▌クライアントの信頼リストにも⼊ってないので拒否される
    root@1ce716be5d42:/# curl -v https://kaiun.lan
    …
    * successfully set certificate verify locations:
    * CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (OUT), TLS alert, Server hello (2):
    * SSL certificate problem: self signed certificate
    * stopped the pause stream!
    * Closing connection 0
    

    View Slide

59. 演習︓kaiun.lanを信頼させましょう
    ▌無理⽮理クライアントの信頼リストにkaiun.lanの証明書を⼊れたら
    TLS通信できる
    ▌ちゃんとしたCAも信頼リストに⼊れる必要
    n OSのアップデート等で更新されることがある
    ▌※危ないなので実験環境以外ではNG
    

    View Slide

60. 何処が危ない︖
    ▌皆 Twitter 好き︖
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> curl -v https://twitter.com
    * Server certificate:
    * subject: C=JP; ST=Tokyo; L=Chuo; O=Evil Corp.; CN=twitter.com
    * start date: Apr 17 03:35:53 2020 GMT
    * expire date: Apr 15 03:35:53 2030 GMT
    * common name: twitter.com (matched)
    * issuer: C=JP; ST=Tokyo; L=Chuo; O=Evil Corp.; CN=twitter.com
    * SSL certificate verify ok.
    

    View Slide

61. CAは信頼が全て
    ▌CAの⾮公開鍵が厳重に守られている
    ▌万⼀漏洩したら⼤変な事になる
    n 証明書の偽装し放題
    ▌https://en.wikipedia.org/wiki/Key_ceremony
    ▌インシデントが起きた時、報告義務がある
    n https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1
    ▌信頼できないCAはブラウザの信頼リストから外される
    n https://blog.mozilla.org/security/2016/10/24/distrusting-
    new-wosign-and-startcom-certificates/
    

    View Slide

62. 参考
    ▌https://www.iana.org/domains/root/servers
    ▌https://www.iana.org/assignments/dns-
    parameters/dns-parameters.xhtml
    ▌https://tools.ietf.org/html/rfc2616
    ▌https://blog.cloudflare.com/the-history-of-the-url/
    

    View Slide