https(SSL/TLS)の仕組みとシーケンス図、パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて~

スポンサーリンク
スポンサーリンク

httpsプロトコルとは

https プロトコルとは、簡単に言うと http プロトコルを暗号化したものです。

httpプロトコルはインターネット等のIPネットワーク上にあるWebサーバからhtmlファイル等のファイルをダウンロードしたり、サイトへログインする際のID・パスワード情報を送ったりするのに使う通信プロトコルです。

ですが、IDパスワードをそのまま送ってしまうと、万が一誰かに通信を傍受(パケットキャプチャ)されていたらパスワードが漏れ、そのサイトへ不正なログインをされてしまいます。楽天等のショッピングサイトだったら勝手に買い物をされてしまう可能性もあります。

そのような事態を防ぐため、通常のショッピングサイトはほぼ100%、httpsによる暗号化を行っています。

厳密には、暗号化以外にもサーバの認証を行っています。つまり、そのサイトが本当に正しいサイトなのか(DNSキャッシュポイズニング攻撃等により、悪意あるサイトへ誘導されていないか)を確認することができます。

認証に失敗するとどうなるかについては下記ページ等をご参照ください。

セキュリティ証明書のエラー警告が表示される理由・原因と対処
セキュリティ証明書のエラー警告が表示される理由・原因と対処
セキュリティ証明書(デジタル証明書やSSL証明書、サーバ証明書などとも呼ばれます...

https のシーケンス図

httpのシーケンス図とhttps のシーケンス図を比べてみます。

スポンサーリンク

『TCP 3way ハンドシェイク』と『暗号化対象のhttp通信』の間に、TLSセッション開始のためのネゴシエーションが入っています。

このネゴシエーションのときに、暗号化のためのパラメータをやり取りします。具体的には以下を実施しています。

  1. サーバからクライアントへデジタル証明書(公開鍵が含まれる)を送付
  2. 暗号化方式の対応リストを互いに提示し、ベストな方式を決定
  3. クライアントからサーバへPremaster Secret (暗号化用の共通鍵を生成するための種)を送付(公開鍵で暗号化するため、秘密鍵を持つサーバのみが復号可能)

ここでは公開鍵・秘密鍵暗号化方式を使って『デジタル証明書の署名によるサーバの認証』および『共通鍵を生成する種の公開鍵による暗号化』しています。

そして実際のhttp通信の暗号化には共通鍵暗号化方式を使います。

この使い分けの理由、仕組みについては以下を参照してください。

【図解】初心者にもわかりやすい『公開鍵・秘密鍵』の仕組み 〜身近で具体的な利用例やメリット〜
【図解】初心者にもわかりやすい『公開鍵・秘密鍵』の仕組み 〜身近で具体的な利用例やメリット〜
公開鍵・秘密鍵でできること 特定のサーバAが秘密鍵を持ち、任意のクライアントが...

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”によるものです。このパケットが出る理由はまちまちです。TLS1.2 を規格化している RFC5246 の Section 7.2 では、以下の種類の Alert Type が定義されています。カッコの中の数字が Alert Type番号です。

close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(21), record_overflow(22), decompression_failure(30),
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単体でトランスポート層の機能は無いので、暗号化を行うアプリケーションという位置付けになるはず)です。

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク