SSL/TLSの見落とされがちな「認証」という基本機能

はじめに

これは、togetterまとめ「暗号」という言葉が暗号技術の理解の妨げになるというお話の焼き直しです。

知っている人にとってはアタリマエに思える話かも知れませんが、SSL/TLSの基本機能、ちゃんと理解してますか? ということで記事にしました。

SSL/TLSの基本機能

SSL/TLSってなに?

SSL/TLS¹とは、HTTPS ( Webサービスに関わるプロトコルHTTPのセキュア版 ) に使われる暗号技術です。Webじゃなくても、メール²等、色々な場面で使えますが、ここでは取り敢えず(一番ポピュラーなので)Webの話にしておきます。

さて、それではSSL/TLSの機能とは何でしょうか?

SSL/TLSの基本機能ってなに?

良くある説明はこうです。「通信の暗号化」
このように覚えてる方もいるでしょう。確かにこれは間違いではありません。しかし正解とも言えません。

正しくはこうです。

• 通信相手の認証
• 通信の暗号化

そう。まず「認証」を持ってこなければなりません³。
「認証」という言葉、英語で言うと"authentication"、言葉として馴染みが薄いかも知れませんが、ここでは「相手が何か(誰か)、想定した通りの相手かどうかを確認すること」ということになります。⁴

何の役にたつの?

先ほどの説明だけでは、まだイメージが掴みにくいかも知れません。ここで情報セキュリティの用語と照らし合わせてみましょう。

SSL/TLSで得られるのは、機密性"confidentiality"、完全性"integrity"、真正性"authenticity"⁵の3要素です。それぞれ具体的には次のようなリスク対策となります。

• 機密性
  通信内容が他者に漏れないこと
  ※「他者」には、通信を中継しているスイッチ等の機器およびそれらの管理者も含む⁶
• 完全性
  通信内容に改ざんがあれば、それに気付けること
• 真正性
  通信相手、一般にWebサイト運用者(サーバー)側になりすましがあれば、それに気付けること⁷

先ほどの「認証」に対応するのがこの「真正性」です。つまり、例えばhttps://qiita.com/の一部であるこのページがブラウザのエラーなく表示されていれば、それは確かに qiita.com から発信されていること、なりすましを行われていないことの保証になるのです。

なぜ認証が重要なの?

さてここで少し話を戻します。

良くある説明はこうです。「通信の暗号化」
このように覚えてる方もいるでしょう。確かにこれは間違いではありません。しかし正解とも言えません。

と上で述べました。

そう。まず「認証」を持ってこなければなりません。

とも。では、なぜ認証 ( なりすまし検出 ) が重要なのでしょうか?

冒頭で紹介したtogetterまとめでは、「ホテルで密会する人がフルフェイスヘルメット着用で誰だか判別できない状況で、果たして密会の意味があるか?」というような喩えを使いました。

ここで、このQiitaのページを見るようなWebの通信はTCP/IPに基づきますので、DNSサーバ等によりドメイン名からIPアドレスと名前解決され、そのIPアドレスにより通信相手の特定されルータ等の中継機器を経て、意図した相手と通信できるようになっています。
しかし、そこに攻撃が介在した場合、本当に意図した相手と通信できているかの保証はないのです。⁸

次の図に示すように、もし認証がなくなりすまし⁹を受けた場合、その状況から暗号化ができたとしても意味がありません。意図した相手以外の他者に通信内容を漏らしたくないからこその暗号化にも関わらず、そもそも意図した相手と通信できていないからです。
認証があるからこそ意図した相手と通信できていることが保証され、暗号化にも意義が生まれるのです。

どうやってなりすましか判断するの?

ということで、SSL/TLSでは認証機能が重要だと説明してきましたが、しかし、どうやってなりすましかどうかを判別できなければ意味がありません。

最低限の条件

最低限の条件はもちろん、SSL/TLSが有効になっていることです。今時のブラウザであれば、錠前型のアイコンが出ることでそれと分かります。以下、Internet Explorer 11 の画面を例に挙げて説明します。

逆に、何らかの問題がある場合は次のように分かり易い画面で警告してくれます。¹⁰ブラウザのアドバイスにある通り、すぐにブラウザを閉じるべきです。

もう1つ大事な条件

しかし、「じゃあ錠前アイコンが出てれば安全ね!」と短絡的に考えてしまうようだと問題があります。もう1つ大事な条件があるのです。
それを意識しないと、次のような状況でコロっとニセサイトに騙される羽目になります。

この画像にある2つのサイト、どちらも錠前アイコンが出ていて、どちらもQiitaのサイトに見えますが…?

はい。サイトの絵面だけで判断してはいけません。幾らでも本物のサイトを模倣することができるからです。見るべきポイントはブラウザのURL欄のドメイン名です。

次の図のように、左側はQiitaの正しいドメインであるqiita.comがURLとなっており、しかも錠前アイコンが出ているので本物です。しかし右側はそもそもドメイン名が違います。なので、Qiitaを模倣しただけのニセサイトと見做すべきなのです。¹¹

つまり、本物かそうでないか、サイトを識別するキーは「ドメイン名」になっているということです。SSL/TLSの認証機能は、そのサイトが意図したURLのドメインのサイトであることを判断してくれるものです。
逆に言うと、そのサイトの正しいドメイン名が何であるかは事前に把握しておかねばなりません。上ではqiitaっぽいドメイン名であってもニセサイトである例を挙げました。ドメイン名が何となくそれっぽいというのでは不十分です。¹²

運営組織情報の照会(一部限定)

一部のサイトでは、運営組織情報が分かるようになっている場合があります。

以下は三井住友銀行のサイトの例です。錠前アイコンの所にも少し出ていますが、アイコンをクリックすることで、三井住友銀行の組織名(英語表記)が現れます。

SSL/TLSで認証機能がある以上、その背景には「認証局(CA)」という、そのサイトの正しい運営者であることを認定する組織¹³があり、そこでの認定レベルにも、DV/OV/EVと種類があります。

EVの場合は、ドメイン名のみならず組織情報等も確認するプロセスを経て認定が行われており、更にブラウザで情報が出るようになっています。
このようなサイトでは、本物のサイトにアクセスしているかどうか、ドメイン名だけでなく組織名という判断材料が増えているということです。¹⁴¹⁵

なりすまし判断のまとめ

一旦、SSL/TLSでのなりすましの判断についてまとめます。

• SSL/TLSが有効になっていることを確認すること
• ブラウザのURL欄にあるドメイン名が意図通りであることも確認すること
• サイトの造りや絵面は、なりすましかどうかの判断には使えない
• 事前に正しいドメイン名を把握しておくこと、それらしいドメイン名というだけでは不十分
• EVのサイトの場合は、サイトの運営組織情報も判断材料とできる

SSL/TLSの前提条件

SSL/TLSを有効に働かせるための条件

ここまで、特に認証に重点をおいて機能を説明してきました。

しかし、SSL/TLSが有効に働くには幾つかの条件があります。それについても把握しておく必要があるでしょう。

• SSL/TLSを使うソフトウェアやOSを乗っ取られないこと
  ものすごく当たり前に見えることですが、ブラウザやPCそのもの、サイト側のサーバがマルウェアに感染するなどして乗っ取られては意味がありません¹⁶。中継機器が乗っ取られたとしても最悪エラーになるだけで済みますが、自分か相手、当事者が乗っ取られた場合は前提が崩れてしまうということです。
• アクセスするサイトの正しいドメイン名を把握すること
  上で説明したとおり、サイトを識別するキーはドメイン名です。アクセスしたいサイトがどういったドメイン名なのか、事前に確認する責任はユーザにあるのです。
• SSL/TLSを使うソフトウェアをなるべく最新に保つこと
  コンピュータの能力は日々進歩し、過去の暗号方式では十分な強度を保てず、短時間で破られてしまう懸念があります。加えて、SSL/TLSの規格自体も弱点の発見とその改善とを繰り返しています。なので、ソフトウェアをなるべく最新の状態にする必要があります。
• 適切な認証局が適切にサイト運営者を認定すること
  これはユーザが関わり辛い点ではありますが、認証局の認定プロセスに瑕疵がある場合なりすましの余地が生まれ、SSL/TLSの信頼性が揺るぎます。実際に過去には、それによって信頼を失った特定の認証局がブラウザで管理しているリストから外されるという話¹⁷もありました。
  ただユーザとしても、不適切な認証局を信頼するような設定をうかつに入れない¹⁸といった知識は持っておくべきではないかと思います。

SSL/TLSでできないこと

これはあまり巷で見かけないのですが、SSL/TLSと言えど何でもできるわけではありません。そこで、何ができないかについても触れておきます。

• 可用性の向上
  可用性(availability)というのも情報セキュリティ用語の1つであり、必要な時に情報にアクセスしたりサービスを利用できることを指します。しかし、SSL/TLSを利用したからといってDOS(サービス妨害攻撃)を防げるわけではないため、直接可用性の向上に寄与するわけではありません。
• 否認防止
  否認防止(non-repudiation)というのも情報セキュリティ用語の1つです。Webサービスであれば、ユーザが確かにそのサイトに特定のリクエストを送ったこと、サーバから特定のコンテンツが送られてきたこと¹⁹を後から立証する(言い逃れできなくする)ことを期待するものです。しかし意外かもしれませんが、SSL/TLSに否認防止の機能はありません。通信している当にその時、確かにその内容を遣り取りしていることを当事者は当てにできますが、後から第三者に立証することはできないのです。²⁰
• サイトの正しいドメイン名の確認
  前提のところで触れた通り、アクセスしたいサイトの正しいドメインが何であるかを確認するのはユーザの責任であって、SSL/TLSの機能の範囲外です。Google等の超有名サイトであればそうそう間違えようがない話ですが、そうでない場合、正しいドメイン名をどう確認するかは情報の信頼性確保という極めて社会的な問題になります。
• そのサイト自体の信頼性確保
  ドメイン名も把握している、SSL/TLSも機能している、加えてEVによって運営組織がどこかの確証も取れている。それであってもそのサイトが信頼できるか、例えばクレジットカード情報等の重要情報を渡しても問題ないかどうか、サイトからダウンロードしたデータがウイルス等に感染していないかどうか、そういった信頼性の保証にはなりません。これはそのサイトの社会的信用の話であるからです。

暗号という言葉の問題点

冒頭で紹介したtogetterまとめのタイトルを、当時「『暗号』という言葉が暗号技術の理解の妨げになるというお話」としました。

その意図についても、最後に触れたいと思います。

暗号という曖昧な言葉

端的に言うと、もはや「暗号」という言葉の持つ意味の幅が広すぎて曖昧なのが問題なのです。

加えて、暗号の持つ元々のイメージ、それはホームズの踊る人形であったり、大戦時のドイツが用いたエニグマであったり、いずれも当事者のみが持つ知識や技術、それによって第三者への情報漏洩を防ぐもの、このイメージにどうしても引き摺られてしまうのです。²¹

技術の総称としては、今更「暗号」以外の言葉を生み出す余地はないでしょうが、人に誤解を与えないよう説明するためには、なるべく個々の技術・機能を表す言葉を選んだ方が良いだろうと思います。

暗号化という言葉の生み出す誤解

もちろん「暗号化」というのは、SSL/TLSの重要な機能の1つです。しかし、暗号の持つ元々のイメージに沿っている言葉であるがためこれだけで完結してしまい、重要な認証が見過ごされてしまうという欠点があります。

これは別に私の勝手な懸念ではなく、過去実際に「オレオレ証明書」という言葉と共に、セキュリティ研究者である高木浩光氏が問題提起されていました。²²尤も当時、認証という言葉が殊更にクローズアップされてはいなかったように記憶していますが。
この問題を単純化して言えば、正式な認証局からの認定を受けていない状態でSSL/TLSを運用しようというもので、いわば「身分証なんて自作で十分」と主張するようなものですから、認証という機能からは当然論外なお話ですし、認証という前提が崩れている以上、暗号化の意義すらなくなります。

以降、流石にオレオレ証明書問題自体は広く認識されるようになったかと思いますが、しかし認証が見過ごされている状況は依然残っているように思えます。
例えば銀行に期待した「常時SSL」その後にある当時のセブン銀行のコメントからもはっきり見て取れます。曰く、

ホームページは社外向けの公開情報のみですので、今後もHTTP通信で問題はありません。
ダイレクトバンキングサービスは顧客情報をお預かりしていますので、現在HTTPS通信を行っています。

つまり、暗号化による機密の確保しか意識がなく、認証によるなりすまし対策の効果がすっぽり抜けていたということです。
※同行の名誉のため補足すると、現在のセブン銀行のサイトは、バンキングサービス以外も常時SSL/TLSに対応しているようなので、認証についても意識をされているのだと思います。

どうしてこうなるのか。あくまで私の考えではありますが、皆が一般に元々持っている暗号のイメージ、これは当事者以外(必要な情報・技術がないので)暗号を解読することができないことで、「暗号を扱える者=当事者として信頼できる者」という暗黙の前提ができてしまい、当事者同士がそういった情報を共有していないところから認証を実現する現代の暗号技術への理解とズレができてしまっているからではないか、と考えています。

そもそも「暗号化」という言葉自体、「電子署名=『秘密鍵で暗号化』」という良くある誤解の話であったり、またSSL/TLS自体も該当しますが、現在のハイブリッド暗号の説明として「共通鍵暗号用の鍵データを公開鍵で暗号化して送り、相手は秘密鍵で復号する」と言った不適切な説明²³が流通していることから、やはり誤解を拡大する言葉なのかなあとも考えています。

おわりに

一度まとめておいた方が良いかなと思い記事にしました。
もちろん、世の中SSL/TLSの認証機能をキチンと説明している資料もたくさんあるのですが、ここまで前面に押し出しているのはないのではないかと思っています。
本記事によって、認証についての意識が強まれば幸いです。

脚注

---

1. SSL/TLSという用語: SSLはSecure Socket Layer、TLSはTranport Layer Securityの略です。SSLはTLSの前身であり今となっては時代遅れなのですが、知名度は依然まだまだあるため、本記事では両用語を併記しています。 ↩

2. Web以外でのSSL/TLS: メールの場合、SMTP,POP3,IMAP4にSSL/TLSを使用すると、それぞれSMTPS,POP3S,IMAP4Sとなります。 ↩

3. 認証を持ってこなければ: 実際、InternetExplorer11で錠前アイコンから情報を見ると、認証と暗号化両方の文言が出てきます。(英語だと"identified"と"encrypted") ↩

4. 認証の補足: PCやサーバ機器にログインする時にパスワードを入れる「パスワード認証」、スマホのロックを解除する時の「指紋認証」なんかが認証の例です。実は日本語の「認証」という言葉には複数の意味があったりして紛らわしい面もあるのですが。その点についてはスマホアプリの認証・認可周りを整理したに色々まとめられています。 ↩

5. 真正性"authenticity": 認証"authentication"と同根の言葉ですが、ぱっと見で対応する日本語が大きく違うのは面白いですね。 ↩

6. 通信を中継している～: よく「end-to-endの暗号化」と言われますが、通信を中継している機器にも介入できないというのが大きな特長です。 ↩

7. なりすまし: 前項と同様、通信を中継している機器が介入を行えないという点も重要ですが、例えばDNS詐称等によりニセサイトに接続させられるような状況も検出できるという点も重要です。 ↩

8. 攻撃の介在: もちろん、そういった攻撃が簡単に起こせるとか、対策しなかったらなりすまし放題とか危機感を煽りたいわけではなくて、SSL/TLSはそういった事態に備えた保険になる技術ですよ、ってますよということを言っています。 ↩

9. なりすましの形態: そもそもニセの相手に通信先を誘導されたり ( DNS詐称等 )、悪意を持つようになった中継機器がなりすましたり、あるいは図の3番目のように、なりすましを行いつつも通信を正当な相手へ中継する形態等、色々なパターンが考えられます。特に最後の形態は(2番目も?)中間者(MITM/Man In The Middle)攻撃と呼ばれます。 ↩

10. SSL/TLSに問題がある場合: この例ではQiitaが危険なサイトのように見えますが、あくまでSSL/TLSに問題があることを表しています ( もちろんサイトそのものが悪質なところである可能性もあります )。今回テストで敢えてSSL/TLSに問題を発生させた様子を映した画像であって、Qiitaのサイトそのものに問題があったわけではありません。なお、エラー表示のバリエーションについては、Internet Explorerの場合、Microsoftの証明書エラー:FAQにあります。 ↩

11. ニセサイトの例: もちろんこの例だと、qiita-nisemono.comというサイトとしては本物であることが、SSL/TLSの認証機能によって分かります。ただそれは、Qiitaとして本物かどうかとは別問題です。 ↩

12. それっぽいドメイン名: ちょうどこの記事を書いている2018年夏頃には、佐川急便のニセサイトの問題がニュースになっていました。これも、ドメイン名自体はなんとなくそれっぽいものが使われていたようです ( SSL/TLSではなかったようですが )。もちろんですが、検索サイトで引っかかったから、というのも判断材料としては確実ではありません。 ↩

13. 認証局の役割: ご存じの方も多いでしょうが、認定の結果は、サイト運営者に対してサーバ証明書の発行という形で還元されます。このサーバ証明書が実際のSSL/TLS通信で認証のために使用されます。 ↩

14. 判断材料: 当然ですが、EVなら即信用できるね、と短絡してはいけません。また、組織情報があった方がより判断しやすいのは確かですが、無名の企業の場合、組織名が分かったからといって情報が増えたことにはなり辛いのでどこでもEVを採用する意味があるとは言えません。 ↩

15. 判断材料: とは言え、例えば金融取引を行うようなWebサービスであれば、最低限EVで組織情報が見えていないと使わないようにしよう、という判断基準に使うのは十分あり得る話です。 ↩

16. ブラウザが乗っ取られる: マルウェアの中には、ブラウザあるいはOSを乗っ取ることで、SSL/TLS通信の内容であっても密かに盗聴する、MITB(Man In The Browser)という攻撃を行うものがあります。脚注9番で触れたMITM(中間者攻撃)と良く似た名前ですが、SSL/TLSで防げるMITMと違い、SSL/TLSの前提を覆すMITBは防御できません ( マルウェア対策か、また別の対策を上乗せする必要があります )。非常に紛らわしい嫌な名前付けをしたものだと個人的には思います。 ↩

17. 特定の認証局を外す: Symantecの運営する認証局でこういう話がありました。例えばChromeで信頼されなくなるSymantec発行のSSL証明書かどうか判定・確認する方法に載っています。 ↩

18. うかつに入れない: 認証局の情報は、認証局(CA)証明書というデータとして、ブラウザなりOSに登録されています。もちろん、ブラウザやOSの開発者が信頼できる認証局を吟味して、です。ここにユーザが手動で認証局証明書を追加するというのは原則として行うべきではないと考えましょう。 ↩

19. Webサービスの実例: 例えばユーザが特定のページにアクセスしただとか、オンラインショップで確かに注文を確定しただとか、サーバがそれを受けてある内容を表示した、例えば商品の見積もり金額を提示しただとか、そういった内容が考えられます。 ↩

20. 否認防止がないからと言って: SSL/TLSに否認防止機能はないのですが、とは言えオンラインショッピングであれば、カード取引履歴がカード会社側に残ったり、商品の発送と言った形で別の証跡が残るわけなので、完全に「言ったもの勝ち」になるわけではありませんが。 ↩

21. イメージに引き摺られる: 何かの技術体系を学ぶとして、過去から順を追って歴史を辿るというのは、決して無益なことだとは思いません。しかし暗号技術については、特に1976年のディフィー・ヘルマンの鍵交換をはじめとする公開鍵暗号のアイデア等によりガラリと世界が変わってしまいました。一部の天才ならまだしも、私のような凡人が、歴史を辿ってその転換を追うなんてことは相当キツイことだと思っています ( 天動説に慣れた人が地動説に切り替えられたかどうか考えてみて下さい )。であれば、慣れ親しんだ、しかし古い概念から辿ろうとするよりは、最初から新しい概念で話をした方が、誤解もなく理解への近道になるだろうと考えています。 ↩

22. オレオレ証明書: 例えば高木浩光氏の自宅の日記2007/11/17分等で、当時の状況が分かります。 ↩

23. 公開鍵で暗号化: SSL/TLSで言えば、2018年現在流通しているTLS1.2規格でもそういう方式は残っているため、完全な誤りではありません。しかしPFSの観点から数年前にやっとSSL/TLSでも非推奨となった方式であり、これを第一に持ってくるとしたらやはり不適切な説明です。なお、類似のハイブリッド暗号技術であるSSH(Secure SHell)では、2000年以前から出回っているSSHv2プロトコルからしてそんなことは微塵も行っておらず、完全に不適切と言えます。 ↩