SSL/TLSについて学ぶ

[yanachuwan9sm]

モチベ

Real World HTTP 読んでたら出てきたトピック。 あんまり理解してなかったのでやる。

• [x] Real World HTTP を読む
• [x] これを読む

文献

SSL/TLS徹底入門: わかりやすい図解解説 インターネット技術 | 松田達也 | コンピュータ・情報処理 | Kindleストア | Amazon

【PKI 応用】SSL/TLS ハンドシェイクをわかりやすく図解 | ねこまるの AD フリーク

【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜 | SEの道標

【図解】TLS v1.3の仕組み ~Handshakeシーケンス,暗号スイートをパケットキャプチャで覗いてみる~ | SEの道標

[yanachuwan9sm]

前提知識

ハッシュ関数・共通鍵暗号・公開鍵暗号・デジタル署名・デジタル証明書

ハッシュ関数

ハッシュ関数をh()、入力データを A,B.....、算出されたハッシュ値を X,Y....、長さを len() とすると以下の様な特性がある。

• 同じアルゴリズムと同じ入力データであれば、結果として得られるハッシュ値（フィンガープリント、メッセージダイジェストとも呼ばれる）は同じ 👉 h(A) = X は常に成り立つ
• アルゴリズムが同じであれば、ハッシュ値は同じ長さとなる。
• ハッシュ値から元データを求めることは難しい（弱衝突耐性）
• 同一ハッシュ値を持つ任意データの組を見つけることは難しい（強衝突耐性）

有名なハッシュ関数には、MD5（128ビット）、SHA-1（160ビット）、SHA-2（SHA-224、SHA-256など）が存在する。（MD5とSHA-1は今現在非推奨のアルゴリズム）

共通鍵方式

• 暗号化、復号化に使用する鍵が共通のものである方式のこと（対象暗号）
• 処理速度は高速だが、通信相手ごとに鍵を管理する必要があり（n人でデータのやり取りをする場合はn(n-1) 個の鍵が必要になる）、第三者に鍵がバレると全然意味がない。
• 共通鍵のアルゴリズムには ブロック暗号・ストリーム暗号の2種類が存在する。

公開鍵方式

• 暗号鍵（公開鍵）と復号鍵（秘密鍵）に異なる鍵を使用する暗号化方式（非対称暗号）
• 秘密鍵はその名のとおり秘密にする必要がある鍵で、公開鍵はみんなに公開しても良い鍵です。この二つは「鍵ペア」と呼ばれ、二つで一組のペアで存在する。
• 共通鍵暗号より強度はあるが、処理速度は低速。また通信相手ごとではなく秘密鍵だけ管理する。
• 「RSA」や「楕円曲線暗号」が該当

以下、公開鍵方式を用いた場合のおおまかな流れ。

１．受信者は公開鍵と秘密鍵（鍵ペア）を作る。 ２．受信者は公開鍵をみんなに公開・配布し、秘密鍵だけを保管します ３．送信者は公開鍵を暗号鍵として暗号化して、送信します ４．受信者は秘密鍵を復号鍵として復号します

ex ) 南京錠

1. 受信者は南京錠（公開鍵）とその鍵（秘密鍵）を作る。
2. 受信者は南京錠を全員に公開・配布し、その鍵だけを保管する
3. 送信者は南京錠をかけて（公開鍵を暗号鍵として暗号化）送信する
4. 受信者は鍵を使って（秘密鍵を復号鍵として復号することで）中身を確認することができる。

[yanachuwan9sm]

前提知識

デジタル署名

1. 署名の対象データのハッシュ値を署名者の秘密鍵で暗号化したもの(A)をデジタル署名とする。
2. デジタル署名の検証者は、公開されている署名者の公開鍵（B)を使ってデジタル署名を復号した値と、署名の対象データのハッシュ値が一致することを確認する(C)

👉 これにより、署名者であることを（B）により確認でき、署名は確かに本人の行為によるものであることを（A)により、署名の対象と署名が対応しているものであることは（C)により保証されます。

ex: 鍵の方を配って、南京錠を秘密にするイメージ。 手紙の本文に対して、南京錠を開けたデータも一緒に添付して送付する 受け取った人は、公開されている鍵を使って南京錠を解除した時に、本文と同じものが出てきたら、本文が改竄されていないことはわかる！

デジタル証明書

「自分が自分であること」を証明するもの。大事なのは、正当性を担保するものは公開鍵。そのため、公開鍵証明書とも呼ばれる。

デジタル証明書の特徴としては以下の通り。

• デジタル証明書には階層構造があり、証明書の位置する階層によって呼び方が異なる。 👉 階層構造の最も上位に位置する証明書をルート証明書、最も下位に位置する証明書をエンドエンティティ証明書と呼ぶ。
• エンドエンティティ証明書として、サーバーの認証に用いる証明書をサーバー証明書と、クライアントの認証に用いる証明書をクライアント証明書がある。

また、デジタル証明書は署名前証明書・ディジタル署名のアルゴリズム・デジタル署名の3つで構成される。

署名前証明書がサーバーやサーバーの所有者の情報であり、サーバーのURLを表すコモンネームや有効期限、公開鍵などが含まれます。また、デジタル署名は、署名前証明書をハッシュ化してできたハッシュ値(メッセージダイジェストとも言う)を、認証局の秘密鍵で暗号化したものです。

サーバー証明書を受け取った受信者は、証明書の中に含まれるデジタル署名を認証局の公開鍵（ルート証明書）で復号し、署名前証明書と比較します。一致していれば、証明書が改ざんされていない、つまりそのサーバーが本物だということがわかります。

ルート証明書

• 自分で「私が言うことは信頼できる！」と主張することが許されている認証局（ルート認証局）が発行した自分自身（ルート認証局）の身元を証明する証明書のこと。
• デジタル証明書によるサーバーやクライアント認証は、ルート証明書を信頼するという前提の上で成り立つもの。
• 最上位に位置するルート認証局は、ベリサインに代表される公的な認証局や企業が運営しており、ルート認証局と名乗るためにはWebTrustforCAという厳正な監査基準に基づく審査を受け、それにパスする必要があり、敷居はとても高い。

下位の認証局(CA)は上位の認証局に証明書を発行してもらうことで、その信頼性を担保しています。階層構造の最上位に位置する認証局をルート認証局と呼び、ルート認証局自身は自分自身に対してディジタル証明書、つまりルート証明書を発行しています。サーバー証明書の場合、クライアントは信頼できる認証局のルート証明書を予め保持しており、信頼する者が発行した証明書は信頼できると考えます。またそれと同様に、「信頼するルート認証局が信頼した子認証局が発行した証明書は信頼できる」と考えるため、サーバー証明書の発行者をたどっていき、ルート証明書をクライアントが信頼している場合、そのサーバー証明書は信頼されます Matsuda Tatsuya. Introduction to TLS Thoroughness: Illustrated explanation Internet Technology (Japanese Edition) (pp.55-56). Kindle 版.

[yanachuwan9sm]

SSL(Secure Socket Layer) / TLS(Transport Layer Security) とは

• 「暗号化・改ざん検知・認証機能」を提供するトランスポート層の上位層に位置するプロトコルであり、セキュアな通信を実現するためのものである。
• SSL/TLSはトランスポート層で動作するものであり、TCPアプリケーションプロトコルを暗号化対象とするもの
• 元々はSSLと言うプロトコルが利用されていたが、脆弱性が発見されたため新しくTLSが設計された。
• HTTPSは、Webサイトの閲覧等に使われるHTTPをSSL/TLSプロトコル上で利用するプロトコルであり、SSL/TLSの代表作。
• SSL/TLSには暗号化・改ざん検知・認証機能の役割がある。（「盗聴」「改ざん」「なりすまし」という3つの脅威からデータを守る役割）👉 これらを実現するために、SSL通信の開始（ハンドシェイク）時に様々な技術を組み合わせている。

以下の様なアプリケーション層のプロトコルと組み合わせて利用されることが多い。

元プロトコル	ポート番号	SSLと組み合わせたプロトコル	ポート番号
HTTP	80	HTTPS	443
SMTP	25	SMTPS	465
FTP	20、21	FTPS	989、990
IMAP	143	IMAPS	993
POP3	110	POP3S	995

[yanachuwan9sm]

SSLハンドシェイク

（以下は TLS v1.2の場合のシーケンス図になる。v1.3は異なる。）

大雑把に何をやっているかを書くと以下の感じ。（本当はもっと色んなことをしてる）

0. クライアントはサーバーに対して暗号化通信の要求を送信（Keep-Alive が有効な場合、セッションが持続するため、これ以降のRTTは必要ない）
1. Webサーバは認証局から発行された SSLサーバ証明書 と 公開鍵 をクライアントに送付
2. クライアント側では、ブラウザに事前に搭載されているルート証明書（認証局が発行したSSLサーバ証明書であることを確認するための証明書）でSSLサーバ証明書を検証して信頼性を確認する。
3. クライアント側で「共通鍵」を生成し、SSLサーバー証明書の公開鍵で暗号化したものをWebサーバーに送る
4. サーバーでは暗号化された鍵を復元し、その後は共通鍵暗号方式で暗号化通信を行う 。

👉 安全性の高い「公開鍵暗号方式」で"共通の鍵"を共通し、処理速度が速い「共通鍵暗号方式」でデータの送受信を行うという「ハイブリッド暗号方式」を利用している。

👉 実際は、RSA の鍵交換において実際に交換されるのは共通鍵そのものではなく、プレマスターシークレットとよばれる乱数のデータやマスターシークレットを扱う事になる。

大事なのは SSLサーバー証明書

• SSLサーバー証明書のフォーマットは X.509（最新の仕様は RFC5280）
• サイトの主体者、発行者、主体者、主体者のサーバーの公開鍵、有効期限などの項目が存在する
• 発行者は認証局(CA)と呼ばれ、信頼性の確認のポイントとなるものである

サーバー証明書を発行するまでの流れは以下の通り。

１．SSL/TLSサーバーで秘密鍵を作成する ２．1で作成した秘密鍵をもとに「CSR(CertificateSigningRequest)」を作成し、認証局に提出する ３．認証局の審査を受ける ４．認証局から受け取ったサーバー証明書をSSL/TLSサーバーにインストールする（サーバー証明書には公開鍵が含まれており、サーバにインストールする際は一緒に秘密鍵もインストールされる）

TLS ハンドシェイクのシーケンス（TLS v1.2）

0. TCP 3way Handshake -> TCPの3ウェイハンドシェイク（SYN→SYN/ACK→ACK）を行い、TCPセッションを確立
1. Client Hello
2. Server Hello
3. (Server Certificate)
4. (Server Key Exchange)
5. (Certificate Request)
6. Server Hello Done
7. (Client Certificate)
8. Client Key Exchange
9. (Certificate Verify)
10. Change Cipher Spec
11. Finished
12. Change Cipher Spec
13. Finished
14. 暗号化通信開始

各シーケンスにおける詳細は以下の記事の解説がめちゃめちゃ分かりやすい。