おたくのサービスとのhttps通信、大丈夫？と聞かれた時の返事

# TL;DR
タイトルのまんまです。

[Symantec社が提供しているSSL Certification Checker](https://cryptoreport.websecurity.symantec.com/checker/)や[The Qualys SSL LabsのSSL Server Test](https://globalsign.ssllabs.com/)を使用してドメインのhttps通信の状態をチェックをすると、Protocol: TLS1.0が有効になっているケースがほとんどかなと思います。
その場合、BEAST脆弱性を突かれる可能性があるよーと合わせて指摘されますが、「攻撃の実現可能性が低いので問題ない」ということを、周囲の関係者にさらっと説明することになります。
なぜ問題が無いのかをよく忘れてしまい、調べなおすのも効率が悪いので現状確認方法も含めてメモ。

----
当ポストには、

　　BEAST脆弱性とは何か？

などは含まれません。


詳細を確認したい方は、

- NICT/IPAさんの[CRYPTREC 暗号技術ガイドライン(SSL/TLS における近年の攻撃への対応)](http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf)
- ["我々はどのようにして安全なHTTPS通信を提供すれば良いか"](https://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92#beast-cve-2011-3389)記事中のBEASTについての説明

あたりの解説記事から掘りさげていただければと。

# 現状確認
SymantecさんたちがSSL Certification Checkerを提供してくれている。
https://cryptoreport.websecurity.symantec.com/checker/

対象ドメインを入力して check ボタンを押せば、対象ドメインにセットされているSSL証明書の状態をレポートしてくれます。

例えばwww.amazon.co.jp。
<img width="335" alt="Screen Shot 2017-11-02 at 20.57.09.png" src="https://qiita-image-store.s3.amazonaws.com/0/14859/16a828d3-f7ad-1596-6802-281911c6a247.png">

# 最低限見ておくポイント

- WARNINGなどが出ていないか？
    - 出ている場合は、"More information"に対応方法が記載されているので対応しちゃいましょう。
- 脆弱なProtocolとCipher suiteの組み合わせが有効になっていないか？
- Vulnerabilities checked欄に突かれる可能性のある脆弱性がないか？（可能性があるものは色がついています)



## 脆弱なProtocolとCipher suiteの組み合わせが有効になっていないか？

2017/11/1時点では、下記が満たされていればひとまずOK

- Protocols enabled/not enabled: SSLv2,v3が無効になっている（TLS1.0以上のみ有効になっている)
- Cipher suites enabled: RC4などの脆弱な暗号スイートが含まれていない


## Vulnerabilities checked欄に突かれる可能性のある脆弱性がないか？（可能性があるものは色がついています)

TLS1.0が有効な場合、"BEAST脆弱性を突かれる可能性があるよー"と指摘されちゃいます。
"BEAST脆弱性とは"については必要に応じてTL;DRにあるリンク先を見ていただくとして、
"脆弱性を突くのは困難なので、現状問題ないよ"と毎度説明します。


# "BEAST脆弱性を突くのは困難なので、TLS1.0が有効でも現状問題ないよ"という説明
こんな感じ。

```
TLS1.0にはBEAST脆弱性が存在しますが、
・脆弱性を突く攻撃を行うための前提条件を満たすことが困難
	- CBCモードが有効
	- かつ、脆弱性を持つJavaアプレット実行環境があるブラウザ(現行バージョンでは修正済み)
	を満たした場合に攻撃が可能だった。

現在は
	- CBCモードが有効
な場合でもブラウザ側で
	- 1/n-1 record splittingがデフォルトで有効となる
などの対策が取られているため、上記Javaアプレットの脆弱性の代わりになる脆弱性が発見されても問題ないと考えている。
```

# 疑問・よくわかっていないところ

## Truncated HMAC(RFC6066)のお話
[CRYPTREC 暗号技術ガイドライン(SSL/TLS における近年の攻撃への対応)](http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf)
p77 図３〜p78 3行目に、

 - 1/n-1 Record Splitting Patchを適用している場合でも、Truncated HMAC (RFC6066)）を使う場合には、必ずしも安全性が保証されるわけではないため、注意が必要

とあるのだけれど、RFCを追い慣れていない自分には、RFC6066で定義されている通常のHMACを80バイトに切り詰めたHMACを使用しているプロダクト、ケースが今もあるのか確認できませんでした。ご存知な方がいらしたら、ご教示いただけると助かりますmm

[TLS1.2におけるTruncated HMAC利用時の脆弱性について](https://sect.iij.ad.jp/d/2011/12/079269.html)

CBCモード時のTLS1.2にも影響があるということなので、今はPatchがあてられているか、非推奨になっていたりしそうですが。

# 参考

[SSL/TLS 1.0 はいつまでに無効化しなければならないか？](http://www.intellilink.co.jp/article/pcidss/18.html) : PCI-SSCは2018/6/30までにTLS1.0を無効化するようプレスリリースしています。
[SSLとTLSの違いと脆弱性の問題](https://jp.globalsign.com/service/ssl/knowledge/ssltls_brittle.html)
[ウェブブラウザにおけるTLS/SSLの対応状況の変化](https://ja.wikipedia.org/wiki/Template:%E3%82%A6%E3%82%A7%E3%83%96%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8BTLS/SSL%E3%81%AE%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81%E3%81%AE%E5%A4%89%E5%8C%96)

[CRYPTREC 暗号技術ガイドライン(SSL/TLS における近年の攻撃への対応)](http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf)
[我々はどのようにして安全なHTTPS通信を提供すれば良いか](https://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92#beast-cve-2011-3389)
[httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？](https://qiita.com/kuni-nakaji/items/5118b23bf2ea44fed96e)