今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景

まず、HTTPSとは何か、その機能や仕組みを簡単に説明します。

HTTPSは、HTTP over TLS、つまり、TLS（Transport Layer Security）上でHTTP（Hypertext Transfer Protocol）を使うプロトコルを意味します。通常のHTTP通信とHTTPS通信の違いを簡単に表すと、以下の図のようになります。

HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。

HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途中の経路で第三者がHTTPデータの中身を見たり変更を加えたりすることが可能です。

一方、HTTPS通信では、TCPハンドシェイクに続いてTLSハンドシェイクを行います（詳細は後述）。TLSハンドシェイクの途中から暗号通信が始まり、TLSハンドシェイクが完了すると、暗号通信のままHTTPリクエストとレスポンスを交換します。

HTTPS通信が行われているWebブラウザでは、安全な通信ができていることをWebページの閲覧ユーザに示すために、アドレスバーに鍵のアイコンを表示します。鍵のアイコンが具体的にどのように表示されるのかはブラウザによって異なります。上の図ではGoogle Chrome 63のアドレスバーを例示しています。

TLSが提供する機能

前節で見たように、HTTPS通信がHTTP通信と大きく違うのは、HTTPリクエストとレスポンスのやり取りに先立ってTLSというプロトコルを利用するための手続き（TLSハンドシェイク）を実施する点です。 このTLSによって提供される機能には、大きく以下の3つがあります。

• 機密性

  通信データを暗号化して途中のネットワーク経路でデータの中身を見ることができないようにする機能です。パスワードやクレジットカード情報など重要なデータが第三者に漏洩することを防ぎます。

• 完全性

  データを単純に暗号化して機密性を確保しても、それだけでは十分に安全ではありません。暗号化でデータの中身がわからなくても、攻撃者は暗号化されたデータの一部をビット反転させることで、データを改ざんできます。このような攻撃を防止するには、メッセージ認証（MAC：Message Authentication Code）を導入する必要があります。メッセージ認証によって通信データの完全性を確保し、途中経路でデータが改ざんされることを防ぎます。

• 真正性

  不特定多数が利用するインターネットの通信では、直接顔を見て通信相手を認識することはできません。通信相手を識別する手段は、ブラウザのアドレスバーに表示されるURLだけです。平文通信のHTTPでは、途中の経路上で、誰でもそのURLを持つサーバに成りすますことができます。HTTPS通信では、認証局が発行したサーバ証明書をブラウザが使ってアクセス先が正当かどうかをチェックすることにより、成りすましを防げます。

TLSのハンドシェイクの仕組み

TLSでは、これら3つの機能をどうやって実現するのでしょうか？ 先ほど、HTTPS通信ではHTTPに先立ってTLSハンドシェイクを行うと説明しましたが、このTLSハンドシェイクの中身を見るとその仕組みがわかります。TLSハンドシェイク自体にはさまざまな形態がありますが、ここでは、その中で現在のHTTPS通信で最も代表的な方式¹を取り上げます。

TLSのハンドシェイクは、以下の図の通り大きく4つのステップに分けることができます。

1. パラメータの交換

最初に、TLSの通信を実現するために必要なパラメータをクライアントとサーバ間で合意します。合意するパラメータは、暗号方式や鍵交換のアルゴリズム、各種拡張機能の利用の有無など、さまざまな項目にわたります。

パラメータの合意では、まずクライアントの側から複数の候補をサーバに対して提示する（ClientHello）というのがTLSプロトコルの原則です。サーバは、クライアントから提示された候補の中から最適なものを1つ選び、その値をクライアントに返します（ServerHello）。このClientHelloとServerHelloの交換によって、サーバとクライアント間でTLS通信に必要なパラメータを合意します。なお、このやり取りはすべて平文通信で行われるので、通信経路上の第三者は中身を見ることができます。

2. サーバ認証

安全なHTTP通信のためには、真正性、つまりユーザが接続しているのが本当に意図したHTTPSサーバなのかを保証する機能も必要です。これには、TLSによって提供されるサーバ証明書を使った認証の仕組みが利用されています。

サーバ証明書は、HTTPSサーバからクライアントに送信される情報です（Certificate）。このサーバ証明書をクライアントが検証することでサーバの真正性を確保しようというのが、TLSにおけるサーバ認証の第1段階です。

サーバ証明書の検証では、信頼に足る認証局から発行された正式な証明書であることを確かめるため、トラストアンカーと呼ばれる認証局のルート証明書を使います。そのようなルート証明書は、HTTPSに対応しているクライアントの内部にあらかじめ登録されています。あらかじめ登録されていることからわかる通り、トラストアンカーは、ブラウザやOSのベンダによって「信頼できる」とみなされた認証局のルート証明書です。

サーバから送信されたサーバ証明書をトラストアンカーで直接検証できれば話は簡単なのですが、一般には中間証明書と呼ばれるものも必要になります。これは、ルート証明書の秘密鍵は認証局の業務にとって非常に大切なものなので、普段はオフラインで厳重に管理されており、認証局における普段のサーバ証明書の発行業務ではルート証明書が使われていないからです。

代わりに、ルート証明書で署名された別の証明書を使ってサーバ証明書が発行されています。そのような証明書が中間証明書です。中間証明書は、ルート証明書と違って通常はクライアントにあらかじめ登録されていません。そのため、HTTPSサーバでは、Certificateメッセージでサーバ証明書と中間証明書の両方をクライアントに送信します。

これらの証明書を受け取ったクライアントは、証明書に記載されている有効期限や用途・名前などの項目をチェックし、ルート証明書までサーバ証明書と中間証明書の署名を検証します。そして、認証局が提供する証明書の失効情報に問題なければ、送られたサーバ証明書は正当なものであると判断します。

サーバ証明書のチェックが終わればそれで十分安全というわけではありません。サーバ証明書自体は公開されているものなので、第三者がサーバ証明書を丸ごとコピーしてクライアントに送りつけるということも可能です。それをクライアントに見分けてもらうには、サーバは正当な証明書に対応した秘密鍵を持っていることを立証しなければなりません。そのためサーバは、サーバ認証の第2段階として鍵交換（後述）で使うデータを秘密鍵で署名しクライアントに送付します（ServerKeyExchange）。

サーバから署名情報が付加されたServerKeyExchangeを受け取ったクライアントは、証明書中の公開鍵を使って署名検証を行います。この署名検証に成功すれば、アクセスしているサーバが正当な証明書と秘密鍵を持つものであると立証されたことになります。サーバ証明書のチェックと署名検証、この2つが成功すればクライアントによるサーバ認証は完了です。

3. 鍵交換（ECDHEの場合）

サーバ認証が完了したら、次に鍵交換を行います。現在、広く利用されているのは、楕円曲線上の公開鍵暗号方式を使ったECDHE鍵交換（Elliptic Curve Diffie–Hellman Ephemeral key exchange）と呼ばれる方式です。

どの楕円曲線でどういったパラメータを使って鍵交換を行うのかといった情報は、ClientHello/ServerHelloを交換したときに既に合意されています。そこで合意した鍵交換方式に従い、サーバとクライアントでは、暗号化やメッセージ認証で使う共有鍵を計算します。ただし、この共有鍵は、Forward Secrecy（前方秘匿性）を実現するため、一回のTLSハンドシェイクでだけ有効な一時的なものにします。ECDHE方式の最後のEは、一時的な（英語でephemeral）共有鍵を生成する鍵交換であることを示しています。

一時的な共有鍵は、原則として、TLSの通信が終わったら廃棄します。そのため、この先サーバに不正侵入されることがあっても共有鍵の情報を盗まれる恐れはなく、TLSで暗号化された通信データの秘匿性が将来にわたって守られます。これが前方秘匿性と呼ばれている理由です²。

クライアントとサーバは、TLSハンドシェイクごとに一時的な公開鍵と秘密鍵のペアを生成しなければなりません。このとき生成した一時的な公開鍵を互いに交換し、各自が持つ秘密鍵と組み合わせて同じ楕円曲線上の点を計算します。この同一点の情報から共有鍵のデータを導出すれば鍵交換は終了です。

4. 暗号化通信の開始、ハンドシェイクの改ざんチェック

鍵交換が終わったら、生成した共有鍵を利用して暗号化通信を開始できます。サーバとクライアントは暗号通信を始める合図を送ります（ChangeCipherSpec）。

最後は、TLSハンドシェイクデータが改ざんされていないかチェックするために、これまで送受信したTLSハンドシェイクデータのハッシュ値を相手に送ります（Finished）。TLSハンドシェイクでは、ChangeCipherSpec以前のやり取り（この記事の「1. パラメータの交換」から「3. 鍵交換」まで）はすべて平文通信なので、通信経路上の第三者によって改ざんされている恐れがあるからです。Finishedを送る段階では既に暗号化通信が行われており、第三者がFinishedの中身（TLSハンドシェイクのハッシュ値）を改ざんすることは不可能です。クライアントとサーバそれぞれの視点でTLSハンドシェイクデータのハッシュ値が一致していれば、経路の途中でやり取りが改ざんされていないことが確かめられます。

以上でTLSハンドシェイクは完了です。この後は、HTTPリクエストやHTTPレスポンスといったアプリケーションのデータを引き続き暗号化して送受信します。

安全なTLS通信は、安全な認証と鍵交換の仕組みをいかに実現するかにかかっています。これを実現するTLSハンドシェイクによって、TLS通信の機密性、完全性、真正性が保証されているのです。

全面的なHTTPS化へ向けて

一昔前までのHTTPSの使われ方

TLSが実現する機能やハンドシェイクの仕組みは、基本的に、TLSの前身となる20年以上前のSSL 3.0の頃から技術的に大きく変わっていません。しかし、その使われ方は最近になって大きく変わりつつあります。

インターネット上のWebサービスでは、不特定多数の相手と情報のやり取りを行うのが一般的です。そのため、重要なデータを扱う際には、昔から暗号化された通信であるHTTPSを使うのが当たり前でした。

2010年に入ると、一部の大手のWebサービスを筆頭に、すべての通信をHTTPS化する対応が始まりました。これは、途中の経路でデータの改ざんが可能なHTTP通信が存在していると、第三者によって勝手に広告が挿入されたり、国策でコンテンツを検閲して通信が制御されたりする場合が増えてきたためです。たとえば、GoogleのGmailは2010年から、Twitterは2012年から全面的にHTTPS化し、初期接続からすべてHTTPSを使うようになりました。

一方で、GoogleやTwitterほど大きくない一般のWebサイトでは、つい最近までセキュリティ上重要な部分にのみHTTPSを利用するのが一般的でした。HTTPSを全面的に導入するには、サイト構成の変更や証明書の取得にかかるコストの増加、必要なサーバ性能の確保など、運用面での課題が少なくありません。特に、HTTPとHTTPSが混ざるmixedコンテンツを避けるためには、広告など他のリソースのHTTPS化が先に必要になります。そうした事情から、サービスを全面的にHTTPS化することに対して二の足を踏むサイトも多い状況でした。

国家的かつ広範囲な盗聴行為（Pervasive Surveillance）が明るみに

2013年6月、エドワード・スノーデンによって、NSA（米国国家安全保障局）とCGHQ（英国政府通信本部）による国家レベルの広範囲な盗聴行為が明らかになりました。スノーデンが公開した資料には、これらの組織が通信キャリアと協力し、データセンター内やインターネットバックボーンに盗聴や改ざんの仕掛けを設置したことが記されていました。ほかにも、搬送途中のネットワーク機器を横取りしてバックドア入りのファームウェアに入れ替えて再出荷したり、暗号の標準化策定作業にかかわってアルゴリズムにバックドアを仕込んだりと、驚くべき内容が書かれています。

この記事で特に注目したいのは、匿名通信のTorクライアントを特定するためにHTTPなどの平文通信を中間者攻撃で改ざんして未知のマルウェアを感染させる仕組みを入れていた、という内容です。この攻撃については、著名な暗号学者のBruce Schneierが次のブログで解説しています。

How the NSA Attacks Tor/Firefox Users With QUANTUM and FOXACID - Schneier on Security（NSAはどうやってQUANTUMとFOXACIDを使ってTor/Firefoxユーザを攻撃したのか）

この記事によると、NSAは膨大なトラフィックが流れるインターネットバックボーンにQUANTUMというシステムを設置し、HTTPの平文通信を横取りして中間者攻撃を仕掛け、FOXACIDというシステムを使って未知のマルウェアを送り込んで端末を感染させていたということです。サービス提供者には、自サイトにアクセスしてきたユーザがこのような攻撃を受けていることを知る由もありません。HTTPのままでは防ぐことも不可能です。

大手のWebサービス提供者にとって、このような大規模な攻撃が実際に行われていたことは非常に衝撃的な事実でした。対策には、機密性・完全性・真正性を実現するHTTPSの導入しかありません。

すべてHTTPS化する理由

エドワード・スノーデンが公開した内容によって明らかになったのは、国家的な規模の予算をかけてコンピュータリソースを投入し、通信キャリアの協力も得られれば、従来は机上での概念実証レベルでしかなかった大規模な攻撃でも現実的な脅威として存在するということでした。この状況に危機感を抱いたIETF（Internet Engineering Task Force）は、2014年5月に「RFC7258: 広範囲の盗聴行為は攻撃である（Pervasive Monitoring Is an Attack）」という文書をまとめ上げ、これらの国家的な広範囲の盗聴行為に対して技術的な対応措置を行うことを明言しました。幸い、スノーデンからは、最新の暗号技術でしっかり守られた通信に関してはまだ破られていないという証言が得られています。

さらに、IETFの上位組織であるIAB（Internet Architecture Board）からは、2014年11月に「インターネットの信頼性に関する宣言（IAB Statement on Internet Confidentiality）」が公開されました。

この宣言の内容は、

• 新しくプロトコルを設計する際には、暗号化機能を必須とすべき。
• ネットワーク運用者やサービス提供者に暗号化通信の導入を推進するよう強く求める。
• コンテンツフィルターやIDSなど平文通信が必要な機能については将来的に代替技術の開発に取り組む。

というものです。ここから、インターネットでは暗号化を前提とした技術の開発と導入が全面的に進められることになりました。

標準化団体だけでなく、特に大手のWebサービス提供者にとっても、一般の人々からインターネット通信やコンテンツに対する信頼性がなくなるのは非常に大きな問題です。通信やコンテンツの健全性を確保することは、自社のビジネスに対する信頼を確保するための重要な課題です。QUANTUMの事例からもわかるように、一部でも平文通信が残っていると、そこを突かれて中間者攻撃を受ける可能性があります。そのような攻撃に関係ないと思っている一般ユーザでも、知らないうちにマルウェアを仕込まれ、他への攻撃に利用される恐れもあります。

この脅威に対抗する手段は、IABが示す通り全面的にHTTPSの導入を推進することです。GoogleがSEOという形でHTTPS導入のインセンティブを与えたのも、そうした動きの一環です。HTTPS化に伴うコスト面の課題を解消するため、中小企業や個人向けに無償でサーバ証明書を発行する認証局「Let’s Encrypt」のサービスも立ち上がりました。

最終的にGoogleやMozillaは、平文のHTTP通信上で使えるブラウザの機能の廃止を計画しています（詳細は後述）。

HTTPSの導入による性能の問題に関しても、最近のCPUではAES-NI³など暗号化処理をハードウェアで行う機能が組み込まれており、HTTPSの導入による急激なCPU負荷の増加は抑えられています。また、TLS上でHTTP/2を利用するとクライアントからの接続が1つのTLS接続に集約されるため、大規模なシステムになればなるほどその集約効果によるシステム負荷削減の効果が見込めることが期待されています⁴。

すべてをHTTPS化する理由は、インターネットの信頼性を維持するためなのです。

将来的に平文のHTTP通信はフェードアウトの方向に

HTTPS化の推進に伴って、ブラウザでは平文のHTTP通信に対してさまざまな機能的制限が入るようになりました。2017年10月中旬にリリースされたChrome 62では、HTTP接続のページにフォームなどにユーザがデータ入力を行うと、以下のようにアドレスバーに「保護されていない通信（Not Secure）」という警告が表示されます。

ユーザのプライバシー情報の保護を高めるシークレットモードでは、より制限が厳しくなり、HTTPページを表示するだけで同様の警告が表示されるようになりました。

Googleでは、「HTTPを安全でないと表示する（Marking HTTP As Non-Secure）」という計画を進めています。この計画の最終目標は、HTTP通信を「保護されていない通信」と表示することです。まず、パスワードやクレジットカードなどの入力項目があった場合に警告が出るようになりました。さらに、ユーザの任意の入力フィールドがあった場合に警告を出すという対応も終わっています。2018年7月にリリースのChrome 68において、すべてのHTTP通信に対して警告を表示することがアナウンスされています。

Googleでは、HTTPページに対する警告だけでなく、「安全でないオリジン上での高度な機能の廃止（Deprecating Powerful Features on Insecure Origins）」という計画も進めています。ユーザのプライバシーに関連する情報を扱うAPIは、HTTPSのページだけで利用可能となるように、ブラウザの機能に制限を加える計画です。

こういった対策に乗り出しているのはGoogleだけではありません。Mozillaでも、2015年4月に「安全でないHTTPの廃止（Deprecating Non-Secure HTTP）」を表明し、それを受けて2018年1月には「すべてをセキュアコンテキストに（Secure Contexts Everywhere）」として、「今後のFirefoxの新機能実装は基本的にHTTPSを必須とする」と決定しました。既にHTTPで利用されているユーザのセキュリティやプライバシーに関連する機能は、ケースバイケースで判断しながら廃止されることになります。

HTTP通信は将来的に、HTTPS通信へと誘導する最低限の機能だけを備えたものになってしまうだろうと言われています。

世界のHTTPS利用状況

こういった動きに伴って、世界ではHTTPS化が急速に進んでいます。

GoogleとMozillaでは、それぞれChromeとFirefoxのHTTPS利用状況を随時取得して公開しており、2017年2月までの結果を「ウェブにおけるHTTPS採用の計測（Measuring HTTPS Adoption on the Web）」という論文にまとめて公表しています。

この調査結果によると、現在はHTTPSのページが全体の過半数を超え、2014年1月から2017年1月までの3年間にHTTPSトラフィックの割合は20%から40%へと増加しています。

とはいえ、サイト別の構成を見ると、Alaxaトップ100ドメインでは88%のサイトがHTTPS化しているのに対し、トップ100万ドメインの調査では46%と大きく出遅れています。これは、大規模な人気サイトがHTTPS化を大きく進めているのに比べ、総数が多い中小規模のサイトではまだ対応が十分進んでいないことを示しています。

地域による差も大きく、東アジア圏、特に日本や韓国ではHTTPSの導入率が目立って低いことが指摘されています。悲しいことに、日本ではHTTPS化の理解が進んでいないのではないかという疑問も論文の著者から投げかけられています。

実は、この調査の後、2017年2月以降に日本の大手ウェブサービスがいくつかHTTPS化を行い、日本のHTTPS化の割合自体は上がっています。2018年2月上旬時点のFirefoxの統計によれば、世界全体のページ読み込みのうち約70%がHTTPS化され、日本は約65%です。Google Chromeの国別の統計では米国が87%、日本が60%となっています。増加したといっても、どちらも国別で日本は最下位のままです。

このように、国や地域・規模によって差がありますが、現在インターネットでは右肩上がりにサイト全体のHTTPS化が進んでいることがわかります。

HTTPS化に残る課題

HTTP/2仕様がHTTPSとHTTPの両方でサポートされている理由

2015年にRFC 7540として標準化されたHTTP/2は、2011年にGoogleが開発したSPDYという実験的なプロトコルを原型としています。Googleでは当初から自社の90%以上のサービスでSPDYを導入し、その際にHTTPS上でのみSPDYを動作させていたので、他のサイトがSPDYを導入するのにHTTPS化は避けられませんでした。とはいえ、SPDYはGoogleが独自に開発した私的プロトコルなので、それで特に問題はありませんでした。

2012年にIETFでHTTP/2の議論が始まり、SPDYがHTTP/2のベースとなる技術の候補として選定されると、事情は変わりました。HTTP/2を従来のSPDYと同様にHTTPSだけで使える仕様にするのか、もしくはHTTP/2では平文通信のHTTPもサポートするよう変更すべきか、IETFのワーキンググループで大きな議論になったのです。当時はまだHTTPSだけに利用が制限される新プロトコルに対して否定的な意見が多く、結局、HTTPとHTTPSの両方をサポートするように仕様を作成することでHTTP/2の標準化はスタートしました。

しかし、仕様の形がある程度見えてきた2013年6月、先に紹介したエドワード・スノーデン事件が明るみになりました。この事件を受け、HTTP/2の仕様化を進めるワーキンググループの議長から、HTTP/2の利用をHTTPSに限定するよう仕様の範囲をもう一度見直す提案が直ちに提出されました。議論は白熱しましたが、最終的に議長の提案は受け入れられませんでした。当時、HTTP/2をHTTPSに限定する提案に対して出された反対意見としては次のようなものがありました。

• HTTPSではコンテンツキャッシュなどProxy機能が損なわれる
• HTTPSにすれば絶対に安全と人々に勘違いさせる
• 機密性の少ないコンテンツも暗号化させるのは無駄ではないのか
• HTTP/2の設計と暗号化は独立した別の議論である
• 端末やサーバ側できちんとウィルススキャンすればよく、通信だけ守っても無駄である
• 一部のネットサービスの大手が通信の干渉を嫌っているだけである
• ユーザの同意なしに全部暗号化するのは問題である
• ネット監視は技術的な問題ではなく、政治的な問題である
• 証明書のコストやシステム負荷が増加する
• IoTなど低性能なデバイスでも暗号通信は必要なのか疑わしい
• 平文通信が必要なら仕様に関係なく使い始める

結果、当初の仕様化の範囲の通り、HTTP/2はHTTPとHTTPSの2つの形式で動作する内容で仕様化が完了しました。 しかし、2018年1月現在では平文のHTTP上で通信するHTTP/2の機能は主要ブラウザでサポートされておらず、HTTP/2を利用するには事実上HTTPSが必要な状況となっています。しかも、仕様では、HTTPSを使ったHTTP/2の利用にはTLSプロトコルのバージョンや暗号方式、鍵長の制限など、より安全を高める厳しい条件が付いています。

上記のような意見や批判は、HTTPS化が推進されている現在でも該当するものもあるでしょう。現在HTTPS化は進んでいますが、まだいくつかの課題は解決できていないままです。

トラストアンカーをめぐる認証局とブラウザベンダの関係

トラストアンカーと呼ばれるクライアントに登録されているルート証明書（rootCA）は、TLSのサーバ認証の要です。 実は、このルート証明書の参照先は統一されたものではなく、クライアントやOSなどの組み合わせによって次の表のように異なります。

†変更されている可能性もあり。

認証局は定期的に一定の基準で厳しいシステム監査を受けます。さらに、それぞれのOSやブラウザベンダが各自のポリシーに基づいて慎重に認証局を審査し、ルート証明書の登録を許可しています。 もし、トラストアンカーに登録されている認証局が外部から不正侵入を受けたり、業務上のミスで不正なサーバ証明書を発行したりしたら、どんなに技術的に安全なTLSハンドシェイクを行ってもTLS通信の安全は守れなくなります。

ところが、ここ数年、認証局による証明書の誤発行など、認証局に対する信頼が疑われるインシデントがさまざまに発生しています。ブラウザベンダは、そうしたインシデントが発生するたびに、ペナルティとして問題を起こした認証局が発行したサーバ証明書を特定の条件で無効化したり、最終的にトラストアンカーから削除したりといった対応をとってきました⁵。

トラストアンカーに登録されている認証局は現状で数百に及びます。このようなインシデントが頻発すると、今後はすべての認証局を同じレベルで信頼することに対して限界も見えてきます。現在はブラウザベンダが主導し、認証局が発行する証明書に規定違反がないか常にチェックしていますが、根本的な解決には程遠い状況です。

安全なHTTPSサーバを作るために知っておくべきこと

世の中のHTTPS化の流れは止まりません。サービスの提供者にとってHTTPS化は避けられない課題ですが、ここで注意が必要なのは、一度サービスを全面的にHTTPS化したらそれで終わりではないことです。対外的なアクセスがすべてHTTPSになるため、TLS通信でインシデントが発生すると、その影響がそれまで以上に広範囲に及びます。長期的に安全で安定したサービスを提供するためには、暗号技術や攻撃方法などのさまざまな動向を把握した上で、将来の運用を考えることが必要です。では、将来を見据えて安全なHTTPSサーバを作るためにはどうすればいいでしょうか？

できるだけ最新のソフトウェアを使用する

まず第一に、現時点で十分なセキュリティを確保する必要があります。多くの場合、Apacheやnginxをはじめとする各種Webサーバのソフトウェアでは、HTTPS化に際してTLSや暗号の処理を担うOpenSSLなどのライブラリが必要です。そうしたライブラリを含め、利用するソフトウェアを安定版の最新リリースにしてください。

最近のオープンソースソフトウェアは、何か脆弱性が発見されると、ユーザの設定で回避させるのではなく、初期設定をセキュリティ的に安全な方向に修正します。そのため、常に最新のバージョンアップに追随していけば、基本的に安全な構成になります。

定期的にサーバの安全性をチェックする

Webサーバの導入後にHTTPSが安全であるかを確認するには、SSL Labsなどのサイトでチェックを行い、安全性を評価します。こうしたサイトのチェックで高いスコアを得るためには、正当な証明書と適切なTLSプロトコルバージョンのサポート、十分なセキュリティ強度を持つ鍵交換や暗号方式の設定が必要です。もちろん、既に知られているTLSの脆弱性対応が施されていなければ、スコアは極端に下がります。チェック項目や判定スコアには随時見直しが入るので、定期的なチェックを行うことを推奨します。

SSL Labsのスコアを向上させるためには、具体的にどうしたらいいでしょう？ その方法をすべて解説すると膨大に量になってしまうので、本記事では割愛します。詳しくは書籍『プロフェッショナルSSL/TLS』などを参照してください。

この記事では、SSL Labsのスコアを決める重要な項目の一つである、「サポートするTLSプロトコルバージョン」の選択についてのみ解説します。

将来を見据えたTLSプロトコルバージョンを選択する

HTTPSサーバがサポートするTLSのプロトコルバージョンは、TLS通信の安全性を決める大きな要因になります。 一般的に、新しいTLSプロトコルのバージョンであればあるほど、安全性を高めるためのセキュリティ対策が施されています。

運用しているサービスで、どこまで古いTLSプロトコルのバージョンも有効にすればいいかは、そのサービスでどれだけ旧型の端末をサポートする必要があるかに依存します。特定の古いTLSバージョンしか利用できないユーザへの影響を考えると、古いプロトコルのサポート廃止に踏み切れない場合も少なくありませんでした。

しかし最近になって、クレジットカード情報を扱う国際的なセキュリティ基準であるPCI DSS（Payment Card Industry Data Security Standard）が、積極的に古いTLSバージョンを廃止する方向を打ち出しました。この新しい運用基準の要請によって、これまでサポート重視で保守的だったHTTPSサーバの運用でも、将来的なセキュリティリスクをあらかじめ排除すべく積極的に対応することが求められるようになりました。

この動きを理解するため、ここで各TLSプロトコルのバージョンがどういうものなのかを簡単に解説しておきます。

SSL2.0/3.0

SSL（Secure Socket Layer）は、TLSの前身のプロトコルです。SSL2.0とSSL3.0は、1990年代の中頃に旧ネットスケープ社によって開発されました。いずれも既にプロトコル仕様上の脆弱性が見つかっており、RFC 6176でSSL2.0が禁止され、RFC 7568でSSL3.0が廃止されています。

現在、SSL2.0だけしか使えない端末はほとんど存在せず、実際にSSL2.0が利用されることはありません。だからといって、HTTPSサーバでSSL2.0を有効にしたまま放置していると危険です。

2016年に公表されたDROWN攻撃は、サーバで放置されたままのSSL2.0の機能を悪用することで、安全なバージョンのTLS通信までをも解読するというものです。たとえHTTPSサーバでSSL2.0を無効にしていても、同じ証明書を共有する別のメールサーバなどが存在し、そこでSSL2.0が有効になっていれば、それを利用することでDROWN攻撃が成功します。このようなリスクを避けるためにも、できればTLSを使っているすべてのサーバに対してSSL2.0を無効化することが必要です。

SSL3.0については、POODLE攻撃というものが知られており、CBCモード⁶の利用時に暗号データの一部が解読されてしまう恐れがあります。SSL3.0のプロトコルの仕様上、この攻撃を回避する方法はありません。2014年にPOODLE攻撃の存在が公表され、CBCモードが安全に利用できないことが判明すると、SSL3.0で安全に利用できる暗号方式がほかになくなったことから、多くのサイトがSSL3.0の利用を停止しました。

TLS1.0

TLS1.0は、1999年にIETFで策定されたプロトコルです。当時、旧ネットスケープ社とマイクロソフト社との間で熾烈なブラウザのシェア争いがあり、両社はそれぞれ独自にセキュリティプロトコルを開発していました。一方、IETFの標準化では、議論の末、ネットスケープのSSL3.0が基本仕様として採用されることになりました。しかし、ブラウザ戦争の余波から、ネットスケープ1社の仕様がそのままIETFに認められたという印象を世間に与えてしまう懸念を受けて、結局、IETFの標準化では、プロトコルの名称をSSLからTLSへと変えることになりました。最終的に、SSL3.0にいくつか機能や変更が追加され、IETFで最初のTLSであるバージョン1.0の標準化が完了しました。

SSLという言葉は、20年近く経った現在でも広く残っています。SSLとTLSがあまり区別されずに使われることも少なくありません。TLSは、技術的にはSSL3.0を発展させたものであり、現在仕様策定中のTLS1.3においてもSSL3.0の影響が色濃く残っています。一方で、先に述べた通り、SSLプロトコルは既に危殆化⁷しています。その利用も禁止されています。SSLという言葉自体も、今後は次第に歴史的遺物になっていくでしょう。

TLS1.0も、SSLと同様、既に仕様上の脆弱性が見つかっています。たとえば、CBCモードを使う際に初期ベクトルが常に通信データに付与されていないため、BEAST攻撃を受けて暗号データの一部が解読されてしまうことが知られています。この攻撃は、サーバ側では対応する方法がなく、クライアント側でしか対策できません。根本的な対策には次のバージョンであるTLS1.1が必要です。ほかにも、TLS1.0に関しては、SSL時代から使われてきた暗号方式の多くが既に危殆化して利用が禁止されています。

TLS1.0は、今ではセキュリティ的に安全性のマージンがあまりなくなっています。 前述したクレジットカード情報を扱う運用規定のPCI DSSでも、バージョン3.1において、2016年6月30日までにTLS1.0の利用を禁止する予定でした。しかし、その当時はTLS1.0だけしか対応していないクライアントもまだ多かったので、2年だけ禁止を延期するよう規定を改定しました⁸。

現在では、大手サービスは順次TLS1.0の利用停止を進めており、既に対応が終わったサイトも増えています。クレジットカード情報を扱う多くのシステムでは、PCI DSS 3.1の予定通り、今年（2018年）6月末にTLS1.0が廃止される見込みです。

このように、TLS1.0の利用は近いうちに縮小していきます。SSLのように利用が全面的に禁止されるほど大きな脆弱性は今のところ公表されていませんが、遠くない将来にTLS1.0は使われなくなるでしょう。

TLS1.1

TLS1.1は、2006年にTLS1.0で発見されたいくつかの脆弱性（前述のBEAST攻撃とCBCモードのエラーを使った攻撃）への対策として仕様が修正されたプロトコルです。サポートしている暗号方式はTLS1.0とほぼ同じです。

TLS1.1だけをサポートする端末は少ないこともあり、TLS1.0の廃止が進んだ後は、続いてTLS1.1の利用も廃止される方向になるでしょう。

TLS1.2

2008年に策定されたTLS1.2は、現時点でもっともよく利用されているバージョンです。

TLS1.2では、安全性を向上させるため、いくつか新しい暗号方式が追加されています。その中でAEAD（認証付き暗号）⁹は、TLS1.1まで利用されてきたCBCモードの弱点を解決し、ハードウェア処理による高速処理も可能な暗号方式もあることから、現在では主流の暗号方式になっています。

現時点で最新のTLS1.2も、当初からずっと安全だったわけではありません。TLS1.2の仕様が固まったあとに見つかったプロトコルの脆弱性に対しては、その都度、機能が無効化されたり、拡張機能が追加されたりしてきました¹⁰。TLS1.2は、いくつもの脆弱性対応で、いわば継ぎはぎだらけになっています。このため、実際の運用では、過去に施された対策が漏れていないかを確認するため、SSL LabsによるHTTPSサーバのチェックといった作業が必要になっているのです。

TLS1.3

現在は、新しいTLS1.3の仕様策定作業が進んでいます（2018年1月時点）。TLS1.2まで継ぎはぎで蓄積されてきたセキュリティの技術的負債を一掃して安全性を高め、さらに接続性能の向上が図られています（詳細は後述）。

TLS1.3では、暗号方式がAEADに限定され、これまで数多くの脆弱性が見つかっているCBCモードは廃止されます。鍵交換についても、Forward Secrecyを持つアルゴリズムに限定されます。さらに、将来的なセキュリティリスクを排除するため、TLS1.2まで使われていた機能の多くが変更、廃止されます。

TLS1.3には、見かけ上まったくTLS1.2と区別がつかないように見せる工夫も施されています。これは、過去のTLSプロトコルのバージョンアップでは新しいプロトコルに対応していないサーバやファイヤウォールなどのミドルボックスが新しいTLSプロトコルの通信を切断してしまう事態が起きたためです。

TLS1.3は、現在、ブラウザベンダを中心に最終試験が続けられている段階です。仕様策定の完了後は、大手サービスを中心に急速に普及することが見込まれています。

以上をまとめると、2018年1月現在のTLSプロトコルのバージョンは以下のような状況になっています。

自社のサービスでどのプロトコルバージョンに対応するかは、最終的にセキュリティポリシーや運用状況、その時点での安全性評価の報告などを参考にして、各自の判断のもとで決定してください。

今後どうなる？ TLS1.3やQUICへ

IETFでは、既にすべてHTTPS化を行った後を見据えた技術開発が進んでいます。現在仕様策定中の新しいプロトコルのTLS1.3とQUICの概要について説明します¹¹。

TLS1.3でセキュリティだけでなく接続性能も向上

完全なHTTPS化を進めるには、長期にわたって安心して使えるTLSプロトコルが必要です。継ぎはぎの対応で安全性を維持してきたTLS1.2のように、頻繁に脆弱性のチェックが必要になるようでは、普段の運用が回らず、将来的にも心もとない状況です。

一方、最近の携帯端末の普及により、ネットワークの使われ方も変わってきました。携帯端末は、基地局を経由してインターネットに接続するため、通信の往復時間（RTT：Round Trip Time）が比較的大きくなってしまいます。モバイル通信の回線速度は速くなっていますが、物理的な距離に依存するRTTを小さくすることはそう簡単ではありません。また、携帯端末はWi-Fiと携帯回線の切り替えを随時行うので、ネットワークの再接続が頻繁に発生する場合があります。再接続時にクライアントとサーバ間でやり取りするTLSハンドシェイクは、このRTTの影響を大きく受けます。

このような課題を解決するため、2013年の後半から検討が始まったTLS1.3では、現在まで積み重なったセキュリティ課題を一掃し、かつ接続の高速化も図ることが目的とされました。TLSプロトコルのバージョンアップで、セキュリティの向上だけでなく通信性能の向上まで目指すことは、これまでにはなかったことです。

TLS1.3で、どのようにセキュリティと接続性能向上の両方を達成できているのでしょうか？ ここでは、TLS1.3の2種類のハンドシェイクについて簡単に説明します。

TLS1.3の代表的なハンドシェイク（1-RTT）

TLS1.3で代表的に使われるのは、サーバ認証の「1-RTTの新規接続」ハンドシェイクです。

1. クライアントパラメータの送付と鍵交換

TLS1.3のハンドシェイクでは、これまで鍵交換の役割を担っていたServerKeyExchangeとClientKeyExchangeが廃止されました。その代わり、鍵交換のやり取りにはClientHelloとServerHelloの拡張領域を使います。TLS1.2では一番最初に行うパラメータの合意を後回しにして、まず鍵交換を先に行います。

ClientHelloを受信したサーバは、一時公開鍵を生成し、鍵交換に必要なパラメータだけが入ったServerHelloでクライアントに返します。

パラメータの事前合意もなしに鍵交換ができるのは、クライアントが鍵交換アルゴリズムをいくつかあらかじめ選定しているからです。最悪もしサーバがサポートしていない鍵交換アルゴリズムを受け取ってしまったら、サーバはクライアントに対して差し戻しを指示してハンドシェイクをやり直します¹²。

TLS1.3のハンドシェイクで平文通信なのは、この鍵交換の部分（ClientHelloとServerHello）だけになります。

2. サーバパラメータの送付

サーバは、ClientHelloを受信した時点で一時共有鍵を導出することができます。ServerHelloを送信後、直ちに暗号化通信を開始します。TLS1.2で暗号化開始の合図だったChangeCipherSpecはもはや必要ありません¹³。鍵交換以外で合意するパラメータは、暗号通信上でクライアントに送付されます（EncryptedExtension）。TLS1.3では、鍵交換以外にクライアント・サーバ間で何の設定が合意されたのか、途中経路の第3者からはわからなくなりました¹⁴。

3. サーバ認証、ハンドシェイクの改ざんチェック、アプリケーションデータの送受信

続いて、サーバ認証が行われます。サーバが送付する証明書の種類（Certificate）や、そのチェックの仕方は、TLS1.2のときと同じです。しかし、証明書が暗号通信上で送付されるので、どんな証明書を使っているのかを外部から見ることはできなくなりました。

サーバ認証の第2段階は、TLS1.2と異なります。ServerKeyExchangeが廃止されたので、代わりにその時点までやり取りしたハンドシェイクデータに対してサーバが署名し、その署名データを送付します（CertificateVerify）。受け取ったクライアントは署名を検証して、サーバが証明書に対応した秘密鍵を保持していることを確認します。これでサーバ認証は完了です。

最後に、TLS1.2と同様、ハンドシェイクが改ざんされていないか確認するFinishedを交換します。これでTLS1.3のハンドシェイクは完了です。TLS1.2とは異なり、クライアントからのFinishedを待つ必要はありません。サーバは、Finishedを送信した直後からアプリケーションデータの送付が可能です。この場合、わずか0.5-RTTでサーバからアプリケーションデータを送れることになります。

クライアントがサーバにアプリケーションを送付できるのは、サーバからのFinishedを受信した1往復（1-RTT）後です。TLS1.2では2往復かかっていた初期接続が、TLS1.3では1往復に短縮されることになります。初期接続にかかるRTTの影響が、TLS1.3ではTLS1.2に比べて半分に減るのです。

4. 再接続用チケットの送付

TLS1.3のハンドシェイクが完了したサーバは、次の再接続に備えて、クライアントにチケットを渡します（NewSessionTicket）。このチケット情報と、ハンドシェイクの鍵交換で生成した一時的な共有鍵を使って、サーバとクライアントの両者で再接続用の事前共有鍵（PSK：Pre-Shared Key）を生成しておきます。PSKを使えば、次に説明するように、さらなる効率化と高速化を図れます。

いきなりアプリケーションデータを暗号化して送る0-RTT

TLS1.3の再接続時には、ClientHelloの送信と同時に、いきなり暗号化したアプリケーションデータをサーバに送付する0-RTT接続が可能です。往復のRTTに影響しない、究極の高速化といえます。

0. 前提条件

TLS1.3の0-RTTでの再接続の際には、前回のハンドシェイク時に生成したPSKをサーバとクライアント間で共有している必要があります。チケットが定める有効期間内であれば、クライアントはいつでもPSKを使って再接続できます。ただし、チケットの有効期限は1週間を超えてはいけないことになっています。

1. クライアントパラメータの送付、鍵交換、0-RTTのアプリケーションデータの送付

クライアントは、サーバに再接続を開始するとき、ClientHelloの送信に続いてアプリケーションデータを送付します。アプリケーションデータはPSKを使って暗号化されます。PSKは、あらかじめサーバと共有しているので、サーバはその鍵を使って暗号化された0-RTTのアプリケーションデータを復号できます。0-RTTのアプリケーションデータを送受信するときもハンドシェイクは継続でき、送信し終わったらクライアントはサーバに送信終了の合図を送ります（EndOfEarlyData）。

ClientHelloを受け取ったサーバは、クライアントの一時的な公開鍵とPSKを組み合わせて、新たに一時的な共有鍵を生成します。これにより、TLS1.2において再接続にチケットを利用することでForward Secrecyが壊れてしまっていた問題が解消されます。TLS1.3では、チケットを使った再接続時でも、Forward Secrecyを維持できるようになったのです。

2. サーバパラメータの送付

鍵交換以外でサーバが合意したパラメータは、暗号化してクライアントに送ります。1-RTTの初期接続と同じです。

3. ハンドシェイクの改ざんチェック、アプリケーションデータの送受信

暗号通信が成功すれば、クライアントはサーバとPSKが共有されていることを確認できたことになります。前回のハンドシェイクでPSKを生成した時点で、サーバ認証は成功しています。それを引き継いだPSKをサーバが持っていることにより、サーバ認証が既に終わっていることになります。よって、あらためて証明書を送付する必要はありません。Finishedの交換による改ざんチェックが済めばハンドシェイクは完了です。

このように、TLS1.3では、0-RTTの再接続を利用することによってTLSハンドシェイクのRTTの影響を極限までなくすことが可能となりました。

0-RTTのセキュリティリスク

0-RTTのアプリケーションデータの送受信は、いくつかセキュリテイ上のリスクもある仕組みです。

0-RTTのアプリケーションデータについては、暗号鍵がPSKだけに依存します。そのため、0-RTTのアプリケーションデータにはForward Secrecyがありません。不正侵入を受け、PSKが外部に漏洩してしまった場合、後から0-RTTのアプリケーションデータが解読されてしまう恐れがあります。

また中間攻撃者が、クラスタリングしているサイトに対して、再接続の0-RTTデータを複製して複数のサーバに送信することも可能です（0-RTT Reply攻撃）。これを完全に防ぐことはできません。そのため0-RTTでやり取りするアプリケーションデータは、複数同時に受信してもサーバ側の処理に問題にならないものに限定されます。¹⁵

IETF QUIC

QUICは、UDP上でTCPとTLS、HTTP/2の機能を実現するプロトコルで、もともとは2013年からGoogleが開発を続けていた私的プロトコル（Google QUIC）でした。現在では、GoogleのほとんどのサービスでQUICが使われています。その検索サービスやYouTubeでの性能改善結果を受け、IETFでも2016年秋よりQUICプロトコルの標準化が始まりました（IETF QUIC）。

IETF QUICは、Google QUICをベースとしていますが、必要となる機能やデータ書式などに全面的な見直しと改良が加えられています。 たとえば、Google QUICではGoogle独自の暗号ハンドシェイクの仕組みを利用していますが、IETF QUICでは、専門家によるセキュリティレビューを受けているTLS1.3の仕組みを全面的に採用することになりました。

TLS1.3はTCP上で使われるので、0-RTT接続を利用する際にもTCPハンドシェイクのオーバヘッドがあります。一方、QUICはUDP上の通信であることから、再接続時にまったくオーバヘッドがありません。QUICでは、RTTにまったく依存しない、真の0-RTT接続が実現できます。

QUICの暗号化の範囲もTLS1.3と異なります。IETF QUICは、バージョン固有の鍵情報を使って、初期ハンドシェイクのClientHello/ServerHelloの部分までも暗号化を行うことが検討されています¹⁶。これによってヘッダの部分を除きQUICのハンドシェイク全体が暗号化されることになります。このようにQUICでは、できるだけデータを隠匿し平文で見える部分をできるだけ最小限にするようになっています。

TLS1.3とQUICのハンドシェイクやHTTPデータのやり取りは、次の図のように比較できます¹⁷。

これらの特徴に加えて、IETF QUICには通信制御機能が組み込まれており、パケットロスの多いモバイル回線やRTTがより大きな回線でも通信の改善が図られる見込みです。

現在のところ、IETF QUICでは、HTTPのやり取りに限定して仕様化が進められています。しかし、将来的には、DNSやWebRTCへの応用も検討されています。さまざまなアプリケーションの通信プラットフォームとなり得るIETF QUICは非常に期待が大きいプロトコルです。

暗号化通信を前提としたプロトコルの進化はこれからも続きます。サービスのすべてをHTTPS化することはその第一歩となるでしょう。

リファレンス

• {$image_15}Transparency Report{$image_16}
  GoolgeによるHTTPS統計情報
• {$image_17}Let's Encrypt Stats - Let's Encrypt - Free SSL/TLS Certificates{$image_18}
  Let’s Encryptの統計情報
• {$image_19}SSL Server Test (Powered by Qualys SSL Labs){$image_20}
  SSL LabsによるSSL Server Test
• {$image_21}『プロフェッショナルSSL/TLS』 – 技術書出版と販売のラムダノート{$image_22}
• {$image_23}GitHub - tlswg/tls13-spec: TLS 1.3 Specification{$image_24}>
  TLS1.3仕様ドラフトのGitHubレポジトリ
• {$image_25}GitHub - quicwg/base-drafts: Internet-Drafts that make up the base QUIC specification{$image_26}
  QUICの基本仕様ドラフトのGitHubレポジトリ

執筆者プロフィール

大津 繁樹（おおつ・しげき） {$image_27}@jovi0608

本記事には、ヤフー株式会社の桑山智耶さん、五水井柾人さん、大石剛さんより数多くのコメント・修正をいただきました。深く感謝いたします。

編集協力：鹿野桂一郎（しかの・けいいちろう、{$image_28}@golden_lucky） {$image_29}技術書出版ラムダノート

脚注