HTTPS

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Hypertext Transfer Protocol SecureHTTPS)は、Hypertext Transfer Protocol(HTTP)の拡張機能です。コンピュータネットワークを介した安全な通信に使用され、インターネットで広く使用されています。[2] [3] HTTPSでは、通信プロトコルはトランスポート層セキュリティ(TLS)または以前のSecure Sockets Layer(SSL)を使用して暗号化されます。したがって、このプロトコルはHTTP over TLS [4]またはHTTPoverSSLとも呼ばれます

HTTPSの主な動機は、アクセスされたWebサイトの認証、および転送中の交換されたデータのプライバシー整合性の保護です。中間者攻撃から保護し、クライアントとサーバー間の通信の双方向暗号化により、盗聴改ざんから通信を保護します。[5] [6] HTTPSの認証の側面では、信頼できるサードパーティがサーバー側のデジタル証明書に署名する必要がありますこれは歴史的に費用のかかる操作でした。つまり、完全に認証されたHTTPS接続は、通常、ワールドワイドウェブ上の安全な支払いトランザクションサービスやその他の安全な企業情報システムでのみ見つかりました。2016年には、Webブラウザ開発者の支援を受けたElectronic Frontier Foundationによるキャンペーンにより、プロトコルがより普及しました。[7] HTTPSは、主にすべてのタイプのWebサイトでページの信頼性を保護するために、元の非セキュアHTTPよりもWebユーザーによって頻繁に使用されるようになりました。安全なアカウント; また、ユーザーのコミュニケーション、ID、およびWebブラウジングを非公開に保つため。

概要

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

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

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

HTTPSは完全にTLSの上にHTTPをピギーバックするため、基盤となるHTTPプロトコル全体を暗号化できます。これには、要求URL(特定のWebページが要求された)、クエリパラメーター、ヘッダー、およびCookie(多くの場合ユーザーに関する識別情報が含まれています)が含まれます。ただし、Webサイトのアドレスとポート番号は、基盤となるTCP / IPの一部である必要があるためです。プロトコル、HTTPSはそれらの開示を保護することはできません。実際には、これは、正しく構成されたWebサーバー上でも、盗聴者がWebサーバーのIPアドレスとポート番号を推測できることを意味します。ドメイン名(たとえば、www.example.org、残りのURLではない)も推測できます。ユーザーは、転送されたデータの量と通信の期間とともに通信していますが、通信の内容は通信していません。[5]

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

  • ユーザーは、ブラウザソフトウェアが正しくプリインストールされた認証局を使用してHTTPSを正しく実装していることを信頼します。
  • ユーザーは、認証局を信頼して、正当なWebサイトのみを保証します。
  • Webサイトは有効な証明書を提供します。これは、信頼できる機関によって署名されたことを意味します。
  • 証明書はWebサイトを正しく識別します(たとえば、ブラウザが「https://example.com」にアクセスした場合、受信した証明書は「example.com」用であり、他のエンティティではありません)。
  • ユーザーは、プロトコルの暗号化レイヤー(SSL / TLS)が盗聴者に対して十分に安全であると信頼しています。

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

HTTPSは、Torネットワークを介した接続にとっても重要です。悪意のあるTorノードは、安全でない方法で通過するコンテンツを損傷または変更し、マルウェアを接続に注入する可能性があるためです。これが、 Electronic FrontierFoundationTorProjectがTorBrowserに含まれているHTTPSEverywhere [ 5]の開発を開始した理由の1つです。[9]

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

HTTPSをデプロイすると、HTTP / 2(またはその前身である現在は非推奨のプロトコルSPDY)を使用することもできます。これは、ページの読み込み時間、サイズ、および待ち時間を短縮するように設計された新世代のHTTPです。

中間者攻撃、特にSSLストリッピングからユーザーを保護するために、HTTPSでHTTP Strict Transport Security (HSTS)を使用することをお勧めします[14] [15]

HTTPSは、RFC 2660で指定され ているめったに使用されないセキュアHTTP (S-HTTP)と混同しないでください。

ウェブサイトでの使用

2018年4月の時点で、Alexaの上位1,000,000のWebサイトの33.2%がデフォルトとしてHTTPSを使用します)HTTPSを使用します。[18]

ブラウザ統合

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

Electronic Frontier Foundationは、 「理想的な世界では、すべてのWebリクエストをデフォルトでHTTPSに設定できる」と述べ、Mozilla FirefoxGoogle ChromeChromiumAndroidにHTTPS Everywhereというアドオンを提供しました。これにより、デフォルトでHTTPSが有効になります。何百もの頻繁に使用されるWebサイト。[19] [20]

WebブラウザにHTTPSコンテンツのみをロードさせることは、バージョン83以降のFirefoxでのみサポートされています。[21]

セキュリティ

HTTPSのセキュリティは、基盤となるTLSのセキュリティです。これは通常、長期の公開鍵と秘密鍵を使用して短期のセッションキーを生成し、クライアントとサーバー間のデータフローを暗号化するために使用されます。X.509証明書は、サーバー(場合によってはクライアントも)を認証するために使用されます。結果として、認証局公開鍵証明書は、証明書とその所有者との関係を検証し、証明書の有効性を生成、署名、および管理するために必要です。これは、信頼の網を介して身元を確認するよりも有益な場合がありますが2013年の大量監視の開示中間者攻撃を可能にする潜在的な弱点として、認証局に注目を集めました[22] [23]このコンテキストでの重要なプロパティは、Forward Secrecyです。これにより、過去に記録された暗号化された通信を、将来、長期の秘密鍵またはパスワードが危険にさらされた場合に取得および復号化できなくなります。すべてのWebサーバーがForwardSecrecyを提供するわけではありません。[24] [更新が必要]

HTTPSを有効にするには、サイトをHTTPS経由で完全にホストする必要があります。サイトのコンテンツの一部(スクリプトや画像など)がHTTP経由で読み込まれる場合、またはログインページなどの機密情報を含む特定のページのみがHTTPS経由で読み込まれ、サイトの残りの部分が読み込まれる場合プレーンHTTPを介すると、ユーザーは攻撃や監視に対して脆弱になります。さらに、HTTPSを介して提供されるサイトのCookieでは、セキュア属性を有効にする必要があります。機密情報が含まれているサイトでは、HTTPSではなくHTTPを使用してサイトにアクセスするたびに、ユーザーとセッションが公開されます。[14]

テクニカル

HTTPとの違い

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

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

ネットワークレイヤー

HTTPは、 TCP / IPモデルの最上位層(アプリケーション層)で動作ますTLSセキュリティプロトコル(同じレイヤーの下位サブレイヤーとして動作)も同様です。これは、送信前にHTTPメッセージを暗号化し、到着時にメッセージを復号化します厳密に言えば、HTTPSは別個のプロトコルではありませんが、暗号化されたSSL / TLS接続を 介した通常のHTTPの使用を指します。

HTTPSは、HTTPヘッダーや要求/応答データを含むすべてのメッセージコンテンツを暗号化します。以下の制限のセクションで説明されている可能性のあるCCA暗号化攻撃を除いて、攻撃者はせいぜい、ドメイン名とIPアドレスとともに2者間で接続が行われていることを発見できるはずです。

サーバーのセットアップ

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

証明書の取得

多くの商用認証局が存在し、 Extended ValidationCertificatesを含む多くのタイプの有料SSL / TLS証明書を提供しています

2016年4月に開始されたLet'sEncrypt [25]は、基本的なSSL / TLS証明書をWebサイトに配信する無料の自動化されたサービスを提供します。[26] Electronic Frontier Foundationによると、Let's Encryptを使用すると、HTTPからHTTPSへの切り替えが「1つのコマンドを発行するか、1つのボタンをクリックするのと同じくらい簡単」になります。[27]現在、Webホストとクラウドプロバイダーの大多数はLet's Encryptを活用して、顧客に無料の証明書を提供しています。

アクセス制御として使用

このシステムは、Webサーバーへのアクセスを許可されたユーザーに制限するためのクライアント認証にも使用できます。これを行うために、サイト管理者は通常、ユーザーごとに証明書を作成し、ユーザーはそれをブラウザーにロードします。通常、証明書には許可されたユーザーの名前と電子メールアドレスが含まれており、接続ごとにサーバーによって自動的にチェックされ、パスワードを必要とせずにユーザーのIDを確認します。

秘密(秘密)鍵が危険にさらされた場合

このコンテキストでの重要なプロパティは、Perfect Forward Secretcy(PFS)です。HTTPSセッションを確立するために使用される長期非対称秘密鍵の1つを所有していても、後で会話を復号化するための短期セッション鍵を簡単に導き出すことはできません。Diffie–Hellman鍵交換(DHE)と楕円曲線Diffie–Hellman鍵交換(ECDHE)は、2013年にその特性を持つことが知られている唯一のスキームです。2013年には、Firefox、Opera、およびChromiumブラウザセッションの30%のみがそれを使用し、AppleのSafariおよびMicrosoft Internet Explorerセッションのほぼ0%がそれを使用しました。[24] 2018年8月に公開されたTLS1.3は、ForwardSecrecyなしの暗号のサポートを終了しました。2020年2月現在、調査対象のWebサーバーの96.6%が何らかの形式の転送秘密をサポートし、52.1%がほとんどのブラウザーで転送秘密を使用します。[28]

証明書の失効

証明書は、たとえば秘密鍵の機密性が侵害されたために、有効期限が切れる前に取り消される場合があります。Firefox[29] Opera[30]Windows VistaInternetExplorer [31]などの人気のあるブラウザの新しいバージョンは、オンライン証明書ステータスプロトコル(OCSP)を実装して、これが当てはまらないことを確認します。ブラウザは、OCSP(Online Certificate Status Protocol)を介して認証局またはその代理人に証明書のシリアル番号を送信し、認証局が応答して、証明書がまだ有効かどうかをブラウザに通知します。[32] CAはCRLを発行する場合もありますこれらの証明書が取り消されていることを人々に伝えるため。CRLは、CA /ブラウザフォーラムでは不要になりましたが[33]、それでもCAによって広く使用されています。インターネット上のほとんどの失効ステータスは、証明書の有効期限が切れるとすぐに消えます。[34]

制限事項

SSL(Secure Sockets Layer)およびTLS(Transport Layer Security)暗号化は、シンプルモードと相互モードの2つのモードで構成できます。シンプルモードでは、認証はサーバーによってのみ実行されます。相互バージョンでは、ユーザーはユーザー認証のためにWebブラウザーに個人用クライアント証明書をインストールする必要があります。[35]いずれの場合も、保護のレベルは、ソフトウェアの実装と使用中の暗号化アルゴリズムの正確さに依存します。

SSL / TLSは、 Webクローラーによるサイトのインデックス作成を妨げません。場合によっては、傍受された要求/応答のサイズのみを知ることで、暗号化されたリソースのURIを推測できます。[36]これにより、攻撃者はプレーンテキスト(公開されている静的コンテンツ)と暗号化されたテキスト(静的コンテンツの暗号化されたバージョン)にアクセスできるようになり、暗号化攻撃が可能になります。

TLSはHTTPよりも低いプロトコルレベルで動作し、上位レベルのプロトコルに関する知識がないため、TLSサーバーは特定のアドレスとポートの組み合わせに対して1つの証明書しか厳密に提示できません。[37]これまでは、HTTPSで名前ベースの仮想ホスティングを使用することは不可能でした。サーバー名表示(SNI)と呼ばれるソリューションが存在します。これは、接続を暗号化する前にホスト名をサーバーに送信しますが、多くの古いブラウザーはこの拡張機能をサポートしていません。SNIのサポートは、Firefox 2、Opera 8、Apple Safari 2.1、Google Chrome 6、およびInternet Explorer7以降で利用できます。WindowsVistaの場合[38] [39] [40]

アーキテクチャの観点から:

  • SSL / TLS接続は、TLS接続を開始する最初のフロントマシンによって管理されます。何らかの理由(ルーティング、トラフィックの最適化など)で、このフロントマシンがアプリケーションサーバーではなく、データを解読する必要がある場合は、ユーザー認証情報または証明書をアプリケーションサーバーに伝播するソリューションを見つける必要があります。誰が接続されるかを知っています。
  • 相互認証を使用するSSL / TLSの場合、SSL / TLSセッションは、接続を開始する最初のサーバーによって管理されます。暗号化をチェーンサーバーに沿って伝播する必要がある状況では、セッションのタイムアウト管理を実装するのは非常に困難になります。
  • 相互SSL / TLSでセキュリティは最大になりますが、クライアント側では、サーバーセッションの有効期限が切れるのを待つか、関連するすべてのクライアントアプリケーションを閉じる以外に、SSL / TLS接続を適切に終了してユーザーを切断する方法はありません。

2009年のBlackhatConferenceで、SSLストリッピングと呼ばれる高度な中間者攻撃が発表されました。このタイプの攻撃は、リンクをリンクに変更することでHTTPSによって提供されるセキュリティを無効にし、ブラウザインターフェイスに実際に「https」と入力するインターネットユーザーはほとんどいないという事実を利用します。リンクをクリックして安全なサイトにアクセスし、したがって、実際にはHTTPを使用しているのに、HTTPSを使用していると思い込まれます。その後、攻撃者はクライアントと明確に通信します。[41]これは、 HTTP Strict TransportSecurityと呼ばれるHTTPの対抗策の開発を促しましたhttps:http:

HTTPSは、さまざまなトラフィック分析攻撃に対して脆弱であることが示されています。トラフィック分析攻撃は、暗号化されたトラフィック自体に関するプロパティを推測するために、トラフィックのタイミングとサイズの変化に依存するサイドチャネル攻撃の一種です。SSL / TLS暗号化はトラフィックの内容を変更するため、トラフィック分析は可能ですが、トラフィックのサイズとタイミングへの影響は最小限です。2010年5月、 MicrosoftResearchインディアナ大学の研究者による研究論文詳細な機密ユーザーデータは、パケットサイズなどのサイドチャネルから推測できることを発見しました。研究者は、ヘルスケア、税務、投資、およびWeb検索におけるいくつかの有名な最高級のWebアプリケーションでのHTTPS保護にもかかわらず、盗聴者がユーザーの病気/薬/手術を推測できることを発見しました。彼女の家族の収入、そして投資の秘密。[42]この作業はトラフィック分析に対するHTTPSの脆弱性を示しましたが、著者によって提示されたアプローチは手動分析を必要とし、HTTPSによって保護されたWebアプリケーションに特に焦点を合わせました。

Google、Yahoo!、Amazonなどの最新のWebサイトのほとんどがHTTPSを使用しているため、パブリックWi-Fiホットスポットにアクセスしようとすると多くのユーザーが問題を引き起こします。ユーザーがアクセスしようとするとWi-Fiホットスポットのログインページが読み込まれないためです。 HTTPSリソースを開きます。[43] neverssl.comnonhttps.comなどのいくつかのWebサイトは、常にHTTPでアクセスできることを保証しています。[44] [45]

歴史

Netscape Communicationsは、1994年にNetscape NavigatorWebブラウザ用にHTTPSを作成しました。[46]元々、HTTPSはSSLプロトコルで使用されていました。SSLがトランスポート層セキュリティ(TLS)に進化するにつれて、HTTPSは2000年5月にRFC 2818によって正式に指定されました。Googleは2018年2月に、Chromeブラウザが20187月以降にHTTPサイトを「安全ではない」とマークすることを発表しましたWorld Wide Webをより安全 にするための取り組みとして、Webサイトの所有者にHTTPSの実装を奨励する。

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ 「HTTPSでサイトを保護する」GoogleサポートGoogle Inc. 2015年3月1日のオリジナルからアーカイブ2018年10月20日取得
  3. ^ 「HTTPSとは何ですか?」Comodo CALimited2015年2月12日にオリジナルからアーカイブされました2018年10月20日取得ハイパーテキスト転送プロトコルセキュア(HTTPS)は、HTTPのセキュアバージョンです[...]
  4. ^ ネットワークワーキンググループ(2000年5月)。「HTTPOverTLS」インターネットエンジニアリングタスクフォース。2018年10月31日にオリジナルからアーカイブされました2018年10月20日取得
  5. ^ a bc 「 HTTPSEverywhereFAQ 2016年11月8日。2018年11月14日のオリジナルからアーカイブ2018年10月20日取得
  6. ^ 「ウェブサイトのデフォルトプロトコルhttpsの使用統計、2019年7月」w3techs.com2019年8月1日にオリジナルからアーカイブされました2019年7月20日取得
  7. ^ 「Webの暗号化」電子フロンティア財団2019年11月18日にオリジナルからアーカイブされました2019年11月19日取得
  8. ^ 「ホテルWifiJavaScriptインジェクション」JustInsomnia2012年4月3日。2018年11月18日のオリジナルからアーカイブ2018年10月20日取得
  9. ^ Tor Project、Inc。「Torブラウザとは」TorProject.org2013年7月17日にオリジナルからアーカイブされました2012年5月30日取得
  10. ^ Konigsburg、Eitan; パンツ、ラジブ; Kvochko、Elena(2014年11月13日)。「HTTPSを採用する」ニューヨークタイムズ2019年1月8日にオリジナルからアーカイブされました2018年10月20日取得
  11. ^ ギャラガー、ケビン(2014年9月12日)。「NSAの暴露から15か月後、HTTPSを使用するニュース組織が増えないのはなぜですか?」報道の自由財団。2018年8月10日にオリジナルからアーカイブされました2018年10月20日取得
  12. ^ 「ランキング信号としてのHTTPS」GoogleウェブマスターセントラルブログGoogle Inc. 2014年8月6日。2018年10月17日のオリジナルからアーカイブ2018年10月20日取得HTTPS(Hypertext Transfer Protocol Secure)を使用してサイトを安全にすることができます[...]
  13. ^ Grigorik、Ilya; ファー、ピエール(2014年6月26日)。「GoogleI / O2014-HTTPSEverywhere」Googleデベロッパー。2018年11月20日にオリジナルからアーカイブされました2018年10月20日取得
  14. ^ a bc 「HTTPSを正しくデプロイする方法」2010年11月15日。2018年10月10日のオリジナルからアーカイブ2018年10月20日取得
  15. ^ 「HTTPStrictTransportSecurity」Mozilla DeveloperNetwork2018年10月19日にオリジナルからアーカイブされました2018年10月20日取得
  16. ^ 「上位100万のWebサイトでのHTTPS使用統計」StatOperator.com2019年2月9日にオリジナルからアーカイブされました2018年10月20日取得
  17. ^ 「QualysSSLLabs-SSLPulse」www.ssllabs.com2018年4月3日。2017年12月2日のオリジナルからアーカイブ2018年10月20日取得
  18. ^ 「統計を暗号化しましょう」LetsEncrypt.org2018年10月19日にオリジナルからアーカイブされました2018年10月20日取得
  19. ^ Eckersley、Peter(2010年6月17日)。「HTTPSEverywhereFirefox拡張機能を使用してWebを暗号化する」EFFブログ2018年11月25日にオリジナルからアーカイブされました2018年10月20日取得
  20. ^ 「HTTPSEverywhere」EFFプロジェクト2011年10月7日。2011年6月5日のオリジナルからアーカイブ2018年10月20日取得
  21. ^ 「FirefoxのHTTPSのみのモード」2021年11月12日取得{{cite web}}: CS1 maint: url-status (link)
  22. ^ Singel、Ryan(2010年3月24日)。「法執行アプライアンスはSSLを覆す」有線2019年1月17日にオリジナルからアーカイブされました2018年10月20日取得
  23. ^ Schoen、Seth(2010年3月24日)。「新しい調査によると、政府はSSL証明書を偽造する可能性があります」EFF2016年1月4日にオリジナルからアーカイブされました2018年10月20日取得
  24. ^ a b ダンカン、ロバート(2013年6月25日)。「SSL:今日傍受され、明日復号化されます」ネットクラフト2018年10月6日にオリジナルからアーカイブされました2018年10月20日取得
  25. ^ Cimpanu、カタリン(2016年4月12日)。「Let'sEncryptは本日リリースされ、現在380万のドメインを保護しています」Softpediaニュース。2019年2月9日にオリジナルからアーカイブされました2018年10月20日取得
  26. ^ Kerner、Sean Michael(2014年11月18日)。「インターネットセキュリティを向上させるための取り組みを暗号化しましょう」eWeek.comクインストリートエンタープライズ2018年10月20日取得
  27. ^ Eckersley、Peter(2014年11月18日)。「2015年の立ち上げ:Web全体を暗号化する認証局」電子フロンティア財団2018年11月18日にオリジナルからアーカイブされました2018年10月20日取得
  28. ^ Qualys SSLLabs「SSLパルス」2019年2月15日にオリジナル(2019年2月3日)からアーカイブされました2019年2月25日取得
  29. ^ 「MozillaFirefoxプライバシーポリシー」MozillaFoundation2009年4月27日。2018年10月18日のオリジナルからアーカイブ2018年10月20日取得
  30. ^ 「FTPで起動されたOpera8」ソフトペディア2005年4月19日。2019年2月9日のオリジナルからアーカイブ2018年10月20日取得
  31. ^ ローレンス、エリック(2006年1月31日)。「InternetExplorer7でのHTTPSセキュリティの改善」MicrosoftDocs2021年10月24日取得
  32. ^ マイヤーズ、マイケル; アンクニー、リッチ; Malpani、Ambarish; ガルペリン、スラヴァ; アダムズ、カーライル(1999年6月20日)。「オンライン証明書ステータスプロトコル–OCSP」インターネットエンジニアリングタスクフォース2011年8月25日にオリジナルからアーカイブされました2018年10月20日取得
  33. ^ 「ベースライン要件」CABフォーラム2021年11月1日取得{{cite web}}: CS1 maint: url-status (link)
  34. ^ Korzhitskii、ニキータ; カールソン、ニクラス(2021)。インターネット上の失効ステータス2021パッシブおよびアクティブ測定会議(PAM 2021)の議事録arXiv2102.04288{{cite book}}: CS1 maint: url-status (link)
  35. ^ 「Chromeデバイスでクライアント証明書を管理する–ビジネスおよび教育向けChromeヘルプ」support.google.com2019年2月9日にオリジナルからアーカイブされました2018年10月20日取得
  36. ^ Pusep、Stanislaw(2008年7月31日)。「ThePirateBay un-SSL」(PDF)2018年6月20日のオリジナルからアーカイブ(PDF)2018年10月20日取得
  37. ^ 「SSL / TLS強力な暗号化:FAQ」apache.org2018年10月19日にオリジナルからアーカイブされました2018年10月20日取得
  38. ^ ローレンス、エリック(2005年10月22日)。「InternetExplorer7 Beta2での今後のHTTPSの改善」Microsoft2018年9月20日にオリジナルからアーカイブされました2018年10月20日取得
  39. ^ 「サーバー名表示(SNI)」エブラヒムの頭の中2006年2月21日。2018年8月10日のオリジナルからアーカイブ2018年10月20日取得
  40. ^ ピエール、ジュリアン(2001年12月19日)。「TLSサーバー名表示のブラウザサポート」BugzillaMozillaFoundation。2018年10月8日にオリジナルからアーカイブされました2018年10月20日取得
  41. ^ "sslstrip0.9"2018年6月20日にオリジナルからアーカイブされました2018年10月20日取得
  42. ^ Shuo Chen; 王ルイ; XiaoFeng Wang; Kehuan Zhang(2010年5月20日)。「Webアプリケーションのサイドチャネルリーク:今日の現実、明日の課題」MicrosoftResearchセキュリティとプライバシーに関するIEEEシンポジウム2010。 2018年7月22日のオリジナルからアーカイブ2018年10月20日取得
  43. ^ Guaay、Matthew(2017年9月21日)。「パブリックWi-Fiネットワークのログインページを強制的に開く方法」2018年8月10日にオリジナルからアーカイブされました2018年10月20日取得
  44. ^ 「NeverSSL」2018年9月1日にオリジナルからアーカイブされました2018年10月20日取得
  45. ^ 「https以外のWebサイト」2018年10月17日にオリジナルからアーカイブされました2018年10月20日取得
  46. ^ 壁、コリン(2005)。組み込みソフトウェア:TheWorksニューンズ。p。344. ISBN 0-7506-7954-92019年2月9日にオリジナルからアーカイブされました2018年10月20日取得
  47. ^ 「安全なウェブはここにとどまる」Chromiumブログ2019年4月24日にオリジナルからアーカイブされました2019年4月22日取得

外部リンク