264.txt

[6] [[SSL]] あるいは [[TLS]] 上で [[HTTP]] を用いる通信、あるいはその[[プロトコル]] [WEAK[(の組み合わせ)]]
のことを [DFN[[[HTTP/SSL]]]]、[DFN[[[HTTP/TLS]]]]、あるいは [DFN[[[HTTPS]]]]
と呼びます。

* 仕様書

[REFS[
- [39] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818>
-- [45] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818#section-2>
-- [51] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) <http://tools.ietf.org/html/rfc2818#section-3>
- [68] [CITE[RFC Errata Report]] ([TIME[2015-03-04 17:58:35 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2818>
]REFS]

;; [87] [[RFC 7230]] が参照されることもありますが、 [CODE(URI)@en[[[https:]]]]
[[URL]] の新たな定義が含まれるのみで、 [[HTTPS]] 本体は [[RFC 2818]]
の規定を参照しています。 ([[RFC 723x]] は [[RFC 2818]] の [CODE(URI)@en[[[https:]]]]
の規定を置き換えていますが、プロトコル自体はなぜか改訂されていません。)

* 呼称

[96] [[TLS]] 上での [[HTTP]] の利用方法について、統一的な呼称はありません。
[[URL scheme]] から [CODE(URI)@en[[[https]]]] ないし [[HTTPS]]
と呼ぶのが最も一般的なようです。

[97] [[HTTPS]] が何の略であるかについては、解釈が揺れており明らかではありません [SRC[>>83]]。
省略形ではなく1つの単語と解するのが適切かもしれません。

[REFS[
- [83] [CITE[HTTPSの「S」は何の略か : mwSoft blog]]
([TIME[2015-03-16 12:37:32 +09:00]] 版)
<http://blog.mwsoft.jp/article/39910926.html>
]REFS]

[98] [[SSL/2.0]] は次のように説明していました。

[FIG(quote)[
[FIGCAPTION[
[86] [CITE[The SSL Protocol]]
<http://web.archive.org/web/19961027104907/http://www3.netscape.com/newsref/std/SSL_old.html>
]FIGCAPTION]

> A special value needs mentioning - the IANA reserved port number for "https" (HTTP using SSL). IANA has reserved port number 443 (decimal) for "https".

]FIG]

[90] [[ポート番号]]に関する[[IANA登録簿]]では、
1994年の >>88 から 2000年の >>91 の間に説明文が書き換わっていますが、
この中間の登録簿が残っていないためどの時点で誰が変更したのかは不明です。

[FIG(quote)[
[FIGCAPTION[
[88] [CITE@en[RFC 1700 - Assigned Numbers]] (1994年)
<https://tools.ietf.org/html/rfc1700>
]FIGCAPTION]

> https           443/tcp    https  MCom
> https           443/udp    https  MCom
> #                          Kipp E.B. Hickman <kipp@mcom.com>
]FIG]

[FIG(quote)[
[FIGCAPTION[
[91] [CITE[PORT NUMBERS]]
(2000年)
<http://web.archive.org/web/20000815053440/http://www.isi.edu/in-notes/iana/assignments/port-numbers>
]FIGCAPTION]

> https           443/tcp    http protocol over TLS/SSL
> https           443/udp    http protocol over TLS/SSL
> #                          Kipp E.B. Hickman <kipp@mcom.com>
]FIG]

[FIG(quote)[
[FIGCAPTION[
[92] [CITE[PORT NUMBERS]]
(2001年)
<http://web.archive.org/web/20010519080902/http://www.iana.org/assignments/port-numbers>
]FIGCAPTION]

> https           443/tcp    http protocol over TLS/SSL
> https           443/udp    http protocol over TLS/SSL
> #                          Kipp E.B. Hickman <kipp@mcom.com>

]FIG]

[FIG(quote)[
[FIGCAPTION[
[89] [CITE[Service Name and Transport Protocol Port Number Registry]]
([TIME[2015-03-12 02:46:25 +09:00]] 版)
<http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=8>
]FIGCAPTION]

> https	443	tcp	http protocol over TLS/SSL	'''['''Kipp_E_B_Hickman''']'''	'''['''Kipp_E_B_Hickman''']'''						
> https	443	udp	http protocol over TLS/SSL	'''['''Kipp_E_B_Hickman''']'''	'''['''Kipp_E_B_Hickman''']'''	

> '''['''Kipp_E_B_Hickman''']'''	Kipp E.B. Hickman		mailto:kipp&mcom.com
]FIG]

[99] [CODE(URI)@en[[[https:]]]] [[URL scheme]] においては一貫して
「Hypertext Transfer Protocol Secure」と説明されているようです。

[FIG(quote)[
[FIGCAPTION[
[95] [CITE[Uniform Resource Identifier (URI) SCHEMES  (last updated 2001 August 20)]]
(2001年)
<http://web.archive.org/web/20011113003825/http://www.iana.org/assignments/uri-schemes>
]FIGCAPTION]

> https           Hypertext Transfer Protocol Secure             '''['''RFC2818''']'''

]FIG]

[FIG(quote)[
[FIGCAPTION[
[94] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]]
([TIME[2015-02-11 04:09:00 +09:00]] 版)
<http://tools.ietf.org/html/rfc7230#section-8.2>
]FIGCAPTION]

> https      | Hypertext Transfer Protocol Secure | Section 2.7.2

]FIG]

[FIG(quote)[
[FIGCAPTION[
[93] [CITE[Uniform Resource Identifier (URI) Schemes]]
([TIME[2015-03-06 13:07:57 +09:00]] 版)
<http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>
]FIGCAPTION]

> https		Hypertext Transfer Protocol Secure	'''['''RFC7230, Section 2.7.2''']'''

]FIG]

* プロトコル

[24] [[HTTPS]] による通信は、 [[TCP]] のかわりに [[TLS]] over [[TCP]]
を使うことや [[URL scheme]] が違うことを除けば、素の [[HTTP]] と同じです [SRC[>>45]]。

;; [[HTTP]] の通信については [[HTTP接続]]や [[HTTPメッセージ]]、
[[HTTPクライアント]]、[[HTTP鯖]]を参照。

;; [77] 通常の [[HTTP]] では[[対象URL]]に[[絶対URL]]を使わずに[[パス]]以下だけを記述しますし、
それ以外に [[URL scheme]] を明記する[[ヘッダー]]などもありませんから、 [[HTTP]]
か [[HTTPS]] か[[メッセージ]]の内容だけから区別することはできません。

[76] 単一の [[TCP/IP]] の[[末端対末端]]通信上で [[TLS]] を使うのが [[RFC]]
で規定されている [[HTTPS]] ですが、実際には [[TCP/IP]] 以外に
[[HTTP]] [CODE(HTTP)@en[[[CONNECT]]]]、[[SOCKS]]、[[Unix domain socket]]
などの[[トンネル]]が下位層の[[ホップ]]として用いられていることもあります。

** 接続の開始

[46] [[クライアント]]は、[[鯖]]の適切な[[ポート]]への[[接続]]を初期化してから、
[[TLSハンドシェイク]]を始める [[TLS]] [[ClientHello]] を送信するべきです。
[[TLSハンドシェイク]]が完了したら、最初の [[HTTP要求]]を送信できます。 [SRC[>>45]]

[54] [[クライアント]]は、[[鯖]]の[[ホスト名]]が分かっているなら、
[[鯖]]の [[Certificate]] [[メッセージ]]に示された[[鯖]]の [[identity]]
を検査しなければ[['''なりません''']]。
通常は [[URL]] で指定された[[ホスト]]に[[要求]]を送信するので、
[[ホスト名]]は既知です。 [SRC[>>51]]

[56] 型 [[dNSName]] の [[subjectAltName]]  拡張が示されている場合には、
これを [[identity]] として使わなければなりません。そうでない場合には、
(最も詳細な) [[証明書]]の [[Subject]] 欄の [[Common Name]] 欄を [[identity]]
として使わなければ[['''なりません''']]。 [SRC[>>51]]

;; [57] [[Common Name]] を使うのが慣習となっていますが、[[非推奨]]であり、 [[dNSName]]
が推奨されています [SRC[>>51]]。

[58] [[一致]]の判定は、 [[RFC 2459]] の規則によります。
複数の [[identity]] が示されている場合には、いずれかに[[一致]]すれば[[一致]]とします。
[[ワイルドカード]] [CODE[[[*]]]] を含む名前は、
単一の[RUBYB[[[ドメイン名部品]]]@en[domain name component]]に[[一致]]するものとします。
[SRC[>>51, >>68]]

[EG[
[59] 例えば [CODE[*.a.com]] は [CODE[foo.a.com]] に一致しますが、
[CODE[bar.foo.a.com]] には一致しません。 [SRC[>>51]]
]EG]

[EG[
[60] 例えば [CODE[f*.com]] は [CODE[foo.com]] に一致します。 [SRC[>>51]]
]EG]

;; [69] ですが、一般には [CODE[[[*]]]] は[[最左]]の[[ラベル]]として1つだけ用いられます
[SRC[>>68]]。

;; [67] [[ワイルドカード]]の処理は [[RFC 2459]] になく、 [[RFC 2818]]
側で規定されています。後に [[RFC 3280]]、 [[RFC 5280]] と改訂されていますが、
この点は変わっていないようです。

;; [81] [[ワイルドカード]]を含む[[ドメイン]]に関する[[証明書]]のことを[[ワイルドカード証明書]]などと呼ぶことがあります。

[61] [[ホスト名]]ではなく [[IPアドレス]]を指定して接続する場合には、
[[証明書]]の [CODE[[[subjectAltName]]]] 拡張の [CODE[[[iPAddress]]]] と完全に[[一致]]しなければなりません。
[SRC[>>51]]

;; [80] [[IPP]] over [[HTTPS]] は [[IPアドレス]]が指定された場合に[[証明書]]の検証が難しいとして、
[CODE(URI)@en[[[ipps:]]]] [[URL]] に[[IPアドレス]]を指定する[['''べきではない''']]
[SRC[>>79]] としています。
[REFS[
- [79] [CITE@en[RFC 7472 - Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme]] ([TIME[2015-03-04 12:23:14 +09:00]] 版) <https://tools.ietf.org/html/rfc7472#section-4.2>
]REFS]

[72] [[クライアント]]は信頼する [[CA]] を注意深く選び、
信頼する [[CA証明書]]を保存する場所が不正に改変されないよう注意するべきです [SRC[>>71]]。

;; [70] これらの [[identity]] の検査のことを、
[DFN[[RUBYB[HTTP鯖認証]@en[HTTPS server authentication]]]] [SRC[>>71]]
などと呼ぶことがあります。
[REFS[
- [71] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) <http://tools.ietf.org/html/rfc6819#section-5.1.2>
]REFS]

[55] [[クライアント]]が外部情報により[[鯖]]の期待される [[identity]]
を承知しているなら、[[ホスト名]]の検査を省略できます。
例えば[[番地]]と[[ホスト名]]が動的に決まる[[機械]]に接続する場合で、
[[鯖]]が示す[[証明書]]が分かっているなら、省略できます。
特別な場合には[[鯖]]の [[identity]] を完全に無視しても構いませんが、
危険なことは理解しなければなりません。 [SRC[>>51]]

[62] [[ホスト名]]と[[証明書]]の [[identity]] が[[一致]]しない場合には、
[[利用者]]指向の[[クライアント]]は[[利用者]]にこれを通知するか、
[[証明書]]誤りにより[[接続]]を終端するかのいずれかとしなければ[['''なりません''']]。
通知する場合には、[[利用者]]に[[接続]]を継続するか選択させても構いません。
自動化された[[クライアント]]は (あれば) [[誤り]]を記録しなければ[['''ならず''']]、
[[証明書]]誤りにより[[接続]]を終端する[['''べきです''']]。
自動化された[[クライアント]]は設定によりこの検査を無効化しても構いませんが、
有効にする設定を設けなければ[['''なりません''']]。 [SRC[>>51]]

;; [63] なお、 [[URL]] など[[接続]]先の[[ホスト名]]が外部の信頼できない情報源からもたらされた場合、
[[identity]] を検査したとしても攻撃を回避できるわけではありません。
[[利用者]]は[[鯖]]の[[証明書]]を注意して調べるなどの対策が必要です。 [SRC[>>51]]
一般的な [[Webブラウザー]]は[[証明書]]の一部の情報を[[アドレスバー]]などに表示すると共に、
詳細な情報を表示する方法を提供しています。

[64] [[鯖]]は普通は[[クライアント]]の [[identity]] がどうであるべきか
(どのような[[証明書]]を有しているべきか) についての外部情報を有していませんから、
[[クライアント]]について検査することはできません。 [SRC[>>51]]

[65] [[鯖]]がそのような外部情報を有している場合には、
[[鯖]]の[[証明書]]の検査と同様の [[identity]] の検査を行う[['''べき''']]です。
[SRC[>>51]]

;; [66] これは一般的には[[SSLクライアント認証]]などと呼ばれているようです。
[[装置]]に埋め込まれた特定の[[クライアント]]や、[[イントラネット]]など、
[[クライアント]]が限定される場合でかつ[[認証]]を行いたい場合に事前に[[クライアント証明書]]を配布しておき、
これを[[鯖]]側で検査して[[接続]]を受け入れるかどうか判断するものです。

** データの送受信

[47] [[HTTP]] のデータは、 [[TLS]] の[[応用データ]]として送信しなければ[['''なりません''']]
[SRC[>>45]]。

** 接続を閉じる

[48] [[TLS]] の実装は、[[接続]]を閉じる前に [[TLS]] [[closure alert]]
の交換をはじめなければ[['''なりません''']]。妥当な [[closure alert]]
を受信したら、その[[接続]]からそれ以上データを受信しないと仮定して構いません。
[[TLS]] の実装は、 [[closure alert]] の送信後に、相手が [[closure alert]] 
を送信するのを待たずに[[接続]]を閉じ ([[incomplete close]] し) ても構いません。
[[クライアント]]は、それ以上のデータを受信できなくなった時、
[[鯖]]の [[closure alert]] を待たずに[[接続]]を閉じて構いません。
[[鯖]]は、 [[closure alert]] の送信後に[[接続]]を閉じて構いません。
[[鯖]]は、[[クライアント]]による [[incomplete close]] に備える[['''べきです''']]。
そのような実装は、[[セッション]]を再利用することにしても構いません。
これは取り扱うメッセージデータをすべて受信したと ([[HTTPメッセージ]]の境界の判定などにより)
分かる場合にのみ行う[['''べきです''']]。
[[クライアント]]は、 [[incomplete close]] を検出したら、 [[graceful]] に回復する[['''べき''']]です。
その場合 [[TLSセッション]]を再開 ([[resume]]) して構いません。
[[鯖]]は [[incomplete close]] された[[TLSセッション]]を再開 ([[resume]])
[RUBYB[できる]@en[willing to]][['''べき''']]です。 [SRC[>>45]]

[50] 実装は、妥当な [[closure alert]] を受信せずに[[接続]]が閉じられた場合
([[premature close]]) には、[[セッション]]を再利用しては[['''なりません''']]。
[[クライアント]]は、 [[premature close]] を[[誤り]]として扱い、
受信したデータは途中で切れてしまっているかもしれないものと扱わなければ[['''なりません''']]。
一般に [[HTTP]] ではデータが途中で途切れたかどうか判定して誤りから回復することが認められてはいますが、
[[HTTPS]] では、 [CODE(HTTP)@en[[[Content-Length:]]]] が無いため[[鯖]]が[[接続]]を閉じて終端を表したのか攻撃者が[[接続]]を不正に閉じたのかわからない場合や、
[CODE(HTTP)@en[[[Content-Length:]]]] よりも実際のデータが短く[[鯖]]の設定に誤りがあるのか攻撃者が[[接続]]を不正に閉じたのかわからない場合もあり、注意が必要です。
[[クライアント]]は、 [CODE(HTTP)@en[[[Content-Length:]]]] で指定された分のデータを受信し終えたものについては、
[[premature close]] であっても完了したものと扱う[['''べきです''']]。 [SRC[>>45]]

;; [31] [[HSTS]] も参照。

* URL scheme

[9] [[HTTPS]] の [[URL scheme]] は [CODE(URI)@en[[[https:]]]] です。

;; [CODE(URI)@en[[[https:]]]] を参照。

* 既定のポート

[49] [[HTTP]]/[[TLS]]/[[TCP]]/[[IP]] の[[既定のポート]]は、 [DFN[[CODE[[[443]]]]]]
です [SRC[>>45]]。

* メタ変数 [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]] を参照。

* 歴史

** Netscape HTTPS

[43] [[HTTPS]] は [[SSL]] の開発者である [[Netscape]] 
が最初に実装しました。

;; [[SSL]] の最初の仕様書である [[SSL/2.0]] には[[アプリケーション層プロトコル]]の例として
[[HTTP]] を示しています。それ以上に特別に [[HTTPS]] について規定した仕様書はこの時代には存在していなかったようです。

[52] [[SSL/2.0]] および [[SSL/3.0]] には、 [[HTTP]] over [[SSL]] ([[https]]) 用に
[CODE[[[443]]]] 番[[ポート]]が [[IANA]] に登録されている旨の記載がありました。

;; [53] [CODE(HTTP)@en[[[https:]]]] [[URL scheme]] に関する明示的な規定はこの時代には存在していないようです。

** 他の HTTP over SSL の提案: [CODE(HTTP)@en[Upgrade: TLS/1.0]] (RFC 2817)

[15] [[Netscape]] によって [[SSL]] と同時に実装された現在の [[HTTPS]]
の他にも、 [[SSL]] と [[HTTP]] を組み合わせる方法はいくつか提案されていました。
しかし結局いずれも広く実装されるには至りませんでした。

;; [22] [[SSL]] を使わない[[暗号化]]の仕組みである [[S-HTTP]] も提案されていましたが、
やはり普及しませんでした。

[20] [[RFC 2817]] は、[[平文]]の [[HTTP]] で [CODE(HTTP)@en[[[Upgrade:]] [DFN[[[TLS/1.0]]]]]]
と指定することで [[HTTP]] over [[TLS]] に切り替える [SRC[>>16]] ことを提案していました。
その場合は [CODE(HTTP)[[[101]]]] [[応答]]を返してから、
[[TLS]] による通信に切り替わることになっていました [SRC[>>16]]。

;; [21] 多くの [[IETF]] の[[プロトコル]]で採用されている [CODE@en[[[STARTTLS]]]]
方式と似ています。

;; [44] [[RFC 2818]] ([[HTTPS]]) が[[情報提供RFC]]なのに対し、 [[RFC 2817]]
は [[IETF]] [[標準化過程]]の[[提案標準]]でした。

;; [75] [[TLS]] のプロトコルの版に関しては [[protocol (HTTP)]] を参照。

[17] [[RFC 2817]] は、それが広く普及すれば [[HTTP/TLS]] も従来の [[HTTP]] も共に
[CODE(URI)@en[[[http:]]]] [[URL]] で識別できるようになると述べています [SRC[>>16 8.1]]。 

[78] [[IPP/1.1]] は (従来の [[IPP/1.0]] の [[HTTPS]] 方式にかわって)
本方式を採用していました。2015年になってようやく [[HTTPS]] 方式が [[RFC 7472]]
として出版されました。 (しかし本方式も廃止はされておらず、一部の実装に問題があって
[[RFC 2817]] 自体には問題が無かったというのが [[IETF]] の立場のようです。)

;; [[IPP]] 参照。 [[RFC 7472]] には本方式の問題点の指摘も含まれています。

[100] [[Apache]] が本方式を実装していたようですが、対応している[[クライアント]]が無かっただけでなく、
実用上使いにくそうとの指摘 [SRC[>>102]] もありました。

[18] 本方式について [[RFC 6454]] は、[[同一起源方針]]における [[URL]] による [[trust]]
の観点から、[[文書]]が [[TLS]] の必要性を明示できないような仕様には問題があると指摘
[SRC[>>19]] しています。

[74] [[RFC 2817]] は、 [CODE(HTTP)@en[[[Upgrade:]]]] 方式が普及すれば、
[[クライアント]]に「ローカルネットワーク外への [CODE(HTTP)@en[[[POST]]]] には [[TLS]]
を必須とする」、[[鯖]]に「このフォームは [[TLS]] でのみ提供する、
[[TLS]] でのみ[[提出]]させる」といった設定が設けられるようになるかもしれない [SRC[>>16]]
と説明していました。 [[TLS]] を使うか否かは[[ネットワーク]]の問題であり、
[[文書]]中の [[URL]] の記述ではなく、[[クライアント]]と[[鯖]]の設定で選ぶものと考えていたのかもしれません。

[40] いずれにせよこの方式は支持を集められませんでした。

[73] 本方式は[[ポート]]が1つで済むことの他、 [[virtual hosting]]
に対応していることが利点として挙げられていました [SRC[>>16]]。 [[HTTPS]]
の [[virtual hosting]] 対応は遅れましたが、2010年代半ばになってようやく
[[SAN]] 対応が普及してきています。 (当時既に [[SAN]] は存在していたのですから、
実は大きな利点とは言えない気がします。)

[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>
- [103] [CITE@en[276813 – '''['''RFE''']''' Support RFC 2817 / TLS Upgrade for HTTP 1.1]] ([TIME[2015-03-16 14:04:56 +09:00]] 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=276813>
- [104] [CITE[Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - An open-source project to help move the web forward. - Google Project Hosting]] ([TIME[2015-03-16 14:07:04 +09:00]] 版) <https://code.google.com/p/chromium/issues/detail?id=4527>
- [102] [CITE[Upgrading to TLS(RFC2817)の設定をApache2.2にしてみる|でびぞー徒然日記]] ([TIME[2015-03-16 14:00:07 +09:00]] 版) <http://debz-di.kabocha.to/archives/2007/06/20070616212947.html>
]REFS]

** RFC 2818

[41] 古く使われてきた [[SSL]] ([[TLS]]) 上で [[HTTP]] を使う方式は、 [[RFC 2818]]
として標準化されました。

[42] その後 [[RFC 2818]] は [[RFC 5785]] と [[RFC 7230]] により[[更新]]されています。
いずれも [CODE(URI)@en[[[https:]]]] [[URL]] について規定するものです。
このため [[RFC 2818]] における [[URL]] に関する規定は現在失効していると解釈されています。

[105] なお [[RFC 2818]] は[[情報提供RFC]]であり、[[IETF]] [[標準化過程]]にはありません。
このため [[RFC 2818]] は標準ではない、従う必要はないなどと主張する人も稀にいます。
[[IETF]] における手続きのみを重視する立場からは間違った主張ではありませんが、
実態としておおむね [[RFC 2818]] に沿った [[HTTPS]] が極めて普及している現実を無視することに意味があるとは思えません。

* メモ

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

[32] [CITE@en[Transitioning the Web to HTTPS]]
( ([TIME[2014-12-09 14:36:23 +09:00]] 版))
<https://w3ctag.github.io/web-https/>

[33] [CITE@en[Official Gmail Blog: Staying at the forefront of email security and reliability: HTTPS-only and 99.978% availability]]
( ([TIME[2014-12-19 08:00:09 +09:00]] 版))
<http://gmailblog.blogspot.jp/2014/03/staying-at-forefront-of-email-security.html>

[34] [CITE@en[Securing the Web]]
([TIME[2015-01-23 09:35:25 +09:00]] 版)
<http://www.w3.org/2001/tag/doc/web-https>

[35] [CITE@en[Follow-up to TAG meeting on Powerful Features]]
([[Wendy Seltzer]] 著, [TIME[2015-02-17 02:07:15 +09:00]] 版)
<https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0298.html>

[36] [CITE@en[Renaming 'powerful features' to 'privileged contexts'. · ee4f1d8 · w3c/webappsec]]
([TIME[2015-02-24 12:52:04 +09:00]] 版)
<https://github.com/w3c/webappsec/commit/ee4f1d83de5fbb720541a440c07f44ececdc98a6>

[37] [CITE[Intent to deprecate: Insecure usage of powerful features - Google グループ]]
([TIME[2015-02-28 11:14:32 +09:00]] 版)
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus>

[38] [CITE[IRC logs: freenode / #whatwg / 20150227]]
([TIME[2015-02-28 11:18:00 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20150227>

[82] [CITE[''''''[''''''ruby-dev:25254'''''']'''''' Re: net/https.rb and server identity (RFC2818)]]
([TIME[2015-03-16 12:49:45 +09:00]] 版)
<http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25254>

[84] [CITE@en[Bug 393385 – RFC 2818 hostname verification for outgoing HTTPS connections]]
([TIME[2015-03-16 12:51:59 +09:00]] 版)
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=393385>

[85] [CITE[Curl: Re: ''''''[''''''curl'''''']'''''' Adding RFC2818 compliance to axTLS and moving helper functions to a generic place. (#46)]]
([[Daniel Stenberg (daniel_at_haxx.se)]] 著, [TIME[2012-11-06 07:42:29 +09:00]] 版)
<http://curl.haxx.se/mail/lib-2012-11/0048.html>