https とは? http との使い分けは?
https とは、簡単に言うと http プロトコルを暗号化したものです。
http プロトコルはインターネット等のIPネットワーク上にある Web サーバから html ファイル等のファイルをダウンロードしたり、サイトへログインする際のID・パスワード情報を送ったりするのに使う通信プロトコルです。
ですが、IDパスワードをそのまま送ってしまうと、万が一誰かに通信を傍受（パケットキャプチャ）されていたらパスワードが漏れ、そのサイトへ不正なログインをされてしまいます。楽天等のショッピングサイトだったら勝手に買い物をされてしまう可能性もあります。
そのような事態を防ぐため、通常のショッピングサイトはほぼ 100%、https による暗号化を行っています。最近は無料のデジタル証明書が増えてきており、ショッピングサイトでない普通のサイトも全て https による暗号化が為されており、むしろ http のサイトを探す方が難しくなってきています。
厳密には、暗号化以外にもサーバの認証を行っています。つまり、そのサイトが本当に正しいサイトなのか ( DNS キャッシュポイズニング攻撃等により、悪意あるサイトへ誘導されていないか ) を確認することができます。
認証に失敗するとどうなるかについては下記ページ等をご参照ください。
https のシーケンス図
httpのシーケンス図とhttps のシーケンス図を比べてみます。
『TCP 3way ハンドシェイク』と『暗号化対象のhttp通信』の間に、TLSセッション開始のためのネゴシエーションが入っています。
このネゴシエーションのときに、暗号化のためのパラメータをやり取りします。具体的には以下を実施しています。
- Certificate によるサーバからクライアントへデジタル証明書の送付
- 暗号化方式の対応リストを互いに提示し、ベストな方式を決定
- Client/Server Key Exchange (TLS1.3はkey_share)による暗号化用共通鍵生成
ここでは公開鍵・秘密鍵暗号化方式を使って『デジタル証明書の署名によるサーバの認証』をしています。
そして実際の『http 通信の暗号化』には共通鍵暗号化方式を使います。
以前はデジタル証明書の公開鍵を使って共有鍵の素の交換を行っていましたが、最近は DHE や ECDHE を使って共有鍵が作られます。
公開鍵・秘密鍵については以下を参照下さい。
なお、2018年8月に最新版のTLS1.3が公開されました。こちらのシーケンスやv1.2どの比較については以下を参照してください。
https 通信であっても盗み見される情報
https通信であっても、(宛先IPアドレスは当然のことながら、)通信先に関して以下の情報を盗み見される可能性があります。
CONNECTメソッドのホスト情報
CONNECTとは、クライアントがプロキシ経由でhttps通信をするときに使われるhttpメソッドです。https://www.yahoo.co.jp と通信するクライアントは、プロキシに対して "CONNECT www.yahoo.co.jp" というメソッドを平文で発行しますので、これを盗み見すれば宛先情報が分かります。
デジタル証明書の Common Name (CN)情報
httpsのセッション開始時(暗号化通信が始まる前)の "Certificate" メッセージではサーバがデジタル証明書を提示しますが、そのデジタル証明書には Common Name (CN) というURLのホスト情報が含まれています。これを盗み見することでやはり宛先情報が分かります。
この情報はよく UTM の URLフィルタでのサイトカテゴリ判別で使われたりします。
Client Hello の ServerName Extension
https のセッション開始時の "Client Hello" メッセージではクライアントが、サーバのURL情報を載せます。この情報もデジタル証明書のCNと同様、UTM の URL フィルタで使われます。
https のパケット構造、ヘッダ、フォーマット
https のフレームフォーマットは以下のようになります。
TLS通信は『レコードヘッダ』と『ペイロード』に分かれています。
レコードヘッダの Version は『SSL2.0 = 0x0200』, 『SSL3.0 = 0x0300』, 『TLS1.0 = 0x0301』, 『TLS1.1 = 0x0302』, 『TLS 1.2 = 0x0303』となっています。
LengthにはTLSペイロードの長さ(MAC: Message Authentication Codeを含む) を示す値が入ります。
そしてContent Type は『ペイロードにどのようなデータが入っているか』を示しています。
Content Type:20 = ChangeCipherSpec
ハンドシェイクプロトコルのサブプロトコル。暗号化通信の準備が整ったことを相手に知らせるメッセージです。
Content Type:21 = Alert
ハンドシェイクプロトコルのサブプロトコル。相手に何かしらの警告を通知するメッセージです。これはさらに Alert Type に分類されます。
Content Type:22 = Handshake
ハンドシェイクプロトコルのサブプロトコル。これはさらに Handshake Type に分類されます。
Content Type:23 = Application Data
http や smtp、ldap等の上位プロトコルが暗号化されて通信されます。
Wireshark で Encrypted Alert が表示されるケースについて
パケットキャプチャ時に Encrypted Alert と表示される場合があります。これは”Content Type:21 = Alert”によるものです。このパケットが出る理由はまちまちですが、TCP FINの直前にある場合は大抵、TLSセッションの終了を意味する『close_notify』だと思われます(暗号化されていて見えない)。
Alertと付くので少し気持ち悪いですが、正常終了でもこの『close_notify』が使われます。
TLS1.2 を規格化している RFC5246 の Section 7.2 では、以下の種類の Alert Type が定義されています。カッコの中の数字が Alert Type番号です。
handshake_failure(40), no_certificate_RESERVED(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction_RESERVED(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), unsupported_extension(110)
close_notify であれば「これ以上暗号化通信するものがないことを相手に伝える」という意味で、正常終了ですが、その他は名前が表す通りに何かしらの原因により異常終了するものです。
https の一般的な通信フロー
ここで、一般的な https 通信のフローを再確認します。
SSL/TLSのレイヤーは何層？
前述の通り、TLSセッション開始のネゴシエーションは『TCP 3way ハンドシェイク』と『暗号化対象のhttp通信』の間に存在しています。このことからもTLSのレイヤーはTCP以上、http以下であることが推察されます。
また、パケット構造を見ても、位置的に同様のことが言えます。
諸説あるようですが、nesuke的にはOSI参照モデルのセッション層扱い、IPセットモデルだとアプリケーション層扱い(TLS単体でトランスポート層の機能は無いので、暗号化を行うアプリケーションという位置付けになるはず)です。
