HTTPS に関するよくある質問

Google での HTTPS への対応

暗号化とは

暗号化とは、従来は紙に書かれた情報を金庫やダイヤル錠で保護していたのと同じように、現代において電子情報を保護する方法です。テクノロジーを利用して暗号作成が行われます。つまり、情報を理解不能な形に変換（エンコード）して、鍵がなければ理解可能な形に変換（デコード）できないようになります。たとえば、デバイスの暗号化の場合、暗号を復号化するには、情報を解読するための PIN か、プログラムやデバイスによって明確に指示された複雑なアルゴリズムが必要になります。暗号化では、計算を効果的に活用して情報のエンコードやデコードを行います。

HTTPS とは何ですか？

HTTP（ハイパーテキスト転送プロトコル）は、ブラウザがウェブサイトに接続する際に使われる技術です。HTTPS とは、暗号化された HTTP 接続で、安全性を高めたものです。ウェブサイトに接続する際、URL に HTTP ではなく HTTPS が含まれていると、その接続が安全であることがわかります。また、ほとんどのブラウザには、安全な接続であることを示すアイコンがあります。たとえば、Chrome では緑色の鍵アイコンが表示されます。

HTTPS を使う必要があるのはなぜですか？

機密情報をやり取りするサイトでなくても、ウェブサイトは HTTPS で保護する必要があります。HTTPS は、ウェブサイトを保全し、サイトにアクセスするユーザーのプライバシーやセキュリティを保護するものです。また、ウェブプラットフォームの強力な新機能のメリットを得られるのは、HTTPS を利用するサイトに限られます。

Google は HTTPS についてどのようなことを目標としていますか？

Google では、ウェブを利用するすべてのユーザーの安全と保安の基礎となるのが強力な暗号化であると考え、Google のあらゆるサービスで暗号化に対応することを目指して尽力しています。Google での HTTPS への対応に関するページで、この目標に向けてのリアルタイムの進捗状況をご覧になれます。

暗号化が重要なのはなぜですか？

やり取りされるデータは、A 地点から B 地点に移動する際、いくつものネットワークが入り組んだ中を通ります。このような移動の間には、意図した受け手以外がネットワークを不正に操作してデータを傍受する恐れがあります。同様に、昨今は単なる電話ではなく多数の機能を備えたモバイルデバイスに頼る傾向が強まっており、こうしたデバイスでは、写真や通信記録、メール、個人データが、利用しやすいよう常にログインしたままのアプリに保存されています。デバイスを紛失したり盗まれたりすると、多くの個人情報に第三者がアクセスできる可能性が高まり、個人情報の盗用や、金銭に関わる不正、個人への危害といった危険にさらされることになります。

このような状況において、暗号化は身を守るのに役立ちます。やり取りするデータを暗号化すると、ウェブを移動する際に傍受されたとしても、データの内容は理解不能なものとなります。これを「暗号文」といい、暗号化されていない状態のデータを「平文」といいます。デバイスの暗号化に関しては、暗号化されたデバイスの復号化に必要な PIN やコードがなければ、デバイス上のコンテンツを盗もうとしてもアクセスできず、デバイスのデータ全体を消去することしかできません。データを失うのは困りますが、個人情報が自分以外の手に渡ってしまうよりはましなことです。

暗号化にはどのような種類がありますか？

送信中の暗号化: エンドユーザーからサードパーティサーバーへの情報の流れを保護します。たとえば、ショッピングサイトでクレジットカードの認証情報を入力する際、安全な接続により、その情報が途中で第三者に傍受されるのを防ぎます。情報を復号化できるのは、自分と接続先のサーバーのみとなります。

エンドツーエンドの暗号化: 送信者と受信者のみが、データの暗号化と復号化を行うための鍵を持ちます。データのやり取りに使われるシステムを管理するサービスプロバイダは、データの実際の内容にアクセスすることはできません。

保存データの暗号化: 送信中でない情報を保護します。たとえば、パソコンのハードディスクでは、保存データの暗号化を利用して、パソコンが盗まれた場合でも第三者がファイルにアクセスできないようにすることが可能です。

これらのグラフにはどのようなプロトコルが含まれていますか？

これらのグラフは、HTTP、HTTP/2、HTTPS、SPDY、QUIC によるリクエストを表しています。

暗号化されていると見なされるのはどのようなプロトコルですか？

HTTPS、SPDY、QUIC によるリクエストは、デフォルトで TLS が組み込まれるため、暗号化されているものと見なされます。また、HTTP/2 も同様です。Google では、暗号化されていない HTTP/2 接続には対応していません。

他のプロトコルに関するデータはどこで確認できますか？

Google では現在、Gmail のメールプロトコルでの TLS の使用に関するデータを公開しています。記載されていないその他のプロトコルは、今のところ、このレポートの対象外となっています。

サービス別のグラフに Google 検索が含まれていないのはなぜですか？

Google 検索では、サービス提供用のインフラストラクチャを他の Google サービスのいくつかと共有しています。Google 検索を単独のカテゴリとして分離すると、サービス提供のインフラストラクチャが共有されているために、データの正確さに対する信頼度が低下する恐れがあります。

2013 年 12 月以前の正確なデータはありますか？

残念ながらありません。2013 年 12 月より前のデータソースは、HTTPS 採用状況を測るのに利用できるほど正確ではないためです。

HTTPS の使用状況データはどのように測定されますか？

測定の対象は、使用統計情報の共有を選択した Chrome ユーザーから提供されたデータです。国や地域は、ユーザーのブラウザに関連付けられた IP アドレスに基づいて分類されます。

HTTPS の使用統計情報について、この 10 件の国と地域が選定されたのはなぜですか？

世界各地の HTTPS の使用状況を比較するにあたり、この 10 件の国と地域を選定した理由は、これらの国の Chrome ユーザー数が相当数にのぼり、また地理的にも分散されているためです。

トップサイトの HTTPS [アーカイブ済み]

「HTTPS サイトとして機能」とはどのような意味ですか？

Googlebot が https://[ドメイン名] に正常にアクセスでき、HTTP ページからリダイレクトされなかった場合、そのサイトは HTTPS サイトとして機能しているものと見なされます。

「最新 TLS 構成」とはどのような意味ですか？

2016 年 2 月以降、Google では、サイトにおいて AEAD モードの操作を使う暗号スイートで TLS v1.2 が利用されている場合、最新の HTTPS を利用しているサイトであると判断します。

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

「デフォルト HTTPS」とはどのような意味ですか？

「デフォルト HTTPS」とは、そのサイトで HTTP リクエストが HTTPS URL にリダイレクトされるという意味です。ただし、「デフォルト HTTPS」に該当するサイトであっても、ドメインに対する HTTPS リクエストが拒否される場合があります（たとえば、http://[ドメイン名] は https://[サブドメイン名].[ドメイン名] にリダイレクトされる一方で、https://[ドメイン名] は接続が拒否されます）。

また、サイトが「デフォルト HTTPS」と見なされている場合でも、そのサイトのあらゆるページですべてのトラフィックに HTTPS が使用されることが保証されるわけではないため、ご注意ください。Chrome では、アクセスするすべてのページで HTTPS の状態が通知されます。別のブラウザをお使いの場合は、そのブラウザで HTTPS のさまざまな状態がどのように表示されるかを詳しく知っておく必要があります。

どのようなデータソースを使用していますか？

さまざまな公開データ（Alexa のトップサイトなど）と Google データを使用しています。これらのデータは、2016 年の初めに数か月かけて集めたもので、このリストの基盤となっています。

このリストは人気順になっていますか？

いいえ。このリストでは、Google 以外のトップ 100 サイトをアルファベット順に並べ、HTTPS の採用状況により 3 つのカテゴリに分けています。

このリストに掲載されているウェブサイトの所有者です。HTTPS に移行するにあたって手助けが必要なのですが、Google でサポートしてもらえますか？

Google では、このリストに掲載されているサイトを対象に、HTTPS への移行について限定的なサポートを提供します。お持ちのメールアドレス security@[ドメイン名] で詳しい情報を確認していただくか、google.com で Google のセキュリティチームまでお問い合わせください。

Certificate Transparency（証明書の透明性）

認証局とは何ですか？

認証局（CA）とは、ウェブサイトの運営者にデジタル証明書を発行する組織です。オペレーティングシステム（Mac OS X、Windows など）やウェブブラウザ（Chrome、Firefox、Safari など）には、信頼できるルート認証局が最初から含まれています。最新のオペレーティングシステムでは通常、200 以上の信頼できる CA（政府が運営しているものも含まれます）が組み込まれており、各 CA は同じようにウェブブラウザで信頼されます。また、多くの CA では、証明書の発行を中間認証局に委ねています。

証明書とは何ですか？

安全な接続（HTTPS）でウェブサイトにアクセスすると、そのウェブサイトからブラウザにデジタル証明書が提供されます。この証明書では、サイトのホスト名を特定し、サイトのオーナーを確認した認証局（CA）から署名を得ます。こうした証明書による身元証明は、認証局が信頼されていれば、信頼できるものとなります。

Certificate Transparency（証明書の透明性）が重要なのはなぜですか？

現在のモデルでは、すべてのユーザーが、多数の CA 組織からどのサイトに対しても正しく証明書が発行されると確信する必要があります。ただし、場合によっては、人為的なミスやなりすましが証明書の不正発行につながりかねません。Certificate Transparency（証明書の透明性）（CT）では、証明書の発行プロセスを変更し、証明書がユーザーのウェブブラウザで有効と見なされるための要件として、公に検証可能で改ざん防止機能を備えた追加専用のログに記録することを義務付けています。このように証明書を公開 CT ログに記録することを必須とすると、いずれの当事者も、特定の認証局により発行されたすべての証明書を調べることができます。また、これによって組織の説明責任が高まり、システムの信頼性の向上が促進されます。最終的には、サイトの証明書が CT ログに記録されていない限り、そのサイトに HTTPS でアクセスしても、ブラウザでは安全な接続を示す鍵アイコンが表示されない、ということになります。

発行されたどの証明書が承認されるかを把握できるのは、特定のドメインに対して責任を負う組織のみです。証明書が承認されない場合、ドメインユーザーは、どのように対処すべきか判断するために、その証明書を発行した CA に連絡する必要があります。

Certificate Transparency（証明書の透明性）ログとは何ですか？

Certificate Transparency（証明書の透明性）ログとは RFC 6962 を実装するサーバーで、これにより、いずれの当事者も、公に信頼できる CA の発行した証明書を送信できるようになります。ログに証明書が追加されると、このログの暗号の特性によって、項目の削除や編集が一切不可であることが保証されます。

ここに表示されている証明書はどこから得られたものですか？

透明性レポートで扱う証明書は、有効な Certificate Transparency（証明書の透明性）ログから取得したものです。このログに含まれている証明書の多くは、CA により発行プロセス内で送信されます。また、Google では、ウェブのインデックス登録の際に見つかった証明書を追加します。サイトのオーナーは、このサイトで管理対象のドメイン名を検索することにより、自身のドメインに関する証明書の不正発行がないことを確認できます。

自分の証明書がここに表示されないのはなぜですか？

証明書がここに表示されるのは、少なくとも 1 つの CT ログに記録されている場合です。ご自身の証明書をログに送信することが可能ですが、うまくいかない場合は、該当の CA にお問い合わせになることをおすすめします。技術に詳しいユーザーであれば、https://certificate-transparency.org で提供されているオープンソースのツールなどの各種ツールを使って、自分でログに証明書を送信できます。

一部のサイトで証明書の発行元が複数あるのはなぜですか？

多くの大規模な組織では、契約上の義務や、導入に関する検討事項、費用など、多様なニーズに対応するために、複数の CA を利用しています。

一部の証明書で複数の DNS 名が記載されているのはなぜですか？

多くの組織では、証明書を 1 つのみ発行して複数のサイトで使用しています。たとえば、大きなサイトではその特性上、複数のサブドメイン（例: www.google.com、mail.google.com、accounts.google.com）を使用することが多いものですが、そうしたサブドメインをすべて 1 つの証明書で指定します。