Developers Summit 2016 【19-C-L】平賀様の資料です。 ※3/15（火）差し替え版に更新しております。

1. 【19-C-L】
Web開発者ならおさえておきたい「常時
SSL/TLS化の実装ポイント」
Product Manager Symantec Website Security
Iwao Hiraga

2. 2
本日ご説明させていただく内容
2
常時SSL/TLSとは
賽は投げられた
常時SSL/TLS化による新たな課題
SSL/TLS実装方法
- 正しいコンテンツを作る
- SSLサーバ証明書の選び方
- 正しいサーバ実装

3. 通信相手が
本物ではないかもしれ
ない…
Copyright © 2016 Symantec Corporation
3

4. Copyright © 2016 Symantec Corporation
4
これ
フィッシング詐欺？

5. 5
なりすまし
盗聴…

6. Copyright © 2016 Symantec Corporation
6
相手は？

7. インターネット
の弱点
Copyright © 2016 Symantec Corporation
7

8. Copyright © 2016 Symantec Corporation
8
「本物」か
確かめる方法

9. 信頼＝証明書
Copyright © 2016 Symantec Corporation
9

10. HTTPS!
Copyright © 2016 Symantec Corporation
10

11. 常時SSL/TLS化とは
• Webサイトを全部HTTPS化すること
• TLSはSSLの進化版（つまりほぼ同義）
• 利点：
–中間者攻撃から盗聴・なりすましを防ぐ
• なりすましWi-Fiスポットの脅威
• Firesheep等のMITMツールの脅威
–ウェブアプリ開発の効率が高まる
–通信速度が高まる（HTTP/2）
–リファラーの増加でログ解析の精度向上
–検索順位での優遇（Google）
–Webサイトの信頼性が高まる
11
ログイ
ン後トップ
https
ログイ
ン後トップ
https

12. 常時SSL/TLS化 ってホントに必要なの？
常時SSL/TLS化をためらう声
銀行やECサイトではないのにそこまでする必要がある？
–銀行やECはセキュリティ対策が進んでいるので、対策が進んでいない
Webサイトこそサイバー攻撃の狙い目
クレジットカード番号、パスワードを入力させていない
–メールドレス、嗜好性、cookieも保護対象と認識され始めている
–ユーザの信頼を損ないかねない
製品の紹介だけでフォームがないWebサイトだ
–フォームがなくてもSEO対策、cookieの保護、フィッシング対策に有効
–もはやフォームだからSSL/TLS、ではなくなってきている
12
そんなことまで
するの？

13. 本日のテーマ 2
13
1 常時SSL/TLSとは
2 賽（サイ）は投げられた
3 常時SSL/TLS化による新たな課題
4
SSL/TLS実装方法
- 正しいコンテンツを作る
- SSLサーバ証明書の選び方
- 正しいサーバ実装

14. HTTPS Webサイトが急増中
14
出典元：HTTP Archive http://httparchive.org/
アメリカ政府では「
2016年末までに全て
の”.gov”サイトを常時
SSL/TLS化」するこ
とを宣言
36%
「サイト丸ごとHTTPS
化」(常時SSL/TLS化)
するウェブサイトが増
加中
Google/Bing/Facebook/Twitter/YouTube/Wikiped
ia/Netflixなど
丸ごと
出典元：Pulse https://pulse.cio.gov/
2015年8月時点：イ
ンターネットの全トラ
フィックの）
約20%がHTTPSトラ
フィック
20%

15. 全HTTPS時代の足音は聞こえ始めている
15
出典元：FORTUNE
http://fortune.com/2015/04/30/netflix-internet-traffic-encrypted/
出典元： Computer Business Review
http://www.cbronline.com/news/telecoms/network/wikipedia-founder-all-
major-internet-traffic-will-be-encrypted-4687930
“インターネットのトラフィックの
大部分は年末までに暗号化
される。これがその理由だ。 “
“Wikipedia創設者：主要な
インターネットトラフィックは
すべて暗号化される。“

16. HTTPSトラフィックの歩み
16
カード・個人情報
などを扱うページ
のみHTTPS化
フォームのみ
HTTPS
サイト丸ごと
HTTPS化する
サイトが増加
常時SSL/TLS
サイトの増加
インターネットは
暗号通信が
デフォルト
全HTTPS時代？
• 製品サイトはHTTPメール
問い合わせからフォーム問
い合わせにシフト
• バックエンドサーバや
ショッピングカートが
HTTPS化
• 金融、EC、ログインサ
イト、米政府、大企業の
コーポレートサイトの常
時SSL/TLS化
• ビーコンのHTTPS対応
証明書のオートメーショ
ンサービスが身近に
• デフォルトHTTPSホス
ティングプランの登場
• リバースプロキシサーバ
が主流に
• オープンソースの証明書
と企業向け証明書に二極
化
今

17. Googleの取り組み
SSL/TLSはSEO順位向上要素のひとつ
–2014年8月からHTTPS Webサイトの順位を優遇するロジックを実装
Google検索サイトを常時SSL/TLS化
–2012年3月から検索サイトがデフォルトでhttps化（BingとYahooもhttps化）
ChromeでHTTP接続の警告対応を検討中
–HTTP接続の場合に安全でないと表示させることを検討中
17
出典元：Marking HTTP As Non-Secure
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

18. Mozillaの取り組み
•FirefoxでHTTP/2サイト接続速度の向上
– HTTP/2プロトコルによる接続速度向上の恩恵が受けられるのはHTTPS接続のみ（Chrome, IEも同様）
•Let’s EncryptでSSL/TLSの裾野を広げる予定
– いわばSSLサーバ証明書のオープンソース版発起人の1社
– DV証明書だけなので企業の一般公開サイト向きではない
•Firefox 44 nightly (開発版) でHTTP接続の
警告対応実装
– HTTP接続ページに<input type=“password”>
があれば警告対象
18
HTTP/2
HTTP
HTTPS

19. ハードウェアやプロトコルの進化
•サーバ・クライアントのCPUの機能向上で
暗号化処理のオーバーヘッドは無視できるレベル
•新しいHTTP/2プロトコルの登場でスピード向上
– SPDYが進化して2015年5月にRFC 7540として文書化
– 接続の多重化、ヘッダ圧縮などによってHTTPより速度向上
– HTTPとHTTP/2の速度比較
19
出典元：HTTP vs HTTPS Test
http://www.httpvshttps.com/

20. 本日のテーマ 3
20
1 常時SSL/TLSとは
2 賽は投げられた
3 常時SSL/TLS化による新たな課題
4
SSL/TLS実装方法
- 正しいコンテンツを作る
- SSLサーバ証明書の選び方
- 正しいサーバ実装

21. 常時 SSL/TLS 化による新たな課題
# カテゴリ 懸念/疑念 解消状況と今後の方向性
1 コスト
SSLサーバ証明書の費用
・ワイルドカード/マルチドメイン証明書の有効活用
・低価格証明書ラインアップの拡充
・API連携等による運用自動化によるTCOの削減
・ホスティングメニューとの「コスト一体化」
2 パフォー
マンス サイトアクセスの遅延
・高速マルチコアCPUの普及
・セッション再利用などのチューニング技術の普及
・ECC(楕円曲線暗号)によるCPU負荷減
・HTTP/2による高速化プロトコルの普及
3 運用性
証明書管理負荷の増加
・シマンテックSSL-API、File/DNS認証を用いたドメイン認
証等のテクニック導入よる申請・発行の自動化
・シマンテック「CIC」等のツール導入による「可視化」
・有効期限切れを未然に防ぐ「更新の自動化」
4 運用性
IPv4アドレスの不足
・Win Vista以降、スマホなど大半のサーバ/クライアント環
境がSNIに対応完了、Name-based VHでのHTTPS化
は以前に比べ容易に
5 カバレッジ
暗号化で十分か
・暗号化が普通になり、むしろ「認証」が差別化要素となる
・暗号化通信以外のセキュリティ施策も引き続き重要。脆弱
性診断、WAF、NGFW、DDoS対策、二要素認証、マ
ネージドサービスなど
21

22. 今できること
•まずはノウハウをためるためにも新しいサーバやWeb
サイトリニューアルは常時SSL/TLS化を前提で検
討してみてみる
•すでにHTTPSフォーム導入済みのサイトの場合、
サイト全にHTTPS適用を検討してみる
22
次のプロジェクト
で試してみよう

23. 本日のテーマ 4
23
1 常時SSL/TLSとは
2 賽は投げられた
3 常時SSL/TLS化による新たな課題
4
SSL/TLS実装方法
- 正しいコンテンツを作る
- SSLサーバ証明書の選び方
- 正しいサーバ実装

24. 正しいコンテンツを作る
常時SSL/TLS前提にソースを記述
– HTTPS混在エラーを避けるHTML記述
• src="../xxxx.html“
• src="/xxxx.html“
• src="//www.example.com/xxxx.html“
HTTPS対応のビーコンタグを利用
– 動画埋め込み、SNSボタン、レコメンド、アフィリエイトタグ、アクセス解析タグ、外部jsファイ
ルなど
なるべく同じドメイン、サブドメインのサーバに置く
– ネゴシエーションも不要になりスピードアップ
24
<script src=“https://www.google.com/jsapi” type=“text/javascript”></script>

25. HTTP/HTTPS混在の回避するための注意点
•httpsのページ内にhttpの画像、js、CSSファイ
ルなどが混在しているとブラウザが警告を出す
→ HTML、CSS、jsファイル内の「http://」で始まる埋め込みファイルはNG
•httpの画像ファイル等を読み込む際に暗号化して
いないCookieの値がやり取りされる危険がある。
25
GET /logo.gif HTTP/1.1
Accept: */*
Referer: http://www.ｘｘｘｘ.com
Accept-Language: ja
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Host: www.ｘｘｘｘ.com
Connection: Keep-Alive
Cookie: sessionID=0233683208C683A3053473E67BE2AE63
サーバーリクエスト例

26. 正しいコンテンツを作る 2
Cookie にセキュア属性をつける
– HTTP接続時にcookieは平文で通信される
– HTTPSの接続時だけcookieを引き渡す設定
HTTPSへの転送設定
– サーバの設定ファイル（.htaccess など）で301転送
– .htaccess などでSSL/TLS接続をブロックしない
– APIの場合は転送せずErrorを返す
– robots.txt、No indexなどmeta tagによる
検索エンジンのブロック排除しない
印刷物に https:// と記載する
Googleで検索してみる
– HTTPSサイトと認識されているか見る
26
Set-Cookie: user=Symantec; secure
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule
^(.*)$ https://ssl.symantec.com/$1
[R=301,L]
RewriteCond %{REQUEST_URI} !^/exce
ption/*.*$

27. host: http://www.xxxx.com¥r¥n
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152;
.NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: sessionID=02333208C683A3053473E67BE2AE63
[Full request URI: http://www.xxxx.com:443/]
Cookieのセキュアタグ属性を付けなかった場合
•HTTPSのサイトであったとしても、偽のアクセスポイント
を経由させられた場合、Secure属性を設定していない
Cookie（セッションIDを含む）は盗聴される
27
出典元 http://blog.tokumaru.org/2013/09/cookie-manipulation-is-possible-even-on-ssl.html
• サイト構成：個人情報
ページのみHTTPS、
他のページはHTTP
（平文）
• 被害者：セッション
クッキーはすでに付与
されている
• 攻撃者：偽APの罠を
仕掛けDst 443ポート
をHTTPとしてデコー
ドするように指定
（port80を閉じている場合でも有
効）
↓ Hypertest Transfer Protocol
→Transmission Control Protocol, Src Port: 50217(50217), Dst Port: https (443), Seq:1
→GET / HTTP/1.1¥r¥n
平文でCookieを
キャプチャされ
てまう

28. 社内ネットワーク
SSL/TLSサーバ証明書の選び方
•信頼できる認証局の証明書を
選ぶ（オレオレ証明書は避ける）
– 証明書発行、ルート証明書などインフラ運用がCAの真
髄
– オレオレ証明書は管理が大変
• 責任者不在、盗難気づかない、何枚存在するか不明等
28
DigiNotar 社は 1998 年にオランダで創業された認証局（CA）で、
SSL サーバ証明書やオランダの電子政府のための証明書を発行し
ていました。同社は 2011 年 6 月と 7 月に掛けて外部ネット
ワークから攻撃を受け、認証局の管理をする 8つのサーバ（リ
テール向け 証明書管理用サーバ、EVSSL 証明書管理用サーバ、
特定顧客用ルート証明書を管理するサーバ等）全てがハッキング
されました。
その結果、後の 2011 年 8 月に実行される大規模な中間者攻撃に
使われる、「google.com」ドメインに対する不正な SSL サーバ
証明書を発行することになりました。発行された不正な SSL サー
バ証明書は、実際に Gmail サービスのユーザを対象とする中間者
攻撃に利用され、イランのユーザの通信が侵害されることになり
ました。
DigiNotar 社はこの事件の後、ブラウザソフトウェアにおける
「信頼されるルート認証局のリスト」から削除されることになり、
最終的には 事業継続の困難から倒産することになりました。
DigiNotar社の例
倒産

29. 信頼性証明
- 世界最高水準の運用体制（弊社例）
29
シマンテックは、認証機関準
拠性検査ISAE3402/SSAE16)
を受けています。
認証機関準拠性検査は、米国
公認会計士協会(AICPA)また
は同様の組織から認定された
独立監査法人によって、年一
回行われます。
監査についても「認証業務運
用規定(CPS)」に規定されて
います。
シマンテックの場合は運用業
務規定「CPS」をWebサイト
にて公開しています。
SSLサーバ証明書の根本であ
る認証局のセキュリティは
非常に堅牢であることが求
められます。
米国シマンテックの認証局
「Vault」は、1100万ドル
を投入した米国国防総省の
セキュリティ指針を基本に
したミリタリーグレードの
セキュリティで安全性を確
保しています。
第三者による
定期監査
認証業務
運用規程の開示
認証施設の
厳格な
セキュリティ

30. 認証レベルに応じた証明書を選ぶ
30
EV SSL
証明書（EV）
企業認証型
証明書（OV）
ドメイン名認証
型証明書
（DV）
特長
最高レベルの認証と
信頼性の視認性向上
（運営主体の常時表示、
緑のURLバー）
企業向け標準レベルの
認証と信頼性
暗号化と
簡易的な認証
利用
シーン
オンラインバイキングや
ECサイト
個人情報など、
重要情報の入力ページ
個人サイト、
イントラネット
認証
レベル
★★★ ★★ ★
発行ま
での目
安
1週間
3営業日以内
（即日発行オプション有）
最短2分
EV

31. 一目でわかる
「企業認証型」と「ドメイン名認証型」の違い
31
ドメイン＋企業情
報まで証明
ドメインの実在性
のみ証明

32. サンプル
サンプル
サンプル
ドメイン名に応じた証明書を選ぶ
一般的なSSLサーバ証明書
– 1枚で購入（FQDNごと）
ワイルドカード証明書（複数サブドメイン
対応）※
– テストサイト、本番サイト両方で対応可能
– 将来のサブドメイン増加に容易に対応できる
– フィーチャフォンは未対応、スマホ対応
マルチドメイン対応証明書（SAN対応）※
– 証明書1つで複数ドメインサイトに対応
– メインのFQDNにいわば代替FQDNを追加することでマルチドメ
インに対応
– フィーチャフォンは未対応、スマホ対応
32
www.symantec.com
*.symantec.com
test.symantec.com
event.symantec.com
www.symantec.com
jp.symantec.com
www.geotrust.co.jp
※ただし、複数サーバに同じ鍵ペアの証明書を配置することには危殆化時のリスクが拡大します（IPA）
https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html

33. 注意すべきサーバ設定
セキュリティ強化の設定
–Client-Initiated Renegotiation（再ネゴシエーション）の禁止
–TLS compressionの禁止
–HTTP Strict Transport Security（HSTS）を設定することが望ましい
SSL/TLSネゴシエーションの負荷を下げる設定
–OCSP Staplingに対応する
–Keep-aliveをon
–画像/css/jsファイルなどはキャッシュ、DB関連コンテンツはNG
さらに強化するには
–Certificate Transparency (CT)対応の認証局から購入
–Public Key Pinningの設定
–Content Security Policy (CSP)の設
（参考） CSP : https://developer.mozilla.org/ja/docs/Security/CSP/Introducing_Content_Security_Policy
33

34. セキュリティ強化の設定
Client-Initiated Renegotiation（再ネゴシ
エーション）の禁止
–SSL/TLS通信では、仕様上、クライアント側からSSL/TLS通信
の「再ネゴシエーション」を要求することが認められている
–「再ネゴシエーション」を行った際、暗号化通信を一から張りなおす
ことになり、サーバの負荷が向上してしまうことになる
–DDoS攻撃に利用されることになるので無効化することを強く推奨
TLS compressionの禁止
–TomcatやMySQL等で多数の脆弱性が報告されている
–古いアプリケーションでは有効になっている場合があるので注意
34

35. <VirtualHost *:443>
ServerName www.symantec.com
SSLEngine on
Header set Strict-Transport-Security "max-age=315360000; includeSubDomains"
</VirtualHost>
セキュリティ強化の設定：
HTTP Strict Transport Security（HSTS）
HSTSとは…
–サーバーからブラウザへ “Strict-Transport-Security” というヘッダを返
すことで、以後、そのブラウザで “www.symantec.com” と入力すると
HTTP ではなく HTTPS で暗号化した通信を行うようにさせる機能
–Apache のバーチャルホストでの設定例
HSTSの課題
–モバイルのSafariブラウザが未対応
–古いブラウザに対応していない
出典元 https://developer.mozilla.org/ja/docs/Security/HTTP_Strict_Transport_Security
35

36. ネゴシエーションの負荷をさげる設定：
OCSPステープリング
–ウェブサーバがウェブブラウザの代わりにOSCP レスポンダ
に問い合わせ、SSL ハンドシェイクの際に OCSP レスポ
ンスをクライアントに提供する
36
CRL
ウェブサーバ
認証局（CA）
データベース
ウェブサイト
利用者
SSLサーバ証明書
1. SSLハンドシェイク
2. SSL通信開始
0. OSCPリクエスト
OCSPレスポンダ
OCSPレスポンス
OCSPレスポンス

37. さらなる強化：
Certificate Transparency (CT)
–認証局が証明書を発行する都度、全ての証明書発行の証跡を、
第三者の監査ログに記載する仕組み
–主に、ウェブサイトの運営者やドメイン名の管理者が、その監査ログ
サーバを確認することで、自分のドメインに対して不正な証明書や、
ポリシー外の認証局からの証明書が発行されていないかを検証が
可能
37
監視
ウェブサイト
利用者のブラウザ
ログ
④ブラウザがウェブサーバの証
明書・SCTを取得 ウェブサーバ
認証局
②SCTを流す
①証明書を登録
③SCTと証明書を提供
ドメイン所有者

38. さらなる強化：
Public Key Pinning
–偽造された証明書による中間者攻撃を防ぐために、特定の暗号公開鍵と特
定のWebサーバを紐付ける（ピン留めする）ようにWebクライアントへ依頼す
る機能
設定方法
–HTTPSでのアクセス時、Public-Key-Pins HTTPヘッダを返す設定を行う
設定例
– Public-Key-Pins: pin-
sha256="cUXc345TAZddWKaASuYWneDt55t3oBAkE3h2+soZS7sWs="; max-
age=5184000; includeSubdomains; report-uri="https://www.symantec.com/hpkp-
report“
注意点
–対応しているブラウザが少ない（Chrome, Firefoxのみ対応）
38

39. 適切な Cipher Suite の選択
•RC4の禁止（弱い共通鍵）
–AES-GCMの推奨
•SSL3.0の禁止（古いSSLプロトコル）
–TLS1.1以上推奨
•Perfect Forward Secrecy (PFS)対応アルゴリズム
を優先
–ECDHE（楕円曲線暗号アルゴリズム）等
ただし強すぎる Cipher Suite の設定はNG
–Mozila、Qualys、CRYPTREC、IPAなどのガイドラインを参照
（参考）IPA http://www.ipa.go.jp/files/000014264.pdf
39
SSL_RSA_WITH_AES_256_SHA
鍵暗号化プロトコル 共通鍵 ダイジェスト

40. プロトコルバージョンの安全性の違い
• 各プロトコルの脆弱性対応状況
• フィーチャーフォンの各社対応状況は以下のサイトを参考にしてください。
– NTT Docomo : https://www.nttdocomo.co.jp/service/developer/make/content/ssl/spec/index.html#p06
– KDDI : http://www.au.kddi.com/ezfactory/web/
– Softbank : http://creation.mb.softbank.jp/mc/tech/tech_web/web_ssl.html
40
TLS1.2 TLS1.1 TLS1.0 SSL3.0 SSL2.0
ダウングレード攻撃
（脆弱の暗号アルゴリズムを強制的に使わせること
ができる）
安全 安全 安全 安全 脆弱
バージョンロールバック攻撃
（SSL2.0を強制的に使わせることができる）
安全 安全 安全 安全 脆弱
ブロック暗号のCBCモード利用時の
脆弱性を悪用した攻撃
（BEAST/POODLE攻撃など）
安全 安全 パッチ適
用要
脆弱 脆弱

41. Cipher Suite 設定の参考例
•フィーチャフォンなどのレガシー環境への対応を考慮した上の
設定が必須
•IPAが実施したクライアント環境におけるCipher Suite調
査結果
– 通信可能であったCipher suiteが少なくとも1つ以上あったものを●印
– 調査で確認されたCipher suiteは、8 種類で、そのうち、推奨されている共通鍵暗号アルゴリ
ズム及びメッセージ認証は以下の4種類
41
Cipher Suite 金融系 物販系 非物販系
1 TSL_RSA_WITH_AES_128_CBC_SHA ● ● ●
2 TSL_RSA_WITH_AES_256_CBC_SHA ● ● ●
3 TSL_DHE_RSA_WITH_AES_256_CBC_SHA ● ● ●
4 TSL_RSA_WITH_CAMELLIA_256_CBC_SHA ― ● ―

42. Copyright © 2016 Symantec Corporation
42
HTTPS化
いつするの？

43. 43
従来の
「目的」
新しい
追加の
「目的」
外部環境
• 暗号化
• サーバ認証
HTTPS化によって
盗聴/情報漏えいの脅威
なりすまし
(フィッシング)の脅威
HTTP＝警告対象
とする検討
Google検索HTTPS化
HTTP/2における
高速化の要件
クラウド/ホスティング
競争環境の激化
• デフォルト化/
自動化による
運用効率化
Google検索におけ
るHTTPSの優遇
• ランキング向上
• リファラ情報取得
サーバ
運用管理者
の視点
サーバ
運用管理者
の視点
事業者様
の視点
• ブラウザの警告
を未然に抑止
• パフォーマンス
向上
マーケティング
(Webの効果的
な活用)の視点
まとめ：「今」 何故HTTPS化するのか？

44. Copyright © 2016 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be
trademarks of their respective owners. This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to
the maximum extent allowed by law. The information in this document is subject to change without notice.
ご清聴ありがとうございました。
Copyright © 2014 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its
affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.
This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or
implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.

45. Appendix
45

46. 正しいSSL/TLSのサーバ設定
•SSL/TLS実装チェッカーで確認
– Symantec Crypto Report
https://www.symantec.com/ja/jp/page.jsp?id=crypto-report
46