TLSにおける証明書チェーンを圧縮する拡張仕様 (RFC 8879)

TLS internet-draft

2020/12/02追記 RFC 8879 とになったので、記事を書き直しました
asnokaze.hatenablog.com

GoogleとCloudflareの方による「Transport Layer Security (TLS) Certificate Compression」という、証明書チェーンの圧縮を行う拡張仕様の提案が出ています。


TLSハンドシェイクの大部分は証明書が占めているらしく、サーバ側から送る証明書チェーンをgzipかbrotliで圧縮できるようにする拡張仕様です。


証明書の圧縮についてはGoogle版QUICでは行っており、TLS1.3で圧縮をサポートするかという議論が昨年末にML上でありました( https://www.ietf.org/mail-archive/web/tls/current/msg22065.html )。


複雑性に見合う効果があるかは分からないが、TLS1.3だけに限る必要はないのではないかという意見が出ていたようです。


IETF版QUICにも証明書の圧縮機能が盛り込まれるかもしれませんが、この拡張を取り込む流れになるのかは分からないです。


QUICはUDPですので、サーバ側からの転送量を削減するのはAMP攻撃対策として大事なのではないかと思います。

TLS Certificate Compression

クライアントは証明書の圧縮に対応している場合、ClientHello内でcompress_server_certificates拡張を使って対応してる圧縮アルゴリズムのリストをサーバに送信します。

       enum {
           zlib(0),
           brotli(1),
           (255)
       } CertificateCompressionAlgorithm;

       struct {
           CertificateCompressionAlgorithm algorithms<1..2^8>;
       } CertificateCompressionAlgorithms;


サーバはクライアントが提示したアルゴリズムに対応していた場合、ServerHelloで同じようにどのアルゴリズムを選択したかを返答します。


ServerHelloで使用するアルゴリズムを通知した場合、Certificateメッセージは以下のように圧縮前の長さと圧縮された証明から構成されます。

       struct {
            uint24 uncompressed_length;
            opaque compressed_certificate_message<1..2^24-1>;
       } Certificate;


server_certificate_type 拡張[RFC7250]の場合も、そのメッセージが圧縮されます。cached_info拡張[RFC7924] とは併用できません。


復号されたあとは、Certificateメッセージは圧縮がなかったようにそのまま処理されます。