サイバー攻撃を受けるリスクが広く知られ、インターネット通信の安全性が重要視されるようになって久しい。しかし、一般的には、SSLやTLSなどの暗号化通信に関わる用語だけが一人歩きしているような状況かもしれない。この記事では、SSLとTLSの概要と違い、そしてそうした技術に潜む危険性について解説していく｡
本記事は2020年9月3日に掲載した「安全な接続方法「SSL」や「TLS」とは？」に加筆修正をしたものです。
SSLとTLSはどのように生まれたのか
SSL（Secure Sockets Layer）やTLS（Transport Layer Security）はインターネット上における通信データを暗号化することで、データの秘匿性を確保するための技術である。そもそも、インターネットにおける通信はパケットと呼ばれる単位で送受信され、原則として暗号化されない。
というのも、インターネットの送受信技術のベースが登場したタイミングでは、今のような全世界的な利用が想定されていなかった。当時、基本的には閉鎖的な環境でのやり取りを前提として設計されたため、通信を暗号化して送受信するという考えには至らなかったのだ。
しかし、1991年にインターネットの父とも言われる、ティム・バーナーズ＝リー（Tim Berners-Lee）によって、インターネットの概念およびWorld Wide Webと呼ばれるWebブラウザーの開発をきっかけに、インターネット利用が普及していくことになった。その過程で、送受信するデータの盗聴リスクが顕在化し、データ暗号化の必要性が認識されるようになった。
SSLのWebブラウザーへの実装は、当時の主要ブラウザーであったNetscape Navigatorの開発元であったネットスケープ社によって進められた。当初開発されていたSSL 1.0では致命的な脆弱性が発覚したことから実装は見送られ、その修正を受けて1994年にSSL 2.0としてリリースされるに至った。
| SSL1.0、SSL2.0 | 1990年代に発表 |
|---|---|
| SSL3.0 | 1995年にリリースされたが、現在は利用禁止 |
| TLS 1.0 | 1999年に発表され、SSLから移行 |
| TLS 1.1 | 2006年に発表 |
| TLS 1.2 | 2008年に発表 |
| TLS 1.3 | 2018年に発表 |
SSL、TLSのバージョンと発表年
その後、SSL 2.0が抱える多数の脆弱性を解消したSSL 3.0が1995年にリリースされた。以降、多くのWebサーバー、ブラウザーへ実装されていくことになる。一方で1999年には、IETF（Internet Engineering Task Force）と呼ばれるインターネット技術の標準化、規格を策定する委員会において、TLS 1.0が公表された。
SSLとTLSには原則として互換性がなく、しばらくは併存していたものの、2014年に発覚したPOODLE攻撃に対する脆弱性を踏まえ、TLSへの完全な移行が推奨されることになった。その結果、実質上暗号化通信はTLSに一本化されることになり、SSL自体は暗号化技術としての役目を終えることになった。
しかし、インターネットの歴史において、長らく暗号化通信の代名詞としてSSLが使われてきたことから、今なお暗号化通信を表す言葉としてSSLは用いられる。「SSL/TLS」のように併記されるのはこういった背景が理由であるが、現在では暗号化通信の技術としてはTLSの系譜の技術が利用されている。
SSL/TLS通信とは
盗聴や改ざん、なりすましを防ぐことを目的とした暗号化通信のプロトコルを総称してSSL/TLSと呼ぶ。暗号化通信は今や広く普及し、Webブラウザーを用いてのWebサイトへのアクセス、メールやFTP（File Transfer Protocol）、VPN（Virtual Private Network）などで利用されている。
中でも、オンラインバンキングやECサイトのような金銭のやり取り、あるいは個人情報を収集するようなWebサービスの場合、SSL/TLSの導入は必須とも言える。SSL/TLSの暗号化通信に対応しているWebサイトではWebブラウザーのアドレスバーに鍵のマークが表示される。また、検索エンジンを提供するグーグル社などによる啓蒙活動の結果、ほとんどのWebサイトでSSL/TLSが導入されるようになった。
SSL/TLSを用いた通信は、WebサイトとWebブラウザー間の通信だけではなく、メールサーバーでも利用されてきた。メールクライアントとメールサーバー間のSSL/TLS通信においては、受信時の「POP over SSL/TLS」、送信時の「SMTP over SSL/TLS」の設定が可能となっている。
サーバー証明書とは
SSL/TLSを用いた暗号化通信の際、サーバーとクライアントでは図1のようなやり取りが行われている。共通鍵暗号方式と公開鍵暗号方式の双方を組み合わせているのが特徴と言える。このような複雑な仕組みになっているのは、通信に関わるさまざまな脅威から守るためだ。これら一連のやり取りにおいて、サーバー証明書は重要な役割を担っている。
図1：暗号化通信における送受信プロセス
送受信のプロセスでは、サーバー証明書の公開鍵を使った暗号化通信によって盗聴を防いでいる。また、暗号化通信にハッシュ関数を含めることで、通信途中での改ざんを検知する。なお、サーバー証明書は、第三者機関がサイト運営元を保証するため、なりすまし対策としても有効だ。サーバー証明書は、認証のレベルによって種類が異なり、担保される安全性のレベルも変わってくる。以下にそれぞれの概要を紹介する。
ドメイン認証（DV）
ドメイン名の利用権のみを認証する。無料のものもあるなど、低価格かつ短期間で容易に取得できるのが特長だ。ユーザーのデバイスとWebサーバー間の暗号化通信を目的とするため、WebサイトやWebサービスの運営元の実在証明は行われない。そのため、「なりすまし」を防ぐ効果は極めて限定的と言える。
近年、無料で利用できる「Let’s Encrypt」といったサーバー証明書もあり、フィッシング詐欺サイトではこうした暗号化通信の証明書が利用されているケースが多くを占めている。こうした背景からも、もはやドメイン認証の導入が安全性を担保しているわけではないと認識しておく必要があるだろう。このように、証明書のレベルとしては高くないため、社内サーバーやメールサーバーなどに適した認証レベルと言える。
企業実在認証（OV）
第三者機関によって、ドメイン名の利用権やWebサイトの運営組織が実在することを証明する。登記事項証明書や電話確認を元に審査が実施されるため、DV認証と比較すると、信頼性が高いと言える。企業・組織のWebサイトや会員情報を保持するWebサービスなどに利用され、ユーザーからの信頼性を向上させる効果が期待できる。
EV認証（EV）
EVはExtended Validationの略であり、先述の企業実在認証（OV）を拡張したものとして提供されている。企業実在認証よりも厳格な審査が必須であり、Webサイトの運営組織が信頼できる点を証明するため、組織の物理的存在、承認者・署名者の認証などが行われる。ECサイトやオンラインバンキングなど、強固なセキュリティが求められるサイトなどで利用される。
なお、サーバー証明書は図2のように、パソコンではユーザーでも容易に確認することができる。ただし、スマートフォン（以下、スマホ）の場合、利用するWebブラウザーによっては確認できない場合もある。参考までに、iPhone版のGoogle Chromeではアドレスバーの「・・・」から、表示される「サイト情報」のメニューをタップすることで確認が可能だ。
図2：サイバーセキュリティ情報局の証明書の例
SSL/TLSに関連する脆弱性
そもそも暗号化通信を利用する経緯を踏まえると、関連する技術が脆弱性を抱えている状態は深刻な被害を招きかねない。しかし、日夜進化を遂げるインターネット技術においては時に脆弱性が生じる。SSL/TLS通信においても、過去に以下のような脆弱性が指摘されてきた。
Heartbleed
SSL/TLS通信を実装するライブラリである、OpenSSLからデータが不正に読み取られる可能性が指摘された。「ハートビート」と呼ばれるOpenSSLの拡張機能を用いることで、ログが残されずにシステムメモリーから情報が漏えいするというこの脆弱性は、多大な被害を及ぼす可能性があったことから、致命的な脆弱性として、当時大きな話題となった。
POODLE
先述のとおり、SSL3.0が原則利用禁止になるきっかけとなった、深刻な脆弱性として知られている。WebブラウザーとWebサーバー間でやり取りされるデータのうち、クッキーなどに保存された個人情報・機密情報が盗聴されてしまう可能性があった。この脆弱性を受け、WebブラウザーではSSL 3.0が無効化されたバージョンを配付。SSL3.0を利用していたWebサーバーではSSL 3.0を無効にし、最新のTLSを利用することが勧告された。
FREAK
2015年に複数のライブラリで発見された脆弱性であり、「Factoring RSA Export Keys」の略である。過去に利用されていた、強度の弱い暗号鍵を狙い、MITM攻撃によって通信内容を盗聴・改ざんするといった攻撃が可能となる脆弱性だ。該当するライブラリを無効化し、強固な暗号システムを採用したライブラリに更新することで対応がされた。
LogJam
同じく2015年に発覚した脆弱性として知られるのがLogJamだ。DH（Diffie-Hellman）鍵交換における脆弱性であり、この脆弱性を悪用することで、MITM攻撃が可能になり、暗号強度が下がって通信内容が盗聴されてしまう恐れがあった。
POODLEの脆弱性が発覚した結果、SSLは実質的に利用されなくなったが、TLSも過去のバージョンを含めて脆弱性が発覚している。Heartbleedはその代表例とも言えるが、先述のようにほかにも多くの脆弱性が過去に発覚している。2023年時点で最新バージョンであるTLS 1.3は過去のバージョンの問題点を踏まえて策定されたことから、セキュリティ面、パフォーマンス面で改善を図っている。
SSL-VPNに関する脆弱性
近年、パソコンやスマホなどのモバイル端末が支給され、オフィス外からVPN経由で社内システムへアクセスする機会も増えている。このような場合に利用されるのがSSL-VPNと呼ばれる技術だ。しかし、こうした技術を実装するための製品、ソリューションが脆弱性を抱えている場合がある。過去に大手VPN事業者の製品に脆弱性が発覚したこともあった。
また、SSL/TLSのサーバー証明書を複数のWebサイトで利用できるワイルドカードについて、その多用を危険視する注意喚起がNSA（米国家安全保障局）からされている。SSL/TLS通信が実装されているからといって、万全ではないという認識がサービスの提供事業者、ユーザーにも求められていると言えるだろう。
総合的な対策でWebサイトの安全性確保を
ビジネス環境の変化により、かつてないほどにコンプライアンスが重視される時代となった。また、関連して情報漏えいも厳しく問われることとなり、企業・組織における情報セキュリティに対する意識は以前と比較すると高まっている。コロナ禍を経て急速に進んだデジタル化を踏まえて、さまざまな対策を講じた企業・組織も少なくないだろう。
しかし、デジタルの世界では日夜技術革新が進んでおり、そうした技術の悪用を試みる攻撃者の存在がある。すなわち、そうした動きを踏まえ、企業・組織においてもセキュリティ対策を定期的にアップデートしていくことが求められている。
サイバー攻撃の巧妙化は著しく、そうしたセキュリティリスクを適切に評価せず対策を講じなければ、結果として被害は甚大となり得る。その結果として、経営を揺るがしかねないほどの影響を及ぼす可能性もあるとの前提に立ち、自社が提供するWebサイト、Webサービスにおいても適切な対策を講じること、そしてその対策を状況に応じて継続的に改善していくことが重要だ。
