TLSについて
日時：
TLSについて．
- TLSはプロトコル．以下の役割がある．
- 通信相手が所望のものであるか確認する（真正性）
- 通信がの暗号化（機密性）
- 通信の改ざん検知（完全性）
- TLS1.3が最新．TLS1.2も使われている．
- TLS1.1，TLS1.0は安全性に問題があり，さらにその前のSSLは脆弱性があるため使わない．
続いてそれに関わってくる公開鍵基盤（PKI）について．
- 通信相手のサーバの認証のために，サーバの公開鍵が必要．SSHで遠隔ログインしたときのように別の手段（サーバの管理者に直接聞くなど）で直接サーバの公開鍵をもらうのがよいが，常にそうはいかない上に，自動化できない．
- 通信相手の公開鍵が本物かどうか確認する仕組みが欲しい．
- その仕組みで代表的なものが信頼の輪と公開鍵基盤（PKI）．
- PKIの仕組みをサーバ認証とサーバ証明書を例に説明．
- サーバに依頼された認証局Aが，サーバSの証明書（サーバ証明書）を発行する．証明書にはサーバの公開鍵と，それを含んだデータから作られた署名が含まれている．この正しさは，認証局Aが公開するAの公開鍵によってだれでも検証できる．
- 認証局Aの公開鍵が本当のものかを保証するために，別の認証局Bが作った認証局Aの証明書が必要．認証局Bは認証局Aの公開鍵とそれから認証局Bの秘密鍵で作った署名を含む認証局Aの証明書を公開し，その証明書の正しさを認証局Bの公開鍵を用いて，誰でも検証できるようにする．
- この連鎖が，誰からも保証されない認証局（ルート認証局）で終わる．ルート認証局はその公開鍵とそれから自分の秘密鍵で作った署名を含んだ自分自身の証明書（自己署名証明書）を公開する．
- ルート認証局自身の証明書は，利用者があらかじめ何かしらの手段で入手する．通常はブラウザにルート認証局の情報とその証明書が最初から入っている．
DV証明書
- 申請者がそのドメインの管理者であることを確認することで発行される証明書．
- 今回はその証明書を自動的に発行してくれる認証局Let’s Encryptを利用する．
- 自動化が故に大変な事がときどきおきているらしい．
DV証明書を始め，アクセスしているサイトのサーバ証明書は大抵のブラウザからだと鍵マークをクリックすれば見られる．
TLS1.3の概要
フルハンドシェイクというサーバと初めて通信する際に行われるものの基本的な流れについて．
（参考）RFC8446 2. Protocol OverviewのFigure 1を引用．
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.
Figure 1: Message Flow for Full TLS Handshake
要点（というより自分の感想）
- (EC)DHE鍵交換の中間者攻撃にはやり取りしたメッセージ全体から作る署名を用いることで対策できている．
- メッセージに依存しないデータに署名する場合，通過させれば中間者攻撃は依然出来る場合もある．
- 署名するデータにClientHelloメッセージとServerHelloメッセージのランダムな値が含まれているため，署名の流用を防げている．
- 実際に生成する鍵にも同じことが言える．ただ，もとからE(ephemeral)な(EC)DHE鍵交換だからその時点で前方秘匿性は確保されているといってよい？
主にやる三つのこと
- 通信相手の認証
- 暗号アルゴリズムの決定
- 暗号化に用いる鍵の生成
ClientHelloメッセージ
クライアントが初めて接続するサーバに対して最初に必ず送るメッセージ．以下の情報を含む（重要なものだけ）．
- 使用可能な暗号スイート（用いるアルゴリズムの組み合わせ）のリスト．
- 使用可能なTLSのバージョン．
- 使用可能な鍵合意・署名・共通鍵・ハッシュアルゴリズムの方式とそれに必要な情報．
- クライアント側で生成した他者による予測が不可能な32バイトの疑似乱数．
ServerHelloメッセージ
サーバがClientHelloメッセージを受信し，クライアントに指定された方式のどれかに基づいて通信が可能だと判断した場合，クライアント側にServerHelloメッセージを返す．以下の情報を含む（重要なものだけ）．
- 使用する暗号スイート．
- 使用するTLSのバージョン．
- 使用する鍵合意・署名・共通鍵・ハッシュアルゴリズムの方式とそれに必要な情報．
- サーバ側でクライアントのものとは全く別に生成した他者による予測が不可能な32バイトの疑似乱数．
ServerHelloを送った後，ClientHelloからServerHelloまでのハンドシェイクメッセージ全体とClientHelloで得た情報を用いて作られるserver_handshake_traffic_secretから導出された鍵を用いてサーバからのメッセージは暗号化される．
ServerHelloを受け取った後のクライアント側も同様．ただし，client_handshake_traffic_secretはserver_handshake_traffic_secretとは値が異なる．
EncryptedExtensionsメッセージ
サーバがServerHelloメッセージを送った後すぐクライアントに送るメッセージ．暗号パラメータの決定には関係ないが，証明書に付随していない情報を送る．
CertificateRequestメッセージ
サーバがクライアント認証を求める場合，クライアント側に送るメッセージ．求めない場合は省略される．
Certificateメッセージ
クライアントまたはサーバ側が認証のための証明書を送るメッセージ．サーバ側が証明書によって認証されていない場合や，サーバがCertificateRequestを送らなかった場合は，それぞれサーバ側，クライアント側でのこのメッセージは省略される．証明書が中間認証局によって署名されている場合は，その中間認証局群の一連の証明書も含めて送る．
CertificateVerifyメッセージ
CertificateVerifyメッセージ前までのハンドシェイクメッセージ全体を用いて作られるデータに秘密鍵を用いて署名し，相手に送る．受け取った側は，Certificateメッセージに含まれる証明書の正しさを所持している認証局の証明書を用いて確認し，格納された公開鍵を用いて，CertificateVerifyメッセージでの署名を検証する．
Finishedメッセージ
一連の手続きが成功したかどうかの検証データを送る．送られた側はそれを検証する．検証が上手くいかなかった場合は接続を切る．
鍵導出
server_handshake_traffic_secretのときと同様，サーバ側から送るアプリケーションデータを暗号化するアルゴリズムで必要な鍵と初期値IV（アルゴリズムの中で必要になる値）はClientHelloからサーバのFinishedまでのハンドシェイクメッセージ全体を用いて作られる．クライアント側も同様．クライアント側からの送信で用いる鍵と初期値IVはサーバ側のそれとは値が異なる．
TLS1.3では暗号化アルゴリズムに，暗号化のみならずメッセージの改ざん検知の機能も持っているAEAD方式が取られており，メッセージの完全性も確保できる．