SSL

TLS (インターネット)

[38] TLS (旧 SSL) は、TCP の上、 アプリケーション層プロトコルの下で動作する安全な輸送路を提供するプロトコルです。

[134] HTTP をはじめとするインターネット上の様々なアプリケーション層プロトコルと併用されています。

[135] 1994年に Netscape によって開発され、当初は SSL と称していました。 後に IETF に移管され TLS と改称されました。現在は最新の TLS 1.2 (と TLS 1.1TLS 1.0) が用いられています。 TLS 1.3 も開発中です。

仕様書

プロトコル

[106] TLS は、 TCP などの下位層の接続の上で動作する TLS Record Protocol と、更にその上で動作する TLS Handshake Protocol で構成されます >>105

[107] TLS は単体で用いられるプロトコルではなく、 上位層アプリケーション層プロトコルセキュリティー機能を提供するものです。 TLS Handshake Protocol による所定の手続きの後、 アプリケーション層プロトコルによる送受信が TLS 上で行われます。 TLS handshake を開始するかどうかの決定方法や、 TLS によって交換された証明書をどう解釈するかは、 TLS 本体仕様の範囲外で、 上位層プロトコルやその実装により決定されるべきものであるとされています >>105

[111] 例えば上位層プロトコルである HTTP では、 サーバー証明書クライアントが検査することが規定されています (HTTPSservice identity を参照)。

[112] TLS を構成する部分プロトコルは、より細かくは次のように分解できます。

[109] その他 TLS には次のような機能やプロトコル要素があります。

[123] TLS は、上位層プロトコルに対して保安輸送路を提供するものです。

[166] TLS を構成する各プロトコルは、 TLS 仕様上のデータ構造をバイト列として表現して送受信するものです。 仕様書では、 C 風の表記法を使って説明されています。

[167] データ構造 (struct) は、いくつかの (field) の順序のある列に名前を与えたものです。 欄は、名前が与えられており、値のが規定されています。 値の固定長のものもあれば、可変長ベクトルもあります。 固定長の値は、そのままのバイト列で表現されます。 可変長の値は、実際の値の長さを表す数値の後に実際の値のバイト列となります。 可変長ベクトルは最小と最大の長さが規定されており、 長さの数値は最大の長さを表現可能な数値型で表されます。 >>165

[168] つまり、データ構造全体のバイト列の長さは、読んでみるまでわからないかもしれません。 またデータ構造によっては前の方のの値により後の方のの有無が条件分岐することもあります。
[169] データ構造の名前やの名前は仕様上のもので、 実際のプロトコル上のデータには現れません。

TLS/SSL の版

[14] TLS は1994年以来脆弱性の修正などで改善を続けており、 次の各版があります。各版は互いに区別可能ですが、互換性はないそれぞれ独立したプロトコルです (異なる版の実装が通信することはできません)。

  1. [19] SSL 1.0 (1994)
  2. [20] SSL 2.0 (1995)
  3. [21] PCT 1.0 (1995)
  4. [22] SSL 3.0 (1996)
  5. [23] TLS 1.0 = RFC 2246 (1999)
  6. TLS 1.1 = RFC 4346
  7. TLS 1.2 = RFC 5246
  8. TLS 1.3

[96] SSLNetscape が開発し、同社サイトおよび Internet Draft として出版しています (SSL/1.0Netscape 社内のみだった模様)。 PCTMicrosoft が開発し、 Internet Draft として出版しています。 TLSIETF (ietf-tls) が開発し、 RFC として出版しています。

[30] SSL 3.0 までは脆弱性のため廃止されています。 SSL 2.0SSL 3.0 を使ってはなりません >>153, >>161TLS 1.0TLS 1.1 はまだ安全と考えられていますが、積極的に使う理由はありません。 TLS 1.0TLS 1.1 は、それより新しい版が使えない場合を除き、 使うよう折衝するべきではありません >>153

[124] Webプロトコルマーク付け言語後方互換性を最重要視して開発されていますが、 TLSセキュリティーに関わる機能であり、例外的に非互換変更が許容されています。

[156] 実装は TLS 1.2 に対応しなければなりません折衝時は TLS 1.2 を以前の版より優先させなければなりません>>153

[207] つまり SSL はすべて廃止済みで既に用いられていないのですが、 TLS よりも SSL の方が馴染み深く TLS だと通じないこともあるため、 敢えて併記したりすることが今後も続きそうです。

[208] 既に浸透していたプロトコル名を変えることも無かったと思うのですが、 外部から提出されたプロトコルの名前や用語やプロトコル自体を好き放題に改変するのは IETF のお家芸なので仕方なかったのでしょうし、今更変えるのも難しそうです。

[155] TLS とは別に、 UDP で用いる DTLS があります。

[152] DTLS 1.0TLS 1.1DTLS 1.2TLS 1.2 に相当します >>153

TLS 拡張

[130] TLS 拡張 (extension) >>128 は、当初の SSL 仕様に含まれていなかった機能です。 拡張と呼ばれてはいますが、そのうちのいくつかは必須、または実質的に必須となっています。

[131] TLS Handshake ProtocolClientHelloServerHello には、 TLS の拡張仕様に基づくデータを含めることができます。

[132] 証明書拡張とは関係ありません。

[133] TLS 拡張については、IANA登録簿 >>129 があります。

[149] 次のような TLS拡張があります。

c
数値
n
識別子
desc
名称
impl
実装
desc
SNI
c
0
impl
Firefox, Chrome, IE
c
13172
n
next_protocol_negotiation
desc
NPN
impl
Firefox, Chrome
desc
ALPN
c
16
impl
Firefox, Chrome
c
30032
n
channel_id
desc
TLS-OBC
impl
Chrome
desc
TLSA
desc
TLS False Start
c
65281
n
renegotiation_info
impl
Firefox, IE
desc
TLS renegotiation
desc
OCSP stapling
c
5
n
status_request
impl
Firefox, Chrome, IE
n
max_fragment_length
n
CertificateURL
n
trusted_ca_keys
c
13
n
signature_algorithms
impl
Firefox, Chrome
c
10
n
supported_groups
impl
Firefox, Chrome, IE
c
11
n
ec_point_formats
impl
Firefox, Chrome, IE
n
truncated_hmac
c
35
n
SessionTicket
desc
セッション再開 (session ticket)
impl
Firefox, Chrome
n
signed_certificate_timestamp
c
18
impl
Chrome
n
SCT
n
extended_master_secret
c
23
impl
Chrome
c
21
n
padding
impl
Chrome
c
12
n
srp
c
15
n
heartbeat
impl
OpenSSL

[231] TLS証明書で使われる証明書拡張とは別なので注意。

下位層プロトコル

[90] TLS は、 TCP/IP 上で用います。

[91] HTTP CONNECTSOCKSUnix domain socketEAP-TTLS のようなトンネル等のプロトコルの接続が下位層輸送路の一部または全部として用いられることもあります。

[92] TCP 緊急データの取り扱いは明文化されていません。

[171] ChromeFirefox緊急データを無視するようです。 IE は無視しないようです (ただちにエラーとするのか、 周りのデータと区別せずに処理するのかは不明)。

[158] 下位層で意図的または障害等により接続が閉じられた際の TLS 実装の行うべき処理は不明です。

上位層プロトコル

[54] アプリケーション層プロトコルによって TLS の使い方はいくつかの種類があります。

[55] 次のプロトコルTCP のかわりに TLS over TCP を使います。

[56] 次のプロトコルSTARTTLS やそれに類する仕組みでプロトコル内で平文から TLS に切り替えます。

[67] IETFTLS over TCP で別のポートを割り当てる方法は好ましくない >>66 と考えているようです。1997年12月の IETF 会議で Applications Area DirectorsIESG により、 別のポートを発行することを非推奨とするべきと再確認しました >>12。 以後の IETFプロトコルSTARTTLS やそれに類する方式で途中で平文から TLS に切り替えるようになっています。

[69] しかしそれ以前から別のポートを割り当てて使うのが一般的になっていた HTTP/HTTPS については、その後も別々のポートが使われています。 IETF はその決定の後2年経過しても Web では新方式に移行できていないとして、 従来の HTTPS 方式を情報提供RFC (RFC 2818)、 Upgrade: ヘッダーを使って平文から TLS に切り替える方式を提案標準 (RFC 2817) として出版し、IPP など新しい応用は後者を使うべき >>12 としました。結局前者の方式が生き残り、 後者は有名無実化しています。

[115] TLS を使うアプリケーションプロトコルは、次のような事項を規定する必要があります。

[176] TLS の実装は、アプリケーションに対して次の情報を提供する必要があります。

TLS プロトコルの版
アプリケーションは結果に応じて接続を拒否したり (例: HTTP/2)、非安全なものとして扱ったり、利用者に情報を表示したりできます。
折衝結果の cipher suite
アプリケーションは結果に応じて接続を拒否したり (例: HTTP/2)、非安全なものとして扱ったり (例: Fetch)、 利用者に情報を表示したりできます。鍵長その他の引数も必要です。
error alert
少なくても受信した事実を知らせる必要があります。 アプリケーションはそれにより挙動を変えることがあります (例: HSTS)。
証明書
相手の証明書 (とあれば中間証明書) を知らせる必要があります。
SNI ホスト名
サーバーでは、 SNIホスト名の指定があれば、 それを使いたいかもしれません。
ALPN プロトコル
ALPN によりプロトコルが折衝されていれば、 それを知らせる必要があります。

[39] Web では TLS 関連の次のような機能があります。

URL scheme

[36] SSLTLS を使う場合の URL は、使わない場合の URL scheme の末尾に s を付け足すのが慣例となっています。

[37] 例えば、 HTTPURL schemehttp: ですが、 HTTPTLS を組み合わせる場合の URL schemehttps: です。

[216] mongodb: は、 queryssl=true / ssl=false (既定値) と記述することで TLS の利用の有無を指定します。

実装

[151] TLS の実装は多数あります。 Unix 系の環境で動作するソフトウェアやオープンソースソフトウェアの多くは OpenSSL を使っています。

[227] TLS の実装

[136] TLS 関連 API ドキュメント:

関連団体

互換性リスト

[71] mozilla-aurora: security/manager/ssl/src/IntolerantFallbackList.inc@e8f0fd3fbd3b ( 版) https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/src/IntolerantFallbackList.inc

[72] 1133187 – Fallback whitelist update: mid-February 2015 ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1133187

歴史

SSL 1.0

[87] SSL/1.0 は1994年に Netscape 社内で開発されて、公開されていないと言われています。

SSL 2.0

[80] 次の版が存在したようです >>79, >>73

PCT 1.0

[95] IE が実装していました。

SSL 3.0

[76] SSL Version 3.0 ( 版) http://web.archive.org/web/19970709162834/http://home.netscape.com/newsref/std/SSL.html

Netscape expects to ship products that conform to the March specification. Please note that Netscape server products with SSL V3.0 support both SSL 2.0 and SSL 3.0 protocols (SSL 3.0 was designed to allow this for transition purposes). SSL 2.0 has a limited lifetime.

[77] Netscape SSLRef 2.0 ( 版) http://web.archive.org/web/19970709162841/http://home.netscape.com/newsref/std/sslref.html

SSLRef is a reference implementation from Netscape Communications of the SSL protocol. Available now and free for noncommercial use, SSLRef is intended to aid and accelerate developers' efforts to provide advanced security within TCP/IP applications using the SSL (Secure Sockets Layer) protocol. Netscape SSLRef consists of a software library distributed in ANSI C source-code form that can be compiled on a wide variety of platforms and operating systems and linked into any TCP/IP application program.

TLS

XXX

SSL 2.0 の廃止

[192] SSL 3.0 が実装されてすぐに消滅すると思われた SSL 2.0 は、結局その後もずるずると使われ続けてしまいます。

[193] 00年代半ば頃になってようやく SSL 2.0 の実装からの削除が始まりました。 には IETF から RFC 6176 が出版され、 SSL 2.0 の利用禁止が明文化されました。

[194] これを根拠に SSL 2.0廃止されたという人もいますが、 正確な表現ではありません。 SSL 3.0 が発表された95年末ないし96年に改訂により事実上廃止されたともいえますが、 その後数年 SSL 2.0 の実装が残り続けたことを考えると、それもまた不正確な表現かもしれません。

SSL 3.0 の廃止

[196] TLS 1.0TLS 1.1TLS 1.2 の出版後も、 SSL 3.0 は古くて相対的に安全性の低いものとなったとはいえ、 危険ではないと認識されていました。ガラケーや古い IE のような更新されない実装が TLS 1.0 に対応していなかったため、 SSL 3.0 は引き続き広く使われていました。

[197] ところが2014年に POODLE 脆弱性が発見され、 ついに SSL 3.0 は危険であると判明しました。 これをきっかけに急速に SSL 3.0 への対応は打ち切られてゆき、 TLS 1.0 以上への移行が進みました。

[163] 2015年6月に出版された RFC 7568 は、 SSL 3.0 を使ってはならないと規定しています。禁止しているのになぜか非推奨と称しており、 廃止ではありません。 SSL 3.0RFC である RFC 6101廃止はされていませんが、これは元々 Historic で発行されたものなので廃止は必要ないという判断なのでしょうか。

[195] IETF の文書が論理性を欠くのは通常営業なので、 あまり細かいことを詮索しても仕方がないかもしれません。

利用の指針

[154] BCP 195 (RFC 7525) >>153 は、 2015年時点の TLSDTLS の利用に関する推奨事項を規定しています。

[183] HTTP/2TLS の利用に関してかなり踏み込んだ規定を含んでいます。 2015年時点で報告されている脆弱性などを踏まえて利用できる TLS の機能や cipher suite などに様々な制限を加えています。

TLS 1.3

[182] TLS 1.2 の改訂版として TLS 1.3IETF で開発されています。

関連

[40] DTLSTLS から派生したプロトコルですが、 TCP ではなく UDP の上で動作します。

プロトコル要素に共通性はありますが、異なるプロトコルです。

[57] SSLSSH は関係ありません。

メモ

[18] SSLの使い方 http://pc2.2ch.net/test/read.cgi/php/1016169881/

[24] 現在は SSL/3.0 が主流らしい。

[25] SSL/TLS は基本的にはどんな応用層のインターネット・プロトコルとも組み合わせられるみたいですが、よく使われるのは HTTP, POP, IMAP, NNTP, FTP 辺りです。

[27] 10 years of SSL in Opera - Implementer's notes - by Yngve Nysæter Pettersen ( 版) http://my.opera.com/yngve/blog/2007/04/30/10-years-of-ssl-in-opera (名無しさん 2007-05-01 01:50:56 +00:00)

[28] SSL は無理矢理 OSI参照モデルに合わせてセッション層プロトコルと説明されることもありますが、 実態としては (TCP と組み合わせて成立する) トランスポート層プロトコルと説明する方が正しいと思います。

[29] 作ろうiモードコンテンツ:その他注意点 | サービス・機能 | NTTドコモ ( 版) http://www.nttdocomo.co.jp/service/imode/make/content/ssl/notice/index.html

[31] Geekなぺーじ : イランからGoogleへのSSL通信が傍受されていた疑い。CAから発行された偽証明書が原因 ( 版) http://www.geekpage.jp/blog/?id=2011/8/31/1

[32] DigiNotar偽SSL証明書事件、「twitter.com」などにも拡大、全貌は未だ不明 -INTERNET Watch ( ( 版)) http://internet.watch.impress.co.jp/docs/news/20110906_475443.html

[33] Microsoft、不正SSL証明書問題に対処 Firefoxは再度更新 - ITmedia エンタープライズ ( ( 版)) http://www.itmedia.co.jp/enterprise/articles/1109/07/news017.html

[34] Certificate Authorities struggle to comply with Baseline Requirements | Netcraft ( ( 版)) http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html

[1] スラッシュドット ジャパン | ApacheがSSLサーバのシェアでIISに追いついた? http://slashdot.jp/articles/06/04/30/1530241.shtml (名無しさん 2006-05-01 12:29:50 +00:00)

[2] SMTP/TLS RFC 2487

HTTP/TLS RFC 2817

FTP/TLS RFC 4217 (名無しさん [sage])

[3] IMAP STARTTLS RFC 2595 (名無しさん)

[4] POP3 STLS RFC 2595 (名無しさん)

[5] ACAP STARTTLS RFC 2595 (名無しさん)

[6] SMTP STARTTLS RFC 3207 (名無しさん)

[7] RFC 3588 (名無しさん)

[8] COPS/TLS RFC 4261 (名無しさん)

[9] NNTP/TLS RFC 4642 (名無しさん 2006-10-26 23:34:01 +00:00)

[10] yebo blog: FSFがTLS Authorization ExtentionsのIETF標準化に反対 ( 版) http://yebo-blog.blogspot.com/2009/02/fsftls-authorization-extentionsietf.html

[11] SSL - Dovecot Wiki ( 版) http://wiki.dovecot.org/SSL

[13] Web Security Context: User Interface Guidelines ( 版) http://www.w3.org/TR/2010/REC-wsc-ui-20100812/

[15] なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 ( ( 版)) http://d.hatena.ne.jp/tkng/20130108/1357610340

[16] RFC 6066 - Transport Layer Security (TLS) Extensions: Extension Definitions ( ( 版)) http://tools.ietf.org/html/rfc6066

[17] RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) ( ( 版)) https://tools.ietf.org/html/rfc6125

[41] HTTPS - IndieWebCamp ( ( 版)) https://indiewebcamp.com/HTTPS#Why

[42] Free SSL Certificate for Open Source Projects ( ( 版)) https://www.globalsign.com/ssl/ssl-open-source/

[43] RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 ( ( 版)) http://tools.ietf.org/html/rfc5246

[44] RFC 7250 - Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ( ( 版)) http://tools.ietf.org/html/rfc7250

[45] Adoption of TLS Extensions ( (Paul Querna 著, 版)) https://journal.paul.querna.org/articles/2012/09/07/adoption-of-tls-extensions/

[46] RFC 5746 - Transport Layer Security (TLS) Renegotiation Indication Extension ( ( 版)) http://tools.ietf.org/html/rfc5746

[47] Introducing Universal SSL ( ( 版)) https://blog.cloudflare.com/introducing-universal-ssl/

[48] Qualys SSL Labs - Projects / SSL Server Test ( ( 版)) https://www.ssllabs.com/ssltest/index.html

[49] MySQL :: MySQL Internals Manual :: 14.5 SSL ( ( 版)) http://dev.mysql.com/doc/internals/en/ssl.html

[50] Security/Server Side TLS - MozillaWiki ( ( 版)) https://wiki.mozilla.org/Security/Server_Side_TLS

[53] Issue 244260 - chromium - Security: TLS Truncation attack on HTTP headers, including cookie flags - An open-source project to help move the web forward. - Google Project Hosting ( ( 版)) https://code.google.com/p/chromium/issues/detail?id=244260

[58] TLS: browser UI — Anne’s Blog ( ( 版)) https://annevankesteren.nl/2014/10/tls-browser-ui

[60] RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) ( ( 版)) http://tools.ietf.org/html/rfc6125

[61] draft-balfanz-tls-channelid-01 - Transport Layer Security (TLS) Channel IDs ( ( 版)) http://tools.ietf.org/html/draft-balfanz-tls-channelid-01

[62] draft-reschke-objsec-01 - A Rationale for Fine-grained Intermediary-aware End-to-End Protocols ( ( 版)) https://tools.ietf.org/html/draft-reschke-objsec-01

[64] Qualys SSL Labs - Projects / SSL Server Test ( ( 版)) https://www.ssllabs.com/ssltest/index.html

[68] RFC 6749 - The OAuth 2.0 Authorization Framework ( 版) http://tools.ietf.org/html/rfc6749#section-1.6

[78] Motoda's - Information about SSL ( 版) http://web.archive.org/web/19990203185646/http://robin.sl.cae.ntt.co.jp/~motoda/SSL/

[82] <ねこだま> SSL関連情報のページ ( 版) http://nekodama.com/SSL/

[70] マイクロソフト セキュリティ アドバイザリ 3046015 ( 版) https://technet.microsoft.com/ja-jp/library/security/3046015

[97] Transport Layer Security - Wikipedia ( 版) http://ja.wikipedia.org/wiki/Transport_Layer_Security

[101] Transport Layer Security - Wikipedia ( 版) http://ja.wikipedia.org/wiki/Transport_Layer_Security

ポート番号を分ける方式をSSL、同一ポート番号で切替える方式(STARTTLS方式)をTLSと呼んでいる実装もある[21]

[102] TLS のひみつ : 迷惑メール対策委員会 ( 版) http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/tls-arc/

[103] SSL Protocol ( 版) http://sehermitage.web.fc2.com/crypto/ssl_protocol.html

[104] PKI関連技術に関するコンテンツ ( 版) https://www.ipa.go.jp/security/pki/071.html

[108] RFC 7457 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) ( 版) https://tools.ietf.org/html/rfc7457

[125] 日本政府機関Webサイト(.go.jp)のTLS対応状況について | Advanced Web Application Laboratory, Keio University ( 版) https://awa.sfc.keio.ac.jp/2015/03/04/survey-of-supporting-tls-at-japanese-governemnts-website/

[126] 自堕落な技術者の日記 : go.jpドメインのHTTPSサイトの状況について私もみてみました(2015年3月4日時点) - livedoor Blog(ブログ) ( 版) http://blog.livedoor.jp/k_urushima/archives/1763144.html

[127] Trustworthy Internet Movement - SSL Pulse ( 版) https://www.trustworthyinternet.org/ssl-pulse/

[147] ニュース - 米RSAがSSL関連特許訴訟でLeon Stambler氏に勝訴。「同氏の特許は侵害されていない」:ITpro ( 版) http://itpro.nikkeibp.co.jp/free/ITPro/USNEWS/20030314/8/

[148] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) ( 版) https://tools.ietf.org/html/rfc7540#section-9.2

Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only

support and use the SNI extension

[150] RFC 7457 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) ( 版) https://tools.ietf.org/html/rfc7457

[159] Transport Layer Security (TLS) Extensions ( 版) http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

21 padding (TEMPORARY - registered 2014-03-12, expires 2016-03-12) [draft-ietf-tls-padding]

23 extended_master_secret (TEMPORARY - registered 2014-09-26, expires 2015-09-26) [draft-ietf-tls-session-hash]

[160] RFC 7250 - Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ( 版) http://tools.ietf.org/html/rfc7250

[164] 「Yahoo!検索」SSL化のお知らせ - Yahoo!検索ガイド - Yahoo! JAPAN ( 版) http://promo.search.yahoo.co.jp/news/service/SSL.html

[170] Compare TLS Extensions for Web Browsers ( 版) http://www.vimino.com/2011/07/compare-tls-extensions-for-web-browsers/

[172] HTTPS and Keep-Alive Connections - IEInternals - Site Home - MSDN Blogs ( 版) http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx

Internet Explorer 1.0 didn’t even support SSL at all (SSL was added in 2.0)

[173] 861266 – Implement TLS 1.2 (RFC 5246) in Gecko (Firefox, Thunderbird), on by default ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=861266

[174] draft-agl-tls-snapstart-00 - Transport Layer Security (TLS) Snap Start ( 版) http://tools.ietf.org/html/draft-agl-tls-snapstart-00

[175] Web Security Context: User Interface Guidelines ( 版) http://www.w3.org/TR/wsc-ui/#sec-tlserrors

[177] 各ブラウザの TLS ClientHello - What I’ve found has never been enough@Hatena ( 版) http://d.hatena.ne.jp/nappa_zzz/20111127/1322339838

[178] IE の TLS ClientHello - What I’ve found has never been enough@Hatena ( 版) http://d.hatena.ne.jp/nappa_zzz/20111129/1322515367

[179] WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まっている ( 版) http://d.hatena.ne.jp/ozuma/20140413/1397397632

[180] HTTP/2から見えるTLS事情 - あどけない話 ( 版) http://d.hatena.ne.jp/kazu-yamamoto/20141219/1418976024

[181] Issue 498998 - chromium - Removing TLS 1.0 version fallback support - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=498998

[184] RFC 7633 - X.509v3 Transport Layer Security (TLS) Feature Extension ( 版) https://tools.ietf.org/html/rfc7633#section-2.2

In order to avoid the confusion that would occur in attempting to

specify an X.509 extension describing the use of TLS extensions, in

this document the term "extension" is reserved to refer to X.509v3

extensions and the term "TLS feature extension" is used to refer to

what the TLS specification [RFC5246] refers to as an "extension".

[185] News & Trend - Vistaやガラケーで買い物できない? カードセキュリティ新基準が波紋:ITpro ( 版) http://itpro.nikkeibp.co.jp/atcl/column/14/346926/110400370/

2016年7月に本格適用されるクレジットカード情報保護のセキュリティ国際基準「PCI DSS(Payment Card Industry Data Security Standard) v3.1」をめぐり、ECサイト事業者から反発の声が高まっている。一部の顧客がECサイトでクレジットカード番号を入力できなくなり、サイトの売り上げを押し下げる可能性があるためだ。

基準策定団体のPCI SSC(Payment Card Industry Security Standards Council)も、反発の声が想定外に多いことから、本誌の取材に対して「v 3.1がもたらす影響の実態調査に乗り出す」(PCI SSC インターナショナルディレクターのジェレミー・キング氏)考えを示した。

既存ECサイトでは2016年7月からSSL 3.0/TLS 1.0が使用禁止

[186] SSL3.0脆弱性への対応としてのアクセス遮断(1/20) ( 版) https://expy.jp/topics/detail/?id=191

平成28年1月20日(水)より「SSL3.0」の利用を停止させていただきます。

[187] ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記 ( 版) http://d.hatena.ne.jp/jovi0608/20160113/1452649563

[188] Generate Mozilla Security Recommended Web Server Configuration Files ( 版) https://mozilla.github.io/server-side-tls/ssl-config-generator/

[189] 弊社 WEB サイトのセキュリティー強化に伴う、お客様への影響について ( 版) https://cmypage.kuronekoyamato.co.jp/portal/20160125_information.pdf

現在、弊社が提供する WEB サイトでは、お客様の個人情報を保護するため、暗号化通信に SSL を

採用しておりますが、より安全に弊社 WEB サイトをご利用いただくため、平成 28 年 4 月 1 日より、

下記の通り、セキュリティー対策を強化することとなりましたのでお知らせいたします。

・SSL サーバー証明書のバージョンアップ(「SHA-1」から「SHA-2」へ移行)

・SSL3.0(旧バージョン)通信を遮断し、より高い暗号化方式「TLS」に切り替え

[190] よくある質問 – より安全なメール – 透明性レポート – Google ( 版) https://www.google.com/transparencyreport/saferemail/faq/?hl=ja

[191] Gmail、暗号化されていない通信でメールを受信すると警告を表示 | TechCrunch Japan (Frederic Lardinois 著, 版) http://jp.techcrunch.com/2015/11/13/20151112gmail-will-soon-warn-users-when-emails-arrive-over-unencrypted-connections/

[198] SSL3.0アクセス遮断について 平成26年11月10日(月) [12月15日(月)更新] | 奈良県立図書情報館 ( 版) http://www.library.pref.nara.jp/news/1395

[199] SSL3.0アクセス遮断について 平成26年11月10日(月) [12月15日(月)更新] | 奈良県立図書情報館 ( 版) http://www.library.pref.nara.jp/news/1395

[200] SSL3.0アクセス遮断について 平成26年11月10日(月) [12月15日(月)更新] | 奈良県立図書情報館 ( 版) http://www.library.pref.nara.jp/news/1395

[201] Internet Explorer 7 における HTTPS セキュリティの強化点 ( ()) https://msdn.microsoft.com/ja-jp/library/bb250503

[203] badssl.com ( ()) https://badssl.com/

[204] google/badssl.com: Memorable site for testing clients against bad SSL configs. ( ()) https://github.com/google/badssl.com

[205] RFC 7858 - Specification for DNS over Transport Layer Security (TLS) ( ()) https://tools.ietf.org/html/rfc7858

By default, a DNS server that supports DNS over TLS MUST listen for

and accept TCP connections on port 853, unless it has mutual

agreement with its clients to use a port other than 853 for DNS over

TLS. In order to use a port other than 853, both clients and servers

would need a configuration option in their software.

By default, a DNS client desiring privacy from DNS over TLS from a

particular server MUST establish a TCP connection to port 853 on the

server, unless it has mutual agreement with its server to use a port

other than port 853 for DNS over TLS. Such another port MUST NOT be

port 53 but MAY be from the "first-come, first-served" port range.

This recommendation against use of port 53 for DNS over TLS is to

avoid complication in selecting use or non-use of TLS and to reduce

risk of downgrade attacks. The first data exchange on this TCP

connection MUST be the client and server initiating a TLS handshake

using the procedure described in [RFC5246].

[206] Issue 338885 - chromium - Use OpenSSL instead of NSS on OS X - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=338885

[209] RFC 7924 - Transport Layer Security (TLS) Cached Information Extension () https://tools.ietf.org/html/rfc7924

[210] RFC 7925 - Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things () https://tools.ietf.org/html/rfc7925

[211] RFC 7919 - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) () https://tools.ietf.org/html/rfc7919

[212] Intent to ship: TLS 1.3 draft - Google グループ () https://groups.google.com/forum/#!topic/mozilla.dev.platform/sfeqeMkyxCI

[213] 1310516 – Enable TLS 1.3 by default () https://bugzilla.mozilla.org/show_bug.cgi?id=1310516

[214] Introducing TLS 1.3 () https://blog.cloudflare.com/introducing-tls-1-3/

[215] replace instances of ssl with tls (andreastt著, ) https://github.com/w3c/webdriver/commit/caa5c7164a945385428f30b2b0b4be4139c24e1a

[217] Change SSL references to TLS (Resolves #119) (inexorabletash著, ) https://github.com/w3c/IndexedDB/commit/1131ec760ed7f11fe4dafe5b13022fbec9edc056

[218] Yahoo! JAPANサービスは常時SSL(AOSSL)に対応します - Yahoo! JAPAN () http://docs.yahoo.co.jp/info/aossl/

HTTPS通信は、実際にはTLS(Transport Layer Security)という技術によって実現されていますが、SSLの名称が広く普及しているため、ここではSSLと表記しています。SSL(Secure Socket Layer)はTLSの元となった技術です。

[219] Secure Transport - Security | Apple Developer Documentation () https://developer.apple.com/reference/security/secure_transport

This document describes the Apple platforms implementation of the following cryptographic protocols: Secure Sockets Layer version 3.0 (SSLv3), Transport Layer Security (TLS) versions 1.0 through 1.2, and Datagram Transport Layer Security (DTLS) version 1.0.

[220] 一部の大手サイトでTLS 1.0無効化が始まる | スラド セキュリティ () https://security.srad.jp/story/17/05/03/0442234/

[221] 【OS】WindowsVista以前・Android4.4以前・【ブラウザ】IE9以前をご利用の方へ|国税庁 () https://www.nta.go.jp/news/tls/tls.htm

「国税庁ホームページ」は、セキュリティ強化を目的として、平成29年5月13日(土)以降、インターネット通信暗号化方式「TLS1.0」及び「TLS1.1」のサポートを終了いたします。

終了後は、TLS1.2以上(最新のバージョンは1.2)に対応していない環境からはご利用いただけなくなります。

[222] vlet/p5-Protocol-TLS: pure Perl TLS protocol implementation (RFC 5246) () https://github.com/vlet/p5-Protocol-TLS

[223] TLS 1.0を無効化したIBMのクラウド、問題が発生して再び有効化 | スラド セキュリティ () https://security.srad.jp/story/17/08/13/0524243/

[224] 重要なお知らせ(2017/09/05) | スターバックス コーヒー ジャパン ( ()) http://www.starbucks.co.jp/notice/20172242.php

弊社では、お客様の情報保護を第一に考え、通信の安全性を確保するために、弊社ホームページにおける「TLS1.0/1.1」を無効化することといたしました。

[225] ssllabs/ssllabs-scan: A command-line reference-implementation client for SSL Labs APIs, designed for automated and/or bulk testing. () https://github.com/ssllabs/ssllabs-scan

[226] Qualys SSL Labs - Projects / SSL Labs APIs () https://www.ssllabs.com/projects/ssllabs-apis/

[228] Yahoo!セキュリティセンター | 2018年6月1日以降、古いブラウザー、パソコン、スマートフォンなどでは、Yahoo! JAPANのウェブサービスが順次ご利用いただけなくなります。 () https://security.yahoo.co.jp/news/tls12.html

Yahoo! JAPANでは、より安全に弊社ウェブサービスをご利用いただくために、2018年6月1日以降、インターネット通信暗号化方式「TLS1.0」および「TLS1.1」のサポートを順次終了いたします。

[229] TLS 1.3 Published: in Firefox Today | Mozilla Security Blog () https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/

[230] IETF | TLS 1.3 () https://www.ietf.org/blog/tls13/

[232] Google Online Security Blog: Modernizing Transport Security () https://security.googleblog.com/2018/10/modernizing-transport-security.html

[233] Modernizing TLS connections in Microsoft Edge and Internet Explorer 11 - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog () https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/

[234] Deprecation of Legacy TLS 1.0 and 1.1 Versions | WebKit () https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/

[235] Removing Old Versions of TLS | Mozilla Security Blog () https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

[236] セキュリティの強化に伴い、携帯電話(フィーチャーフォン)及び一部のスマートフォンなどで一部コンテンツがご利用できなくなります【平成31年1月4日より】 - 大阪府立図書館 () http://www.library.pref.osaka.jp/site/e-service/keitai-seigen.html

暗号化方式のうち、TLS1.0及びTLS1.1を無効化し、TLS1.2のみの利用に変更します。