[6] SSL あるいは TLS 上で HTTP を用いる通信、あるいはそのプロトコル (の組み合わせ方) のことを HTTP/SSL、HTTP/TLS、あるいは HTTPS と呼びます。
[96] TLS 上での HTTP の利用方法について、統一的な呼称はありません。
URL scheme から https ないし HTTPS
と呼ぶのが最も一般的なようです。
[97] HTTPS が何の略であるかについては、解釈が揺れており明らかではありません >>83。 省略形ではなく1つの単語と解するのが適切かもしれません。
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 の間に説明文が書き換わっていますが、 この中間の登録簿が残っていないためどの時点で誰が変更したのかは不明です。
https 443/tcp https MCom
https 443/udp https MCom
# Kipp E.B. Hickman <kipp@mcom.com>
https 443/tcp http protocol over TLS/SSL
https 443/udp http protocol over TLS/SSL
# Kipp E.B. Hickman <kipp@mcom.com>
https 443/tcp http protocol over TLS/SSL
https 443/udp http protocol over TLS/SSL
# Kipp E.B. Hickman <kipp@mcom.com>
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」と説明されているようです。
https Hypertext Transfer Protocol Secure [RFC2818]
https | Hypertext Transfer Protocol Secure | Section 2.7.2
https Hypertext Transfer Protocol Secure [RFC7230, Section 2.7.2]
Secure Hypertext Transfer Protocol (HTTPS)
[24] HTTPS による通信は、 TCP のかわりに TLS over TCP を使うことや URL scheme が違うことを除けば、素の HTTP と同じです >>45。
[76] 単一の TCP/IP の末端対末端通信上で TLS を使うのが RFC
で規定されている HTTPS ですが、実際には TCP/IP 以外に
HTTP CONNECT、SOCKS、Unix domain socket
などのトンネルが下位層のホップとして用いられていることもあります。
[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。
[134] HTTP/2 over TLS/1.2 の再折衝は、無効としなければなりません。
接続エラー PROTOCOL_ERROR としなければなりません。 >>128
[136] ただしクライアント証明書の機密性保持のために再折衝を使うことはできます。 再折衝は接続序文の送信の前に行わなければなりません。 サーバーは、接続の確立の直後に再折衝要求があったら、 クライアント証明書を要求するべきです。 >>128
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。
[227] Opportunistic Security for HTTP/2 は、 HTTP/2 over TLS
を http: URL の要求と応答の送受信に使うものです。
https: URL の場合とは若干の違いがあります。
[46] クライアントは、鯖の適切なポートへの接続を初期化してから、
TLSハンドシェイクを始める TLS ClientHello メッセージを送信するべきです。
>>45
[111] クライアントは、接続先が DNSホスト名なら、 ClientHello
に SNI を含める必要があります。 HTTPS の実装は、 SNI
に対応しなければなりません >>159。 WebSocket >>80 や
HTTP/2 >>128 の場合は、 SNI
を使わなければなりません。 HTTP/2 TLS 実装は SNI
に対応しなければなりません >>128。
[112] クライアントとサーバーは、互いの証明書を検査する必要があります (後述)。
[81] WebSocket over TLS (wss:) でも、
本節のようにしなければなりません >>80。
[164] TLSハンドシェイクは、成功裏に完了するか、失敗するかのいずれかです。 失敗した場合は、 HTTP の処理を続けることはできません。なお成功の場合でも、 (fatal ではない) TLS error alert を受信しているかもしれません。
[165] HSTS や PKP が適用されるホストでは、 (エラーのレベルに関わらず) エラーがあれば接続を失敗として閉じなければなりません >>161, >>162。
[163] TLSハンドシェイクが完了したら、データの送受信 (>>47) を開始できます。
[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 が出典となっています。
[145] HTTP/2 の実装は、 ALPN を使わなければなりません >>144。
[124] HTTP/2クライアントが https: URL
に接続する時は、 ALPN でプロトコル識別子 h2
を使います >>107。
[125] ALPN の IANA登録簿には、 h2c も登録されています。
これは HTTP/2 over TLS を表しています。クライアントは、この値を送ってはなりません。
サーバーは、このプロトコルを選択してはなりません。 >>107
spdy/1, spdy/2, spdy/3 も登録されています。
また HTTP/2 の過去の版では h2-11 のような暫定的な値を使っていました。
古い実装はこうした値に対応しているかもしれませんが、近いうちに削除されると思われます。[154] HTTP の版の選択については、プロトコルの版を参照。
[127] 利用者エージェントが送信するプロトコルの値は、fingerprinting vector です。
[180] Firefox は、 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 の検証を行わなければなりません。
[116] 利用者エージェントは、証明書の誤りを利用者に報告するべきです。 利用者エージェントは、誤った証明書により送られた資源のダウンロードを拒むか、 または暗号化されずに送られた場合のように動作するかのいずれかとしなければなりません。 >>115
[118] 自己署名証明書が使われていた場合、暗号化されていなかったものとして扱うことができます。(利用者に警告して利用者の判断においてであっても) 通常通りに表示してしまうと、 利用者を騙して MITM を受け入れさせてしまうかもしれません。 >>115
[117] 利用者エージェントは、あるページに再訪した時に前より暗号化が安全で無くなっている場合に、 利用者に問題があるかもしれないと警告するべきです。 MITM攻撃の虞があります。 >>115
[160] クライアントは、 PKP を実装する場合、 PKP の検査を行う必要があります。 検査に失敗した場合は、接続を閉じることになります。報告を送信する場合もあります。
[131] HTTP/2 で接続を再利用する際には、接続確立時と同様に要求のホストを証明書に対して検証しなければならないことになっています。
[216] WebDriver には、自己証明証明書や信頼できない証明書を受け入れることを指定する
acceptSslCerts オプションがあります。ただし、「信頼できない証明書」
の具体的な範囲は規定されていません。おそらくは、利用者が画面から手動で受け入れることを選択できるものと同等の機能が提供されることが期待されています。
[217] wget や curl のような Webブラウザー以外の利用者エージェントにも、
証明書の検証を飛ばしたり、結果を無視したりするオプションが用意されていることがよくあります。
残念ながら、実用上はこのようなオプションが不可欠かもしれません。
[232]
Chrome は www. つきドメインが SI 検証エラーになるとき、
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 でも同じ挙動になります。
[64] 鯖は普通はクライアントの identity がどうであるべきか (どのような証明書を有しているべきか) についての外部情報を有していませんから、 クライアントについて検査することはできません。 >>51
[65] 鯖がそのような外部情報を有している場合には、 鯖の証明書の検査と同様の identity の検査を行うべきです。 >>51
[228] Opportunistic Security for HTTP/2 ではクライアント認証を行わないことになっています。 Opportunistic Security for HTTP/2 参照。
[204] TLS接続の確立でエラー (TLS のエラー、認証のエラー、 エラーとして扱うべき警告、エラーとして扱うべき古い TLS の版、 エラーとして扱うべき弱い cipher suite など) が検出された場合、 ネットワークエラーとする >>203 ことになっています。
[205] そうでない場合、 HTTP-network fetch が返す応答において、
HTTPS状態を modern または deprecated のいずれかに設定することになっています
>>203。
[206] どちらにするかは、利用者エージェントの基準で決めることができます >>203。
廃止予定で移行期間中にある弱い cipher suite などの場合は deprecated
を使い、そうでない場合は modern を使うことが期待されています。
[207] かつては、エラーがあった場合でも (エラーの種別にもよりますが) 利用者の指示により一時的にネットワークエラーとせずに処理を続行させることができる実装が一般的でした。 現在でも一部そのような機能が残っている Webブラウザーもありますし、 認証の一部を省略するオプションを用意しているクライアントのプログラムやライブラリーも広く流通しています。 しかしながら、 (悪意の有無はともかく) 利用者に十分な理解をさせずにセキュリティー的に問題のあるそうした操作を強いる Webサイトが増えて激しく非難されたこともありました。 こうしたオプションは廃止したり、一般の利用者が使いにくくしたりする流れとなってきています。
[47] HTTP のデータは、 TLS応用データとして送信しなければなりません >>45。
[58] TLS応用データとして送受信される HTTP接続上の HTTP要求や HTTP応答の処理は、基本的には TCP 上の HTTP の場合と同じです。
[152] HTTP/1.1 以下では、 TLS handshake の完了後、すぐに通常の HTTP の要求や応答を送受信できる状態となります。
[153] HTTP/2 では、 TLS handshake の完了後、 まず接続序文の送受信を行わなければなりません >>107, >>144。
[56] HSTS や PKP の処理は、 TLS レベルで誤りや警告があった時には行わないことになっています。
[178] 接続中にクライアント認証を目的とした再折衝が行われることがあります。
[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) できるべきです。 >>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 仕様はその後改訂されていないのですが、 変更の趣旨を考えると、セッション再利用の禁止は失効していると考えるべきでしょう。
[9] HTTPS の URL scheme は https: です。
https: を参照。[210] HTTPS プロトコルとしてのポート番号の制限はありません。
[49] HTTP/TLS/TCP/IP の既定のポートは、 443 です >>45。
[231] HTTP Web Push は 1001 をも使っています。
[200] 素のHTTPとHTTPSとで、 HTTP プロトコルやそれを通じてやり取りされる文書の処理で、 異なる動作が求められることがあります。
HTTPS1 だったり ON だったり on だったり、空文字列あるいは値未設定だったり OFF だったり off だったり色々のようです。そもそもこのメタ変数を実装していないサーバーもあります。iPlanet-WebServer-Enterprise/4.1 は ON / OFF らしいです。SERVER_PORT_SECURE が参考になるかもしれません。[7] CGI (RFC 3875) の規定により、プロトコルと URL scheme が異なる時に
URL scheme と同名のメタ変数を定義してよいとされており、メタ変数
HTTPS がこれに合致します。
[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 とすることもできるかもしれませんが、 そのような使い方も一般的ではありません。
[173] ブラウザー拡張の類で、閲覧中のページの URL を自動的に送信するもの
(例えばソーシャルブックマークサービスで、サービスのサーバーから URL
に関する情報を自動的に取得するもの) の中には、プライバシーへの配慮から、
https: URL は既定では自動的な取得対象から除外する設定になっていることもありました。
[176] Web Security Context 仕様書に表示に関する規定があります。
[43] HTTPS は SSL の開発者である Netscape が最初に実装しました。
[52] SSL/2.0 および SSL/3.0 には、 HTTP over SSL (https) 用に
443 番ポートが IANA に登録されている旨の記載がありました。
Upgrade: TLS/1.0 (RFC 2817)[15] Netscape によって SSL と同時に実装された現在の HTTPS の他にも、 SSL と HTTP を組み合わせる方法はいくつか提案されていました。 しかし結局いずれも広く実装されるには至りませんでした。
[20] RFC 2817 は、平文の HTTP で Upgrade: TLS/1.0
と指定することで HTTP over TLS に切り替える >>16 ことを提案していました。
その場合は 101 応答を返してから、
TLS による通信に切り替わることになっていました >>16。
[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 の立場のようです。)
[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 は存在していたのですから、 実は大きな利点とは言えない気がします。)
[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 が極めて普及している現実を無視することに意味があるとは思えません。
[151] RFC 2818 は HTTP/1.1 の改訂版である RFC 723x により更新されていますが、
これは https: URL の定義に関するものです。
それ以外の点は RFC 2818 が参照されています。
[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
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
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
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.
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.
常時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
TLSを用いたHTTPS通信を必要とする一部サイトのURLに対して、はてなブックマークからの情報取得(クロール)が失敗していたことが主な原因です。
[221] HTTPSを利用できるニュースサイトは105サイト中29% | スラド セキュリティ () https://security.srad.jp/story/16/12/16/2355245/
| https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, |
| | | | RFC 2818 |
Implementations should use HTTPS rather than HTTP for all interactions with Annotation Containers.
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].
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].
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].
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
https:も合わせて参照してください。