Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
コンテンツにスキップ

HTTPS

出典: フリー百科事典『ウィキペディア（Wikipedia）』
HTTP
主要項目
リクエストメソッド
ヘッダーフィールド（英語版）
ステータスコード
認証方式
セキュリティホール
インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

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通信の手順

[編集]
  1. クライアントがhttpsサーバにTCP接続を行い、TLSハンドシェイクを開始する。または、HTTP/3の場合はQUICでのTLSハンドシェイクを開始する。
    • （任意）この際、ALPNで使用するプロトコルのネゴシエーションを行う。http/1.1またはh2、h3を使用する。
  2. TLSハンドシェイク中にサーバーが提示した証明書の内容をもとに、クライアントはホスト名の検証を行う。これはRFC 9110 4.3.4. https Certificate Verificationに規定されている。
  3. 以降はTLS接続上のアプリケーションデータとしてHTTP通信を行う。または、HTTP/3の場合はQUICでのストリームとしてHTTP通信を行う。
    • HTTPのバージョンはALPNで決定したものを使用する。
    • TLSでALPNを使用していない場合は、HTTP/1.1またはHTTP/1.0を使用する。

情報の保護における誤解

[編集]

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である。

脚注

[編集]
[脚注の使い方]
  1. ^ 國谷武史; ITmedia (2012年3月29日). “Webサイトに“常時SSL”の実装を――団体提唱の米国で機運高まる？”. ITmedia エンタープライズ. 2019年9月21日閲覧。 “Wi-Fiスポットが特に危険とされるのは、攻撃者が正規ユーザーのすぐ近くに身を潜めて通信を傍受できてしまう可能性が高いため。”
  2. ^ 鈴木聖子; ITmedia (2014年12月16日). “HTTP接続は「安全でない」と明示すべし――Googleが提案 - ITmedia エンタープライズ”. ITmedia. 2016年11月26日閲覧。
  3. ^ “【翻訳】安全でない HTTP の廃止 - Mozilla Security Blog 日本語版” (2015年9月17日). 2016年11月26日閲覧。
  4. ^ “Securing the Web” (英語). W3C (2015年1月22日). 2016年11月26日閲覧。
  5. ^ 大津繁樹 (2018年2月14日). “今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景”. エンジニアHub powered by エン転職. 2019年9月21日閲覧。
  6. ^ 鈴木聖子; ITmedia (2014年8月8日). “WebサイトのHTTPS対応、Google検索ランキングに反映”. ITmedia NEWS. 2019年9月21日閲覧。 “米Googleは8月6日、デフォルトでのHTTPS接続を推進する一環として、WebサイトがHTTPSを使っているかどうかを検索ランキングに反映させると発表した。ユーザーがGoogleのサービスを通じてアクセスするWebサイトのセキュリティ強化を促す措置と説明している。”
  7. ^ HTTPS をランキング シグナルに使用します
  8. ^ “安全なコンテキスト - ウェブセキュリティ”. MDN Web Docs. 2020年5月9日閲覧。
  9. ^ “混在コンテンツ - Security”. MDN Web Docs. 2020年5月9日閲覧。
  10. ^ Jo-el van Bergen. “混合コンテンツとは”. Google Developers. 2020年5月9日閲覧。
  11. ^ Mark Nottingham (2019年8月20日). “Bring RFC2818 into semantics · Issue #236 · httpwg/http-core”. GitHub. 2022年7月3日閲覧。
  12. ^ Transport Layer Security (TLS) Extensions, TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
  13. ^ CA/Browser Forum. “About the Baseline Requirements” (英語). 2021年2月12日閲覧。 “The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a certification authority must meet in order to issue digital certificates for SSL/TLS servers to be publicly trusted by browsers.”
  14. ^ 山崎 文明 (2010年11月25日). “欧米セキュリティ事情の新潮流 SSLでは不十分、クラウド時代の暗号化”. 日経 xTECH（クロステック）. 2019年9月28日閲覧。
  15. ^ “HTTPSが安全とは限らない | カスペルスキー公式ブログ” (2018年1月22日). 2022年9月29日閲覧。 “今ではフィッシング詐欺の4分の1がHTTPSサイトで行われています”
  16. ^ 後藤大地 (2016年11月9日). “Google、Chromeで半数以上がHTTPSを利用と発表”. マイナビニュース > 企業IT > セキュリティ. 2017年3月16日閲覧。
  17. ^ 後藤大地 (2017年2月3日). “HTTPS、トラフィックの50%を突破”. マイナビニュース > 企業IT > セキュリティ. 2017年3月16日閲覧。
  18. ^ letsencryptのツイート（938091855941550080）
  19. ^ https://httparchive.org/reports/state-of-the-web#pctHttps
  20. ^ https://letsencrypt.org/stats/
  21. ^ https://web.archive.org/web/20190414205011/https://etherealmind.com/percentage-of-https-tls-encrypted-traffic-on-the-internet/
  22. ^ “中国大陸でネット検閲の中，HTTPSでGmailなどを安全に使えるのかどうか”. モバイル通信とIT技術をコツコツ勉強するブログ. 2017年2月16日閲覧。
  23. ^ “ロシアでWikipediaが禁止サイトのリストに加えられ閲覧不能に、原因は一体何だったのか？”. GIGAZINE. 2017年2月16日閲覧。
  24. ^ 大森敏行 (2019年2月25日). “韓国がアダルトサイトのブロックに使う技術、SNIの正体”. 日経クロステック（xTECH）. 2020年7月19日閲覧。

関連項目

[編集]

外部リンク

[編集]

ウェブブラウザ側に関する規定

[編集]

利用統計

[編集]
公式
非公式
プロトコル一覧（英語版）
プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装
「https://ja.wikipedia.org/w/index.php?title=HTTPS&oldid=102818528」から取得