moz://a SSL Config Generator
mozillaが推奨するTLSサーバ設定を久々に更新したので主な注意点を確認。
原則2019/7時点のInteemdiate configについて。
TLSv1.2 TLSv1.3
だいぶ前からTLS1.0/1.1を完全にドロップしている。
古いAndroid4.3、IE10やJava7はハンドシェイク時点で切り捨てられる。
CBCのドロップ
CBCをドロップしてGCMとCHACHA20に限定された。CCMはまだ入っていない。
これにより、Safari8とそれ以前や、Windows Phone8.1との互換性が失われる。
正確にはECDSA-GCMで接続できるはずだが、現状証明書はほぼRSAなので選択されない。
Let's encryptなどECDSA対応したCAから別途証明書を取得する必要があり、またRSAを維持しようとすれば複数証明書をサポートするサーバ実装(nginx 1.15など)が必要。
openssl cipherに明示指定しなくても、TLSv1.3を選択した時点でTLSv1.3で導入されたKx/Au=Anyな3つのcipherは選択される。
ssl_prefer_server_ciphers off
以前のconfigでは3des/rc4など比較的安全でないcipherを含めている古いブラウザを想定していたため、優先順はサーバ指定で回避していた。
サポート対象のブラウザが絞られ、サポートcipherがすべて問題の無い妥当な順序に改善されたため優先順指定をする必要はなくなった。クライアント側で最も性能の出るものを使うことができる。
サーバの命令セットで性能向上するAESGCMを優先したければonでも構わないが、その場合は指定順序を管理する必要がある。
RFC 7919 ffdhe2048
Ephemeral DH用のパラメータにRFC 7919で推奨される既知のパラメータを使用する。
https://qiita.com/n-i-e/items/fac121aa5b2a3d16a632
1024bitなど弱いパラメータを使うことは避けるべきとされていたが、現状破れていないと考えられる2048bitなら共通であること自体に問題は無い。
むしろ、生成手順がわかっていて安全性下限を評価できる既知パラメータを使うほうが、安全性が評価できないランダムパラメータに依存するよりも望ましいということだろう。
また、将来既知のパラメータがそのサイズ（推奨例では2048bit）で安全でなくなったと考えられる場合、実装側でそのサイズのDHパラメータは拒否されるかDHが無効化され、ランダム生成であろうとなかろうとビット数を増やすかECに移行する必要がある。結局移行が必要となるのは変わらない。
実装のサポートが必要になるが、TLSハンドシェイクのECサポート曲線を示すelliptic_curves拡張と同様に、クライアントが安全と考える既知のDHパラメータを申告することで、DHパラメータに関する互換性問題を回避できる。複数のDHパラメータから合意可能なものを選択するといったことも可能になる。
ブラウザが対応するよりDHが廃止されてECDHへ完全移行するほうが早そう……。
個人的にセキュリティレベルがだいたい対称鍵128bit相当なECDH secp257あたりと同じffdhe3072にしてしまいたいところ。
そうするとDH<=2048bitまで対応なjava6あたりが死ぬのでold config