Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
2019-02 HTTP_DNS
Cybozu
PRO
May 27, 2019
Technology
4
170k
2019-02 HTTP_DNS
Cybozu
PRO
May 27, 2019
Tweet
Share
More Decks by Cybozu
See All by Cybozu
テキストマイニングを使って 今年1年のレビュー内容をふりかえってみた話
cybozuinsideout
PRO
0
170
Waffle Festival「ITのすゝめ~文系からITキャリアへ」
cybozuinsideout
PRO
1
180
サイボウズのプロダクトデザイナーについて
cybozuinsideout
PRO
0
680
jsconf-sponsor-lt.pdf
cybozuinsideout
PRO
0
4.1k
Kubernetesストレージ可用性の監視ツール「pie」のご紹介
cybozuinsideout
PRO
0
52
kintone UXリサーチャーのお仕事紹介
cybozuinsideout
PRO
1
840
サイボウズのUXリサーチャーについて
cybozuinsideout
PRO
0
410
サイボウズの日英翻訳/ローカライズ担当について
cybozuinsideout
PRO
0
460
Garoon 開発チーム / Garoon development team
cybozuinsideout
PRO
0
1.1k
Other Decks in Technology
See All in Technology
DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Random Subdomain Attack and mitigations
kazeburo
5
1.3k
NGINXENG JP#2 - 4-NGINX-エンジニアリング勉強会
hiropo20
0
120
cdk deployに必要な権限ってなんだ?
kinyok
0
190
初めてのデータ移行プロジェクトから得た学び
tjmtmmnk
0
400
NGINXENG JP#2 - 3-NGINX Plus・プロダクトのアップデート
hiropo20
0
250
Deep Neural Networkの共同学習
hf149
0
330
証明書って何だっけ? 〜AWSの中間CA移行に備える〜
minorun365
3
2.1k
都市ARの作り方 PLATEAU ✖︎ Geospatial API
41h0_shiho
0
250
S3とCloudWatch Logsの見直しから始めるコスト削減 / Cost saving S3 and CloudWatch Logs
shonansurvivors
0
260
ChatGPT for Hacking
anugrahsr
0
4.6k
ECテックカンファレンス2023 EC事業部のモバイル開発2023
tatsumi0000
0
340
Oracle Cloud Infrastructure:2023年1月度サービス・アップデート
oracle4engineer
PRO
0
170
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
22
43k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
13
1.1k
Art, The Web, and Tiny UX
lynnandtonic
284
18k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
6
840
Large-scale JavaScript Application Architecture
addyosmani
499
110k
Optimizing for Happiness
mojombo
365
64k
Music & Morning Musume
bryan
37
4.6k
jQuery: Nuts, Bolts and Bling
dougneiner
57
6.6k
Git: the NoSQL Database
bkeepers
PRO
419
60k
Design by the Numbers
sachag
271
18k
Making Projects Easy
brettharned
102
4.8k
Building Flexible Design Systems
yeseniaperezcruz
314
35k
Transcript
HTTP と DNS サイボウズ株式会社
DNS Domain Name System
名前って何? ▌hoge.cybozu.com は人間に読みやすい・覚えやすい名前 ▌実際使われているのは IPアドレス ▌じゃあ hoge.cybozu.com の IPアドレスは?
名前解決 ▌hoge.cybozu.com = 103.79.14.41, 103.79.14.42 ▌ドメイン名を IPアドレスに紐づける
誰に聞けば良い? ▌dig コマンドを打ってみましょう ◼ 無かった場合: sudo apt install dnsutils ▌$>
dig +noall +stats +answer hoge.cybozu.com bozuman.cybozu.com. 2795 IN A 103.79.14.41 bozuman.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
Recursive DNS Resolver ▌10.224.136.183 は何でも知っている? ▌hoge の IPアドレスが変わったらどうなる? ▌7億人が同時に名前解決したらどうなる? ▌そもそも
10.224.136.183 は社内の IP
名前解決の流れ https://www.cloudflare.com/learning/dns/what-is-dns/ 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 だって こんちゃっす dns-1.cybozu.com
Root Servers https://www.iana.org/domains/root/servers
実際に見てみましょう ▌$> dig +trace hoge.cybozu.com ▌$> dig +trace hoge.cybozu.cn ▌$>
dig +trace hogehagehige.com
毎回やる? https://www.cloudflare.com/learning/dns/what-is-dns/ hoge.cybozu.com はど こ? こんちゃっす 覚えてる! 103.79.14.41, 103.79.14.42
DNSレコードの種類 ▌SOA ▌NS ▌A ▌AAAA ▌CNAME ▌MX ▌TXT ▌PTR ▌…
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) )
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.
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レコードがある ◼ 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 ▌逆名前解決 ◼ 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
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 ファイル <$ORIGIN下の名前> IN <レコードタイプ> <レコード値> 例)bozuman IN A 103.79.14.41
演習: DNSサーバーを触りましょう ▌Docker をインストール ◼ https://docs.docker.com/install/linux/docker- ce/ubuntu/#install-docker-ce ▌docker-compose をインストール ◼
https://docs.docker.com/compose/install/ ▌演習用のレポジトリをクローン ◼ https://github.dev.cybozu.co.jp/tu-antoine/kaiun-dmz
構成 ▌dns: kaiun.lan の権威 DNS (NSD) ▌cache: recursive DNS resolver/cache
(Unbound) ◼ kaiun.lan に関しては dns である 172.30.0.3 に問い合わせる ▌client: 外から見れないので client コンテナーに入って様々なコマンドを打つ ▌おまけ: ◼ l7lb: 負荷分散、TLS termination (nginx) ◼ 外から見えるのは l7lb。裏で実際のウエブサーバーにリクエストを割り当てる ◼ web: ウエブサーバー
演習: 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ダイレクトリー下) ◼ kaiun.lan -> 172.30.0.6 にしましょう
◼ rDNS もやりましょう ◼ ついでに www の CNAME も追加しよう (kaiun.lan のアリアス)
演習: DNSサーバーを触りましょう ▌$> docker-compose -p kaiun up --build --scale ap=3
▌$> docker exec -it kaiun_client_1 bash ▌$> dig kaiun.lan ▌$> curl –v kaiun.lan おまけ:L7LB も見ましょう ◼ $> seq 5 | xargs -n1 -P5 bash -c 'curl kaiun.lan'
HTTP Hypertext Transfer Protocol
Hypertext Transfer Protocol ▌hyper-text:テキストを超える ▌複数の文書をリンクにより関連付ける仕組み →HTML:Hypertext Markup Language ▌HTTP:hypertextを送受信する手順 ▌今では,hypertextに限らずあらゆるデータの送受信に使われる
→演習:ファイルの受信
演習1:HTTPによるファイル受信 ターミナル1 テスト用HTTPサーバを立てる ターミナル2 HTTPサーバにアクセスし,hello.txtを受信 $ mkdir httproot $ cd
httproot $ echo 'hello world' > hello.txt $ python3 -m http.server 8080 $ telnet localhost 8080 Trying 127.0.0.1... … GET /hello.txt HTTP/1.1 Host: 127.0.0.1:8080 HTTP/1.0 200 OK … hello world Connection closed by foreign host. ファイルの中身が受信できた!
HTTPリクエスト(要求) ▌HTTPリクエスト:クライアントからHTTPサーバへの要求 GET /hello.txt HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: curl/7.47.0 Accept:
*/*
HTTPレスポンス(応答) ▌HTTPレスポンス:HTTPサーバからの応答 HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/3.5.2 Date: Wed,
15 May 2019 09:11:53 GMT Content-type: text/plain Content-Length: 12 Last-Modified: Wed, 15 May 2019 09:09:07 GMT hello world
HTTP 1.Xのフォーマット 32 スタートライン ヘッダ ボディ (ないこともある) リクエスト レスポンス
HTTPリクエスト
Method: 要求の種類 34 ◼ GET ◼ POST ◼ DELETE ◼
PUT ◼ CONNECT … ▌このリクエストがどのようなものか推測する手がかり (例:安全か、べき等か、キャッシュ可能か) Request line
Request target: 要求の対象 35 ▌Webサーバが持つどのサービスに対 するリクエストか ▌サービス ◼ 単なるファイル ◼
動的なファイル ◼ DBへの書き込み ◼ etc.
Version:HTTPのバージョン 36 ▌HTTP/X.Y というフォーマット 「メジャーバージョンが同じなら 後方互換性がある」…というタテマエ ※ HTTP/2はそもそもバイナリプロトコル メジャーバー ジョン
マイナー バージョン
Hostヘッダ: サーバの名前 37 ▌どのサーバに対するリクエストか ← 同じIPアドレス上に複数のHTTP サーバがいることがある (Virtual Host)
その他のヘッダ 38 ◼ Controls ◼ Conditionals ◼ Content Negotiation ◼
Authentication Credentials ◼ Request Context ◼ 独自拡張
Message Body: データ部分 39 ▌ヘッダ部分と空行(CRLF)で隔てら れた部分 ▌メソッドによってあったりなかったり ◼ 典型的には… ◼
GETはボディを持たない ◼ PUT/POSTはボディを持つ
HTTPレスポンス
Status Code: リクエストの処理結果 41 ◼ 1XX: コネクションの情報 ◼ 2XX: 成功
◼ 3XX: リダイレクト ◼ 4XX: クライアント側のエラー ◼ 5XX: サーバ側のエラー ▌クライアントはこれに応じてリトライしたりエ ラー処理をしたりする
Status Codeに対するクライアントの反応例 ▌302 Found → Locationヘッダに指定されたURLを見に行く ▌304 Not Modified →
キャッシュされている結果を使う ▌500 Internal Server Error → 500エラーを画面に出す ▌401 Unauthorized → 認証パスワードを再度求める 42
Status Codeの罠 ▌ステータスコードを信用しすぎてはいけない ◼ サーバーが実装を間違えている ◼ ステータスコードは200でもボディにエラーメッセージが入る ◼ 独自のステータスコードを返す 43
HTTP/1.0 200 OK {"status": "error"} 200 OKなのにエラーを返す例
Reason Phrase 44 ▌人間が読むための文字列 ▌プログラムからは利用しない
動的コンテンツ ▌HTTPサーバは,受け取ったHTTPリクエストに対し,反応する ▌HTTPレスポンスをどうやって生成するか ◼ ファイルをそのまま送る ◼ 内容を動的に生成して送る ▌Webアプリ(kintoneやGaroonなど)がやっているのはこれ!
演習2:動的コンテンツを送信するHTTPサーバを作る $ curl http://localhost:8080/add/2/3 5 $ curl http://localhost:8080/add/-4/3 -1 ▌仕様
◼ GET /add/X/Y とすると X+Y の結果を返す ◼ X,Yはともに整数(値の範囲は自由に仮定していいです) ▌ひな形 https://gist.github.com/uchan-nos/18fdd22cdf9c358109dd938c98ca79cd メモ: 演習2は20分想定. 時間が足りなそうなら 演習2はスキップする.
演習2のプログラム起動方法 (ほぼ答え)四則演算に対応した版 https://gist.github.com/uchan-nos/9d05dbaa7b190f890ea962cf4e81456a $ chmod +x simple_add_server.py $ ./simple_add_server.py $
curl http://localhost:8080/add/2/3 5 $ ターミナル1 HTTPサーバを立てる ターミナル2 HTTPサーバにアクセスする
演習2のヒント ▌(ほぼ答え)四則演算に対応した版 https://gist.github.com/uchan-nos/9d05dbaa7b190f890ea962cf4e81456a # X+Y result = arguments[0] + arguments[1]
# レスポンスボディの作成 self.wfile.write(バイト列) # 数値→バイト列の変換 '{}'.format(数値).encode('utf-8')
HTTPS HTTP Secure
HTTP Secure ▌HTTPは平文プロトコル = 攻撃者が簡単に情報を盗める ▌HTTPS:HTTPをTLSの上に構築 ◼ TLS:Transport Layer Security
▌暗号化されるので盗聴されても解読が難しい HTTP TCP/UDP IP Ethernet HTTP TCP/UDP IP Ethernet TLS アプリケーション/プレゼンテーション層 セッション層 トランスポート層 ネットワーク層 データリンク/物理層
TLSで守りたいもの・守り方 ▌通信相手が本物であること → デジタル署名 ◼ (クライアント視点で)本物のサーバか? ◼ (サーバ視点で)本物のクライアントか? ▌通信内容が盗聴されないこと →
対称暗号 ◼ クレジットカード番号などが漏洩しないように ▌通信内容が改竄されないこと → メッセージ認証コード ◼ 説明は省略
デジタル署名:通信相手が本物であること 認証局 サーバB クライアントA 公開鍵B 秘密鍵B' 公開鍵T 秘密鍵T' 公開鍵B Bのハッシュ
一方向ハッシュ Bの署名 暗号化 証明書B Bの署名 証明書B Bの署名 Bのハッシュ 復号 比較 公開鍵B 一方向ハッシュ Bのハッシュ
対称暗号:通信内容が盗聴されないこと ▌共通鍵暗号とも呼ぶ ▌公開鍵暗号またはDiffie-Hellman鍵交換にて クライアントとサーバが鍵を共有する ▌公開鍵暗号より対称暗号の方が(とても)速い 鍵K 鍵K サーバB クライアントA msg
暗号化 復号 msg
TLSハンドシェイク ▌TLS通信をするには,クライアントとサーバ間で合意が必要 ◼ 証明書のやり取り ◼ 共通鍵の生成と交換 ▌開発環境のドメインにアクセスしてハンドシェイクの様子を見てみよう $ curl -v
https://foo.cybozu-dev.com/
$ curl -v https://foo.cybozu-dev.com/ * Trying 192.0.2.100... * TCP_NODELAY set
* Connected to foo.cybozu-dev.com (192.0.2.100) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (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 (続く)… foo.cybozu-dev.com にアクセスするときの TLSハンドシェイクの様子
… * ALPN, server accepted to use http/1.1 * Server
certificate: * subject: OU=Domain Control Validated; CN=*.cybozu-dev.com * start date: Aug 29 10:54:08 2018 GMT * expire date: Oct 29 01:13:38 2020 GMT * subjectAltName: host "foo.cybozu-dev.com" matched cert's "*.cybozu-dev.com" * issuer: … CN=Starfield Secure Certificate Authority - G2 * SSL certificate verify ok. > GET / HTTP/1.1 > Host: foo.cybozu-dev.com > User-Agent: curl/7.58.0 > Accept: */* > < HTTP/1.1 200 OK … ここからHTTPが始まる
RFC 57
RFCとは ▌Request for Comments(コメント求む)の略 ▌RFCの目的は色々 ◼ インターネット標準を定める ◼ 情報提供 ◼
ジョーク … ▌RFC 2616 https://tools.ietf.org/html/rfc2616 Hypertext Transfer Protocol -- HTTP/1.1 58
なぜ標準が必要か ▌HTTPの場合:様々なサーバ、様々なクライアント… 59 nginx Apache IIS 自作サーバ Chrome Firefox IE
Edge curl wget 独自クライアント
なぜ標準が必要か ▌もしも標準がないと… ◼ メッセージがうまく処理できず、サービスが動かない ◼ 色んな独自仕様に対応しないといけなくなってとても大変 ◼ セキュリティ上の抜け穴が発生する ※Googleのようにサーバもクライアントも自社開発する場合,自社製 品に独自の仕様を突っ込んで普及させ,後からインターネット標準に仕
立て上げる、ということもできる。SPDY,HTTP/2,QUIC 60
ググった記事よりRFC ▌みんな、自分が思うように相手が動いてほしいと思っている → 「なぜうちに合わせて◦◦という動作じゃないの?」 → 「そっちこそなぜうちに合わせて××じゃないんだ!?」 → もめる ▌…ということになるので、相手に合わせるのではなくRFCに合わせましょう ▌「正しい挙動」が知りたいときは、ググって出てくるページではなくRFCを読
む 61
RFCを読もう ▌RFCの中にはユーモアにあふれるものもある ◼ RFC1149 https://tools.ietf.org/html/rfc1149 ◼ 「鳥類キャリアによるIPデータグラムの伝送に関する標準」 ◼ 1990年4月1日に発表 ▌(もちろん,ほとんどのRFCは真面目)
▌明日のRFC精読会をお楽しみに!