コピペでssl_ciphers(暗号化スイート)の指定をやってたけど、もうちょっと調べてみた

tapira.hatenablog.com

SSL Server Testで A+ 判定を得るために、Generate Mozilla Security Recommended Web Server Configuration Files で生成した設定を一部利用しています。その中でも特に目につくのが↓のなっがいやつでした。

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';

そもそも暗号化スイートとは？

鍵交換方式 & 鍵認証のアルゴリズム & 共通鍵暗号アルゴリズム & 利用するハッシュ関数 を組み合わせたものを、 暗号化スイート と呼ぶそうです。

ssl_ciphersで先頭にきている一番のおすすめ(?) ECDHE-RSA-AES128-GCM-SHA256 を例にとってみます。

鍵交換方式(Kx)に ECDHE(楕円曲線ディフィー・ヘルマン鍵共有 - Wikipedia - Elliptic curve Diffie–Hellman key exchange)を使う
Kxは「安全でない経路で結ばれたサーバとクライアント間で共通鍵を安全に交換する」という目的を達するための仕組み。 公開鍵暗号の鍵交換を担う
サーバ認証のアルゴリズム(Au)にRSA 実際に通信する相手が、証明書の持ち主か認証するための仕組み。 公開鍵暗号の署名を担う
暗号化の方法(Enc)に AES&GCM
共通鍵を使用して暗号化通信する際の方式。 共通鍵を交換し終わったあと実際に情報をやり取りする際の暗号化・復号化を担う
ハッシュアルゴリズム(Mac)に SHA256

で、いいのかな。KxとAuの役割の違いがよくわからんくなった。

結論

最新の 鍵交換方式 & 鍵認証のアルゴリズム & 共通鍵暗号アルゴリズム & 利用するハッシュ関数 を全部追っかけとかないといこうとすると辛いなーと思った。
何も考えずにコピペしない、という前提のもと Generate Mozilla Security Recommended Web Server Configuration Files などを参考に、内容を理解し、自身の環境に適用できるか検討したうえで選択する、というのが現実的なところか…

ちなみに

ssl_ciphers で完璧なものを指定しておけば安心！というわけではない(最近おしえてもらった)

ssl_prefer_server_ciphers on; でサーバ側の暗号化スイート設定を優先するようにしておかないと、クライアント側の設定が利用されて辛い
ssl_session_tickets off; デフォは有効なので、使わないのであれば明示的に off にする。(クラスタ構成にする場合は、複数台のnginxでsession cacheを共有するため有効にし、定期的にkeyの更新を行わせる必要がある。nginx.conf ssl_session_ticket_key /etc/nginx/ticket.key; とファイルを明示し、cronなどで openssl rand 48 > /etc/nginx/tickets.key で定期更新し、各nginxで同じものを使う。
ssl_session_timeout 5m; 有効期限が短ければ短いほど、安全なはず。サーバ負荷と相談しつつ設定
nginx外のそもそものサーバ設定。ミドルウェアの設定を頑張ってもfirewallが全空きでした！じゃ辛い