HTTP_DNS_2020

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 をインストール
   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

4. DNS
   Domain Name System
   

   View Slide

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

   View Slide

6. 名前解決
   ▌hoge.cybozu.com. = 103.79.14.41, 103.79.14.42
   ▌ドメイン名を IPアドレスに紐づける
   

   View Slide

7. 誰に聞けば良い︖
   ▌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: 10.224.136.183#53(10.224.136.183)
   ;; WHEN: Wed May 15 16:13:32 JST 2019
   ;; MSG SIZE rcvd: 79
   ▌$> dig hoge.cybozu.com @1.1.1.1
   

   View Slide

8. Recursive DNS Resolver
   ▌10.224.136.183 は何でも知っている︖
   ▌hoge.cybozu.com の IPアドレスが変わったらどうなる︖
   ▌7億⼈が同時に名前解決したらどうなる︖
   ▌そもそも 10.224.136.183 は社内の IP
   

   View Slide

9. 名前解決の流れ
   https://www.cloudflare.com/learning/dns/what-is-dns/
   dns-1.cybozu.com
   hoge.cybozu.com はど
   こ︖
   知らん。「.」に聞いてみる 俺も知らんし、断⾔する権限がない。「.com」なら知ってる
   hoge.cybozu.com はどこ︖
   知らん、断⾔する権限ない。「cybozu.com」なら知ってるはず
   hoge.cybozu.com はどこ︖
   103.79.14.41, 103.79.14.42
   103.79.14.41,
   103.79.14.42
   だって
   こんちゃっす
   

   View Slide

10. 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

11. 実際に⾒てみましょう
    ▌$> 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

12. 毎回やる︖
    https://www.cloudflare.com/learning/dns/what-is-dns/
    hoge.cybozu.com はど
    こ︖
    覚えてる︕
    103.79.14.41,
    103.79.14.42
    こんちゃっす
    

    View Slide

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

    View Slide

14. SOA
    ▌ Start of Authority
    ▌ DNS Zone の権威情報
    ▌ $> dig SOA +noall +multiline +answer cybozu.com
    cybozu.com. 51 IN SOA dns-1.cybozu.com. root.io.cybozu.co.jp. (
    2019050500 ; serial
    3600 ; refresh (1 hour)
    900 ; retry (15 minutes)
    604800 ; expire (1 week)
    60 ; minimum (1 minute)
    )
    

    View Slide

15. NS
    ▌Name Server
    ▌対象ドメインの権威 DNSサーバー(達)
    ▌$> dig NS +noall +answer cybozu.com
    cybozu.com. 2819 IN NS dns-1.cybozu-bk.com.
    cybozu.com. 2819 IN NS dns-1.cybozu.com.
    cybozu.com. 2819 IN NS dns-2.cybozu.com.
    cybozu.com. 2819 IN NS dns-2.cybozu-bk.com.
    cybozu.com. 2819 IN NS dns-3.cybozu.com.
    cybozu.com. 2819 IN NS dns-4.cybozu.com.
    

    View Slide

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

    View Slide

17. 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

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

    View Slide

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

    View Slide

20. 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

21. PTR
    ▌Pointer
    ▌逆名前解決
    n IPアドレスからドメイン名を問い合わせる
    ▌$> dig +noall +answer -x 103.79.14.84
    84.14.79.103.in-addr.arpa. 86394 IN PTR dns-3.cybozu.com.
    ▌$> dig +short dns-3.cybozu.com
    103.79.14.84
    

    View Slide

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

    View Slide

23. 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

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

    View Slide

25. 演習環境構成
    ▌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

26. 演習: 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

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

    View Slide

28. 演習: 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

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

    View Slide

30. 歴史の話
    ▌歴史を知る
    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

31. HTTP
    Hypertext Transfer Protocol
    

    View Slide

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

    View Slide

33. 演習︓実際に⽣のHTTPを使ってみよう
    ▌$> docker exec -it kaiun_client_1 bash
    ▌$> telnet kaiun.lan 80
    GET / HTTP/1.1
    Host: kaiun.lan
    <改⾏>
    

    View Slide

34. 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

35. HTTPリクエスト
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. HTTPレスポンス
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

46. 演習︓HTTPサーバーをいじってみよう
    ▌web/server.go の中⾝をいじって Target を追加する
    n 例）現時刻を出⼒させる、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

47. HTTPS
    HTTP Secure
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

54. 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

55. 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

56. 信頼されてない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

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

    View Slide

58. 演習︓何処が危ない︖
    ▌皆 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

59. 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

60. 参考
    ▌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