/
264.txt
139 lines (96 loc) · 7.1 KB
/
264.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
[6] [[SSL]] あるいは [[TLS]] 上で [[HTTP]] を用いる通信、あるいはその[[プロトコル]] [WEAK[(の組み合わせ)]]
のことを [DFN[[[HTTP/SSL]]]]、[DFN[[[HTTP/TLS]]]]、あるいは [DFN[[[HTTPS]]]]
と呼びます。
* プロトコル
[24] [[HTTPS]] による通信は、 [[TCP]] のかわりに [[TLS]] over [[TCP]]
を使うことや [[URL scheme]] が違うことを除けば、素の [[HTTP]] と同じです。
;; [[HTTP]] の通信については [[HTTP接続]]や [[HTTPメッセージ]]、
[[HTTPクライアント]]、[[HTTP鯖]]を参照。
;; [31] [[HSTS]] も参照。
* URL scheme
[9] [[HTTPS]] の [[URL scheme]] は [CODE(URI)@en[[[https:]]]] です。
;; [CODE(URI)@en[[[https:]]]] を参照。
* メタ変数 [CODE(CGI)@en[HTTPS]]
- [1] [[SSL]] or [[TLS]] が使われた [[HTTP]] 要求に伴った [[CGI]] のスクリプトに与えられることがある[[メタ変数]]です。 (標準化はされていません。)
- [2] 値はサーバーのソフトウェアによって [CODE(CGI)[1]] だったり [CODE(CGI)[ON]] だったり [CODE(CGI)[on]] だったり、空文字列あるいは値未設定だったり [CODE(CGI)[OFF]] だったり [CODE(CGI)[off]] だったり色々のようです。そもそもこのメタ変数を実装していないサーバーもあります。
- [3] [CODE[iPlanet-WebServer-Enterprise/4.1]] は [CODE(CGI)[ON]] / [CODE(CGI)[OFF]] らしいです。
- [4] このメタ変数を提供しないサーバーでも [CODE(CGI)[[[SERVER_PORT_SECURE]]]] が参考になるかもしれません。
[DEL[
[5]
>>1 一応 [[RFC 3875]] で規定されました。
]DEL]
[7] [[CGI]] ([[RFC 3875]]) の規定により、[[プロトコル]]と [[URL scheme]] が異なる時に
[[URL scheme]] と同名の[[メタ変数]]を定義してよいとされており、[[メタ変数]]
[CODE(CGI)@en[[[HTTPS]]]] がこれに合致します。
;; 同仕様上、それ以外の場面でそれを定義してはならないとはされていませんし、
設定する値についても規定が無いので、 >>2 のどの値でも仕様と矛盾はしていません。
** 実装
[8] [[HTTP::Request::AsCGI]] は [CODE[[[ON]]]] または [CODE[[[OFF]]]] を設定します。
* 逆串によるプロトコル情報ヘッダー
[13] [[HTTPS]] を [[HTTP]] として[[転送]]する[[逆串]]は、元々が [[HTTP]]
だったか [[HTTPS]] だったかの区別を保持するために[[要求]]に[[ヘッダー]]を付加することがあります。
[14] そのような[[ヘッダー]]としては次のものが知られています。
[FIG(short list)[
- [CODE(HTTP)@en[[[X-Forwarded-HTTPS:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Proto:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Protocol:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Scheme:]]]]
- [CODE(HTTP)@en[[[X-Forwarded-Ssl:]]]]
- [CODE(HTTP)@en[[[CF-Visitor:]]]]
- [CODE(HTTP)@en[[[Forwarded:]]]]
- [CODE(HTTP)@en[[[Front-End-Https:]]]]
- [CODE(HTTP)@en[[[X-Url-Scheme:]]]]
]FIG]
[25] [[Webアプリケーション]]提供者が最外 (最も[[クライアント]]側) に配置する[[逆串]]で
[[HTTPS]] の [[TLS]] を終端させ、内部の[[アプリケーション鯖]]には [[HTTP]]
で[[転送]]するように設定されていることがよくあります。また場合によっては別の
[[TLS]] 接続により [[HTTPS]] で[[アプリケーション鯖]]に接続するケースもあります。
* 串
[26] ([[逆串]]ではない順方向の) [[串]]を使う時は普通は [[HTTPS]] の通信は
[CODE(HTTP)@en[[[CONNECT]]]] [[要求メソッド]]を使って[[トンネル]]を通過させる形とし、
[[串]]により変更されないようにします。
[27] [[串]]の前後でそれぞれ [[HTTP]] over [[TLS]] を使うこともできるかもしれませんが、
[[串]]は[[鯖]]の[[証明書]]を持っていませんから、[[クライアント]]から見ると不正な
[[証明書]]を使った [[TLS]] 通信に見えます。 (これは [[MITM]] 攻撃そのものです。)
特殊な場面では[[串]]の[[証明書]]を[[クライアント]]が信頼することで回避できるかもしれませんが、一般的には使えない方法です。
[28] [[串]]と[[クライアント]]の間が信頼できるネットワークの場合は[[串]]で [[TLS]]
を終端させ[[串]]と[[クライアント]]の間は素の [[HTTP]] とすることもできるかもしれませんが、
そのような使い方も一般的ではありません。
[30] 仕様に適合しない不正な[[串]]の悪影響を避けるために敢えて [[HTTPS]]
を使うこともあります。
[29] 素の [[HTTP]] の通信を[[串]]により中継する場合に、[[串]]と[[クライアント]]の間で
[[HTTPS]] を使うことは可能です。
* 素の HTTP との混在
[23] [[HTTPS]] で送信された[[文書]]における素の [[HTTP]] の[[資源]]の参照には色々な制限があります。
;; [[Mixed Content]] や [[Referrer]] を参照。
* 歴史
** 他の HTTP over SSL の提案
[15] [[Netscape]] によって [[SSL]] と同時に実装された現在の [[HTTPS]]
の他にも、 [[SSL]] と [[HTTP]] を組み合わせる方法はいくつか提案されていました。
しかし結局いずれも広く実装されるには至りませんでした。
*** S-HTTP
;; [22] [[S-HTTP]] を参照。
*** [CODE(HTTP)@en[Upgrade: TLS/1.0]] (HTTP)
[20] [[RFC 2817]] は、[[平文]]の [[HTTP]] で [CODE(HTTP)@en[[[Upgrade:]] [DFN[[[TLS/1.0]]]]]]
と指定することで [[HTTP]] over [[TLS]] に切り替える [SRC[>>16]] ことを提案していました。
;; [21] 多くの [[IETF]] の[[プロトコル]]で採用されている [CODE@en[[[STARTTLS]]]]
方式と似ています。
[17] [[RFC 2817]] は、それが広く普及すれば [[HTTP/TLS]] も従来の [[HTTP]] も共に
[CODE(URI)@en[[[http:]]]] [[URL]] で識別できるようになると述べています [SRC[>>16 8.1]]。
[18] これについて [[RFC 6454]] は、[[同一起源方針]]における [[URL]] による [[trust]]
の観点から、[[文書]]が [[TLS]] の必要性を明示できないような仕様には問題があると指摘
[SRC[>>19]] しています。
[REFS[
- [16] [CITE@en[RFC 2817 - Upgrading to TLS Within HTTP/1.1]] ([TIME[2012-01-09 20:05:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2817>
- [19] [CITE@en[RFC 6454 - The Web Origin Concept]] ([TIME[2011-12-12 09:13:37 +09:00]] 版) <http://tools.ietf.org/html/rfc6454#section-3.1.1>
]REFS]
* メモ
[10] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]]
( ([TIME[2014-08-08 08:15:49 +09:00]] 版))
<http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>
[11] [CITE[HTTPS Everywhere | Electronic Frontier Foundation]]
( ([TIME[2014-09-01 09:47:53 +09:00]] 版))
<https://www.eff.org/https-everywhere>
[12] [CITE[Indicators for high-security features - Google グループ]]
( ([TIME[2014-09-18 04:41:11 +09:00]] 版))
<https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RnAx-t-wOVU/dYjKJF4E7L8J>