HTTPS (Hypertext Transfer Protocol Secure)は、HTTP 通信をより安全(セキュア )に行うためのURI スキームである。「HTTPS」はプロトコルではなく、SSL/TLS プロトコルなどによって提供されるセキュアな接続の上でのHTTP通信をさす。
概要
HTTP通信において認証 や暗号化を行うために、ネットスケープコミュニケーションズ によって開発された。当初、World Wide Web 上での個人情報の送信や電子決済 など、セキュリティが重要となる通信で使用されるようになった。その後、公衆無線LAN の普及による中間者攻撃 のリスクの増加[ 1] 、PRISM による大規模な盗聴 、ネット検閲 への対抗などを要因として、あらゆるHTTP通信をHTTPSに置き換える動きが活発になっている[ 2] [ 3] [ 4] [ 5] 。
HTTPSは、メッセージを平文 のままで送受信する標準のHTTPと異なり、SSL/TLS やQUIC といったプロトコルを用いて、サーバの認証・通信内容の暗号化 ・改竄検出 などを行う。これによって、なりすまし ・中間者攻撃 ・盗聴 などの攻撃を防ぐことができる。HTTPSでは、ウェルノウンポート番号 として443が使われる。
HTTPSによるセキュリティ保護の強度は、Webサーバやブラウザで用いられるSSL/TLSの実装の正確性や、使用する暗号アルゴリズムに依存する(TLS を参照)。
プロキシ サーバを介してインターネットにアクセスする場合、HTTPSのSSL/TLS通信時にプロキシ サーバをトンネリング する必要がある場合がある。その場合はCONNECTメソッド を使用する。
メリット/デメリット
HTTPSを利用するメリット・デメリットは、以下のとおりである。
メリット
通信が暗号化されるため、改竄 、盗聴 などの攻撃を防ぐことができる。通信の最適化 も改竄の一種であるので、同様に防げる。
HTTP/2 やHTTP/3 対応でブラウザ表示が高速化される。
SEO に有利になる。検索エンジン最大手のGoogleがHTTPSの導入を推進するため、自社検索サービスにおいてHTTPSの使用するウェブサイトを優遇することを発表していることによる[ 6] [ 7] 。
デメリット
無料発行サービスを除き、導入に費用がかかる。
SSL証明書を定期的(90日/一年など)に更新する必要がある。
https非対応のツールや広告、ブログパーツなどが非表示になる(後述する混在コンテンツに該当するため)。
暗号化/復号が必要になるため、クライアントとサーバ共に負荷が上がる(ただし、前述のHTTP/2を併用することで負荷を表示速度で相殺できる場合もある)。
古いウェブブラウザ から閲覧ができなくなる。
ウェブブラウザでの扱い
ウェブブラウザ (ユーザーエージェント )では、対象のURLがhttpsであるなど、セキュアな通信経路であることが明らかであるか否かで動作を変える場合がある。これに関わる規定として、W3CのSecure Contexts(安全なコンテキスト)[ 8] やMixed Content(混在コンテンツ・混合コンテンツ)[ 9] [ 10] がある。
Secure Contextsでは、いくつかの条件を満たす場合に「安全なコンテキスト(secure context)である」とする規定がなされている。これを参照して、ウェブブラウザの提供する一部の機能では、安全なコンテキストであるか否かにより挙動が変化する。そのような機能の一覧が安全なコンテキストに制限されている機能 (MDN Web Docs )にある。
Mixed contentは、セキュアな経路で取得したコンテンツ内で、非セキュアなデータの取り扱いに関する規定である。たとえば、https URLのHTMLドキュメント内でhttp URLのJavaScriptの実行は阻止される。
通信に関する仕様
https URIスキームのURLを対象とする通信に使用されるプロトコルとして、以下が存在する。
HTTP Over TLS
HTTP/1.0、HTTP/1.1、HTTP/2のいずれかをTLS接続上で使用。
HTTP/3
HTTP/3は下位層としてQUIC を使用するプロトコルであり、QUICにより暗号通信が行われる。
HTTPSの仕様が最初に標準化されたのはRFC 2818 HTTP Over TLSである。TLS上でのHTTP通信について、ホスト名の検証(証明書のサブジェクト代替名 (英語版 ) (subjectAltName)またはCommon Nameが接続しているURLのホスト名またはIPアドレスに合致することの判定)やhttps URIスキームなどの規定が明文化された。その後、HTTP本体に取り込まれ[ 11] 、 RFC 9110 となっている。また、以下のように各HTTPバージョンにも規定が移されている。
TLS接続上でのHTTP/1.1通信は、HTTP/1.1の RFC 9112 で規定されている(9.7. TLS Connection Initiation, 9.8. TLS Connection Closure)。
TLS接続上でのHTTP/2通信は、HTTP/2の RFC 9113 で規定されている(3.2. Starting HTTP/2 for "https" URIs)。
このほか、HTTPSには以下の仕様が関係している。
X.509 (PKIX)では、証明書に対する要件が規定されている。特にHTTPSに特有のものとして以下がある(RFC 5280 4.2.1.12. Extended Key Usage)。
サーバー証明書を表す拡張鍵用途: TLS WWWサーバー認証(OID 1.3.6.1.5.5.7.3.1)。
クライアント証明書を表す拡張鍵用途: TLS WWWクライアント認証(OID 1.3.6.1.5.5.7.3.2)。
Application-Layer Protocol Negotiation を用いる場合、プロトコルIDとしてhttp/1.1(RFC 7301 6. IANA Considerations)またはh2(RFC 7540 11.1. Registration of HTTP/2 Identification Strings)、h3(RFC 9114 3.1. Discovering an HTTP/3 Endpoint)を使用する。
RFCなどでプロトコルIDを登録する明示的な規定は存在しないものの、IANAの登録簿にはhttp/0.9とhttp/1.0も存在する[ 12] 。
HTTP/2 では、TLSに対する追加の要件を課している。
TLS 1.2未満の使用禁止と、TLS 1.2~1.3に対する要件: RFC 9113 9.2. Use of TLS Features
このほか、ウェブブラウザから公に信頼される証明書を発行する認証局 に対する要求として、CA/ブラウザフォーラム (英語版 ) がBaseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates を定めている[ 13] 。
https通信の手順
クライアントがhttpsサーバにTCP接続を行い、TLSハンドシェイクを開始する。または、HTTP/3の場合はQUICでのTLSハンドシェイクを開始する。
(任意)この際、ALPNで使用するプロトコルのネゴシエーションを行う。http/1.1またはh2、h3を使用する。
TLSハンドシェイク中にサーバーが提示した証明書の内容をもとに、クライアントはホスト名の検証を行う。これはRFC 9110 4.3.4. https Certificate Verificationに規定されている。
以降はTLS接続上のアプリケーションデータとしてHTTP通信を行う。または、HTTP/3の場合はQUICでのストリームとしてHTTP通信を行う。
HTTPのバージョンはALPNで決定したものを使用する。
TLSでALPNを使用していない場合は、HTTP/1.1またはHTTP/1.0を使用する。
情報の保護における誤解
この節には独自研究 が含まれているおそれがあります。 問題箇所を検証 し出典を追加 して、記事の改善にご協力ください。議論はノート を参照してください。(2013年5月 )
HTTPSを用いた保護に関するよくある誤解に、「HTTPSによる通信は入力した情報にかかわる全ての処理を完全に保護する」というものがある。HTTPSは名前の通りアプリケーションレイヤのHTTPを保護するプロトコルでありWebブラウザとWebサーバの間の通信を暗号化して、盗聴 や改竄 を防いでいるに過ぎず、IPsecのようなネットワークレイヤの保護を行うプロトコルではない。
情報を受け取ったサイトは、送信された情報のうち必要最小限のデータのみを安全に保管することが期待されるが、重要な個人情報がサイトのデータベースに格納されない保証はなく、さらにデータベースはしばしば外部からの攻撃の標的にされる。また、こうした情報が人為的に不当に流用されたり、事故によって漏洩する可能性もある[ 14] 。
このように通信が完全に保護されていたとしても、利用者が期待する安全性が確保されているとは言えない場合がある。現在のインターネットでは、フィッシング がHTTPSで行われることも多い。[ 15]
統計
2016年から2017年にかけて、HTTPSのシェアが50%を超えたという複数の調査結果が明らかになっている[ 16] [ 17] 。
2017年末、66%のシェアという調査報告がされた[ 18] 。
2018年末、httparchive.orgの調査によると、79.9%のトラフィックという調査報告がされた[ 19] [ 20] [ 21] 。
検閲
HTTPS通信は暗号化されているため、通信内容を読み取ったり改竄 したりすることはできない。そのため、基本的に通信内容を検閲することはできない。
HTTPSによる検閲対策に対抗する措置として、中華人民共和国 では、暗号化技術の利用が許可制になっている[ 22] 。また、ウィキペディア に不適切な記述を含むページがあり、ロシアがこれを検閲しようとしたが、ウィキペディアがHTTPSを用いているため問題のページ単体を検閲できず、ロシアがウィキペディア全体をブロックし、ロシア国内からウィキペディアを閲覧できなくなったこともあった[ 23] 。2019年、韓国では有害サイトへのアクセスのブロックを開始し、HTTPS(TLS)において暗号化せずに送受信するSNIからドメイン名を読み取ってブロック対象を判定していると報じられている[ 24] 。
類似のプロトコル
このほかに、TLS上でのHTTP通信に関するプロトコルが2つ存在する。いずれもURIスキームはhttpを用いる。
RFC 2817 Upgrading to TLS Within HTTP/1.1は、HTTPのUpgradeヘッダーを用いることで、HTTPと同じTCP 80番ポートでHTTP over TLS通信を行う方式を規定している。HTTPにおけるSTARTTLS に相当する。
RFC 8164 Opportunistic Security for HTTP/2は、http URLに対する通信における日和見暗号化 を提供するものである。
その他
RFC 2660 が規定するS-HTTP (Secure HTTP: Secure HyperText Transfer Protocol )は、httpsスキームで用いられるHTTP over SSL/TLSとは別のプロトコルである。S-HTTPに対応するURIスキームはshttpである。
脚注
関連項目
外部リンク
ウェブブラウザ側に関する規定
利用統計