[1] HTTP に関する保安輸送路とは、 TLS や SSL のことをいいます。すなわち、素のHTTPではなく HTTPS を使っていることを指します。
[36] 長らくこれを表す統一された用語が無かったため、色々な表現がされていました。 現在は Fetch Standard によって HTTPS状態として整理され、 徐々に移行しています。
[25] RFC 7469 は「保安輸送路」の語を使っています。
[2] RFC 6265 はこれを「保安」通信路 >>6 や「保安」プロトコル >>3 と呼んでいます。ただし何をもって「保安」とするかは利用者エージェント定義 >>6, >>3 となっています。
[4] 普通は SSL や TLS のようなトランスポート層の保安機能を使っているプロトコルが保安プロトコルとみなされており、
ほとんどの利用者エージェントは https: URL scheme
を保安プロトコルとしています >>3。
[13] RFC 5849 (OAuth 1.0) では、「a transport-layer mechanisms such as TLS or Secure Socket Layer (SSL) (or a secure channel with equivalent protections)」 という表現が使われています >>12。
[28] RFC 7616 はダイジェスト認証について、 HTTPS のような保安通信路で使うべき >>27 と述べています。
[10] RFC 4918 (WebDAV) は、保安接続の例として、 TLS において強い cipher suite と鯖の認証を用いた接続を挙げています >>9。
[20] RFC 2910 (IPP/1.1) は、「channel is secure」なら HTTP
基本認証に対応することができる >>19 しています。 TLS で
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite
を用いると「secure channel」となり得る >>19 ともしています。
それ以外の方法で secure となるかどうかには言及がありません。
[17] OAuth 2.0 は認可符号の転送において保安通信路の利用を求めています >>16。持参人トークンについては「TLS or equivalent transport security」 の利用を求めています >>18。しかしそれ以外の箇所では明示的に TLS の利用を求めており、 なぜこの文脈でのみ保安通信路と広く指定しているのかは不明です。
[38] RFC 7231 (HTTP) は、 Referer: ヘッダーに関する規定で、
「secure protocol」、「unsecured HTTP request」という語を (定義せず) 使っています
>>37。
[33] HTML Standard には「非暗号化通信路」 や「非暗号化接続」 についてautofillを無効化する旨の規定があります >>32, >>34。
[31] Fetch Standard は HTTPS状態を規定しています。 これは TLS で安全と判断されるものか、 TLS だが安全ではないものか、 平文であるかの3段階に区別するものです。 HTML Standard、Mixed Content などの現代的な Web標準仕様書はこの定義を参照しています。
[30] HTML Standard は ping 属性に関する規定で
「retrieved over an encrypted connection」かどうかを条件としていましたが、
2016年2月に HTTPS状態を使った条件に書き換えられています >>29。
[22] HTML Standard には「has a scheme component that is itself a secure protocol, e.g. HTTPS」 >>21 との条件があり、 URL scheme が保安プロトコルを表すかどうかを検査することを求めています。 これは実際には Mixed Content 制約を指していると思われます。 2016年3月に Fetch Standard との統合により削除されました >>35。
[41] RFC 8291 はまた少し違った要件を示しています。
[42] RFC 7515 は一貫性保護を提供するプロトコルを要求しています。
RDAP does not impose any unique server authentication requirements. The server authentication provided by TLS fully addresses the needs of RDAP. In general, transports for RDAP must either provide a TLS-protected transport (e.g., HTTPS) or a mechanism that provides an equivalent level of server authentication.
[14] Web においては次の URL scheme が保安輸送路を使ったプロトコルを表していると考えられます。
[8] >>7 の URL scheme 一覧 JSON データファイルには、 URL scheme
が「保安」であるかどうかを示す secure フラグが含まれています。
[43] 潜在的に信頼できる起源の判断に、これに相当する定義が組み込まれています。
[45]
MySQL プロトコルの caching_sha2_password は通信路が安全かどうかで分岐します。
ここでいう安全とは、 TLS モードに切り替わっているか、
Unixソケットを使っているかを指しています。
[39] 最近の Chrome (日本語) では、保護された通信と表示されます。
Secure Transport; encryption of the HTTP connection using Transport Layer Security
[RFC5246]. The security session may be negotiated at the initiation of the connection
("HTTPS") or by Upgrading to TLS Within HTTP/1.1 [RFC2817].