[6] [[SSL]] あるいは [[TLS]] 上で [[HTTP]] を用いる通信、あるいはその[[プロトコル]] [WEAK[(の組み合わせ方)]] のことを [DFN[[[HTTP/SSL]]]]、[DFN[[[HTTP/TLS]]]]、あるいは [DFN[[[HTTPS]]]] と呼びます。 ;; [[HTTP接続]]や [CODE(URI)@en[[[https:]]]] も合わせて参照してください。 * 仕様書 [REFS[ - [39] '''[CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) ''' -- [45] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) -- [51] [CITE@en[RFC 2818 - HTTP Over TLS]] ([TIME[2014-12-15 14:10:09 +09:00]] 版) - [68] [CITE[RFC Errata Report]] ([TIME[2015-03-04 17:58:35 +09:00]] 版) - [115] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-03-05 09:33:40 +09:00]] 版) - [80] [CITE@en[RFC 6455 - The WebSocket Protocol]] ([TIME[2015-03-11 20:42:50 +09:00]] 版) - [161] [CITE@en[RFC 6797 - HTTP Strict Transport Security (HSTS)]] ([TIME[2015-05-03 13:27:16 +09:00]] 版) - [159] [CITE@en[RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]] ([TIME[2015-05-29 03:22:56 +09:00]] 版) - [162] [CITE@en[RFC 7469 - Public Key Pinning Extension for HTTP]] ([TIME[2015-05-05 21:00:37 +09:00]] 版) - [188] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) -- [107] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) -- [144] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) -- [187] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) -- [128] '''[CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) ''' -- [142] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) -- [143] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) - [203] [CITE@en-US[Fetch Standard]] ([TIME[2016-04-19 01:53:35 +09:00]] 版) ]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]] 版) ]REFS] [98] [[SSL/2.0]] は次のように説明していました。 [FIG(quote)[ [FIGCAPTION[ [86] [CITE[The SSL Protocol]] ]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年) ]FIGCAPTION] > https 443/tcp https MCom > https 443/udp https MCom > # Kipp E.B. Hickman ]FIG] [FIG(quote)[ [FIGCAPTION[ [91] [CITE[PORT NUMBERS]] (2000年) ]FIGCAPTION] > https 443/tcp http protocol over TLS/SSL > https 443/udp http protocol over TLS/SSL > # Kipp E.B. Hickman ]FIG] [FIG(quote)[ [FIGCAPTION[ [92] [CITE[PORT NUMBERS]] (2001年) ]FIGCAPTION] > https 443/tcp http protocol over TLS/SSL > https 443/udp http protocol over TLS/SSL > # Kipp E.B. Hickman ]FIG] [FIG(quote)[ [FIGCAPTION[ [89] [CITE[Service Name and Transport Protocol Port Number Registry]] ([TIME[2015-03-12 02:46:25 +09:00]] 版) ]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年) ]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]] 版) ]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]] 版) ]FIGCAPTION] > https Hypertext Transfer Protocol Secure '''['''RFC7230, Section 2.7.2''']''' ]FIG] [FIG(quote)[ [FIGCAPTION[ [61] [CITE@ja[OpenService アクセラレータ開発者向けガイド]] ([TIME[2015-04-19 15:00:58 +09:00]] 版) ]FIGCAPTION] >Secure Hypertext Transfer Protocol (HTTPS) ]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]] などの[[トンネル]]が下位層の[[ホップ]]として用いられていることもあります。 ;; [[TLS]] を参照。 ** HTTP/2 over TLS/1.2 [129] [[HTTP/2]] の実装は、 [[TLS/1.2]] [[以上]]を使わなければ[['''なりません''']] [SRC[>>128]]。 [[BCP 195]] の指針に従う[['''べきです''']] [SRC[>>128]]。 [132] 実装上の制限で [[HTTP/2]] over [[TLS/1.2]] の要件に沿わない場合に [[TLS]] 折衝を失敗とできない場合もありますから、[[エンドポイント]]は、 [[接続エラー]] [CODE[[[INADEQUATE_SECURITY]]]] によって[[接続]]を直ちに閉じても構いません。 [SRC[>>128]] [186] [[誤り符号]] [DFN[[CODE[[[INADEQUATE_SECURITY]]]]]] ([CODE[[[0xc]]]]) は、下位層輸送路が最小セキュリティー要件を満たさないことを示します [SRC[>>186]]。 [133] [[HTTP/2]] over [[TLS/1.2]] の[[圧縮]]は、無効としなければ[['''なりません''']] [SRC[>>128]]。[[TLS]] のような一般的なストリーム圧縮は使っては[['''なりません''']] [SRC[>>142]]。 ;; [[CRIME攻撃]]対策です。 [134] [[HTTP/2]] over [[TLS/1.2]] の[[再折衝]]は、無効としなければ[['''なりません''']]。 [[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]] としなければ[['''なりません''']]。 [SRC[>>128]] ;; [135] そのため長時間の[[接続]]は [[cipher suite]] の暗号化回数制限に当たるかもしれません [SRC[>>128]]。その場合は[[接続]]を新たに開く必要があります。 [136] ただし[[クライアント証明書]]の機密性保持のために[[再折衝]]を使うことはできます。 [[再折衝]]は[[接続序文]]の送信の前に行わなければ[['''なりません''']]。 [[サーバー]]は、[[接続]]の確立の直後に[[再折衝]]要求があったら、 [[クライアント証明書]]を要求する[['''べきです''']]。 [SRC[>>128]] ;; [137] [[再折衝]]制限のため、特定の[[資源]]への要求に対して[[再折衝]]を使うことができません。 将来の改訂でそのような利用にも対応するかもしれません。 あるいは[[サーバー]]は [CODE(HTTP)[[[HTTP_1_1_REQUIRED]]]] を送信し、 [[再折衝]]に対応するプロトコルを使うよう求めることができます。 [SRC[>>128]] [183] [[Chrome]] は[[再折衝]]を無効にしているようで、[[サーバー]]が[[再折衝]]を求めると [[TLS fatal alert]] [CODE[[[no_renegotiation]]]] により切断します。 ([[HTTP]] レベルのエラーは送信しません。) [[サーバー]]の[[接続序文]]の送信前でも、 受け入れられないようです。 [[Firefox]] は[[再折衝]]を有効にしているようで、 [[接続序文]]の前後に関わらず、必要に応じて[[クライアント認証]]の[[ダイアログ]]も表示します。 [TIME[2015-10-11T14:15:42.800Z]] [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 ビットまで受け入れなければ[['''なりません''']]。 [[エンドポイント]]は、下限より小さな鍵長の折衝を[[接続エラー]] [CODE[[[INADEQUATE_SECURITY]]]] として構いません。 [SRC[>>128]] [139] [[HTTP/2]] over [[TLS/1.2]] の実装は、 ブラックリスト [SRC[>>143]] の [[cipher suite]] を使う[['''べきではありません''']] [SRC[>>128]]。 [[エンドポイント]]は、ブラックリストの [[cipher suite]] が使われていたら、[[接続エラー]] [CODE[[[INADEQUATE_SECURITY]]]] としても構いません [SRC[>>128, >>143]]。ブラックリストにない [[cipher suite]] に[[折衝]]された時にこのエラーとしては[['''なりません''']] [SRC[>>128]]。 [140] [[HTTP/2]] over [[TLS/1.2]] の実装は、[[cipher suite]] [CODE[[[TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]]]] を [[P-256 elliptic curve]] で対応しなければ[['''なりません''']] [SRC[>>128]]。 ;; [141] [[クライアント]]は、[[HTTP/2]] に対応しない[[サーバー]]のためにブラックリストの [[cipher suite]] への対応も[[広告]]するかもしれません。 [SRC[>>128]] ** Opportunistic Security for HTTP/2 [227] [[Opportunistic Security for HTTP/2]] は、 [[HTTP/2]] over [[TLS]] を [CODE(URI)@en[http:]] [[URL]] の[[要求]]と[[応答]]の送受信に使うものです。 [CODE(URI)@en[https:]] [[URL]] の場合とは若干の違いがあります。 ;; [[Opportunistic Security for HTTP/2]] 参照。 * 接続の開始 [46] [[クライアント]]は、[[鯖]]の適切な[[ポート]]への[[接続]]を初期化してから、 [[TLSハンドシェイク]]を始める [[TLS]] [CODE[[[ClientHello]]]] [[メッセージ]]を送信するべきです。 [SRC[>>45]] ;; [110] [[TLS]] より前にそれ以外のデータを送受信することはできません。 ([[TCP接続]]の途中の[[要求]]や[[応答]]から [[TLS]] に切り替えるような使い方はできません。) [111] [[クライアント]]は、接続先が [[DNSホスト名]]なら、 [CODE[[[ClientHello]]]] に [[SNI]] を含める必要があります。 [[HTTPS]] の実装は、 [[SNI]] に対応しなければなりません [SRC[>>159]]。 [[WebSocket]] [SRC[>>80]] や [[HTTP/2]] [SRC[>>128]] の場合は、 [[SNI]] を使わなければ[['''なりません''']]。 [[HTTP/2]] [[TLS]] 実装は [[SNI]] に対応しなければ[['''なりません''']] [SRC[>>128]]。 ;; [113] [[HTTP/1.1]] [[以下]]の [[HTTPS]] の仕様上は [[SNI]] への対応は要求されていませんが、 対応しない[[クライアント]]は [[Web互換]]ではありません。 ;; [130] [[IPアドレス]]への接続時にどうするべきかは不明です。 ;; [114] [[サーバー]]はこれが[[実効要求URL]]と一致しているか検査する必要がありますが、 実際にはしていない[[サーバー]]が多いようです。[[実効要求URL]]や [[SNI]] を参照。 [112] [[クライアント]]と[[サーバー]]は、互いの[[証明書]]を検査する必要があります (後述)。 [81] [[WebSocket]] over [[TLS]] ([CODE(URI)@en[[[wss:]]]]) でも、 本節のようにしなければ[['''なりません''']] [SRC[>>80]]。 [164] [[TLSハンドシェイク]]は、成功裏に完了するか、失敗するかのいずれかです。 失敗した場合は、 [[HTTP]] の処理を続けることはできません。なお成功の場合でも、 (fatal ではない) [[TLS error alert]] を受信しているかもしれません。 [165] [[HSTS]] や [[PKP]] が適用される[[ホスト]]では、 (エラーのレベルに関わらず) エラーがあれば[[接続]]を失敗として閉じなければなりません [SRC[>>161, >>162]]。 ;; それぞれの項を参照。 [163] [[TLSハンドシェイク]]が完了したら、データの送受信 (>>47) を開始できます。 ** ALPN [155] [[クライアント]]は、 [[ALPN]] によって [CODE[[[h2]]]], [CODE[[[http/1.1]]]] を指定するべきと思われます。 [156] [[サーバー]]は、 [[ALPN]] が用いられている時は [CODE[[[h2]]]] または [CODE[[[http/1.1]]]] があれば [[HTTP/2]] と [[HTTP/1.1]] のいずれか適切な方を選択し、 いずれもなければ [[fatal alert]] を返すべきと思われます。 [[ALPN]] が用いられていない時は [[HTTP/1.1]] を使うべきと思われます。 [122] [[ALPN]] の [[IANA登録簿]]には、 [CODE[[[http/1.1]]]] が [[HTTP/1.1]] 用に登録され、 [[RFC 7230]] が出典となっています。 ;; [157] しかし現時点でこの値の利用方法は定義されていません。 自明だから登録以上の説明は不要だということなのでしょうか。 [TIME[2015-05-18T13:09:39.900Z]] ;; [158] 例えば [CODE[[[http/1.1]]]] が指定された時に [[HTTP/1.0]] や [[HTTP/0.9]] の[[要求]]が送られてきたらどう処理するべきかは不明です。 [145] [[HTTP/2]] の実装は、 [[ALPN]] を使わなければ[['''なりません''']] [SRC[>>144]]。 [124] [[HTTP/2クライアント]]が [CODE(URI)@en[[[https:]]]] [[URL]] に接続する時は、 [[ALPN]] で[[プロトコル識別子]] [CODE[[[h2]]]] を使います [SRC[>>107]]。 ;; [146] [[ALPN]] を使わない [[HTTP/2]] (らしき) 接続を[[サーバー]]が拒絶しなければならないのかどうかはあまり明確ではありません。 [[cross-protocol attack]] を防止するためには、拒絶するべきでしょう。 ;; [147] [[ALPN]] を (エラーすら) [[サーバー]]が返さなかった時に、 [[HTTP/2]] [[クライアント]]がどうするべきなのかは明確ではありません。 [[相互運用性]]と [[cross-protocol attack]] 防止の観点からは、 エラーとして切断するべきでしょうか。 [125] [[ALPN]] の [[IANA登録簿]]には、 [CODE[[[h2c]]]] も登録されています。 これは [[HTTP/2]] over [[TLS]] を表しています。[[クライアント]]は、この値を送っては[['''なりません''']]。 [[サーバー]]は、この[[プロトコル]]を選択しては[['''なりません''']]。 [SRC[>>107]] ;; [126] [[ALPN]] の [[IANA登録簿]]には、 [[HTTP/2]] の過去の版を表す [CODE[[[spdy/1]]]], [CODE[[[spdy/2]]]], [CODE[[[spdy/3]]]] も登録されています。 また [[HTTP/2]] の過去の版では [CODE[[[h2-11]]]] のような暫定的な値を使っていました。 古い実装はこうした値に対応しているかもしれませんが、近いうちに削除されると思われます。 [154] [[HTTP]] の版の選択については、[[プロトコルの版]]を参照。 [127] [[利用者エージェント]]が送信するプロトコルの値は、[[fingerprinting vector]] です。 [180] [[Firefox]] は、 [CODE[[[h2]]]], [CODE[[[spdy/3.1]]]], [CODE[[[http/1.1]]]] を (この順で) 指定するようです。 [TIME[2015-09-26T13:31:35.400Z]] [HISTORY[ [171] [[Firefox]] は、 [CODE[[[h2-16]]]], [CODE[[[h2-15]]]], [CODE[[[h2-14]]]], [CODE[[[h2]]]], [CODE[[[spdy/3.1]]]], [CODE[[[http/1.1]]]] を (この順で) 指定するようです。 [TIME[2015-08-04T09:58:57.100Z]] ]HISTORY] [172] [[Chrome]] は、 [CODE[[[http/1.1]]]], [CODE[[[spdy/3.1]]]], [CODE[[[h2-14]]]], [CODE[[[h2]]]] を (この順で) 指定するようです。 [TIME[2015-08-04T10:12:20.100Z]] [184] [[WebSocket]] の接続の時、 [[Firefox]] は [[ALPN]] と [[NPN]] を指定します。 [[ALPN]] では [CODE[[[http/1.1]]]] のみを指定します。 [[Chrome]] は [[NPN]] のみを指定します。 [TIME[2015-10-11T14:38:05.000Z]] [185] [[WebSocket]] の接続で (候補に指定されていないにも関わらず) [[サーバー]]が [[ALPN]] で [CODE[[[h2]]]] を選択すると、 [[Firefox]] は [[HTTP/2]] に変換した [[WebSocket handshake]] を送信してきます。 ただし [CODE[[[connection]]]] や [CODE[[[upgrade]]]] は含まれていない不完全なものです。 なお [CODE[[[:scheme]]]] は [CODE[[[https]]]] になります。 [TIME[2015-10-11T14:39:15.100Z]] * 証明書による認証 [167] [[TLS]] の実装は、 [[TLS]] としての[[証明書]]・[[証明書鎖]]の検査の他に、 [[HTTPS]] において規定される次のような検査も行う必要があります。 ** サーバー証明書の検査 (クライアント側) [54] [[クライアント]]は、[[サーバー証明書]]について [[service identity]] の検証を行わなければ[['''なりません''']]。 ;; [[service identity]] を参照。 [116] [[利用者エージェント]]は、[[証明書]]の[[誤り]]を[[利用者]]に報告する[['''べき''']]です。 [[利用者エージェント]]は、誤った[[証明書]]により送られた[[資源]]の[[ダウンロード]]を拒むか、 または[[暗号化]]されずに送られた場合のように動作するかのいずれかとしなければ[['''なりません''']]。 [SRC[>>115]] [EG[ [118] [[自己署名証明書]]が使われていた場合、暗号化されていなかったものとして扱うことができます。([[利用者]]に警告して[[利用者]]の判断においてであっても) 通常通りに表示してしまうと、 [[利用者]]を騙して [[MITM]] を受け入れさせてしまうかもしれません。 [SRC[>>115]] ]EG] [117] [[利用者エージェント]]は、あるページに再訪した時に前より[[暗号化]]が安全で無くなっている場合に、 [[利用者]]に問題があるかもしれないと警告する[['''べきです''']]。 [[MITM攻撃]]の虞があります。 [SRC[>>115]] [EG[ [119] [[ブックマーク]]から再訪したサイトが[[自己署名証明書]]に変わっていると、 [[MITM攻撃]]を受けた可能性があると警告する方が良いかもしれません [SRC[>>115]]。 ]EG] [160] [[クライアント]]は、 [[PKP]] を実装する場合、 [[PKP]] の検査を行う必要があります。 検査に失敗した場合は、接続を閉じることになります。報告を送信する場合もあります。 ;; [[PKP]] を参照。 [131] [[HTTP/2]] で[[接続]]を再利用する際には、[[接続]]確立時と同様に[[要求]]の[[ホスト]]を[[証明書]]に対して検証しなければならないことになっています。 ;; [[HTTP接続]]参照。 [216] [[WebDriver]] には、[[自己証明証明書]]や信頼できない[[証明書]]を受け入れることを指定する [CODE[acceptSslCerts]] オプションがあります。ただし、「信頼できない[[証明書]]」 の具体的な範囲は規定されていません。おそらくは、[[利用者]]が画面から手動で受け入れることを選択できるものと同等の機能が提供されることが期待されています。 [217] [CODE[wget]] や [CODE[curl]] のような [[Webブラウザー]]以外の[[利用者エージェント]]にも、 [[証明書]]の[[検証]]を飛ばしたり、結果を無視したりするオプションが用意されていることがよくあります。 残念ながら、実用上はこのようなオプションが不可欠かもしれません。 -*-*- [232] [[Chrome]] は [CODE[www.]] つきドメインが [[SI][service identity]] 検証エラーになるとき、 [CODE[www.]] のないドメインに自動[[リダイレクト]]します。 例えば に [[navigate]] すると に[[リダイレクト]]され、 次のようなメッセージが[[開発者コンソール]]に表示されます。 [TIME[2021-02-06T03:26:05.600Z]] > 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] 逆方向で [CODE[www.]] を補足する[[リダイレクト]]もあります。 [234] [[アドレスバー]]からの [[navigate]] だけでなく [CODE[location.href]] でも同じ挙動になります。 [236] [[Mozilla]] も追随しました。 [REFS[ - [233] [CITE@en[507454 - Implement Redirect for the WWW Subdomain Mismatch case - chromium]], [TIME[2021-02-06T03:28:43.000Z]] - [235] [CITE@en[1617987 - https://magmalabs.io redirects to https://www.magmalabs.io in Chrome but not Firefox '''['''SSLCommonNameMismatchHandling''']''']], [TIME[2021-02-06T03:30:51.000Z]] ]REFS] ** クライアント証明書の検査 (サーバー側) [64] [[鯖]]は普通は[[クライアント]]の [[identity]] がどうであるべきか (どのような[[証明書]]を有しているべきか) についての外部情報を有していませんから、 [[クライアント]]について検査することはできません。 [SRC[>>51]] [65] [[鯖]]がそのような外部情報を有している場合には、 [[鯖]]の[[証明書]]の検査と同様の [[identity]] の検査を行う[['''べき''']]です。 [SRC[>>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]] など) が検出された場合、 [[ネットワークエラー]]とする [SRC[>>203]] ことになっています。 [205] そうでない場合、 [[HTTP-network fetch]] が返す[[応答]]において、 [F[HTTPS状態]]を [CODE[modern]] または [CODE[deprecated]] のいずれかに設定することになっています [SRC[>>203]]。 [206] どちらにするかは、[[利用者エージェント]]の基準で決めることができます [SRC[>>203]]。 廃止予定で移行期間中にある弱い [[cipher suite]] などの場合は [CODE[deprecated]] を使い、そうでない場合は [CODE[modern]] を使うことが期待されています。 ;; [[HTTPS状態]]も参照。 [207] かつては、エラーがあった場合でも (エラーの種別にもよりますが) [[利用者]]の指示により一時的に[[ネットワークエラー]]とせずに処理を続行させることができる実装が一般的でした。 現在でも一部そのような機能が残っている [[Webブラウザー]]もありますし、 [[認証]]の一部を省略するオプションを用意している[[クライアント]]の[[プログラム]]や[[ライブラリー]]も広く流通しています。 しかしながら、 (悪意の有無はともかく) [[利用者]]に十分な理解をさせずにセキュリティー的に問題のあるそうした操作を強いる [[Webサイト]]が増えて激しく非難されたこともありました。 こうしたオプションは廃止したり、一般の[[利用者]]が使いにくくしたりする流れとなってきています。 * データの送受信 [47] [[HTTP]] のデータは、 [[TLS応用データ]]として送信しなければ[['''なりません''']] [SRC[>>45]]。 [58] [[TLS応用データ]]として送受信される [[HTTP接続]]上の [[HTTP要求]]や [[HTTP応答]]の処理は、基本的には [[TCP]] 上の [[HTTP]] の場合と同じです。 ;; [[HTTP接続]]参照。 [152] [[HTTP/1.1]] [[以下]]では、 [[TLS handshake]] の完了後、すぐに通常の [[HTTP]] の[[要求]]や[[応答]]を送受信できる状態となります。 [153] [[HTTP/2]] では、 [[TLS handshake]] の完了後、 まず[[接続序文]]の送受信を行わなければ[['''なりません''']] [SRC[>>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]]) [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]] [177] [[TLS 1.1]] 以後、 [[premature close]] 時にも[[セッション再開]]を認めるよう (実態に合わせて) 仕様変更されています。 [[HTTPS]] 仕様はその後改訂されていないのですが、 変更の趣旨を考えると、[[セッション]]再利用の禁止は失効していると考えるべきでしょう。 ;; [[closure alert]] も参照。 ;; [31] [[HSTS]] も参照。 * URL scheme [9] [[HTTPS]] の [[URL scheme]] は [CODE(URI)@en[[[https:]]]] です。 ;; [CODE(URI)@en[[[https:]]]] を参照。 * ポート [210] [[HTTPS]] [[プロトコル]]としての[[ポート番号]]の制限はありません。 [EG[ [211] 理論上は、例えば [N[80]] を使うことも (不自然ですが) 可能です。 ]EG] ;; [198] [[port blocking]] も参照。 [49] [[HTTP]]/[[TLS]]/[[TCP]]/[[IP]] の[[既定のポート]]は、 [DFN[[N[443]]]] です [SRC[>>45]]。 [231] [[HTTP Web Push]] は [N[1001]] をも使っています。 * 素の HTTP と異なる動作 [200] [[素のHTTP]]と[[HTTPS]]とで、 [[HTTP]] [[プロトコル]]やそれを通じてやり取りされる[[文書]]の処理で、 異なる動作が求められることがあります。 [FIG(list)[ - [201] [[HTTPS]] では、[[応答]]に [[HSTS]] [[ヘッダー]]を含める[SHOULD[べきです]]。 [[素のHTTP]]では含めては[MUST[なりません]]。 - [[secure context]] ]FIG] * メタ変数 [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(middle 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:]]]] - [CODE(HTTP)@en[CloudFront-Forwarded-Proto:]] ]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]] や [CODE(HTTP)@en[[[upgrade-insecure-requests]]]] を参照。 * プライバシー [173] [[ブラウザー拡張]]の類で、閲覧中のページの [[URL]] を自動的に送信するもの (例えば[[ソーシャルブックマーク]]サービスで、サービスの[[サーバー]]から [[URL]] に関する情報を自動的に取得するもの) の中には、[[プライバシー]]への配慮から、 [CODE(URI)@en[[[https:]]]] [[URL]] は既定では自動的な取得対象から除外する設定になっていることもありました。 [174] [[HTTPS]] が例外ではなく基本となりつつある現在では、 そのような設定では実用的ではないかもしれません。 ;; [175] だとしても、 [CODE(URI)@en[[[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]]) 用に [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]] 版) - [19] [CITE@en[RFC 6454 - The Web Origin Concept]] ([TIME[2011-12-12 09:13:37 +09:00]] 版) - [103] [CITE@en[276813 – '''['''RFE''']''' Support RFC 2817 / TLS Upgrade for HTTP 1.1]] ([TIME[2015-03-16 14:04:56 +09:00]] 版) - [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]] 版) - [102] [CITE[Upgrading to TLS(RFC2817)の設定をApache2.2にしてみる|でびぞー徒然日記]] ([TIME[2015-03-16 14:00:07 +09:00]] 版) ]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]] が極めて普及している現実を無視することに意味があるとは思えません。 ** RFC 723x [151] [[RFC 2818]] は [[HTTP/1.1]] の改訂版である [[RFC 723x]] により[[更新]]されていますが、 これは [CODE(URI)@en[[[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] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]] ( ([TIME[2014-08-08 08:15:49 +09:00]] 版)) [11] [CITE[HTTPS Everywhere | Electronic Frontier Foundation]] ( ([TIME[2014-09-01 09:47:53 +09:00]] 版)) [12] [CITE[Indicators for high-security features - Google グループ]] ( ([TIME[2014-09-18 04:41:11 +09:00]] 版)) [32] [CITE@en[Transitioning the Web to HTTPS]] ( ([TIME[2014-12-09 14:36:23 +09:00]] 版)) [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]] 版)) [34] [CITE@en[Securing the Web]] ([TIME[2015-01-23 09:35:25 +09:00]] 版) [35] [CITE@en[Follow-up to TAG meeting on Powerful Features]] ([[Wendy Seltzer]] 著, [TIME[2015-02-17 02:07:15 +09:00]] 版) [36] [CITE@en[Renaming 'powerful features' to 'privileged contexts'. · ee4f1d8 · w3c/webappsec]] ([TIME[2015-02-24 12:52:04 +09:00]] 版) [37] [CITE[Intent to deprecate: Insecure usage of powerful features - Google グループ]] ([TIME[2015-02-28 11:14:32 +09:00]] 版) [38] [CITE[IRC logs: freenode / #whatwg / 20150227]] ([TIME[2015-02-28 11:18:00 +09:00]] 版) [82] [CITE[''''''[''''''ruby-dev:25254'''''']'''''' Re: net/https.rb and server identity (RFC2818)]] ([TIME[2015-03-16 12:49:45 +09:00]] 版) [84] [CITE@en[Bug 393385 – RFC 2818 hostname verification for outgoing HTTPS connections]] ([TIME[2015-03-16 12:51:59 +09:00]] 版) [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]] 版) [108] [CITE@en[Securing the Web]] ([TIME[2015-01-27 14:26:10 +09:00]] 版) [109] [CITE@en[w3ctag/web-https]] ([TIME[2015-03-19 16:03:12 +09:00]] 版) [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]] 版) ]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]] 版) [55] [CITE@en[Official Google Webmaster Central Blog: HTTPS as a ranking signal]] ([TIME[2015-04-01 01:09:39 +09:00]] 版) [59] [CITE[Insecure HTTP Deprecation Plan - Google ドキュメント]] ([TIME[2015-04-14 12:28:53 +09:00]] 版) [60] [CITE@en[Re: ''''''[''''''EME'''''']'''''' HTTPS performance experiments for large scale content distribution]] ([[Mark Watson]] 著, [TIME[2015-04-16 05:21:43 +09:00]] 版) [62] [CITE@en[Privileged Contexts]] ([TIME[2015-04-24 19:29:37 +09:00]] 版) [63] [CITE[Insecure HTTP Deprecation Plan - Google ドキュメント]] ([TIME[2015-05-03 15:22:03 +09:00]] 版) [67] [CITE@en-US[Deprecating Non-Secure HTTP | Mozilla Security Blog]] ([TIME[2015-05-03 15:25:02 +09:00]] 版) [69] [CITE[Adopting Encryption: The Need for HTTPS - IABlog]] ([TIME[2015-03-27 23:28:21 +09:00]] 版) [70] [CITE[The HTTPS-Only Standard]] ([TIME[2015-04-29 15:57:01 +09:00]] 版) [71] [CITE[Deprecating Non-Secure HTTP Frequently Asked Questions]] ([TIME[2015-05-02 11:35:50 +09:00]] 版) [72] [CITE@ja[HTTPS 化する Web をどう考えるか - Block Rockin’ Codes]] ([TIME[2015-05-06 08:37:43 +09:00]] 版) [79] [CITE@en[Please rename while we can · w3c/webappsec@42e9a78]] ([TIME[2015-05-11 11:26:09 +09:00]] 版) [106] [CITE@en[Secure Contexts]] ([TIME[2015-05-17 18:30:14 +09:00]] 版) [168] [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-06-21 13:46:56 +09:00]] 版) [169] [CITE[SSL/TLS upgrades - RFC2817 - Google グループ]] ([TIME[2015-06-21 13:53:12 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [170] [CITE[エクスプレス予約 新幹線の会員制ネット予約]] ([TIME[2015-07-31 17:59:42 +09:00]] 版) ]FIGCAPTION] > > 8月29日以降は、専用線方式からSSL(暗号化通信)によるインターネット接続方式に変更します。 > これに伴い、リニューアル後は携帯電話の予約画面URLが、「https」から始まるURLへ変更になり、一部の携帯電話(SSL非対応機種)でご利用いただけなくなります。 ]FIG] [181] [CITE@en[1132357 – remove h2-draft support starting in gecko-40]] ([TIME[2015-09-27 00:09:25 +09:00]] 版) [182] [CITE@en[Bug 468106 – cannot establish an http2 connection]] ([TIME[2015-09-27 00:53:40 +09:00]] 版) [189] [CITE@en-US[Deprecating Non-Secure HTTP | Mozilla Security Blog]] ([TIME[2015-10-13 19:07:43 +09:00]] 版) [190] ([TIME[2015-05-02 11:35:50 +09:00]] 版) [191] [CITE@en[Moving t.co to HTTPS only for new links - Announcements - Twitter Developers]] ([[]] 著, [TIME[2015-10-22 20:50:00 +09:00]] 版) [192] [CITE@en[Re: Marking HTTP As Non-Secure]] ([[Chris Palmer]] 著, [TIME[2015-11-06 05:05:07 +09:00]] 版) [193] [CITE[Marking HTTP As Non-Secure - The Chromium Projects]] ([TIME[2015-11-06 07:31:43 +09:00]] 版) [194] [CITE[TLS Everywhere, not https: URIs - Design Issues]] ([TIME[2015-03-28 06:20:30 +09:00]] 版) [195] [CITE@ja[Google ウェブマスター向け公式ブログ: HTTPS ページが優先的にインデックスに登録されるようになります]] ([TIME[2015-12-18 17:31:34 +09:00]] 版) [196] [CITE@en-US[Supporting HTTPS and HSTS on w3.org | W3C Blog]] ( ([TIME[2016-01-12 11:13:23 +09:00]] 版)) [197] [CITE@ja[DevTools へのセキュリティ パネル導入について - Google Developers Japan]] ([TIME[2016-02-23 10:16:43 +09:00]] 版) [199] [CITE@en[Fix #222: no credentials, no TLS client certificate · whatwg/fetch@bef06e1]] ([TIME[2016-03-15 11:37:07 +09:00]] 版) [202] [CITE@en[Issue 4527 - chromium - implement RFC 2817: Upgrading to TLS Within HTTP/1.1 - Monorail]] ([TIME[2016-04-18 17:25:26 +09:00]] 版) [208] [CITE@ja[WordPress.com、独自ドメインも全てHTTPS接続に - ITmedia エンタープライズ]] ( ([TIME[2016-05-11 01:13:46 +09:00]])) [209] [CITE@ja[萩原栄幸の情報セキュリティ相談室:銀行に期待した「常時SSL」 その後…… (1/2) - ITmedia エンタープライズ]] ( ([TIME[2016-05-11 01:19:07 +09:00]])) [212] [CITE@en[660749 – (CVE-2011-0082) Firefox doesn't (re)validate certificates when loading a HTTPS page from the cache]] ( ([TIME[2016-06-12 00:04:49 +09:00]])) [FIG(quote)[ [FIGCAPTION[ [213] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [214] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [215] [CITE@ja[ウェブサービス型高機能CMS「MovableType.net」追加費用不要で、常時SSL化に対応 - プレスリリース | シックス・アパート - CMSソフトウェア、サービスを提供]] ([TIME[2016-07-05 10:33:33 +09:00]]) ]FIGCAPTION] > 常時SSL化は、MovableType.net の標準のドメインである *.movabletype.io はもちろん、独自ドメインで運用しているサイトにも追加費用不要で適用されます。標準ドメインのサイトではサービス共通のSSL証明書を利用し、独自ドメインサイトでは、非営利団体ISRGが提供する無料でSSL/TLS証明書を発行するサービス「Let's Encrypt」のドメイン認証型SSL証明書を利用します。SSL証明書の更新は、シックス・アパートが行うため、お客様は面倒なSSL証明書の更新作業を行うことなしに、常時SSL化の機能を利用し続けることができます。 ]FIG] [218] [CITE@en[rename acceptSslCerts to acceptInsecureCerts]] ([[andreastt]]著, [TIME[2016-11-02 02:45:54 +09:00]]) [219] [CITE@en[rename acceptSslCerts to acceptInsecureCerts]] ([[andreastt]]著, [TIME[2016-11-02 02:45:54 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [220] [CITE@ja[HTTPSを利用する一部のサイトで、タイトルなどが取得できるようになりました - はてなブックマーク開発ブログ]] ([TIME[2016-12-07 17:14:13 +09:00]]) ]FIGCAPTION] > TLSを用いたHTTPS通信を必要とする一部サイトのURLに対して、はてなブックマークからの情報取得(クロール)が失敗していたことが主な原因です。 ]FIG] [221] [CITE@ja[HTTPSを利用できるニュースサイトは105サイト中29% | スラド セキュリティ]] ([TIME[2016-12-18 11:36:22 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [222] [CITE@en[RFC 8006 - Content Delivery Network Interconnection (CDNI) Metadata]] ([TIME[2016-12-14 14:55:04 +09:00]]) ]FIGCAPTION] > | https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, | > | | | | RFC 2818 | ]FIG] [FIG(quote)[ [FIGCAPTION[ [223] [CITE@en[Web Annotation Protocol]] ([TIME[2017-02-24 02:14:26 +09:00]]) ]FIGCAPTION] > Implementations should use HTTPS rather than HTTP for all interactions with Annotation Containers. > ]FIG] [FIG(quote)[ [FIGCAPTION[ [224] [CITE@en[RFC 8040 - RESTCONF Protocol]] ([TIME[2017-03-27 23:03:09 +09:00]]) ]FIGCAPTION] > 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''']'''. ]FIG] [FIG(quote)[ [FIGCAPTION[ [225] [CITE@en[RFC 8040 - RESTCONF Protocol]] ([TIME[2017-03-27 23:03:09 +09:00]]) ]FIGCAPTION] > 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''']'''. ]FIG] [FIG(quote)[ [FIGCAPTION[ [226] [CITE[PWG 5100.13 – IPP: Job and Printer Extensions – Set 3]] ( ([TIME[2012-07-28 08:38:41 +09:00]])) ]FIGCAPTION] > 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]. ]FIG] [FIG(quote)[ [FIGCAPTION[ [229] [CITE@en[RFC 4791 - Calendaring Extensions to WebDAV (CalDAV)]] ([TIME[2017-09-24 16:22:36 +09:00]]) ]FIGCAPTION] > o MUST support transport over TLS '''['''RFC2246''']''' as defined in '''['''RFC2818''']''' > (note that '''['''RFC2246''']''' has been obsoleted by '''['''RFC4346''']'''); ]FIG] [230] [CITE[Qualys SSL Labs - Projects / SSL Client Test]] ([TIME[2018-01-30 17:49:13 +09:00]])