ID/パスワードなどのログイン情報やクレジットカード情報などを入力する際に、「送信先は偽サイトではないだろうか」「途中で誰かに覗き見されてないだろうか」といった不安が頭をよぎったことはありませんか。そんな不安が現実のものにならないようにするために、「SSL/TLS」という仕組みが用意されています。大切な情報を入力する際には必ずこの仕組みを利用するようにし、いくつかの項目を確認するように心がければ、偽サイトに騙されたり第三者に盗聴されたりすることはない、安全な通信を行うことができます。
＜INDEX＞
■「SSL/TLS」の仕組み
・正しい相手との接続を確認する「認証」
・盗聴を防ぐ「暗号化」
・改ざんを防止する「改ざん検出」
■「SSL/TLS」の使い方
・ブラウザの警告に注意（主要ブラウザの警告例）
・正常な接続の確認（主要ブラウザの表示例）
・運営者の確認
・URLの確認
★コラム：「SSL/TSLの脅威」１――POODLE（プードル）
★コラム：「SSL/TSLの脅威」２――FREAK（フリーク）
★コラム：「SSL/TSLの脅威」３――Superfish（スパーフィッシュ）
＜以下本文＞
インターネットの通信が第三者に盗聴されたり改ざんされたりすることを防ぎ、安全な通信が行えるようにするために、SSL/TLSという仕組みが用意されている。SSL（Secure Sockets Layer）は、TLS（Transport Layer Security）のベースとなった古い規格の名前だが、この名が広く浸透しているため、今も両者をまとめて「SSL」と呼ぶことが多い。この仕組みは、「認証」「暗号化」「改ざん検出」という3つの重要な機能を提供することによって、安全な通信を実現している。
・正しい相手との接続を確認する「認証」
認証機能は、ビルに入館する際などに行うセキュリティチェックと似ており、相手に自分の電子証明書（以下、証明書と記す）を提示し、正当な接続先であることを確認してもらう。一般的なSSL/TLS通信では、サーバー側が証明書を提示し、クライアント側に正規サイトであることを確認してもらうだけだが、企業向けオンラインバンキングなどの一部のサービスでは、クライアントの認証にも利用されている。サーバーがクライアント側に証明書の提示を求め、提示された証明書をチェックして正規ユーザーであることを確認。取引を行う仕組みだ。
・盗聴を防ぐ「暗号化」
盗聴されてもかまわないように、送信するデータは暗号化してから送り、受信側で復号化（解読）する。暗号化/復号化に使用する鍵は、接続時にその場限りのものを生成し、これを安全に共有するための特別な仕組みを使用してやりとりする。通信を盗聴されていても、第三者に鍵が渡ることは無く、鍵を持たない第三者は通信内容を解読することができない。
・改ざんを防止する「改ざん検出」
データを送る際には、送信側で送信データに鍵をからめたチェック用のコードを算出して一緒に送る。受信側では、受け取ったデータと鍵を元にコードを算出し、受け取ったコードと一致しているかどうかをチェックして、改ざんされていないことを確認する。データの内容が変われば算出するコードも変化するが、鍵を持たない第三者は正しいコードを算出できないため、コードをチェックすれば改ざんされたかどうかを検出できる。
SSL/TLSは、通常の通信を安全に行うための拡張機能として用意されている。例えば、Webブラウザの場合には、URLで明示的に指示する。URLの頭の「http:」を「https:」にすると、ブラウザはSSL/TLSを利用してサーバーに接続しようと試みるのだ。
汎用のメールソフトの場合には、接続先に合わせてユーザーが設定するが、設定項目を持たないその他多数の専用アプリの場合には、SSL/TLSを利用しているのかどうか分からない。また、利用してはいるものの、証明書の検証が正しく行われていないものが多数あるようだ。米国のセキュリティ機関CERT/CCの調査によれば、テストした約100万個のAndroidアプリのうち、2万3667個に問題があったという（注1）。問題のある個々のアプリについては、開発元に対処してもらわないといけないが、証明書の正しい検証方法については、私たちも心得ておく必要がある。
電子証明書は、実社会の身分証明書と同様、相手を確認するためのものであり、チェックが不十分だと成りすましに騙されてしまうかもしれない。Webサーバーへの接続を例に、チェックポイントを確認しておこう。
・ブラウザの警告に注意
主要なWebブラウザは、SSL/TLSの接続時に、サーバーの証明書が信頼できる機関から発行されたものなのか、期限は切れていないか、このホストの証明書なのかといったことを自動的に検証するようになっており、問題がある場合には警告を表示する。
使用しているブラウザが図1のような警告を表示した場合には、正しい相手と安全に通信できるかどうか分からないので、重要な情報のやり取りは中止する。中には、安全だと主張するサイトや、エラー表示を無視して進むよう案内するサイトもあるが、真偽が確認できない相手の言うことを鵜呑みしてはいけない。少しでも不審なところがあった場合には、それ以上先に進まないようにするのが、身を守る鉄則だ。
図1 主要なWebブラウザの警告例
<Windows>
図1-1 Internet Explorer
図1-2 Firefox
図1-3 Google Chrome
<Mac>
図1-4 Safari
図1-5 Firefox
図1-6 Google Chrome
<Android>
図1-7 標準ブラウザ
図1-8 Firefox
図1-9 Google Chrome
<iOS>
図1-10 Safari
図1-11 Google Chrome
・正常な接続の確認
SSL/TLSで正常に接続できると、ブラウザは安全な通信であることを示すために、アドレスバーの横に「錠前」マークなどを表示する。証明書には、運営者の実在確認などを一定のルールのもとに審査して発行するEV（Extended Validation）証明書（EV SSL証明書とも）と呼ばれるタイプもあり、この証明書を持っているサイトの場合には、運営者の名前が表示される。使用しているブラウザが、接続時にどのような表示になるのかを、しっかり把握しておこう。
図2 主要なWebブラウザのSSL/TLS接続時の表示例
<Windows>
図2-1 Internet Explorer（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの右側に錠前マークを表示。EV証明書の場合には、アドレスバーが緑色に変わり、錠前マークの右に運営者名が表示される。
図2-2 Firefox（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に錠前マークと「https://」を表示。EV証明書の場合には、錠前マークと運営者名が緑色で表示される。
図2-3 Google Chrome（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に緑色の錠前マークと「https://」を表示。EV証明書の場合には、錠前マーク右に運営者名が表示される。
<Mac>
図2-4 Safari（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーのドメイン名の左側に錠前マークを表示。EV証明書の場合には、緑色の錠前マークと運営者名の表示に変わる。
図2-5 Firefox（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に錠前マークと「https://」を表示。EV証明書の場合には、錠前マークと運営者名が緑色で表示される。
図2-6 Google Chrome（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に緑色の錠前マークと「https://」を表示。EV証明書の場合には、錠前マークの右に運営者名も表示される。
<Android>
図2-7 標準ブラウザ（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に錠前マークと「https://」が表示。EV証明書には対応していないので表示は同じ。
図2-8 Firefox（上から非SSL、SSL、EV SSL）
アドレスバーにはページのタイトルが表示され、SSL接続時には錠前マーク追加。EV証明書の場合には、錠前マークが緑色に変わる。錠前マークをタップすると、運営者名が確認できる。
図2-9 Google Chrome（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に緑色の錠前マークと「https://」を表示。EV証明書に未対応なので、通常のSSLと表示は同じ。
<iOS>
図2-10 Safari（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーのドメイン名の左側に錠前マークを表示。EV証明書の場合には、緑色の錠前マークと運営者名の表示に変わる。
図2-11 Google Chrome（上から非SSL、SSL、EV SSL）
SSL接続時にはアドレスバーの左側に緑色の錠前マークが表示。EV証明書に未対応なので、通常のSSLと表示は同じ。
・運営者の確認
So-netのログインページは、「So-net Corporatio(JP)」と表示される。このように、名前が表示されるEV証明書の場合には、接続先の真偽が分かりやすい。普通の証明書の場合にも、証明書に運営者が記載されていることもあり、真偽の判定に役立つ。証明書の中身は、錠前マークのクリックなどで表示できる（図3）。
図3 証明書の表示例（Internet Explorer）
図3-1 錠前マークをクリックし[証明書の表示]
図3-2 [フィールド]欄の[サブジェクト]を確認
証明書の[詳細]タブのリストから[サブジェクト]フィールドを選択すると、アクセス先について証明されている諸情報が確認できる。通常のSSL証明書は、証明書によって審査項目がまちまちだが、ここに記載されている事項が確認済みであることを示している。主な項目には、表1のようなものがあり、「O」という項目があれば、そこに記載されている運営者が実在する組織であることの確認がとれている証となる。
表1 サブジェクトの記載項目
CN（Common Name） 一般名（ドメイン名を含むサーバー名）
OU（Organizational Unit） 部門名（部署名など)
O（Organizational Name） 組織名（会社名や団体名など）
L（Locality） 所在地の市区町村名
S（State） 所在地の都道府県名
C（Country） 所在地の国名（JP＝Japan）
・URLの確認
SSL/TLSで正常に接続でき、証明書から正しい運営者であることが確認できれば、偽物ではないと推定できる。運営者は分からないが、SSL/TLSで正常に接続でき、URLがアクセス先の正しいURLである場合も偽物ではないと推定できる。これは、証明書が必ず「CN」の確認を行っているからだ。「CN」は、ドメイン名を含むサーバー名のこと。正しい名前を知らないと真偽を判定することができないが、これを知っていれば、正しいサーバーにSSL/TLSで正常に接続できたので本物だろう推定できるようになる。
中でも特に重要なのがドメイン名だ。URLの最初の「/」までの間に並んでいる「.」で区切られた文字列は、右から順にトップレベルドメイン、第2レベルドメイン、第3レベルドメイン…といい（図4-1）、ドメイン名の多くは、この第2レベルや第3レベルに自由な名前を付け、「example.jp」「example.co.jp」という形で登録される。例えば当サイトの場合は、「www.so-net.ne.jp」の「so-net.ne.jp」の部分がドメイン名だ。ブラウザによっては、アドレスバーに表示されるURLのドメイン名が強調表示されるようになっているので、識別しやすいだろう（図4-2）。
図4-1 ドメイン名
図4-2 ドメイン名の強調表示例
ドメイン名を強調表示するInternet Explorer（上）とFirefox（中）。
ドメイン名のみ表示するSafari（下）。
ドメイン名は重複して登録できず、乗っ取らない限りは登録者以外の者が勝手に使うこともできない。ドメイン名が「so-net.ne.jp」なら、このドメインの登録者であるソネットが管理・運営していることが期待できる。なおかつ、SSL/TLSで正常に接続できていれば、偽称の可能性も無いと考えられるのだ。ただし、ドメインが一致しているからといって、ログインページや個人情報などを求めるページが本物であると決めつけてしまうのは早計だ。ユーザーが自由に扱えて公開できるサービスが同じドメイン上で提供されている場合には、そのサービスが悪用される可能性がある。ドメイン名だけでなく、サーバー名全体が正規のものと一致していることを確かめていただきたい。さらに、同じサーバーの階層下でサービスを分けている場合には、サーバー名の後に続くリソース名も要チェックとなる。
本物のサイトのことを知らないでいると、本物になりすました偽サイトに簡単に騙されてしまう。騙される前に本物のサイトのURLとSSL接続時に確認できる運営会社の名前をしっかり覚えておこう。正規サイトのURLをブラウザのブックマークに登録しておき、利用時にはブックマークからアクセスするように心掛けると、より確実だ。
図5 正規サイトのサービスを悪用した偽サイト例
OneDriveを悪用したYahoo!のフィッシングサイト
★コラム：「SSL/TSLの脅威」１――POODLE（プードル）
SSL/TSLの安全性を脅かす問題が相次いでいる。2014年10月に公になったPOODLE（Padding Oracle On Downgraded Legacy Encryption）と呼ばれる問題は、SSL 3.0で使われている暗号が解読されるおそれがあるというもの。攻撃自体は、ブラウザとサーバー間の通信に介入してSSL 3.0を強制的に使用させたり、大量の通信エラーを発生させる必要があるなど、非常に難易度の高いものだったが、互換性のために残っていた本来の意味での「SSL」を捨て、「TSL」のみの対応へと移行を始めるきっかけとなった。（注２）
★コラム：「SSL/TSLの脅威」２――FREAK（フリーク）
2015年3月に公になったFREAK (Factoring attack on RSA-EXPORT Keys) もまた、互換性のために残っていた古い仕様に起因する問題だ。かつて米政府は暗号輸出に厳しい規制をかけており、その名残で輸出向けの弱い暗号がサポートされ続けてきた。この弱い暗号は、現在では数時間で解読できてしまうレベルのものだ。サーバーの中には、本来ならばその都度使い捨てるべき暗号化の鍵を、使い捨てずに使い続ける実装のところがあるため、事前に解読しておき、ブラウザとサーバー間の通信に介入して弱い暗号を強制的に使用させれば、即座に盗聴や改ざんが行えるようになってしまう。規制緩和から15年の歳月を経て、輸出向けの弱い暗号の排除がようやく始まった。（注３）
★コラム：「SSL/TSLの脅威」３――Superfish（スパーフィッシュ）
2015年2月、一般向けに販売されていたメーカー製パソコンに、Superfish社製のソフトウェアがプリインストールされていたことが公けになった。このソフトはブラウザとサーバー間の通信に介入し、閲覧中のページを改ざんして広告を挿入するものだった。SSL/TSLで保護されたページも改ざん対象にしており、これを実現するために、パソコン内に証明書を発行する認証局の仕組みを持つようになっていた。証明書は、認証局だけが持っている鍵を使って署名するため、通常は第三者が勝手に発行することはできない。ところが、パソコン内に作られた認証局の鍵が抽出されてしまい、その鍵がどのパソコンにも共通していることが判明した。対象がプリインストールパソコンのみに限定されるものの、任意のサイトの証明書を誰でも作成でき、なりすましや盗聴、改ざんが行える状態になってしまった。（注４）
（執筆：現代フォーラム/鈴木）
<注1>
・【注意喚起】HTTPSで通信するAndroidアプリの開発者はSSLサーバー証明書の検証処理の実装を（IPA）
https://www.ipa.go.jp/about/press/20140919_1.html
<注2>
・更新：SSL 3.0 の脆弱性対策について(CVE-2014-3566)（IPA）
http://www.ipa.go.jp/security/announce/20141017-ssl.html
・SSLv3 プロトコルに暗号化データを解読される脆弱性(POODLE 攻撃)（JVN）
http://jvn.jp/vu/JVNVU98283300/
・SSL 3.0 の脆弱性により、情報漏えいが起こる（マイクロソフト）
https://technet.microsoft.com/ja-jp/library/security/3009008
<注3>
・SSL/TLS の実装が輸出グレードの RSA 鍵を受け入れる問題 (FREAK 攻撃)（JVN）
http://jvn.jp/vu/JVNVU99125992/
・セキュリティ アドバイザリ 3046015S：channel の脆弱性により、セキュリティ機能のバイパスが起こる（マイクロソフト）
https://technet.microsoft.com/ja-jp/library/security/3046015
<注4>
・Komodia Redirector がルート CA 証明書と秘密鍵をインストールする問題（JVN）
http://jvn.jp/vu/JVNVU92865923/
・Superfish がインストールされた Lenovo 製 PC に HTTPS スプーフィングの脆弱性（JVN）
http://jvn.jp/ta/JVNTA91476059/
・Superfishに関するレノボの見解（レノボ）
http://support.lenovo.com/jp/ja/documents/HT102632