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

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

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

環境のセットアップ ▌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

DNS Domain Name System

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

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

誰に聞けば良い︖ ▌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

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

名前解決の流れ 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

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

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

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

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

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

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) )

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.

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

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

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

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

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

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と⾔う特殊のゾーン

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

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のバージョン番号 他のネームサーバーへのタイミン グ指⽰

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

演習環境構成 ▌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サーバー

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

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

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

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

歴史の話 ▌歴史を知る 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)も存在していた

HTTP Hypertext Transfer Protocol

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

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

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レスポンス: サーバーからの応答

HTTPリクエスト

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

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

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

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

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

HTTPレスポンス

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

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

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

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

演習︓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

HTTPS HTTP Secure

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

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

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

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

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

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

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

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

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

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

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

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/

参考 ▌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/