HTTPS

HTTPS (Web)

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

HTTP接続https: も合わせて参照してください。

仕様書

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

呼称

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

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

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

[86] The SSL Protocol <http://web.archive.org/web/19961027104907/http://www3.netscape.com/newsref/std/SSL_old.html>

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

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

[88] RFC 1700 - Assigned Numbers (1994年) <https://tools.ietf.org/html/rfc1700>

https 443/tcp https MCom

https 443/udp https MCom

# Kipp E.B. Hickman <kipp@mcom.com>

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

https 443/tcp http protocol over TLS/SSL

https 443/udp http protocol over TLS/SSL

# Kipp E.B. Hickman <kipp@mcom.com>

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

https 443/tcp http protocol over TLS/SSL

https 443/udp http protocol over TLS/SSL

# Kipp E.B. Hickman <kipp@mcom.com>

[89] Service Name and Transport Protocol Port Number Registry ( 版) <http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=8>

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

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

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

https Hypertext Transfer Protocol Secure [RFC2818]

[94] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( 版) <http://tools.ietf.org/html/rfc7230#section-8.2>

https | Hypertext Transfer Protocol Secure | Section 2.7.2

[93] Uniform Resource Identifier (URI) Schemes ( 版) <http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>

https Hypertext Transfer Protocol Secure [RFC7230, Section 2.7.2]

[61] OpenService アクセラレータ開発者向けガイド ( 版) <https://msdn.microsoft.com/ja-jp/library/cc287851(v=vs.85).aspx>

Secure Hypertext Transfer Protocol (HTTPS)

プロトコル

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

HTTP の通信については HTTP接続HTTPメッセージHTTPクライアントHTTP鯖を参照。
[77] 通常の HTTP では対象URL絶対URLを使わずにパス以下だけを記述しますし、 それ以外に URL scheme を明記するヘッダーなどもありませんから、 HTTPHTTPSメッセージの内容だけから区別することはできません。

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

TLS を参照。

HTTP/2 over TLS/1.2

[129] HTTP/2 の実装は、 TLS/1.2 以上を使わなければなりません >>128BCP 195 の指針に従うべきです >>128

[132] 実装上の制限で HTTP/2 over TLS/1.2 の要件に沿わない場合に TLS 折衝を失敗とできない場合もありますから、エンドポイントは、 接続エラー INADEQUATE_SECURITY によって接続を直ちに閉じても構いません。 >>128

[186] 誤り符号 INADEQUATE_SECURITY (0xc) は、下位層輸送路が最小セキュリティー要件を満たさないことを示します >>186

[133] HTTP/2 over TLS/1.2圧縮は、無効としなければなりません >>128TLS のような一般的なストリーム圧縮は使ってはなりません >>142

CRIME攻撃対策です。

[134] HTTP/2 over TLS/1.2再折衝は、無効としなければなりません接続エラー PROTOCOL_ERROR としなければなりません>>128

[135] そのため長時間の接続cipher suite の暗号化回数制限に当たるかもしれません >>128。その場合は接続を新たに開く必要があります。

[136] ただしクライアント証明書の機密性保持のために再折衝を使うことはできます。 再折衝接続序文の送信の前に行わなければなりませんサーバーは、接続の確立の直後に再折衝要求があったら、 クライアント証明書を要求するべきです>>128

[137] 再折衝制限のため、特定の資源への要求に対して再折衝を使うことができません。 将来の改訂でそのような利用にも対応するかもしれません。 あるいはサーバーHTTP_1_1_REQUIRED を送信し、 再折衝に対応するプロトコルを使うよう求めることができます。 >>128

[183] Chrome再折衝を無効にしているようで、サーバー再折衝を求めると TLS fatal alert no_renegotiation により切断します。 (HTTP レベルのエラーは送信しません。) サーバー接続序文の送信前でも、 受け入れられないようです。 Firefox再折衝を有効にしているようで、 接続序文の前後に関わらず、必要に応じてクライアント認証ダイアログも表示します。

[138] HTTP/2 over TLS/1.2 の実装は、 ephemeral finite field DHE を使う cipher suite では最低2048ビット、 ephemeral ECDHE を使う cipher suite では最低224ビットの ephemeral key exchange size に対応しなければなりませんクライアントDHE サイズ最大 4096 ビットまで受け入れなければなりませんエンドポイントは、下限より小さな鍵長の折衝を接続エラー INADEQUATE_SECURITY として構いません。 >>128

[139] HTTP/2 over TLS/1.2 の実装は、 ブラックリスト >>143cipher suite を使うべきではありません >>128エンドポイントは、ブラックリストの cipher suite が使われていたら、接続エラー INADEQUATE_SECURITY としても構いません >>128, >>143。ブラックリストにない cipher suite折衝された時にこのエラーとしてはなりません >>128

[140] HTTP/2 over TLS/1.2 の実装は、cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256P-256 elliptic curve で対応しなければなりません >>128

[141] クライアントは、HTTP/2 に対応しないサーバーのためにブラックリストの cipher suite への対応も広告するかもしれません。 >>128

Opportunistic Security for HTTP/2

[227] Opportunistic Security for HTTP/2 は、 HTTP/2 over TLShttp: URL要求応答の送受信に使うものです。 https: URL の場合とは若干の違いがあります。

接続の開始

[46] クライアントは、の適切なポートへの接続を初期化してから、 TLSハンドシェイクを始める TLS ClientHello メッセージを送信するべきです。 >>45

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

[111] クライアントは、接続先が DNSホスト名なら、 ClientHelloSNI を含める必要があります。 HTTPS の実装は、 SNI に対応しなければなりません >>159WebSocket >>80HTTP/2 >>128 の場合は、 SNI を使わなければなりませんHTTP/2 TLS 実装は SNI に対応しなければなりません >>128

[113] HTTP/1.1 以下HTTPS の仕様上は SNI への対応は要求されていませんが、 対応しないクライアントWeb互換ではありません。
[130] IPアドレスへの接続時にどうするべきかは不明です。
[114] サーバーはこれが実効要求URLと一致しているか検査する必要がありますが、 実際にはしていないサーバーが多いようです。実効要求URLSNI を参照。

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

[81] WebSocket over TLS (wss:) でも、 本節のようにしなければなりません >>80

[164] TLSハンドシェイクは、成功裏に完了するか、失敗するかのいずれかです。 失敗した場合は、 HTTP の処理を続けることはできません。なお成功の場合でも、 (fatal ではない) TLS error alert を受信しているかもしれません。

[165] HSTSPKP が適用されるホストでは、 (エラーのレベルに関わらず) エラーがあれば接続を失敗として閉じなければなりません >>161, >>162

それぞれの項を参照。

[163] TLSハンドシェイクが完了したら、データの送受信 (>>47) を開始できます。

ALPN

[155] クライアントは、 ALPN によって h2, http/1.1 を指定するべきと思われます。

[156] サーバーは、 ALPN が用いられている時は h2 または http/1.1 があれば HTTP/2HTTP/1.1 のいずれか適切な方を選択し、 いずれもなければ fatal alert を返すべきと思われます。 ALPN が用いられていない時は HTTP/1.1 を使うべきと思われます。

[122] ALPNIANA登録簿には、 http/1.1HTTP/1.1 用に登録され、 RFC 7230 が出典となっています。

[157] しかし現時点でこの値の利用方法は定義されていません。 自明だから登録以上の説明は不要だということなのでしょうか。
[158] 例えば http/1.1 が指定された時に HTTP/1.0HTTP/0.9要求が送られてきたらどう処理するべきかは不明です。

[145] HTTP/2 の実装は、 ALPN を使わなければなりません >>144

[124] HTTP/2クライアントhttps: URL に接続する時は、 ALPNプロトコル識別子 h2 を使います >>107

[146] ALPN を使わない HTTP/2 (らしき) 接続をサーバーが拒絶しなければならないのかどうかはあまり明確ではありません。 cross-protocol attack を防止するためには、拒絶するべきでしょう。
[147] ALPN を (エラーすら) サーバーが返さなかった時に、 HTTP/2 クライアントがどうするべきなのかは明確ではありません。 相互運用性cross-protocol attack 防止の観点からは、 エラーとして切断するべきでしょうか。

[125] ALPNIANA登録簿には、 h2c も登録されています。 これは HTTP/2 over TLS を表しています。クライアントは、この値を送ってはなりませんサーバーは、このプロトコルを選択してはなりません>>107

[126] ALPNIANA登録簿には、 HTTP/2 の過去の版を表す spdy/1, spdy/2, spdy/3 も登録されています。 また HTTP/2 の過去の版では h2-11 のような暫定的な値を使っていました。 古い実装はこうした値に対応しているかもしれませんが、近いうちに削除されると思われます。

[154] HTTP の版の選択については、プロトコルの版を参照。

[127] 利用者エージェントが送信するプロトコルの値は、fingerprinting vector です。

[180] Firefox は、 h2, spdy/3.1, http/1.1 を (この順で) 指定するようです。

[171] Firefox は、 h2-16, h2-15, h2-14, h2, spdy/3.1, http/1.1 を (この順で) 指定するようです。

[172] Chrome は、 http/1.1, spdy/3.1, h2-14, h2 を (この順で) 指定するようです。

[184] WebSocket の接続の時、 FirefoxALPNNPN を指定します。 ALPN では http/1.1 のみを指定します。 ChromeNPN のみを指定します。

[185] WebSocket の接続で (候補に指定されていないにも関わらず) サーバーALPNh2 を選択すると、 FirefoxHTTP/2 に変換した WebSocket handshake を送信してきます。 ただし connectionupgrade は含まれていない不完全なものです。 なお :schemehttps になります。

証明書による認証

[167] TLS の実装は、 TLS としての証明書証明書鎖の検査の他に、 HTTPS において規定される次のような検査も行う必要があります。

サーバー証明書の検査 (クライアント側)

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

service identity を参照。

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

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

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

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

[160] クライアントは、 PKP を実装する場合、 PKP の検査を行う必要があります。 検査に失敗した場合は、接続を閉じることになります。報告を送信する場合もあります。

PKP を参照。

[131] HTTP/2接続を再利用する際には、接続確立時と同様に要求ホスト証明書に対して検証しなければならないことになっています。

HTTP接続参照。

[216] WebDriver には、自己証明証明書や信頼できない証明書を受け入れることを指定する acceptSslCerts オプションがあります。ただし、「信頼できない証明書」 の具体的な範囲は規定されていません。おそらくは、利用者が画面から手動で受け入れることを選択できるものと同等の機能が提供されることが期待されています。

[217] wgetcurl のような Webブラウザー以外の利用者エージェントにも、 証明書検証を飛ばしたり、結果を無視したりするオプションが用意されていることがよくあります。 残念ながら、実用上はこのようなオプションが不可欠かもしれません。

クライアント証明書の検査 (サーバー側)

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

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

[66] これは一般的にはSSLクライアント認証などと呼ばれているようです。 装置に埋め込まれた特定のクライアントや、イントラネットなど、 クライアントが限定される場合でかつ認証を行いたい場合に事前にクライアント証明書を配布しておき、 これを側で検査して接続を受け入れるかどうか判断するものです。
[121] なお、当然ながらこれら証明書による identity の検査の他に、 証明書の有効期限や発行元など TLS / ドメイン名 / クライアント認証に依存しない証明書一般に関する検査も行う必要があります。 (それらの検査を通過できない場合も、利用者の判断により通信を継続させるオプションを提供する実装が一般的です。)

[228] Opportunistic Security for HTTP/2 ではクライアント認証を行わないことになっています。 Opportunistic Security for HTTP/2 参照。

ネットワークエラーとHTTPS状態

[204] TLS接続の確立でエラー (TLS のエラー、認証のエラー、 エラーとして扱うべき警告、エラーとして扱うべき古い TLS の版、 エラーとして扱うべき弱い cipher suite など) が検出された場合、 ネットワークエラーとする >>203 ことになっています。

[205] そうでない場合、 HTTP-network fetch が返す応答において、 HTTPS状態modern または deprecated のいずれかに設定することになっています >>203

[206] どちらにするかは、利用者エージェントの基準で決めることができます >>203。 廃止予定で移行期間中にある弱い cipher suite などの場合は deprecated を使い、そうでない場合は modern を使うことが期待されています。

HTTPS状態も参照。

[207] かつては、エラーがあった場合でも (エラーの種別にもよりますが) 利用者の指示により一時的にネットワークエラーとせずに処理を続行させることができる実装が一般的でした。 現在でも一部そのような機能が残っている Webブラウザーもありますし、 認証の一部を省略するオプションを用意しているクライアントプログラムライブラリーも広く流通しています。 しかしながら、 (悪意の有無はともかく) 利用者に十分な理解をさせずにセキュリティー的に問題のあるそうした操作を強いる Webサイトが増えて激しく非難されたこともありました。 こうしたオプションは廃止したり、一般の利用者が使いにくくしたりする流れとなってきています。

データの送受信

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

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

HTTP接続参照。

[152] HTTP/1.1 以下では、 TLS handshake の完了後、すぐに通常の HTTP要求応答を送受信できる状態となります。

[153] HTTP/2 では、 TLS handshake の完了後、 まず接続序文の送受信を行わなければなりません >>107, >>144

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

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

[178] 接続中にクライアント認証を目的とした再折衝が行われることがあります。

[179] ただし HTTP/2 では禁止されています (>>134, >>136)。

接続を閉じる

[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) できる (willing to) べきです。 >>45

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

[177] TLS 1.1 以後、 premature close 時にもセッション再開を認めるよう (実態に合わせて) 仕様変更されています。 HTTPS 仕様はその後改訂されていないのですが、 変更の趣旨を考えると、セッション再利用の禁止は失効していると考えるべきでしょう。

closure alert も参照。
[31] HSTS も参照。

URL scheme

[9] HTTPSURL schemehttps: です。

https: を参照。

ポート

[210] HTTPS プロトコルとしてのポート番号の制限はありません。

[211] 理論上は、例えば 80 を使うことも (不自然ですが) 可能です。

[198] port blocking も参照。

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

素の HTTP と異なる動作

[200] 素のHTTPHTTPSとで、 HTTP プロトコルやそれを通じてやり取りされる文書の処理で、 異なる動作が求められることがあります。

メタ変数 HTTPS

[5] >>1 一応 RFC 3875 で規定されました。

[7] CGI (RFC 3875) の規定により、プロトコルURL scheme が異なる時に URL scheme と同名のメタ変数を定義してよいとされており、メタ変数 HTTPS がこれに合致します。

同仕様上、それ以外の場面でそれを定義してはならないとはされていませんし、 設定する値についても規定が無いので、 >>2 のどの値でも仕様と矛盾はしていません。

実装

[8] HTTP::Request::AsCGION または OFF を設定します。

逆串によるプロトコル情報ヘッダー

[13] HTTPSHTTP として転送する逆串は、元々が HTTP だったか HTTPS だったかの区別を保持するために要求ヘッダーを付加することがあります。

[14] そのようなヘッダーとしては次のものが知られています。

[25] Webアプリケーション提供者が最外 (最もクライアント側) に配置する逆串HTTPSTLS を終端させ、内部のアプリケーション鯖には HTTP転送するように設定されていることがよくあります。また場合によっては別の TLS 接続により HTTPSアプリケーション鯖に接続するケースもあります。

[26] (逆串ではない順方向の) を使う時は普通は HTTPS の通信は CONNECT 要求メソッドを使ってトンネルを通過させる形とし、 により変更されないようにします。

[27] の前後でそれぞれ HTTP over TLS を使うこともできるかもしれませんが、 証明書を持っていませんから、クライアントから見ると不正な 証明書を使った TLS 通信に見えます。 (これは MITM 攻撃そのものです。) 特殊な場面では証明書クライアントが信頼することで回避できるかもしれませんが、一般的には使えない方法です。

[28] クライアントの間が信頼できるネットワークの場合はTLS を終端させクライアントの間は素の HTTP とすることもできるかもしれませんが、 そのような使い方も一般的ではありません。

[30] 仕様に適合しない不正なの悪影響を避けるために敢えて HTTPS を使うこともあります。

[29] 素の HTTP の通信をにより中継する場合に、クライアントの間で HTTPS を使うことは可能です。

素の HTTP との混在

[23] HTTPS で送信された文書における素の HTTP資源の参照には色々な制限があります。

プライバシー

[173] ブラウザー拡張の類で、閲覧中のページの URL を自動的に送信するもの (例えばソーシャルブックマークサービスで、サービスのサーバーから URL に関する情報を自動的に取得するもの) の中には、プライバシーへの配慮から、 https: URL は既定では自動的な取得対象から除外する設定になっていることもありました。

[174] HTTPS が例外ではなく基本となりつつある現在では、 そのような設定では実用的ではないかもしれません。

[175] だとしても、 https:URL平文で他に自動送信するのは今後も避けるべきでしょう。

レンダリング

[176] Web Security Context 仕様書に表示に関する規定があります。

歴史

Netscape HTTPS

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

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

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

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

他の HTTP over SSL の提案: Upgrade: TLS/1.0 (RFC 2817)

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

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

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

[21] 多くの IETFプロトコルで採用されている STARTTLS 方式と似ています。
[44] RFC 2818 (HTTPS) が情報提供RFCなのに対し、 RFC 2817IETF 標準化過程提案標準でした。
[75] TLS のプロトコルの版に関しては protocol (HTTP) を参照。

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

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

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

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

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

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

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

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

RFC 2818

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

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

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

RFC 723x

[151] RFC 2818HTTP/1.1 の改訂版である RFC 723x により更新されていますが、 これは https: URL の定義に関するものです。 それ以外の点は RFC 2818 が参照されています。

RFC 7540

[148] RFC 7540 は、 HTTP/2 における TLS の利用について規定しています。

[149] ただ TLScipher suiteTLS拡張などに関する規定はありますが、 通常の下位層輸送路としての TLS の利用方法の規定はありません。 接続の切断時の扱いなどにはまったく言及がありません。

[150] service identity の検証については、 RFC 2818 を参照しています。 他の規定について言及はまったくありませんが、 HTTPS としての歴史的継続性から推測すると、 基本的には RFC 2818 の規定に従い動作するべきと思われます。

メモ

[10] Official Google Webmaster Central Blog: HTTPS as a ranking signal ( ( 版)) <http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>

[11] HTTPS Everywhere | Electronic Frontier Foundation ( ( 版)) <https://www.eff.org/https-everywhere>

[12] Indicators for high-security features - Google グループ ( ( 版)) <https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RnAx-t-wOVU/dYjKJF4E7L8J>

[32] Transitioning the Web to HTTPS ( ( 版)) <https://w3ctag.github.io/web-https/>

[33] Official Gmail Blog: Staying at the forefront of email security and reliability: HTTPS-only and 99.978% availability ( ( 版)) <http://gmailblog.blogspot.jp/2014/03/staying-at-forefront-of-email-security.html>

[34] Securing the Web ( 版) <http://www.w3.org/2001/tag/doc/web-https>

[35] Follow-up to TAG meeting on Powerful Features (Wendy Seltzer 著, 版) <https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0298.html>

[36] Renaming 'powerful features' to 'privileged contexts'. · ee4f1d8 · w3c/webappsec ( 版) <https://github.com/w3c/webappsec/commit/ee4f1d83de5fbb720541a440c07f44ececdc98a6>

[37] Intent to deprecate: Insecure usage of powerful features - Google グループ ( 版) <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus>

[38] IRC logs: freenode / #whatwg / 20150227 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20150227>

[82] [ruby-dev:25254] Re: net/https.rb and server identity (RFC2818) ( 版) <http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25254>

[84] Bug 393385 – RFC 2818 hostname verification for outgoing HTTPS connections ( 版) <https://bugs.eclipse.org/bugs/show_bug.cgi?id=393385>

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

[108] Securing the Web ( 版) <https://w3ctag.github.io/web-https/>

[109] w3ctag/web-https ( 版) <https://github.com/w3ctag/web-https>

[120] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) <http://tools.ietf.org/html/rfc5280#page-104>

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.

[123] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting ( 版) <https://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities>

[55] Official Google Webmaster Central Blog: HTTPS as a ranking signal ( 版) <http://googlewebmastercentral.blogspot.jp/2014/08/https-as-ranking-signal.html>

[59] Insecure HTTP Deprecation Plan - Google ドキュメント ( 版) <https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit>

[60] Re: [EME] HTTPS performance experiments for large scale content distribution (Mark Watson 著, 版) <https://lists.w3.org/Archives/Public/www-tag/2015Apr/0027.html>

[62] Privileged Contexts ( 版) <http://www.w3.org/TR/2015/WD-powerful-features-20150424/>

[63] Insecure HTTP Deprecation Plan - Google ドキュメント ( 版) <https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit>

[67] Deprecating Non-Secure HTTP | Mozilla Security Blog ( 版) <https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>

[69] Adopting Encryption: The Need for HTTPS - IABlog ( 版) <http://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html>

[70] The HTTPS-Only Standard ( 版) <https://https.cio.gov/>

[71] Deprecating Non-Secure HTTP Frequently Asked Questions ( 版) <https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf>

[72] HTTPS 化する Web をどう考えるか - Block Rockin’ Codes ( 版) <http://jxck.hatenablog.com/entry/web-over-https>

[79] Please rename while we can · w3c/webappsec@42e9a78 ( 版) <https://github.com/w3c/webappsec/commit/42e9a78198ba61e630c9b0c7da0ebf39727ee29f>

[106] Secure Contexts ( 版) <https://w3c.github.io/webappsec/specs/powerfulfeatures/>

[168] 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 ( 版) <https://code.google.com/p/chromium/issues/detail?id=4527>

[169] SSL/TLS upgrades - RFC2817 - Google グループ ( 版) <https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/4Im0YcJcWiU>

[170] エクスプレス予約 新幹線の会員制ネット予約 ( 版) <http://expy.jp/renew2015/>

8月29日以降は、専用線方式からSSL(暗号化通信)によるインターネット接続方式に変更します。

これに伴い、リニューアル後は携帯電話の予約画面URLが、「https」から始まるURLへ変更になり、一部の携帯電話(SSL非対応機種)でご利用いただけなくなります。

[181] 1132357 – remove h2-draft support starting in gecko-40 ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=1132357>

[182] Bug 468106 – cannot establish an http2 connection ( 版) <https://bugs.eclipse.org/bugs/show_bug.cgi?id=468106>

[189] Deprecating Non-Secure HTTP | Mozilla Security Blog ( 版) <https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/>

[190] ( 版) <https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf>

[191] Moving t.co to HTTPS only for new links - Announcements - Twitter Developers ( 著, 版) <https://twittercommunity.com/t/moving-t-co-to-https-only-for-new-links/52380>

[192] Re: Marking HTTP As Non-Secure (Chris Palmer 著, 版) <https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0001.html>

[193] Marking HTTP As Non-Secure - The Chromium Projects ( 版) <https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>

[194] TLS Everywhere, not https: URIs - Design Issues ( 版) <http://www.w3.org/DesignIssues/Security-NotTheS.html>

[195] Google ウェブマスター向け公式ブログ: HTTPS ページが優先的にインデックスに登録されるようになります ( 版) <http://googlewebmastercentral-ja.blogspot.jp/2015/12/indexing-https-pages-by-default.html>

[196] Supporting HTTPS and HSTS on w3.org | W3C Blog ( ( 版)) <https://www.w3.org/blog/2016/01/w3-org-supporting-https-and-hsts/>

[197] DevTools へのセキュリティ パネル導入について - Google Developers Japan ( 版) <http://googledevjp.blogspot.jp/2016/02/draft-devtools.html>

[199] Fix #222: no credentials, no TLS client certificate · whatwg/fetch@bef06e1 ( 版) <https://github.com/whatwg/fetch/commit/bef06e11e3b3b7589d23c0c892057c5cd5174c2a>

[202] Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - Monorail ( 版) <https://bugs.chromium.org/p/chromium/issues/detail?id=4527>

[208] WordPress.com、独自ドメインも全てHTTPS接続に - ITmedia エンタープライズ ( ()) <http://www.itmedia.co.jp/enterprise/articles/1604/12/news059.html>

[209] 萩原栄幸の情報セキュリティ相談室:銀行に期待した「常時SSL」 その後…… (1/2) - ITmedia エンタープライズ ( ()) <http://www.itmedia.co.jp/enterprise/articles/1502/20/news038.html>

[212] 660749 – (CVE-2011-0082) Firefox doesn't (re)validate certificates when loading a HTTPS page from the cache ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=660749>

[213] RFC 7030 - Enrollment over Secure Transport () <https://tools.ietf.org/html/rfc7030#section-3.2.3>

HTTP Basic and Digest authentication MUST only be performed over TLS

1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST

NOT be used because they do not provide confidentiality or support

mutual certificate-based or certificate-less authentication,

respectively.

[214] RFC 7030 - Enrollment over Secure Transport () <https://tools.ietf.org/html/rfc7030#section-3.3>

HTTPS [RFC2818] specifies how HTTP messages are carried over TLS.

HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST be

used for all EST communications. TLS session resumption [RFC5077]

SHOULD be supported.

[215] ウェブサービス型高機能CMS「MovableType.net」追加費用不要で、常時SSL化に対応 - プレスリリース | シックス・アパート - CMSソフトウェア、サービスを提供 () <https://www.sixapart.jp/press_releases/2016/06/23-1100.html>

常時SSL化は、MovableType.net の標準のドメインである *.movabletype.io はもちろん、独自ドメインで運用しているサイトにも追加費用不要で適用されます。標準ドメインのサイトではサービス共通のSSL証明書を利用し、独自ドメインサイトでは、非営利団体ISRGが提供する無料でSSL/TLS証明書を発行するサービス「Let's Encrypt」のドメイン認証型SSL証明書を利用します。SSL証明書の更新は、シックス・アパートが行うため、お客様は面倒なSSL証明書の更新作業を行うことなしに、常時SSL化の機能を利用し続けることができます。

[218] rename acceptSslCerts to acceptInsecureCerts (andreastt著, ) <https://github.com/w3c/webdriver/commit/df3b04aebbcc755f2bd429383b2a60cbbaf1b3fd>

[219] rename acceptSslCerts to acceptInsecureCerts (andreastt著, ) <https://github.com/w3c/webdriver/commit/df3b04aebbcc755f2bd429383b2a60cbbaf1b3fd>

[220] HTTPSを利用する一部のサイトで、タイトルなどが取得できるようになりました - はてなブックマーク開発ブログ () <http://bookmark.hatenastaff.com/entry/2016/12/07/163742>

TLSを用いたHTTPS通信を必要とする一部サイトのURLに対して、はてなブックマークからの情報取得(クロール)が失敗していたことが主な原因です。

[221] HTTPSを利用できるニュースサイトは105サイト中29% | スラド セキュリティ () <https://security.srad.jp/story/16/12/16/2355245/>

[222] RFC 8006 - Content Delivery Network Interconnection (CDNI) Metadata () <https://tools.ietf.org/html/rfc8006#section-7.3>

| https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, |

| | | | RFC 2818 |

[223] Web Annotation Protocol () <https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-containers>

Implementations should use HTTPS rather than HTTP for all interactions with Annotation Containers.

[224] RFC 8040 - RESTCONF Protocol () <https://tools.ietf.org/html/rfc8040#section-2.2>

RESTCONF servers MUST present an X.509v3-based certificate when

establishing a TLS connection with a RESTCONF client. The use of

X.509v3-based certificates is consistent with NETCONF over TLS

[RFC7589].

[225] RFC 8040 - RESTCONF Protocol () <https://tools.ietf.org/html/rfc8040#section-2.3>

The RESTCONF client MUST either (1) use X.509 certificate path

validation [RFC5280] to verify the integrity of the RESTCONF server's

TLS certificate or (2) match the server's TLS certificate with a

certificate obtained by a trusted mechanism (e.g., a pinned

certificate). If X.509 certificate path validation fails and the

presented X.509 certificate does not match a certificate obtained by

a trusted mechanism, the connection MUST be terminated, as described

in Section 7.2.1 of [RFC5246].

[226] PWG 5100.13 – IPP: Job and Printer Extensions – Set 3 ( ()) <http://ftp.pwg.org/pub/pwg/candidates/cs-ippjobprinterext3v10-20120727-5100.13.pdf>

Kerberized Printing; authenticated printing based on SPNEGO-based Kerberos and NTLM

HTTP Authentication in Microsoft Windows [RFC4559], Transport Layer Security/1.2

[RFC5246], and Upgrading to TLS Within HTTP/1.1 [RFC2817].

[229] RFC 4791 - Calendaring Extensions to WebDAV (CalDAV) () <https://tools.ietf.org/html/rfc4791#section-2>

o MUST support transport over TLS [RFC2246] as defined in [RFC2818]

(note that [RFC2246] has been obsoleted by [RFC4346]);

[230] Qualys SSL Labs - Projects / SSL Client Test () <https://www.ssllabs.com/ssltest/viewMyClient.html>