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>
- [115] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-05 09:33:40 +09:00]] 版) <https://html.spec.whatwg.org/#encrypted-http-and-related-security-concerns>
]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]] [CODE[[[ClientHello]]]] [[メッセージ]]を送信するべきです。
[[TLSハンドシェイク]]が完了したら、最初の [[HTTP要求]]を送信できます。 [SRC[>>45]]

;; [110] [[TLS]] より前にそれ以外のデータを送受信することはできません。
([[TCP接続]]の途中の[[要求]]や[[応答]]から [[TLS]] に切り替えるような使い方はできません。)

[111] [[クライアント]]は、接続先が [[DNSホスト名]]なら、 [CODE[[[ClientHello]]]]
に [[SNI]] を含める必要があります。

;; [113] [[TLS]] や [[HTTPS]] の仕様上は [[SNI]] への対応は要求されていませんが、
対応しない[[クライアント]]は [[Web互換]]ではありません。

;; [114] [[サーバー]]はこれが[[実効要求URL]]と一致しているか検査する必要があります。
[[実効要求URL]]を参照。

[112] [[クライアント]]と[[サーバー]]は、互いの[[証明書]]を検査する必要があります (後述)。

** データの送受信

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

[58] [[TLS応用データ]]として送受信される [[HTTP接続]]上の [[HTTP要求]]や
[[HTTP応答]]の処理は、基本的には [[TCP]] 上の [[HTTP]] の場合と同じです。

;; [[HTTP接続]]参照。

[56] [[HSTS]] の処理は、 [[TLS]] レベルで誤りや警告があった時には行わないことになっています。

;; [[HSTS]] 参照。

;; [57] [[TLS]] の誤りや警告は、 [[HSTS]] 以外の通常の [[HTTP]] の機能を処理する上では当然に無視されるものもありますし、
[[サーバー証明書]]の問題などを無視するよう[[利用者]]が指示している場合もあります。
通常の [[HTTP]] としての処理は行うものの、 [[HSTS]] の処理は飛ばすことになります。

** 接続を閉じる

[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]] も参照。

* 証明書による認証

[54] [[クライアント]]は、[[サーバー証明書]]について [[service identity]]
の検証を行わなければ[['''なりません''']]。

;; [[service identity]] を参照。

[116] [[利用者エージェント]]は、[[証明書]]の[[誤り]]を[[利用者]]に報告する[['''べき''']]です。
[[利用者エージェント]]は、誤った[[証明書]]により送られた[[資源]]の[[ダウンロード]]を拒むか、
または[[暗号化]]されずに送られた場合のように動作するかのいずれかとしなければ[['''なりません''']]。 [SRC[>>115]]

[EG[
[118] [[自己署名証明書]]が使われていた場合、暗号化されていなかったものとして扱うことができます。([[利用者]]に警告して[[利用者]]の判断においてであっても) 通常通りに表示してしまうと、
[[利用者]]を騙して [[MIIT]] を受け入れさせてしまうかもしれません。 [SRC[>>115]]
]EG]

[117] [[利用者エージェント]]は、あるページに再訪した時に前より[[暗号化]]が安全で無くなっている場合に、
[[利用者]]に問題があるかもしれないと警告する[['''べきです''']]。 [[MIIM攻撃]]の虞があります。 [SRC[>>115]]

[EG[
[119] [[ブックマーク]]から再訪したサイトが[[自己署名証明書]]に変わっていると、
[[MIIM攻撃]]を受けた可能性があると警告する方が良いかもしれません [SRC[>>115]]。
]EG]

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

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

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

;; [121] なお、当然ながらこれら[[証明書]]による [[identity]] の検査の他に、
[[証明書]]の有効期限や発行元など [[TLS]] / [[ドメイン名]] / [[クライアント認証]]に依存しない[[証明書]]一般に関する検査も行う必要があります。
(それらの検査を通過できない場合も、[[利用者]]の判断により通信を継続させるオプションを提供する実装が一般的です。)

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

[108] [CITE@en[Securing the Web]]
([TIME[2015-01-27 14:26:10 +09:00]] 版)
<https://w3ctag.github.io/web-https/>

[109] [CITE@en[w3ctag/web-https]]
([TIME[2015-03-19 16:03:12 +09:00]] 版)
<https://github.com/w3ctag/web-https>

[FIG(quote)[
[FIGCAPTION[
[120] [CITE@en[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]]
([TIME[2015-02-22 15:44:10 +09:00]] 版)
<http://tools.ietf.org/html/rfc5280#page-104>
]FIGCAPTION]

> CAs SHOULD NOT include URIs that specify https, ldaps, or similar
>    schemes in extensions.  CAs that include an https URI in one of these
>    extensions MUST ensure that the server's certificate can be validated
>    without using the information that is pointed to by the URI.  Relying
>    parties that choose to validate the server's certificate when
>    obtaining information pointed to by an https URI in the
>    cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
>    extensions MUST be prepared for the possibility that this will result
>    in unbounded recursion.
> 

]FIG]


[123] [CITE[Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting]]
([TIME[2015-03-31 16:49:49 +09:00]] 版)
<https://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities>

[55] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]]
([TIME[2015-04-01 01:09:39 +09:00]] 版)
<http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>