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

WebサイトをHTTPS化する最も大きな理由は、インターネットの信頼性を維持することです。TLS技術の現状や、安全なHTTPS化に何が必要かを、ヤフー株式会社の大津繁樹氏が解説します。

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

「SEO対策のためには、WebサイトをHTTPS化しないといけない。」 —— そう聞かされて対応を迫られている技術者の方も多いのではないでしょうか?

確かに、Googleは「HTTPSページが優先的にインデックスに登録されるようになります」と表明し、HTTPS化されたWebサイトが同社の検索結果で有利になると示唆しています。はたして、WebサイトのHTTPS化が必要な理由は、SEO対策だけなのでしょうか? そして、それはGoogleという一社だけの意向で推奨されていることなのでしょうか?

こうした疑問に答えるべく、この記事ではHTTPSおよびTLSについて歴史的経緯と技術的な背景を説明します。 さらに、そうした背景を踏まえて、Webサーバを安全にHTTPS化するための技術的な要件を解説していきます。 最後に、HTTPS化したあとを見据えてIETFで仕様策定が進められている新しいプロトコル、TLS1.3とQUICの概要について説明します。

※本稿では、現時点で安全と判断できるTLSの技術要件についてまとめています。実際にどういう設定でTLSを使うべきかは、最終的に各社のセキュリティポリシーや運用状況に応じて、その時点での安全性評価の報告などを参考に、各自の判断のもとで決定してください。
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか? 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。

HTTPSのおさらい

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

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

1

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通信で最も代表的な方式1を取り上げます。

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

2
1. パラメータの交換

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

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

2. サーバ認証

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

3

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

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

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

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

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

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

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

3. 鍵交換(ECDHEの場合)

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

4

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

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

クライアントとサーバは、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が次のブログで解説しています。

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

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

6

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

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

7

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

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

8

ユーザのプライバシー情報の保護を高めるシークレットモードでは、より制限が厳しくなり、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利用状況

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く