サーバー コンピュータ セキュリティ 暗号化

TLSv1.3とOCSP Stapling に対応しました

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

## TLSv1.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には大きく2つの確認方法があります。ここでは仮にV1とV2と記載してます。

OCSP Stapling V1(RFC 6066)では1つの証明書しかステータス要求を行えませんでした。
そのため、TLSv1.2でOCSP Stapling V2(RFC 6961)で1つの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部分が暗号化されるため、セッションキーが必要になる点注意

-サーバー, コンピュータ, セキュリティ, 暗号化
-, , ,