SSL/TLS に関する動向、注意点等
HTTPS 通信割合の増加
米Google社のレポート “HTTPS encryption on the web” にもある通り、HTTPS通信の割合は、2015年時点では、米国約49%、国内約24%であったのに対し、2017年現在は、米国約70%、国内約51%まで、普及しており、インターネット通信におけるSSL暗号化の流れは、今後も加速していくと予想されます。
https://transparencyreport.google.com/https/overview?hl=en
ここでは、最近のSSL/TLSに関する業界動向、および、SSLサーバ証明書をお使いいただく上での注意点について、触れていきたいと思います。
HTTPS Everywhere （Google の取り組み）
・ウェブ利用のあらゆるサービスで暗号化を目指す
（例）HTTPSを使わない、パスワード・カード番号入力フォームで警告（～Chrome62)
HTTPSを使わない、全フォームへ警告（Chrome62～）
・「デフォルト HTTPS」
サイトアクセス時、HTTP リクエスト を HTTPS URL にリダイレクト
・Certificate Transparency (CT：証明書の透明性) の義務化
全認証局へ、発行する証明書の公開ログ(CTログ）への登録を義務化
誰もが、発行されたすべての証明書を調べることが可能に
認証局の説明責任がより求められ、システムの信頼性向上を促進
・他、HTTPS利用促進、安全性向上
SEO向上、 HTTP/2はHTTPS前提、Sha-1廃止
安全性の追求 （Mozillaや CA Browser Forumの取り組み）
・「Baseline Requirements」
https://cabforum.org/baseline-requirements-documents/
CA Browser Forum （ブラウザベンダと各認証局の業界団体）が策定
認証局に対し、証明書発行・失効に関わる各種要件を制定
・4.9.1.1章：証明書の“24時間以内”の失効（必須）
The CA SHALL revoke a Certificate within 24 hours if ・・ occurs:
・利用者の失効要求が確認された場合
・Webサイトで使用している鍵ペアが危殆化した場合
・証明書の内容が正しくない、審査が誤っていた等が分かった場合
・利用者が既にそのFQDNの利用権、他を有さないと分かった場合、他
↓
認証局が、第３者から通報を受けた場合も対応要
→ CT により透明化 → 認証局は・・24時間以内対応、または、時間要の説明責任
Webサイト管理者側の注意事項（１）
利用中のWebの証明書が 突然「失効」「再発行」とならないために・・・
GitHub 等で、利用中のWebの鍵ペアを公開してしまっていませんか？
・Git : ソースコード、他のバージョン管理システム
・複製（バックアップ）作成の際に、鍵ペア・証明書も一緒に含めてしまうことも
・これが不特定からアクセス可能になっていると・・・
（例）cisco 利用の秘密鍵が GitHubに(Moziilaへの報告）
“Private key corresponding to public key in trusted Cisco certificate ・・・”
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/T6emeoE-lCU
→ GitHub に、他にも「秘密鍵」が公開されていないか、”サーチ”する動きに・・
→ 報告された認証局は、”24時間以内“ の失効対応を求められる （CTで透明化）
Webサイト管理者側の注意事項（２）
・利用中のWebの証明書が 突然「失効」「再発行」とならないために・・・
OpenSSL 等のバージョンは極力最新のご利用を ・・・ 弱い鍵を使っていませんか？
バージョンが古いと、弱い（脆弱な）鍵を生成することも
・（例）2008年 Debian OpenSSLに脆弱性発見（CVE-2008-0166）
https://wiki.debian.org/SSLkeys
OpenSSL が弱い鍵を生成 → 証明書を失効、再発行、再設定
・（例）2017年 SSL Certificate Contains Weak RSA Key (CVE-2017-15361)
https://www.tenable.com/plugins/index.php?view=single&id=103864
Infineon Technologies 社が提供の RSA鍵生成ライブラリに脆弱性
5年以上前から、各種機器（Microsoft TPM(Trusted Platform Modules )含む）に組込み
Mozilla コミュニティ内で CTログ内サーチ、弱い鍵使用の証明書一覧を列挙（次項）
・弱い鍵使用の証明書と、それを発行した認証局の一覧
“Batch: ROCA (CVE-2017-15361) fingerprints found”
https://misissued.com/batch/28/
CAAレコード（DNS）
・「Baseline Requirements」
CA Browser Forum （ブラウザベンダと各認証局の業界団体）が策定
・3.2.2.8章：CAAレコード確認(発行審査時)の必須化 (2017/9/8～)
CAAレコードとは？
・意図しない認証局から証明書が発行されることを防ぐ（認証局を限定できる）
・「RFC6844」で規格化された DNS レコードの１つ
・CAA レコードに証明書の発行を許可する認証局を FQDNやドメイン毎に指定
・Webサイト管理者は、設定しなくてもよい →設定されていない場合は、どの認証局からも証明書を発行できる
https://www.cybertrust.ne.jp/sureserver/productinfo/caa.html
設定例（CAAレコード）：
・example.com CAA 0 issue “cybertrust.ne.jp“
-認証局としてサイバートラストを指定（ワイルドカード証明書を含む）
-CN=example.com の他、www.example.com、web.sub.example.com 等も発行可能
まとめ
・SSL/TLS最新動向
HTTPS Everywhere
安全性の追求 （Mozillaや CA Browser Forumの取り組み）
不正な証明書については、第３者から通報を受けた場合でも、24時間以内に失効される可能性あり
・「利用中のWebの証明書が 突然「失効」「再発行」とならないために・・・
GitHub 等で、利用中のWebの鍵ペアを公開していないか確認ください
OpenSSL 等のバージョンが最新であることを確認ください
・CAAレコードによる認証局の制限
意図しない認証局から証明書が発行されることを防ぐことが可能
設定されている場合は、指定の認証局しか証明書を発行できない 上位のドメインに設定されている場合、下位ドメインにも影響するため、設定に注意
技術本部 本部長 東 久貴
2000年頃より、PKI技術を中心としたICTシステムの認証／暗号等セキュリティシステム提案～実装に携わってまいりました。
現在は、サイバートラストの技術本部長として20名のエンジニアを率いており、市場を見据えた次世代認証局やコンテキスト認証、IoT分野向けセキュリティサービスなど、新技術開発をリードしております。