[1] HTTP に関する保安輸送路secure transportとは、 TLS や SSL のことをいいます。すなわち、素のHTTPではなく HTTPS を使っていることを指します。

[36] 長らくこれを表す統一された用語が無かったため、色々な表現がされていました。 現在は Fetch Standard によって HTTPS状態として整理され、 徐々に移行しています。

用例

[25] RFC 7469 は「保安輸送路secure transport」の語を使っています。

[26] ただ保安輸送路ではなく TLS と言っているところがあるので、 実質的に TLS 以外の保安輸送路となり得るものは排除されています。

[2] RFC 6265 はこれを「保安」通信路"secure" channel >>6 や「保安」プロトコル"secure" protocol >>3 と呼んでいます。ただし何をもって「保安」とするかは利用者エージェント定義 >>6, >>3 となっています。

[4] 普通は SSL や TLS のようなトランスポート層の保安機能を使っているプロトコルが保安プロトコルとみなされており、 ほとんどの利用者エージェントは https: URL scheme を保安プロトコルとしています >>3。

[5] クッキーにおける Secure 属性が保安輸送路限定かどうかを表しています。

[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。

[15] 一時credentials要求、トークン要求、oauth_signature=PLAINTEXT が保安輸送路を必須としています。

[28] RFC 7616 はダイジェスト認証について、 HTTPS のような保安通信路secure channelで使うべき >>27 と述べています。

[10] RFC 4918 (WebDAV) は、保安接続secure connectionの例として、 TLS において強い cipher suite と鯖の認証を用いた接続を挙げています >>9。

[11] Basic認証の利用の条件となっています。

[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 には「非暗号化通信路unencrypted channels」 や「非暗号化接続unencrypted connection」 についてautofillを無効化する旨の規定があります >>32, >>34。

[31] Fetch Standard は HTTPS状態を規定しています。 これは TLS で安全と判断されるものか、 TLS だが安全ではないものか、 平文であるかの3段階に区別するものです。 HTML Standard、Mixed Content などの現代的な Web標準仕様書はこの定義を参照しています。

HTTPS状態を参照。

[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 はまた少し違った要件を示しています。 RFC 8291

[42] RFC 7515 は一貫性保護を提供するプロトコルを要求しています。 JWSの取得プロトコル

[23] RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP) ( 版) https://tools.ietf.org/html/rfc7481

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 (日本語) では、保護された通信と表示されます。

[44] これは近年の概念である HTTPS状態により近いものと思われます。
[40] PWG 5100.13 – IPP: Job and Printer Extensions – Set 3 ( ()) http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf#page=15

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].