httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？

# 課題

サイトをを立ち上げるときに当然のごとくSSL証明書をベンダーから購入して設置していたが、いざセキュリティ診断等でチェックしてもらうとSSLについての指摘を何件か受けてみた。なんでだろうと思いながらも、さらに最適なSSL設定は？と聞かれてそういえばあまり昔から手を入れたことなかったなと思い調べてみた

# SSL通信が確立するまでの概要フロー

SSL通信について再度おさらい
![ssl2.png](https://qiita-image-store.s3.amazonaws.com/0/8726/7badc3d2-d1da-8ee3-30da-48470a353d70.png "ssl2.png")


# Nginxを元にしたSSLの設定

nginxの[HTTPS サーバの設定](http://nginx.org/ja/docs/http/configuring_https_servers.html)を参考に、たった２行だけどSSLを考えてみる。書き方は違えどもapacheも概念は一緒のはず。

```Nginx
ssl_protocols        SSLv3 TLSv1;
ssl_ciphers          HIGH:!ADH:!MD5;
```

# SSLプロトコルの種類を確認

[wiki](http://ja.wikipedia.org/wiki/Transport_Layer_Security)よりプロトコルの種類を確認してみる。

|略称|正式名称|開発元|
|---|---|---|
|SSL|Secure Socket Layer|ネットスケープコミュニケーション|
|TLS|Transport Layer Security|IETF|

バージョン毎の概要を確認してみる。

|バージョン|安全性|概要|
|---|:---:|---|
|SSL1.0|✕|最初のSSLとして設計したが、設計レビューの時点でプロトコルの脆弱性が発見されたため破棄されている。|
|[SSL2.0](https://tools.ietf.org/html/rfc6176)|✕|SSL1.0の問題を修正して設計後、1994年にSSL2.0として発表。その後、いくつか脆弱性が発見されてSSL3.0が登場するが、未使用でもSSL2.0が有効な状態の場合に提示する最弱のアルゴリズムを使用させるダウングレード攻撃などを受ける可能性があるので、明示的に無効にする必要がある。|
|[SSL3.0](https://tools.ietf.org/html/rfc7568)|✕|SSL2.0の問題を修正して機能追加も行い1995年にSSL3.0として発表。ただ、古くなってきている。CVE-2014-3566で脆弱性が発生したため明示的に無効にする必要がある。|
|[TLS1.0](https://tools.ietf.org/html/rfc2246)|△|SSL3.0とTLS1.0の両者間には正確な互換性はないがほぼ同じ。CVE-2011-3389(BEAST)による一部脆弱性を含む。|
|[TLS1.1](https://tools.ietf.org/html/rfc4346)|△|TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。[PCIDSSv3.2](https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls)([Google翻訳](https://bit.ly/2qm7KR5))ではTLS1.1も非推奨になっている|
|[TLS1.2](https://tools.ietf.org/html/rfc5246)|◎|ハッシュのアルゴリズムにSHA-256が追加されたほか、ブロック暗号について、従来のCBCモードだけではなく、GCM、CCMといった認証付き暗号が利用可能となった。|
|[TLS1.3](https://tlswg.github.io/tls13-spec/)|◎|インターネット環境の変化とTLS1.2までの暗号化強度不足を改善するため2016年中に仕様化完了を目指している(らしい)。2018年8月に[RFC 8446](https://datatracker.ietf.org/doc/rfc8446/)になったようです

そのため、SSLv1 / SSLv2 / SSLv3 は脆弱性があるので、 **現時点で使用できるものはTLSv1以上**

# SSL_Ciphersについて調べてみる...

`HIGH:!ADH:!MD5;`と書いてはあるものの、「HIGHグループでADHとMD5を使わない」という読み方であってるのか？調べてみると[OpenSSL](https://www.openssl.org/docs/apps/ciphers.html)で確認出来るらしい

`$ openssl ciphers -v 'HIGH:!ADH:!MD5;'`


```bash:result
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
KRB5-DES-CBC3-SHA       SSLv3 Kx=KRB5     Au=KRB5 Enc=3DES(168) Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
```

なんかいっぱい出てきた

# 暗号方法の内容を１つ１つ確認

まずは１行目の `DHE-RSA-AES256-SHA　　      SSLv3 　Kx=DH　       Au=RSA　  Enc=AES(256)　  Mac=SHA1` を読み解いてみる。[このサイト](http://nzbget.net/Choosing_a_cipher)によると下記のようだ。

|Column|内容|原文|
|---|---|---|
|DHE-RSA-AES256-SHA|暗号化スイート|cipher suite name|
|kx|鍵交換をする時のアルゴリズム|the algorithm used for key exchange|
|Au|鍵認証のためのアルゴリズム|the algorithm for authentication|
|Enc|暗号化通信に使われる一括暗号化アルゴリズム|the bulk encryption algorithm|
|Mac|メッセージ認証符号|the message authentication code (MAC) algorithm|

いろいろアルゴリズムを使ってるのはわかったもののどこで使ってるんだ？

# それぞれどこで使ってるの？
![ssl_alg.png](https://qiita-image-store.s3.amazonaws.com/0/8726/732b01e4-4004-382c-97af-f59e9b4ac0d4.png "ssl_alg.png")

# 主な暗号化アルゴリズム

種類がたくさんありますが、一部集めてみました。

|アルゴリズム|用途|ブロック長|鍵長|概要|
|---|---|---|---|---|
|[RSA](http://ja.wikipedia.org/wiki/RSA%E6%9A%97%E5%8F%B7)|Au:公開鍵暗号[署名]||1024-4096 bit|[主流] 桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした公開鍵暗号の一つである|
|[DSA](http://ja.wikipedia.org/wiki/Digital_Signature_Algorithm)|Au:公開鍵暗号[署名]||1024bit|[まだ少ない?] OpensslでみるとDSSと表記されている。有限体上の離散対数問題の困難性を安全性の根拠としており、現仕様においては有効な攻撃方法が示されたことはないものの、理論上はいまだ署名としての最も高い安全性を満たすことが証明されていない。|
|[ECC](http://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9A%E6%9A%97%E5%8F%B7)|Au:公開鍵暗号[署名]|||[注目株] EC-DLPを解く準指数関数時間アルゴリズムがまだ見つかっていないため、それが見つかるまでの間は、[ベリサイン](http://www.atmarkit.co.jp/ait/articles/1303/21/news005.html)によると12分の1の鍵長で、現在主流のRSA 2048の1.5倍の強度を実現できるため同レベルの安全性をより短い鍵で実現でき、処理速度も速いことをメリットとして、ポストRSA暗号として注目されている。|
|[DH](https://www.ipa.go.jp/security/rfc/RFC2631JA.html)|Kx:公開鍵暗号[鍵交換]|||[主流] DHパラメータは証明書に書かれている物を使う。よって、static DHとも呼ばれる。|
|[ECDH](http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange)|Kx:公開鍵暗号[鍵交換]|||[注目株] Elliptic curve Diffie–Hellmanの略。楕円曲線上でDiffie-Hellman(DH)鍵共有を⾏う楕円DH(ECDH)⽅式。PFS(perfect forward secrecy)をサポートしていない。 |
|[ECDSA](http://en.wikipedia.org/wiki/Elliptic_Curve_DSA)|Kx:公開鍵暗号[鍵交換]|||[注目株] Elliptic Curve Digital Signature Algorithmの略。楕円曲線上でDigital Signature Algorithm(DSA)を実現する楕円DSA（ECDSA）⽅式。PFS(perfect forward secrecy)をサポートしていない。|
|[ECDHE](http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html)|Kx:公開鍵暗号[鍵交換]|||[注目株]  Ephemeral Elliptic curve Diffie–Hellmanの略。DHパラメータを通信時に動的に作成する。楕円曲線上でDiffie-Hellman(DH)鍵共有を⾏う楕円DH(ECDH)⽅式。EはEphemeral(一時的）を意味している。PFS(perfect forward secrecy)をサポートしている。 |
|[DES](http://en.wikipedia.org/wiki/Data_Encryption_Standard)|Enc:共通鍵暗号|64bit|56bit|[強度弱] 現代においては十分な強度とは言えなくなっています。並列処理可能なDES破り専用プロセッサも存在し、 資金さえ投入すれば数時間～数日というレベルで解読することができます。|
|[AES](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)|Enc:共通鍵暗号|128bit|128/192/256bit|[注目株] DESに代わる次世代の暗号標準。暗号強度、高速性に優れてます。|
|[RC4](http://en.wikipedia.org/wiki/RC4)|Enc:共通鍵暗号|可変長|ストリーム暗号|[脆弱性あり] RC4はストリーム暗号としては大変広く使われていますが、同時にいろんな脆弱性があることでも知られてきている。WEPやSSL/TLSで広く使われてますが、WEPが脆弱であることが広く知られているのに比べ、SSL/TLSでのRC4はそれほど恐れられていませんでした。|
|[MD5](http://en.wikipedia.org/wiki/MD5)|Mac:ハッシュ関数|||[脆弱性あり] 任意長メッセージから128ビットの一方向ハッシュ値を生成します。SLOTH攻撃(CVE-2015-7575)による影響があります。|
|[SHA-1](http://ja.wikipedia.org/wiki/SHA-1)|Mac:ハッシュ関数|||[脆弱性あり] 160ビットメッセージダイジェストアルゴリズム。SLOTH攻撃(CVE-2015-7575)による影響があります。|
|[SHA-2](https://jp.globalsign.com/sha256/)|Mac:ハッシュ関数|||[主流] 224ビット・256ビット・384ビット・512ビットのメッセージダイジェストアルゴリズム|
|[SHA-3](https://ja.wikipedia.org/wiki/SHA-3)|Mac:ハッシュ関数|||[次世代?]米国の国立標準技術研究所(NIST)は，2012年10月2日に次世代の暗号学的ハッシュ関数の標準を決めるSHA-3として Keccak を選定した。しかし、その後、SHA-2への有望な攻撃法は2015年8月現在発表されていないため結果としてSHA-2の代替の用意が重要ではなくなるなど、状況が変化している|


# 暗号化利用モード

[暗号化利用モード](http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation)とは、ブロック長よりも長いメッセージを暗号化するための方式。

|略称|名称|利用モード|概要|
|---|---|---|---|
|ECB|Electronic CodeBook|秘匿用|[強度弱]各ブロックを１つずつ暗号化処理をする。最もシンプルな方式
|[CBC](http://j-net21.smrj.go.jp/develop/digital/entry/001-20120229-01.html)|Cipher Block Chaining|秘匿用|[脆弱性あり]各平文のブロックは暗号化される前に、前の暗号化ブロックでXORすることを繰り返す。最初のブロックは暗号と無関係なIV(Initialization Vector)を使用して暗号化する。BEAST攻撃によりデータが復号化される可能性あり。
|CTR|CounTeR|秘匿用|[主流]IVではなくカウンターの値をインクリメントしつつブロック暗号処理したものに平文ブロックをXORする。|
|[CCM](http://en.wikipedia.org/wiki/CCM_mode)|Counter with CBC-MAC|認証用|TLS1.2で使用可能。カウンター (CTR)モードとCBC-MACモードを組み合わせたものであり、前者が暗号化に、後者が認証に用いられる。同一の鍵を暗号化と認証の双方に用いることができることができ、暗号化に用いられたカウンター値が認証で用いられる初期化ベクトルと衝突することがない|
|[GCM](http://en.wikipedia.org/wiki/Galois/Counter_Mode)|Galois/Counter Mode|認証用|[主流]TLS1.2で使用可能。GCMは認証付き暗号の一つであり、データ保護と認証（完全性確認）の双方に利用できる。遅延、オーバーヘッドが少ないことから、パケット化されたデータの保護に適している。|

# PFS(Perfect Forward Secrecy)について

[SSL/TLS & Perfect Forward Secrecy](http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html)

|名称|略称|概要|Kx|例|
|---|---|---|---|---|
|Without forward secrecy|-|認証と同じ公開暗号を使用した場合に、攻撃者が暗号化した通信を全部記録していたとすると、後に認証に使用していた秘密鍵が漏洩してしまうと復号化が出来てしまう。|FS・PFS以外|AES128-SHA|
|Forward Secrecy|FS|認証用の鍵と鍵交換用の鍵が異なるので、通信の漏洩の可能性が低くなります。RSA 2048bitと比べるとサーバへのCPU負荷が3.1倍程度に増加するようです。|DH / ECDH|DH-RSA-AES128-SHA|
|Perfect Forward Secrecy|PFS|FSに比べて、一定時間後に定期的に異なる鍵交換を行うため、より漏洩の可能性を低く出来ます。また、RSA 2048bitと比べてもサーバへのCPU負荷は微増のようです。|DHE / ECDHE|DHE-RSA-AES128-SHA|

# TLS証明書発行方法にも種類がある？

Googleのレポート[HTTPS encryption on the web](https://transparencyreport.google.com/https/overview?load_os_region=chrome-usage:1;series:page-load;groupby:os&lu=load_os_region)からも年々SSL利用者が増加しています。それに伴いなりすましによる被害も増加しているため所在確認などを強化した証明書発行があるようです。

|名称|審査内容|
|---|---|
|Extended Validation(EV)証明書|ドメイン所有者について認証局が実在証明を厳格に行なったのちに発行される|
|Organization Validation(OV)証明書|組織情報の審査を経てから発行される|
|Domain Validation(DV)証明書|ドメインの管理権限を元に発行される|

# 暗号化方法はたくさんあるけどナニを選べばいいの？

[SSL/TLS Deployment Best Practices](https://www.ssllabs.com/projects/best-practices/index.html) というのがある


> Use Secure Protocols
>
>   * SSL v2 is insecure and must not be used.
>
>   * SSL v3 is very old and obsolete. Because it lacks some key features and because virtually all clients support TLS 1.0 and better, you should not support SSL v3 unless you have a very good reason.
>
>   * TLS v1.0 is largely still secure; we do not know of major security ﬂaws when they are used for protocols other than HTTP. When used with HTTP, it can almost be made secure with careful conﬁguration.
>   * TLS v1.1 and v1.2 are without known security issues.

***SSLプロトコル***

* SSLv2は使用しない
* SSLv3は非常に古く廃止されています。いくつかの主要機能が不足しており、事実上すべてのクライアントがTLS1.0をサポートしている。そのため、よっぽど良い理由がない限りはSSLv3をサポートするべきではない
* TLS v1.0の大部分はまだ安全です。HTTPを使用するときに、キチンと設定をすればセキュアに出来る
* TLS v1.1 とTLS v1.2はセキュリティに関する問題が発見されていない

> Use Secure Cipher Suites
>
>   * Anonymous Difﬁe-Hellman (ADH) suites do not provide authentication.
>
>   * NULL cipher suites provide no encryption.
>
>   * Export key exchange suites use authentication that can easily be broken.
>
>   * Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken.
>
>   * RC4 is weaker than previously thought. You should remove support for this cipher in the near future.
>
>   * 3DES provides only 108 bits of security (or 112, depending on the source), which is below the
recommended minimum of 128 bits. You should remove support for this cipher in the near future.

***暗号化スイート***

* ADH(Anonymous Diffie-Hellman)は認証機能を提供していない
* Null暗号化スイートは暗号化しない
* Export鍵交換は簡単に解除される認証機能を使っている
* 特に40, 56bitの弱い暗号スイートは簡単に暗号化を解除される
* RC4は以前考えられてたよりも弱い。近い将来、サポート対象外にするべき。
* 3DESは108または112bitsしか提供していない。最低でも128bits以上が推奨されるので、近い将来サポート対象外にするべき。

# セキュリティに余念のない有名企業はどうしているのか？

[Netcraft](http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html)が2013年9月に調査した情報によると下記のような対応状況です。2014年3月にwww.facebook.comを確認したところ、ECDHE-RSA-AES128-GCM-SHAになっていたので各社変わっている可能性はありそうです。

![ssl_list.png](https://qiita-image-store.s3.amazonaws.com/0/8726/091078bb-ba66-66c4-6e66-71bc38ef3771.png "ssl_list.png")

# 最近発生した主なSSLの脆弱性

|名称|CVE|発生日|概要|対応概要|
|---|---|---|---|---|
|[Beast](http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html)|[CVE-2011-3389](http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389)|2011/9/6|CBC mode脆弱性||
|[TLS heartbleed](http://d.hatena.ne.jp/Kango/20140410/1397139257)|[CVE-2014-0160](https://www.openssl.org/news/secadv_20140407.txt)|2014/4/7|TLS脆弱性|opensslをupdate|
|[CCS injection](http://d.hatena.ne.jp/Kango/touch/20140605/1401978480)|[CVE-2014-0224](https://www.openssl.org/news/secadv_20140605.txt)|2014/6/5|CCS脆弱性|opensslをupdate|
|[POODLE](http://googleonlinesecurity.blogspot.jp/2014/10/this-poodle-bites-exploiting-ssl-30.html)|[CVE-2014-3566](https://access.redhat.com/security/cve/CVE-2014-3566)|2014/10/14|SSLv3脆弱性|SSLv3を無効にする|
|[複数脆弱性](https://jvn.jp/vu/JVNVU95877131/index.html)|[CVE-2015-0291等(全14個)](https://www.openssl.org/news/secadv_20150319.txt)|2015/3/19|複数脆弱性対応|opensslをupdate|
|[Altチェイン証明書偽造](http://d.hatena.ne.jp/jovi0608/20150710/1436521488)|[CVE-2015-1793](https://mta.openssl.org/pipermail/openssl-announce/2015-July/000037.html)|2015/7/6|証明書偽造|opensslをupdate|
|[SLOTH攻撃](http://d.hatena.ne.jp/jovi0608/20160113/1452649563)|[CVE-2015-7575](https://access.redhat.com/articles/2112261)|2016/1/8|TLS脆弱性(ハッシュ衝突)|[MD5とSHA-1を使用しない](https://nakedsecurity.sophos.com/2016/01/08/the-sloth-attacks-why-laziness-about-cryptography-puts-security-at-risk/)|
|[DROWN](http://d.hatena.ne.jp/Kango/20160301/1456849603)|[CVE-2016-0800](https://mta.openssl.org/pipermail/openssl-announce/2016-March/000066.html)|2016/3/1|クロスプロトコル攻撃|SSLv2を無効にする|
|[SWEET32](https://sweet32.info/)|[CVE-2016-2183](https://access.redhat.com/security/cve/cve-2016-2183)|2016/8/24|[誕生日攻撃](https://ja.wikipedia.org/wiki/%E8%AA%95%E7%94%9F%E6%97%A5%E6%94%BB%E6%92%83)|3DESなど64bitsブロック暗号の停止|
|[SHAttered](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)|[CVE-2005-4900](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4900)|2017/2/23|[ハッシュ衝突攻撃](https://shattered.io/)|SHA-256, SHA-3への移行|
|[バッファオーバーラン](https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html)|[CVE-2022-3602](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3602)|2022/10/25|[X.509証明書の検証処理を通じてバッファオーバーフロー](https://qiita.com/SnykSec/items/8c1996fbb4ab14dec484)|opensslをupdate|

# 結局今のところどのような設定が良さそうか

最初に記載したNginxの公式にサイトに書いてあったよりも、脆弱性があるまたは弱い暗号化を除いて、明示的に使用する暗号化スイートを設定するのが良さそう。 ***あくまで例なのでサイトに合ったものを設定してください。***

* 最新版のopenssl [CVE-2014-0160 / CVE-2014-0224]
* 128bit以上
* Enc: AES
* Au: RSA
* Kx: DH/ECDH/ECDHE (FS以上)
* 暗号化利用モード: GCM
* SSLv3以下を無効 [CVE-2014-3566]

```Nginx
ssl on;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:
            DH+AESGCM:ECDH+AES256:DH+AES256:
            ECDH+AES128:DH+AES:
            !EXPORT:!DES:!3DES:!MD5:!DSS;
```

### 対応暗号スイートを確認

```
$openssl ciphers -v 'ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!EXPORT:!DES:!3DES:!MD5:!DSS'
```

ローカルだとこのような感じで出てきた

```bash:result
ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH       Au=RSA   Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH       Au=RSA   Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384     TLSv1.2 Kx=DH         Au=RSA   Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256     TLSv1.2 Kx=DH         Au=RSA   Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384       TLSv1.2 Kx=ECDH       Au=RSA   Enc=AES(256)    Mac=SHA384
ECDHE-ECDSA-AES256-SHA384     TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AES(256)    Mac=SHA384
ECDHE-RSA-AES256-SHA          SSLv3   Kx=ECDH       Au=RSA   Enc=AES(256)    Mac=SHA1
ECDHE-ECDSA-AES256-SHA        SSLv3   Kx=ECDH       Au=ECDSA Enc=AES(256)    Mac=SHA1
ECDH-RSA-AES256-SHA384        TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AES(256)    Mac=SHA384
ECDH-ECDSA-AES256-SHA384      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AES(256)    Mac=SHA384
ECDH-RSA-AES256-SHA           SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=AES(256)    Mac=SHA1
ECDH-ECDSA-AES256-SHA         SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=AES(256)    Mac=SHA1
DHE-RSA-AES256-SHA256         TLSv1.2 Kx=DH         Au=RSA   Enc=AES(256)    Mac=SHA256
DHE-RSA-AES256-SHA            SSLv3   Kx=DH         Au=RSA   Enc=AES(256)    Mac=SHA1
ECDHE-RSA-AES128-SHA256       TLSv1.2 Kx=ECDH       Au=RSA   Enc=AES(128)    Mac=SHA256
ECDHE-ECDSA-AES128-SHA256     TLSv1.2 Kx=ECDH       Au=ECDSA Enc=AES(128)    Mac=SHA256
ECDHE-RSA-AES128-SHA          SSLv3   Kx=ECDH       Au=RSA   Enc=AES(128)    Mac=SHA1
ECDHE-ECDSA-AES128-SHA        SSLv3   Kx=ECDH       Au=ECDSA Enc=AES(128)    Mac=SHA1
ECDH-RSA-AES128-SHA256        TLSv1.2 Kx=ECDH/RSA   Au=ECDH  Enc=AES(128)    Mac=SHA256
ECDH-ECDSA-AES128-SHA256      TLSv1.2 Kx=ECDH/ECDSA Au=ECDH  Enc=AES(128)    Mac=SHA256
ECDH-RSA-AES128-SHA           SSLv3   Kx=ECDH/RSA   Au=ECDH  Enc=AES(128)    Mac=SHA1
ECDH-ECDSA-AES128-SHA         SSLv3   Kx=ECDH/ECDSA Au=ECDH  Enc=AES(128)    Mac=SHA1
DHE-RSA-AES128-SHA256         TLSv1.2 Kx=DH         Au=RSA   Enc=AES(128)    Mac=SHA256
DHE-RSA-AES128-SHA            SSLv3   Kx=DH         Au=RSA   Enc=AES(128)    Mac=SHA1
```

Apacheの場合はこのような感じになると思う(Apache 2.4以降ではSSLv2が除外)

```Apache
SSLProtocol ALL -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE+RSAGCM:ECDH+AESGCM:
               DH+AESGCM:ECDH+AES256:DH+AES256:
               ECDH+AES128:DH+AES:
               !EXPORT:!DES:!3DES:!MD5:!DSS
```

### 設定を生成してくれるサービスもある!

* [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)
* [nginxconfig](https://nginxconfig.io)

#SSLがキチンと設定されているかテストするには

[SSL Server Test](https://www.ssllabs.com/ssltest/)または[GlobalSign SSL チェック](https://sslcheck.globalsign.com/ja)で暗号化強度やブラウザのサポート具合などもチェックできます。また、コンソールでチェックするのに[testssl.sh: Testing TLS/SSL encryption](https://testssl.sh/)も便利です。
簡易的には下記でもSSLの状態が確認出来る

```
$ openssl s_client -host [URL/HOST NAME] -port 443 -ssl3
```

# まとめ

たかが２行設定するのにここまで色々あるとは...まだ関連する技術がありそうなので日々精進が必要そうです。ただ、今回わかったことは単にコピペで設定すると、かなりのセキュリティホールになりそうなのでちゃんとテストして設定しようと。

# 参考資料
> 電子政府における調達のために参照すべき暗号のリスト（ＣＲＹＰＴＲＥＣ暗号リスト） 
http://www.cryptrec.go.jp/list.html
http://search.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000097652

> Hardening Your Web Server’s SSL Ciphers
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/


> IE使うならVista以降が無難、SSLの暗号強度調査結果から
http://internet.watch.impress.co.jp/docs/event/iw2009/20091126_331592.html

> SSL/TLSでBEASTを恐れてRC4を優先するのは危ない
http://tetsutalow.hateblo.jp/entry/2013/04/02/053927

> HTTP/2 RFC7540
https://tex2e.github.io/rfc-translater/html/rfc7540.html

> HTTP/3 RFC9114
https://datatracker.ietf.org/doc/rfc9114/