KaedeBlogにTLSv1.3とOCSP Staplingを対応しましたので解説や確認方法を含め記載したいと思います。
TLSv1.3
TLSv1.3は2018年にRFC 8446で標準化されたTLSプロトコルであり、2023年時点1.3が最新バージョンである。
暗号手続き方法を見直したり、古い暗号アルゴリズムを廃止などTLSv1.2と互換性がないです。
そのため、IoTなどTLSv1.2とTLSv1.3を両立させる必要がある場合は苦労することもあり、AWSのALBは2023年3月、IoT Coreは2023年5月19日にTLSv1.3とつい先日対応したばっかり。
IETFのブログでもTLSv1.3について記述されているので参考にどうぞ：IETF｜TLS1.3
Nginxでの対応
Nginxでは1.13.0（2017年4月）から対応したみたいです。
OpenSSLのバージョンによってはTLSv1.3がONにならない場合がありますが、下記記述を行うだけで簡単に対応することができます。
server {
listen 443 ssl default_server;
listen [::]:443 ssl ;
ssl_protocols TLSv1.3 TLSv1.2; #TLSv1.3を追記
・
・
・
}TLSv1.3の検証
Chromeで確認する方法
Chromeの場合、F12でDevToolを開き「Security」タブにあるConnectionで確認できます。
OpenSSLで確認する方法
OpenSSLの場合、s_clientより確認することができます。
※TLSv1.3はOpenSSL 1.1.1に対応したため、RHEL7などOpenSSL 1.1.1未満を使用している場合は確認できないので注意
# openssl version
OpenSSL 1.1.1f 31 Mar 2020
## TLSｖ1.3を指定し、成功すればTLSv1.3対応していることになる
# openssl s_client -connect kaede.jp:443 -tls1_3 -status
CONNECTED(00000003)
【証明書情報など】
・
・
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
・
・
## TLSv1.3に対応していない場合は通信に失敗する
# openssl s_client -connect kaede.jp:443 -tls1_3 -status
CONNECTED(00000003)
139901291615552:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1543:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 241 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---OCSP Stapling
OCSP StaplingはTLSの拡張機能としてRFC 6961として標準化されており、TLSv1.3のRFC 8446で統合されてます。
クライアントがOCSPレスポンダサーバへサーバ証明書やクライアント証明書など証明書が失効されていないか？をOCSP通信にて確認します。
これだと、クライアントのIPアドレスがOCSPレスポンダサーバに教えてしまうことになるのと、大量クライアントからOCSPレスポンダサーバに通信を行うことになるため、OCSPレスポンダサーバが過負荷になることが懸念されました。
そのため、クライアントと通信するWebサーバが代理でOCSPレスポンダサーバに証明書失効確認を行い、TLS通信上にOCSP情報を記載（Stapling）してあげる機能がOCSP Staplingとなります。
【OCSP通信】
①[クライアント]←[Webサーバ] ：Webサーバがサーバ証明書を取得
②[クライアント]→[OCSPレスポンダサーバ] ：①で取得したWebサーバのサーバ証明書が失効されていないか確認
【OCSP Stapling】
⓪[Webサーバ]→[OCSPレスポンダサーバ] ：Webサーバのサーバ証明書が失効されていないか確認（事前または通信時に確認）
①[クライアント]←[Webサーバ]：Webサーバがサーバ証明書を取得（OCSP情報を記載して送信する）
OCSP Staplingについては「まさるの勉強部屋」さんが公開している「【#28 情報処理安全確保支援士】OCSPステープリング」がわかりやすいです。
OCSP Stapling V1とOCSP Stapling V2の違い
OCSP Staplingには大きく２つの確認方法があります。ここでは仮にV1とV2と記載してます。
OCSP Stapling V1（RFC 6066）では1つの証明書しかステータス要求を行えませんでした。
そのため、TLSv1.2でOCSP Stapling V2（RFC 6961）で１つのOCSPレスポンダで複数証明書のステータス要求を行えるようになりました。
TLSv1.3では複数のOCSPレスポンダに対し、証明書のステータス要求を行えるようなりました。
そのため、OCSP Stapling V1（RFC 6961）は廃止としOCSP Stapling V2（RFC 6066）のみとなりました。
TLSv1.2とTLSv1.3ではOCSPの確認方法が違う場合があるので注意ですね。
参考：OCSP Stapling
参考：WOLFSSLのOCSPサポート
Nginxでの対応
Nginxでは1.3.7（2012年10月）から対応してます。
設定方法も簡単です。
OCSPレスポンダにアクセスするためにはDNSサーバへ名前解決が必要であるため、必要に応じてDNSサーバを設定してください。
server {
listen 443 ssl default_server;
listen [::]:443 ssl ;
ssl_protocols TLSv1.3 TLSv1.2; #TLSv1.3を追記
#OCSP Staplingの有効化
ssl_stapling on;
ssl_stapling_verify on;
#必要に応じてリゾルバの設定
# resolver ***.***.***.*** valid=300s;
・
・
・
}OpenSSLで確認する方法
OpenSSLの場合、s_clientより確認することができます。
### OCSP Stapling情報がない場合「OCSP response: no response sent」と返却される。
# openssl s_client -connect kaede.jp:443 -status
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.kaede.jp
verify return:1
OCSP response: no response sent
・
・
・
### OCSP Stapling情報がある場合「OCSP Response Data:」と証明書ステータス情報が送信される。
openssl s_client -connect kaede.jp:443 -status
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.kaede.jp
verify return:1
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = R3
Produced At: May 26 23:32:00 2023 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6
Serial Number: 039AB94D4BF3B01B43E52C039FA21818ADEB
Cert Status: good
This Update: May 26 23:00:00 2023 GMT
Next Update: Jun 2 22:59:58 2023 GMT
Signature Algorithm: sha256WithRSAEncryption
8e:d9:8a:e3:8f:02:82:6f:25:d6:17:84:13:33:7a:f8:01:f5:
28:10:1d:43:b5:b1:f8:9f:d3:fe:57:5f:bb:a7:fe:69:39:1c:
53:72:2c:a9:39:3d:93:e7:26:a8:38:0a:15:00:cd:30:35:6a:
40:ed:b6:3d:66:d2:ef:f9:c0:84:ec:83:03:af:ee:5b:c2:f2:
ec:40:2c:9f:5d:f7:b4:08:2a:89:00:37:d8:fc:1b:b7:c7:cd:
e6:62:99:e3:91:5c:51:b6:dc:45:45:91:fe:90:11:60:df:46:
9f:e0:e3:fc:84:61:20:bb:4f:80:e3:bb:c0:39:96:82:78:74:
13:3e:5a:eb:54:9a:58:d2:d1:34:38:d6:00:35:f1:d1:96:75:
a1:a6:c1:59:48:cd:aa:68:0b:b1:ce:4c:5c:e2:12:cd:66:b8:
cf:cd:78:72:b5:54:2e:4a:a9:7b:ca:f0:09:54:dd:cf:56:35:
82:b6:dc:0b:cf:db:40:5a:60:be:df:f0:93:83:2e:99:2f:a4:
d2:35:71:8e:54:b0:b4:cd:7f:cd:77:21:05:c4:5b:04:24:3e:
df:1c:57:6d:e1:eb:c5:a8:ad:7d:19:a9:41:7a:e0:16:39:2f:
bd:08:7e:43:53:ad:b5:8b:ae:b6:d6:6f:4b:f2:c2:8d:44:7e:
88:ea:9b:53
======================================WireSharkで確認した場合
TLS通信開始時にClient Helloにstatus_requestを付与している場合、Certificate Statusで応答されるようです。
TLSv1.2ではパケットキャプチャで確認できますが、TLSv1.3ではCerticate部分が暗号化されるため、セッションキーが必要になる点注意
