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

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

仕様書

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

呼称

[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 を明記するヘッダーなどもありませんから、 HTTP か HTTPS かメッセージの内容だけから区別することはできません。

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

TLS を参照。

HTTP/2 over TLS/1.2

[129] HTTP/2 の実装は、 TLS/1.2 以上を使わなければなりません >>128。 BCP 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 の圧縮は、無効としなければなりません >>128。TLS のような一般的なストリーム圧縮は使ってはなりません >>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 の実装は、 ブラックリスト >>143 の cipher 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_SHA256 を P-256 elliptic curve で対応しなければなりません >>128。

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

Opportunistic Security for HTTP/2

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

Opportunistic Security for HTTP/2 参照。

接続の開始

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

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

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

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

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

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

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

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

それぞれの項を参照。

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

ALPN

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

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

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

[157] しかし現時点でこの値の利用方法は定義されていません。 自明だから登録以上の説明は不要だということなのでしょうか。 [158] 例えば http/1.1 が指定された時に HTTP/1.0 や HTTP/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] ALPN の IANA登録簿には、 h2c も登録されています。 これは HTTP/2 over TLS を表しています。クライアントは、この値を送ってはなりません。 サーバーは、このプロトコルを選択してはなりません。 >>107

[126] ALPN の IANA登録簿には、 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 の接続の時、 Firefox は ALPN と NPN を指定します。 ALPN では http/1.1 のみを指定します。 Chrome は NPN のみを指定します。

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

証明書による認証

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

[232] Chrome は www. つきドメインが SIservice identity 検証エラーになるとき、 www. のないドメインに自動リダイレクトします。 例えば https://www.suikawiki.org に navigate すると https://suikawiki.org にリダイレクトされ、 次のようなメッセージが開発者コンソールに表示されます。

Redirecting navigation www.suikawiki.org -> suikawiki.org because the server presented a certificate valid for suikawiki.org but not for www.suikawiki.org. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling

[237] 逆方向で www. を補足するリダイレクトもあります。

[234] アドレスバーからの navigate だけでなく location.href でも同じ挙動になります。

[236] Mozilla も追随しました。

  • [233] 507454 - Implement Redirect for the WWW Subdomain Mismatch case - chromium, https://bugs.chromium.org/p/chromium/issues/detail?id=507454
  • [235] 1617987 - https://magmalabs.io redirects to https://www.magmalabs.io in Chrome but not Firefox [SSLCommonNameMismatchHandling], https://bugzilla.mozilla.org/show_bug.cgi?id=1617987

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

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

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

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

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

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

TLSクライアント認証を参照。

[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] HTTPS の URL scheme は https: です。

https: を参照。

ポート

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

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

[198] port blocking も参照。

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

[231] HTTP Web Push は 1001 をも使っています。

素の HTTP と異なる動作

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

メタ変数 HTTPS

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

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

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

実装

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

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

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

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

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

串

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

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

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

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

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

素の HTTP との混在

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

Mixed Content や Referrer や upgrade-insecure-requests を参照。

プライバシー

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

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

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

レンダリング

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

歴史

Netscape HTTPS

[43] HTTPS は SSL の開発者である 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 の他にも、 SSL と HTTP を組み合わせる方法はいくつか提案されていました。 しかし結局いずれも広く実装されるには至りませんでした。

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

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

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

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

[78] IPP/1.1 は (従来の IPP/1.0 の HTTPS 方式にかわって) 本方式を採用していました。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 に対応していることが利点として挙げられていました >>16。 HTTPS の virtual hosting 対応は遅れましたが、2010年代半ばになってようやく SAN 対応が普及してきています。 (当時既に SAN は存在していたのですから、 実は大きな利点とは言えない気がします。)

  • [16] RFC 2817 - Upgrading to TLS Within HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2817
  • [19] RFC 6454 - The Web Origin Concept ( 版) http://tools.ietf.org/html/rfc6454#section-3.1.1
  • [103] 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1 ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=276813
  • [104] 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
  • [102] Upgrading to TLS(RFC2817)の設定をApache2.2にしてみる|でびぞー徒然日記 ( 版) http://debz-di.kabocha.to/archives/2007/06/20070616212947.html

RFC 2818

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

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

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

RFC 723x

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

RFC 7540

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

[149] ただ TLS の cipher suite や TLS拡張などに関する規定はありますが、 通常の下位層輸送路としての 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