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

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

* 用例

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

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

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

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

;; [5] [[クッキー]]における [CODE(HTTP)@en[[[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)」
という表現が使われています [SRC[>>12]]。

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

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

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

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

[20] [[RFC 2910]] ([[IPP/1.1]]) は、「channel is secure」なら [[HTTP]]
[[基本認証]]に対応することができる [SRC[>>19]] しています。 [[TLS]] で
[CODE[[[TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA]]]] [[cipher suite]]
を用いると「secure channel」となり得る [SRC[>>19]] ともしています。
それ以外の方法で secure となるかどうかには言及がありません。

[17] [[OAuth 2.0]] は[[認可符号]]の転送において[[保安通信路]]の利用を求めています
[SRC[>>16]]。[[持参人トークン]]については「TLS or equivalent transport security」
の利用を求めています [SRC[>>18]]。しかしそれ以外の箇所では明示的に [[TLS]] の利用を求めており、
なぜこの文脈でのみ[[保安通信路]]と広く指定しているのかは不明です。

[38] [[RFC 7231]] ([[HTTP]]) は、 [CODE(HTTP)@en[Referer:]] [[ヘッダー]]に関する規定で、
「secure protocol」、「unsecured HTTP request」という語を (定義せず) 使っています
[SRC[>>37]]。

[33] [[HTML Standard]] には「[DFN[[RUBYB[非暗号化通信路]@en[unencrypted channels]]]]」
や「[DFN[[RUBYB[非暗号化接続]@en[unencrypted connection]]]]」
について[[autofill]]を無効化する旨の規定があります [SRC[>>32, >>34]]。

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

;; [[HTTPS状態]]を参照。

[HISTORY[
[30] [[HTML Standard]] は [CODE(HTMLa)@en[[[ping]]]] [[属性]]に関する規定で
「retrieved over an encrypted connection」かどうかを条件としていましたが、
2016年2月に [[HTTPS状態]]を使った条件に書き換えられています [SRC[>>29]]。

[22] [[HTML Standard]] には「has a scheme component that is itself a secure protocol, e.g. HTTPS」
[SRC[>>21]] との条件があり、
[[URL scheme]] が[[保安プロトコル]]を表すかどうかを検査することを求めています。
これは実際には [[Mixed Content]] 制約を指していると思われます。
2016年3月に [[Fetch Standard]] との統合により削除されました [SRC[>>35]]。
]HISTORY]

[41] [[RFC 8291]] はまた少し違った要件を示しています。
[SEE[ [[RFC 8291]] ]]

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


[REFS[
- [19] [CITE@en[RFC 2910 - Internet Printing Protocol/1.1: Encoding and Transport]] ([TIME[2015-02-15 15:24:06 +09:00]] 版) <https://tools.ietf.org/html/rfc2910#section-8.1.2>
- [6] [CITE@en[RFC 6265 - HTTP State Management Mechanism]] ([TIME[2014-10-12 15:11:47 +09:00]] 版) <http://tools.ietf.org/html/rfc6265#section-4.1.2.5>
- [3] [CITE@en[RFC 6265 - HTTP State Management Mechanism]] ([TIME[2014-10-12 15:11:47 +09:00]] 版) <http://tools.ietf.org/html/rfc6265#section-5.4>
- [12] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版) <http://tools.ietf.org/html/rfc5849#section-2.1>
- [9] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) <http://tools.ietf.org/html/rfc4918#section-20.1>
- [16] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) <http://tools.ietf.org/html/rfc6749#section-10.5>
- [18] [CITE@en[RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage]] ([TIME[2015-02-11 06:22:47 +09:00]] 版) <http://tools.ietf.org/html/rfc6750#section-5>
- [21] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-15 01:40:28 +09:00]] 版) <https://html.spec.whatwg.org/#dom-websocket>
- [24] [CITE@en[RFC 7469 - Public Key Pinning Extension for HTTP]] ([TIME[2015-05-05 21:00:37 +09:00]] 版) <https://tools.ietf.org/html/rfc7469#section-2.2>
- [27] [CITE@en[RFC 7616 - HTTP Digest Access Authentication]] ([TIME[2015-11-10 07:05:08 +09:00]] 版) <https://tools.ietf.org/html/rfc7616#section-5.1>
- [29] [CITE@en[Use the HTTPS state concept instead of "encrypted connection" · whatwg/html@1ee3316]] ([TIME[2016-02-25 14:08:27 +09:00]] 版) <https://github.com/whatwg/html/commit/1ee3316caa1a5754f7bbd29c494842785f9a181b>
- [32] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2016-02-24 02:49:49 +09:00]] 版) <https://html.spec.whatwg.org/#dom-form-requestautocomplete>
- [34] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2016-02-24 02:49:49 +09:00]] 版) <https://html.spec.whatwg.org/#dom-autocompleteerrorreason-disabled>
- [35] [CITE@en[Update WebSocket to use Fetch's WebSocket alterations · whatwg/html@3dadbca]] ([TIME[2016-03-28 23:40:35 +09:00]] 版) <https://github.com/whatwg/html/commit/3dadbcad063a10b586ef52dd4b427aa339048ee7>
- [37] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2016-05-22 16:14:08 +09:00]]) <https://tools.ietf.org/html/rfc7231#section-5.5.2>

[FIG(quote)[
[FIGCAPTION[
[23] [CITE@en[RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP)]]
([TIME[2015-03-26 07:39:15 +09:00]] 版)
<https://tools.ietf.org/html/rfc7481>
]FIGCAPTION]

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

]FIG]
]REFS]

* 保安輸送路を提供するプロトコル

[14] [[Web]] においては次の [[URL scheme]] が[[保安輸送路]]を使った[[プロトコル]]を表していると考えられます。
[FIG(short list)[
- [CODE(HTTP)@en[[[https:]]]]
- [CODE(HTTP)@en[[[wss:]]]]
]FIG]

[8] >>7 の [[URL scheme]] 一覧 [[JSON]] データファイルには、 [[URL scheme]]
が「保安」であるかどうかを示す [CODE[secure]] フラグが含まれています。
[REFS[
- [7] [CITE@en[data-web-defs/url-schemes.txt at master · manakai/data-web-defs]] ([TIME[2014-11-04 10:02:13 +09:00]] 版) <https://github.com/manakai/data-web-defs/blob/master/doc/url-schemes.txt>
]REFS]

[43] [[潜在的に信頼できる起源]]の判断に、これに相当する定義が組み込まれています。

* 関連

[45] 
[[MySQL]] プロトコルの [CODE[caching_sha2_password]] は通信路が安全かどうかで分岐します。
ここでいう安全とは、 [[TLS]] モードに切り替わっているか、
[[Unixソケット]]を使っているかを指しています。

* メモ

[39] 最近の [[Chrome]] ([[日本語]]) では、[DFN[保護された通信]]と表示されます。
[TIME[2017-02-18T13:03:20.500Z]]

;; [44] これは近年の概念である [[HTTPS状態]]により近いものと思われます。

[FIG(quote)[
[FIGCAPTION[
[40] [CITE[PWG 5100.13 – IPP: Job and Printer Extensions – Set 3]]
( ([TIME[2012-07-28 08:38:41 +09:00]]))
<http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf#page=15>
]FIGCAPTION]

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

]FIG]