-
Notifications
You must be signed in to change notification settings - Fork 4
/
32.txt
151 lines (116 loc) · 9.47 KB
/
32.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
[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]] [CODE[jku]] は[[一貫性]]保護を提供する[[プロトコル]]を要求しています。
[SEE[ [[jku]] ]]
[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]
* メモ
[39] 最近の [[Chrome]] ([[日本語]]) では、[DFN[保護された通信]]と表示されます。
[TIME[2017-02-18T13:03:20.500Z]]
[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]