HTTPS
チェック済み
ページは変更保留のため保護されています

ハイパーテキスト転送プロトコルセキュア（HTTPS ）は、ハイパーテキスト転送プロトコル（HTTP）の拡張版です。コンピュータネットワーク上での安全な通信のために暗号化技術を採用しており、インターネットで広く利用されています。[ 1 ] [ 2 ] HTTPSでは、通信プロトコルはトランスポート層セキュリティ（TLS）、または以前はセキュアソケットレイヤー（SSL）を使用して暗号化されます。そのため、このプロトコルはHTTP over TLS、[ 3 ]またはHTTP over SSLとも呼ばれます。

HTTPS の主な目的は、アクセスしたウェブサイトの認証と、交換されたデータが転送中にそのデータのプライバシーと整合性を保護することです。中間者攻撃から保護し、クライアントとサーバー間の通信の双方向ブロック暗号暗号化により、盗聴や改ざんから通信を保護します。[ 4 ] [ 5 ] HTTPS の認証の側面では、信頼できる第三者がサーバー側のデジタル証明書に署名する必要があります。これは歴史的に高価な操作であり、完全に認証された HTTPS 接続は通常、ワールド ワイド ウェブ上の安全な支払い取引サービスやその他の安全な企業情報システムにのみ見られました。2016 年に、電子フロンティア財団がウェブ ブラウザー開発者の支援を受けてキャンペーンを行ったことで、このプロトコルがより普及しました。[ 6 ] HTTPS は 2018 年以降[ 7 ]、安全でない HTTP よりもウェブ ユーザーによって頻繁に使用されています。これは主に、あらゆる種類のウェブサイトのページの信頼性を保護し、アカウントを保護し、ユーザーの通信、ID、ウェブ閲覧をプライベートに保つためです。

概要

HTTPSスキームとWWWドメイン名ラベルで始まるURL

URI ( Uniform Resource Identifier ) スキームであるHTTPS の使用構文は、HTTP スキームと同じです。ただし、HTTPS はブラウザに対し、トラフィックを保護するために SSL/TLS という追加の暗号化レイヤーを使用するよう指示します。SSL/TLS は、通信の片側のみが認証されている場合でもある程度の保護を提供できるため、特に HTTP に適しています。これは、インターネットを介した HTTP トランザクションの場合に当てはまります。通常、サーバーのみが認証されます（クライアントがサーバーの証明書を検証することによって認証されます）。

HTTPSは、安全でないネットワーク上に安全なチャネルを構築します。適切な暗号スイートが使用され、サーバー証明書が検証され信頼されている場合、これにより盗聴や中間者攻撃から十分な保護が確保されます。

HTTPSはHTTPをTLSの上に完全に乗せているため、基盤となるHTTPプロトコル全体を暗号化できます。これにはリクエストのURL、クエリパラメータ、ヘッダー、Cookie（多くの場合、ユーザー識別情報が含まれます）が含まれます。しかし、ウェブサイトのアドレスとポート番号は基盤となるTCP/IPプロトコルの一部であるため、HTTPSではそれらの漏洩を防ぐことはできません。実際には、これは、正しく構成されたウェブサーバーであっても、盗聴者がウェブサーバーのIPアドレスとポート番号、さらにはユーザーが通信しているドメイン名（例：www.example.org、URLの残りの部分は不明）まで推測できることを意味します。さらに、転送されたデータの量と通信時間は推測できますが、通信内容はわかりません。[ 4 ]

ウェブブラウザは、ソフトウェアにプリインストールされている証明機関に基づいて、HTTPSウェブサイトを信頼する方法を知っています。このように、証明機関はウェブブラウザの作成者によって有効な証明書を提供すると信頼されています。したがって、ユーザーは、以下のすべての条件が満たされている 場合にのみ、ウェブサイトへのHTTPS接続を信頼する必要があります。

  • ユーザーは、ブラウザをホストしているデバイスとブラウザ自体を取得する方法が侵害されていない（つまり、サプライ チェーン攻撃がない）ことを信頼しています。
  • ユーザーは、ブラウザ ソフトウェアが、正しくプリインストールされた証明機関を使用して HTTPS を正しく実装していることを信頼します。
  • ユーザーは、証明機関が正当な Web サイトのみを保証すると信頼します (つまり、証明機関が侵害されておらず、証明書の誤発行はありません)。
  • ウェブサイトは有効な証明書を提供しており、信頼できる機関によって署名されていることを意味します。
  • 証明書は Web サイトを正しく識別します (たとえば、ブラウザーが " https://example.com " にアクセスすると、受信した証明書は "example.com" のものであり、他のエンティティのものではありません)。
  • ユーザーは、プロトコルの暗号化層 (SSL/TLS) が盗聴者に対して十分に安全であると信頼しています。

HTTPSは、安全でないネットワークや改ざんされる可能性のあるネットワークでは特に重要です。公共のWi-Fiアクセスポイントなどの安全でないネットワークでは、同じローカルネットワーク上の誰もがパケットスニッフィングを行い、HTTPSで保護されていない機密情報を入手できてしまいます。さらに、一部の無料および有料のWLANネットワークでは、パケットインジェクションによってウェブページを改ざんし、他のウェブサイトに独自の広告を掲載していることが確認されています。この行為は、ウェブページにマルウェアを注入したり、ユーザーの個人情報を盗んだりするなど、様々な方法で悪用される可能性があります。 [ 8 ]

HTTPSはTorネットワークを介した接続においても重要です。悪意のあるTorノードが、安全でない方法で通過するコンテンツを破損または改ざんし、接続にマルウェアを注入する可能性があるためです。これが、電子フロンティア財団とTorプロジェクトがHTTPS Everywhereの開発を開始した理由の一つであり、[ 4 ] Torブラウザに含まれています。[ 9 ]

世界的な大規模監視や個人情報を盗む犯罪者に関する情報が明らかになるにつれ、インターネット接続の種類に関係なく、すべてのウェブサイトでHTTPSセキュリティを使用することがますます重要になっています。[ 10 ] [ 11 ]ユーザーが訪問した個々のページに関するメタデータは機密情報とは見なされないかもしれませんが、集約されるとユーザーに関する多くの情報を明らかにし、ユーザーのプライバシーを侵害する可能性があります。[ 12 ] [ 13 ] [ 14 ]

HTTPS を導入すると、ページの読み込み時間、サイズ、および待ち時間を削減するように設計された新しい HTTP バージョンであるHTTP/2とHTTP/3 (およびそれらの前身であるSPDYとQUIC )も使用できるようになります。

中間者攻撃、特にSSLストリッピングからユーザーを保護するために、HTTPSとHTTP Strict Transport Security （HSTS）を併用することが推奨されています。[ 14 ] [ 15 ]

HTTPS を、RFC 2660 で指定されている、 あまり使用されないSecure HTTP (S-HTTP) と混同しないでください。

ウェブサイトでの使用

2018年4月時点で、Alexaのトップ1,000,000ウェブサイトの33.2%がデフォルトでHTTPSを使用しており[ 16 ]、ページ読み込みの70%（Firefox Telemetryで測定）がHTTPSを使用しています。[ 17 ] 2025年6月時点で、インターネットで最も人気のある150,000のウェブサイトの71.2%がHTTPSの安全な実装を備えています（2022年12月の58.4%から増加）[ 18 ]。ただし、 2018年にTLS 1.3がリリースされたにもかかわらず、採用は遅く、多くのサイトが依然として古いTLS 1.2プロトコルのままです。[ 19 ]

ブラウザ統合

ほとんどのブラウザは、無効な証明書を受信すると警告を表示します。古いブラウザでは、無効な証明書を持つサイトに接続すると、ユーザーに続行するかどうかを尋ねるダイアログボックスが表示されていました。新しいブラウザでは、ウィンドウ全体に警告が表示されます。また、新しいブラウザは、アドレスバーにサイトのセキュリティ情報を目立つように表示します。EV証明書（EVC）では、証明書情報に法人組織名が表示されます。ほとんどのブラウザは、暗号化されたコンテンツと暗号化されていないコンテンツが混在するサイトにアクセスした場合にも、ユーザーに警告を表示します。さらに、多くのウェブフィルターは、禁止されているウェブサイトにアクセスした際にセキュリティ警告を返します。

さまざまな種類のSSL/TLS証明書の比較( Firefoxを例に)
  • Firefox (ここに表示) を含む多くの Web ブラウザは、アドレス バーを使用してユーザーに接続が安全であることを通知しますが、Extended Validation 証明書では証明書の法人を識別する必要があります。
    Firefox (ここに表示) を含む多くの Web ブラウザは、アドレス バーを使用してユーザーに接続が安全であることを通知しますが、Extended Validation 証明書では証明書の法人を識別する必要があります。
  • 共通証明書のみでサイトにアクセスすると、Firefox などのブラウザのアドレスバーに「ロック」記号が表示されます。
    共通証明書のみでサイトにアクセスすると、Firefoxなどのブラウザのアドレスバーに「ロック」記号が表示されます。
  • ほとんどの Web ブラウザは、無効なセキュリティ証明書を持つサイトにアクセスするとユーザーに警告を表示します。
    ほとんどの Web ブラウザは、無効なセキュリティ証明書を持つサイトにアクセスするとユーザーに警告を表示します。

電子フロンティア財団は、「理想的な世界では、すべてのウェブリクエストがデフォルトでHTTPSになる可能性がある」として、 Mozilla Firefox、Google Chrome、Chromium、Android向けにHTTPS Everywhereというアドオンを提供しており、これにより、頻繁に使用される数百のウェブサイトでデフォルトでHTTPSが有効になる。[ 20 ] [ 21 ]

Firefoxのバージョン83以降では、ウェブブラウザにHTTPSコンテンツのみを強制的に読み込む機能がサポートされています。[ 22 ] Google Chromeのバージョン94以降では、ブラウザの設定で「常に安全な接続を使用する」に切り替えることができます。[ 23 ] [ 24 ]

安全

HTTPSのセキュリティは、基盤となるTLSのセキュリティです。TLSは通常、長期公開鍵と秘密鍵を用いて短期セッション鍵を生成し、この鍵を用いてクライアントとサーバー間のデータフローを暗号化します。X.509証明書はサーバー（場合によってはクライアントも）の認証に使用されます。そのため、証明書とその所有者の関係を検証し、証明書の生成、署名、有効性の管理を行うために、証明機関と公開鍵証明書が必要となります。これは信頼の輪を介して本人確認を行うよりも効果的ですが、2013年の大規模監視の暴露により、証明機関が中間者攻撃を許す潜在的な弱点として注目を集めました。[ 25 ] [ 26 ]この文脈において重要な特性は前方秘匿性です。これは、長期秘密鍵やパスワードが将来漏洩した場合でも、過去に記録された暗号化通信を取得・復号できないことを保証します。すべてのWebサーバーが前方秘匿性を提供しているわけではありません。[ 27 ]

HTTPS を効果的に利用するには、サイト全体が HTTPS でホストされている必要があります。サイトのコンテンツの一部（スクリプトや画像など）が HTTP で読み込まれている場合、またはログインページなど機密情報を含む特定のページのみが HTTPS で読み込まれ、サイトの残りの部分が通常の HTTP で読み込まれている場合、ユーザーは攻撃や監視に対して脆弱になります。さらに、HTTPS で提供されるサイトのCookieにはsecure 属性が有効になっている必要があります。機密情報を含むサイトでは、HTTPS ではなく HTTP でアクセスするたびに、ユーザーとセッションが危険にさらされることになります。[ 14 ]

テクニカル

HTTPとの違い

HTTPS URL は「https://」で始まり、デフォルトでポート443 を使用しますが、HTTP URL は「http://」で始まり、デフォルトでポート 80 を使用します。

HTTPは暗号化されていないため、中間者攻撃や盗聴攻撃に対して脆弱です。これらの攻撃により、攻撃者はウェブサイトのアカウントや機密情報にアクセスしたり、ウェブページを改ざんしてマルウェアや広告を挿入したりする可能性があります。HTTPSはこのような攻撃に耐えられるように設計されており、安全であると考えられています（ただし、非推奨のSSLバージョンを使用するHTTPS実装は除きます）。

ネットワーク層

HTTPはTCP/IPモデルの最上位層であるアプリケーション層で動作します。TLSセキュリティプロトコル（同じ層の下位サブ層として動作）も同様に動作します。TLSはHTTPメッセージを送信前に暗号化し、受信時に復号化します。厳密に言えば、HTTPSは独立したプロトコルではなく、暗号化されたSSL/TLS接続を介して通常のHTTPを使用することを指します。

HTTPSは、HTTPヘッダーとリクエスト/レスポンスデータを含むすべてのメッセージコンテンツを暗号化します。以下の制限事項のセクションで説明するCCA暗号攻撃の可能性を除けば、攻撃者はせいぜい、2者間で接続が行われているという事実と、それぞれのドメイン名およびIPアドレスを知ることができる程度です。

サーバーのセットアップ

HTTPS接続を受け入れるようにWebサーバーを準備するには、管理者はWebサーバーの公開鍵証明書を作成する必要があります。Webブラウザが警告なしに証明書を受け入れるには、この証明書が信頼できる証明機関によって署名されている必要があります。証明機関は、証明書の所有者が、証明書を提示するWebサーバーの運営者自身であることを証明する必要があります。Webブラウザには通常、主要な証明機関の署名証明書のリストが配布されており、各証明機関によって署名された証明書を検証できます。

証明書の取得

数多くの商用証明機関が存在し、 Extended Validation Certificatesを含むさまざまなタイプの有料 SSL/TLS 証明書を提供しています。

2016年4月に開始されたLet's Encrypt [ 28 ]は、ウェブサイトに基本的なSSL/TLS証明書を配信する無料の自動サービスを提供しています。[ 29 ]電子フロンティア財団によると、Let's Encryptにより、HTTPからHTTPSへの切り替えは「1つのコマンドを発行するか、1つのボタンをクリックするのと同じくらい簡単」になります。[ 30 ]現在、ほとんどのウェブホストとクラウドプロバイダーがLet's Encryptを活用し、顧客に無料の証明書を提供しています。

アクセス制御として使用

このシステムは、Webサーバーへのアクセスを承認されたユーザーのみに制限するためのクライアント認証にも使用できます。これを行うには、通常、サイト管理者は各ユーザーに対して証明書を作成し、ユーザーはそれをブラウザに読み込みます。通常、証明書には承認されたユーザーの名前とメールアドレスが含まれており、接続ごとにサーバーによって自動的にチェックされ、ユーザーのIDが検証されます。パスワードを要求されない場合もあります。

秘密鍵（プライベート鍵）が侵害された場合

この文脈で重要な特性は、完全前方秘匿性（PFS）である。HTTPSセッションを確立するために使用される長期非対称秘密鍵の1つを所有することで、たとえ後であっても、会話を復号化するための短期セッション鍵の導出が容易になってはならない。 2013年時点でこの特性を持つことが知られている方式は、ディフィー・ヘルマン鍵交換（DHE）と楕円曲線ディフィー・ヘルマン鍵交換（ECDHE）のみである。2013年には、Firefox、Opera、Chromiumブラウザのセッションでこの特性が使用されていたのはわずか30%で、AppleのSafariとMicrosoft Internet Explorerのセッションではほぼ0%であった。[ 27 ] 2018年8月に公開されたTLS 1.3では、前方秘匿性のない暗号のサポートが廃止された。 2019年2月現在、調査対象のウェブサーバーの96.6%が何らかの形式の前方秘匿性をサポートしており、52.1%がほとんどのブラウザで前方秘匿性を使用する予定です。[ 31 ] 2023年7月現在、調査対象のウェブサーバーの99.6%が何らかの形式の前方秘匿性をサポートしており、75.2%がほとんどのブラウザで前方秘匿性を使用する予定です。[ 32 ]

証明書の失効

証明書は、有効期限が切れる前に、例えば秘密鍵の機密性が損なわれたなどの理由で失効することがあります。Firefox [ 33 ] 、Opera [ 34 ]、Windows VistaのInternet Explorer [ 35 ]などの人気ブラウザの新しいバージョンでは、そうでないことを確認するためにオンライン証明書ステータス プロトコル(OCSP)が実装されています。ブラウザは OCSP (オンライン証明書ステータス プロトコル) を介して証明書のシリアル番号を証明機関またはその代理人に送信し、証明機関はそれに応答して、ブラウザに証明書がまだ有効かどうかを通知します。[ 36 ]また、CA はこれらの証明書が失効したことを人々に通知するためにCRLを発行することもあります。CRL は CA/ブラウザ フォーラムでは必須ではなくなりましたが[ 37 ]、CA では依然として広く使用されています。インターネット上のほとんどの失効ステータスは、証明書の有効期限が切れるとすぐに消えます。[ 38 ]

制限事項

SSL（Secure Sockets Layer）とTLS（Transport Layer Security）暗号化は、シンプルモードと相互モードの2つのモードで設定できます。シンプルモードでは、認証はサーバー側でのみ行われます。相互モードでは、ユーザーは認証のためにWebブラウザに個人のクライアント証明書をインストールする必要があります。 [ 39 ]どちらの場合も、保護レベルはソフトウェアの実装の正確性と使用されている暗号化アルゴリズムに依存します。

SSL/TLSはウェブクローラーによるサイトのインデックス作成を阻止できず、場合によっては傍受したリクエスト/レスポンスのサイズを知るだけで暗号化されたリソースのURIを推測できる可能性があります。 [ 40 ]これにより、攻撃者は平文（公開されている静的コンテンツ）と暗号化されたテキスト（静的コンテンツの暗号化バージョン）にアクセスでき、暗号攻撃が可能になります。

TLSはHTTPよりも下位のプロトコルレベルで動作し、上位プロトコルの知識を持たないため、TLSサーバーは特定のアドレスとポートの組み合わせに対して1つの証明書しか提示できません。 [ 41 ]これまで、これはHTTPSで名前ベースの仮想ホスティングを使用することが現実的ではないことを意味していました。Server Name Indication （SNI）と呼ばれるソリューションがあり、これは接続を暗号化する前にホスト名をサーバーに送信しますが、古いブラウザはこの拡張機能をサポートしていません。SNIのサポートは、Firefox 2、Opera 8、Apple Safari 2.1、Google Chrome 6、およびWindows Vista上のInternet Explorer 7以降で利用可能です。[ 42 ] [ 43 ] [ 44 ]

2009年のブラックハットカンファレンスでは、SSLストリッピングと呼ばれる高度な中間者攻撃が発表されました。この攻撃は、リンクをリンクに変更することでHTTPSが提供するセキュリティを破ります。インターネットユーザーがブラウザインターフェースに「https」と入力するケースは少ないという事実を悪用します。ユーザーはリンクをクリックして安全なサイトにアクセスし、実際にはHTTPを使用しているにもかかわらず、HTTPSを使用していると勘違いしてしまいます。攻撃者はその後、クライアントと平文で通信を行います。[ 45 ]このことがきっかけとなり、HTTPにおけるHTTP Strict Transport Securityと呼ばれる対策が開発されました。 https:http:

HTTPSは、様々なトラフィック分析攻撃に対して脆弱であることが示されています。トラフィック分析攻撃は、トラフィックのタイミングとサイズの変化を利用して暗号化されたトラフィック自体の特性を推測するサイドチャネル攻撃の一種です。SSL/TLS暗号化はトラフィックの内容を変更するものの、トラフィックのサイズとタイミングには最小限の影響しか与えないため、トラフィック分析が可能になります。2010年5月、Microsoft Researchとインディアナ大学の研究者による研究論文で、パケットサイズなどのサイドチャネルから詳細な機密ユーザーデータを推測できることが発見されました。研究者たちは、医療、税務、投資、ウェブ検索などの著名な最先端ウェブアプリケーションのいくつかでHTTPS保護が採用されているにもかかわらず、盗聴者はユーザーの病気／投薬／手術、家族の収入、投資に関する秘密を推測できることを発見しました。[ 46 ]

Google、Yahoo!、Amazonなど、最近のウェブサイトのほとんどがHTTPSを使用しているため、公衆Wi-Fiホットスポットにアクセスしようとする多くのユーザーに問題が発生しています。これは、ユーザーがHTTPSリソースを開こうとすると、キャプティブポータルWi-Fiホットスポットのログインページが読み込まれないためです。 [ 47 ] NoSSL.shなどのいくつかのウェブサイトは、常にHTTPでアクセス可能であることを保証しています[ 48 ]。

歴史

Netscape Communicationsは、 1994年にNetscape Navigatorウェブブラウザ用にHTTPSを作成した。[ 49 ]当初、HTTPSはSSLプロトコルで使用されていた。[ 50 ]オリジナルのSSLプロトコルは、 Netscape Communicationsの主任科学者であるTaher Elgamalによって開発された。[ 51 ] [ 52 ] [ 53 ] SSLがトランスポート層セキュリティ（TLS）に進化したため、HTTPSは2000年5月にRFC 2818 [ 54 ]によって正式に規定された。Googleは2018年2月、Chromeブラウザが2018年7月以降HTTPサイトを「安全でない」とマークすると発表した。[ 50 ]この動きは、ワールドワイドウェブをより安全にするための取り組みとして、ウェブサイト所有者にHTTPSの実装を促すためであった。

参照

参考文献

  1. ^ 「HTTPSでサイトを保護する」 Googleサポート、Google Inc. 2015年3月1日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  2. ^ 「HTTPSとは？」 Comodo CA Limited . 2015年2月12日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。Hyper Text Transfer Protocol Secure（HTTPS）は、HTTPのセキュアバージョンです [...]
  3. ^ "https URIスキーム" . HTTPセマンティクス. IETF . 2022年6月 . sec. 4.2.2. doi : 10.17487/RFC9110 . RFC 9110 .
  4. ^ a b c「HTTPS Everywhere FAQ」。2016年11月8日。2018年11月14日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  5. ^ 「ウェブサイトのデフォルトプロトコルhttpsの使用統計、2019年7月」w3techs.com。2019年8月1日時点のオリジナルよりアーカイブ。2019年7月20日閲覧。
  6. ^ 「Webの暗号化」電子フロンティア財団。2019年11月18日時点のオリジナルよりアーカイブ。2019年11月19日閲覧。
  7. ^ 「世界トップ100万のウェブサイトの大半が現在HTTPSを使用している」 welivesecurity.com 2025年5月22日閲覧。
  8. ^ 「ホテルのWifi JavaScriptインジェクション」JustInsomnia、2012年4月3日。2018年11月18日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  9. ^ The Tor Project, Inc. 「Torブラウザとは？」TorProject.org . 2013年7月17日時点のオリジナルよりアーカイブ。2012年5月30日閲覧。
  10. ^ Konigsburg, Eitan; Pant, Rajiv; Kvochko, Elena (2014年11月13日). 「HTTPSの採用」 . The New York Times . 2019年1月8日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  11. ^ギャラガー、ケビン（2014年9月12日）「NSAの暴露から15ヶ月、なぜ報道機関はHTTPSを採用していないのか？」報道の自由財団。2018年8月10日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  12. ^ 「HTTPS をランキングシグナルとして」。Google Webmaster Central ブログ。Google Inc.、2014年8月6日。2018年10月17日時点のオリジナルからのアーカイブ。2018年10月20日閲覧。HTTPS （Hypertext Transfer Protocol Secure）を使用すると、サイトを安全に保護できます。[...]
  13. ^ Grigorik, Ilya; Far, Pierre (2014年6月26日). 「Google I/O 2014 - HTTPS Everywhere」 . Google Developers. 2018年11月20日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  14. ^ a b c「HTTPSを正しく導入する方法」。2010年11月15日。2018年10月10日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  15. ^ 「HTTP Strict Transport Security」 . Mozilla Developer Network . 2018年10月19日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  16. ^ 「上位100万ウェブサイトのHTTPS使用統計」StatOperator.com。 2019年2月9日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  17. ^ “Let's Encrypt Stats” . LetsEncrypt.org . 2018年10月19日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  18. ^ “Qualys SSL Labs - SSL Pulse” . www.ssllabs.com . 2025年6月2日. 2022年12月7日時点のオリジナルよりアーカイブ。 2022年12月7日閲覧。。
  19. ^ 「TLS 1.3：強力なウェブ暗号化の導入が遅れ、悪意のある人物に攻撃の手が伸びている」 Help Net Security . 2020年4月6日. 2022年5月24日時点のオリジナルよりアーカイブ。 2022年5月23日閲覧。
  20. ^ Eckersley, Peter (2010年6月17日). 「HTTPS Everywhere Firefox拡張機能でWebを暗号化」 . EFFブログ. 2018年11月25日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  21. ^ 「HTTPS Everywhere」EFFプロジェクト。2011年10月7日。2011年6月5日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  22. ^ 「FirefoxのHTTPS専用モード」。2021年11月12日時点のオリジナルよりアーカイブ。2021年11月12日閲覧。
  23. ^ 「Chrome の安全性とセキュリティを管理する - Android - Google Chrome ヘルプ」 support.google.com . 2022年3月7日時点のオリジナルよりアーカイブ。 2022年3月7日閲覧。
  24. ^ Venkat (2021年7月19日). 「ChromeのHTTPSファーストモードを体験」 Techdows . 2022年3月7日時点のオリジナルよりアーカイブ。2022年3月7日閲覧。
  25. ^ Singel, Ryan (2010年3月24日). 「Law Enforcement Appliance Subverts SSL」 . Wired . 2019年1月17日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  26. ^ Schoen, Seth (2010年3月24日). 「新たな研究によると、政府はSSL証明書を偽造している可能性がある」 . EFF . 2016年1月4日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  27. ^ a b Duncan, Robert (2013年6月25日). 「SSL: Intercepted today, decrypted tomorrow」 . Netcraft . 2018年10月6日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  28. ^ Cimpanu, Catalin (2016年4月12日). 「Let's Encryptが本日ローンチ、現在380万のドメインを保護」 Softpedia News. 2019年2月9日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  29. ^ Kerner, Sean Michael (2014年11月18日). 「Let's Encryptの取り組みはインターネットセキュリティの向上を目指す」 . eWeek.com . Quinstreet Enterprise. 2023年4月2日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  30. ^ Eckersley, Peter (2014年11月18日). 「2015年にローンチ：ウェブ全体を暗号化する認証局」 .電子フロンティア財団. 2018年11月18日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  31. ^ Qualys SSL Labs . 「SSL Pulse」 . 2019年2月3日時点のオリジナルより2019年2月15日時点のアーカイブ。2019年2月25日閲覧。
  32. ^ 「Qualys SSL Labs - SSL Pulse」www.ssllabs.com . 2023年9月4日閲覧。
  33. ^ 「Mozilla Firefox プライバシーポリシー」Mozilla Foundation、2009年4月27日。2018年10月18日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  34. ^ 「Opera 8がFTPで起動」 Softpedia 、 2005年4月19日。2019年2月9日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  35. ^ Lawrence, Eric (2006年1月31日). 「Internet Explorer 7におけるHTTPSセキュリティの改善」 . Microsoft Docs . 2021年10月24日時点のオリジナルよりアーカイブ。 2021年10月24日閲覧。
  36. ^ Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (1999年6月20日). 「オンライン証明書ステータスプロトコル – OCSP」 . Internet Engineering Task Force . doi : 10.17487/RFC2560 . 2011年8月25日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  37. ^ 「ベースライン要件」 CABフォーラム、2013年9月4日。2014年10月20日時点のオリジナルよりアーカイブ。 2021年11月1日閲覧。
  38. ^ Korzhitskii, N.; Carlsson, N. (2021年3月30日). 「インターネット上の失効ステータス」.受動的測定と能動的測定. コンピュータサイエンス講義ノート. 第12671巻. pp.  175– 191. arXiv : 2102.04288 . doi : 10.1007/978-3-030-72582-2_11 . ISBN 978-3-030-72581-5。
  39. ^ 「Chrome 端末でのクライアント証明書の管理 - Chrome for Business および教育機関向けヘルプ」 support.google.com 。 2019年2月9日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  40. ^ Pusep, Stanislaw (2008年7月31日). 「The Pirate Bay un-SSL」(PDF) . 2018年6月20日時点のオリジナルよりアーカイブ(PDF) . 2018年10月20日閲覧。
  41. ^ 「SSL/TLS Strong Encryption: FAQ」apache.org . 2018年10月19日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  42. ^ Lawrence, Eric (2005年10月22日). 「Internet Explorer 7 Beta 2における今後のHTTPSの改善」 . Microsoft . 2018年9月20日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  43. ^ 「Server Name Indication (SNI)」 . inside aebrahim's head . 2006年2月21日. 2018年8月10日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  44. ^ Pierre, Julien (2001年12月19日). 「TLSサーバー名表示のブラウザサポート」 . Bugzilla . Mozilla Foundation. 2018年10月8日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  45. ^ “sslstrip 0.9” . 2018年6月20日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  46. ^ Shuo Chen、Rui Wang、XiaoFeng Wang、Kehuan Zhang (2010年5月20日). 「Webアプリケーションにおけるサイドチャネル漏洩：今日の現実、明日の課題」 . Microsoft Research . IEEE Symposium on Security & Privacy 2010. 2018年7月22日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  47. ^ Guaay, Matthew (2017年9月21日). 「公衆Wi-Fiネットワークのログインページを強制的に開く方法」 . 2018年8月10日時点のオリジナルよりアーカイブ。 2018年10月20日閲覧。
  48. ^ "nossl.sh HTTPのみの免責事項" . nossl.sh . 2025年12月18日閲覧。
  49. ^ウォールズ、コリン (2005).組み込みソフトウェア：その成果. ニューネス. p. 344. ISBN 0-7506-7954-9. 2019年2月9日時点のオリジナルよりアーカイブ。2018年10月20日閲覧。
  50. ^ a b「安全なウェブはこれからも存在し続ける」 Chromium Blog . 2019年4月24日時点のオリジナルよりアーカイブ。 2019年4月22日閲覧。
  51. ^メスマー、エレン. 「SSLの父、タヘル・エルガマル博士、中東で急速に発展するITプロジェクトを発見」 . Network World . 2014年5月31日時点のオリジナルよりアーカイブ。 2014年5月30日閲覧。
  52. ^ Greene, Tim. 「SSLの父は、攻撃にもかかわらず、セキュリティの要であるSSLにはまだまだ寿命があると語る」 Network World . 2014年5月31日時点のオリジナルよりアーカイブ。 2014年5月30日閲覧。
  53. ^ Oppliger, Rolf (2016). 「序論」 . SSLとTLS：理論と実践（第2版）. Artech House . p. 13. ISBN 978-1-60807-999-52018年3月1日閲覧– Googleブックス経由。
  54. ^ Rescorla, Eric (2000年5月). HTTP Over TLS (レポート). インターネット技術タスクフォース.
ウィキメディア コモンズには、 HTTPSに関連するメディアがあります。
  • RFC  8446 : トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3
「 https://en.wikipedia.org/w/index.php?title=HTTPS&oldid=1330814157」から取得