SSLが90年代後半にTLSへ名称変更された理由

 (tim.dierks.org)
1 ポイント 投稿者 GN⁺ 2025-06-16 | 1件のコメント | WhatsAppで共有
  • 1990年代半ばのブラウザ戦争の中で、NetscapeのSSLとMicrosoftのPCTが分裂していく可能性が高まると、業界はこれらを1つの公開標準にまとめようとした
  • 初期のSSLは欠陥のためリリースに至らず、最初の実運用版であるSSL 2も数年間使われたが、暗号学的・実用的な限界を抱えていた
  • MicrosoftのPCTはSSL 2をベースに、IEとIIS向けに独自拡張を加えたもので、Netscapeは標準の主導権を失わないためにSSL 3.0で対抗した
  • NetscapeとMicrosoftはIETFの公開標準化プロセスに合意したが、IETFがNetscapeのプロトコルをそのまま追認する形になるのは避ける必要があった
  • 最終的にSSL 3.0にはいくつかの変更が加えられ、名称も変更され、TLS 1.0は事実上SSL 3.1に近い形で始まった

ブラウザ戦争におけるSSLとPCT

  • 1990年代半ばのNetscapeとMicrosoftのブラウザ競争は、セキュリティプロトコルの標準化にも影響を与えた
  • NetscapeはSSLプロトコルを開発した
    • 初期バージョンは暗号学的欠陥によりすぐに破られ、リリースされなかった
    • 最初のプロダクション版はSSL 2で、数年間使用された
    • SSL 2には暗号学的・実用的な欠陥があったが、ただちに置き換えなければならないほどの劇的な危機ではなかった
  • MicrosoftはSSL 2を修正し、独自の追加要素を加えてPCTを定義した
    • PCTはSSL 2から派生したプロトコルだった
    • サポート範囲はIEとIISに限定されていた
  • NetscapeもSSL 2の問題を修正しようとしたが、Microsoftが標準のリーダーシップや所有権を握る状況は望まなかった
    • その結果、より大きな変更を盛り込んだSSL 3.0を開発した

IETF標準化とTLSという名前

  • 業界やコミュニティの多くの人々は、プロトコルがフォークする状況を避けようとしていた
  • Consensus Developmentは、NetscapeとMicrosoftの代表者が会う会議を主催した
    • Tim Dierksは当時、Christopher AllenとともにConsensus Developmentで働いていた
    • 彼はNetscapeとの契約のもとでSSL 3.0参照実装を書いた
    • 会議にはBruce Schneierが参加し、SSL 3プロトコルを設計したPaul Kocherもおそらく参加しており、MicrosoftはBarbara Foxが代表した
  • 交渉の結果、MicrosoftとNetscapeは、IETFがプロトコルを引き継いで公開プロセスで標準化することに同意した
    • このプロセスは、Tim DierksがRFCを編集するという結果につながった
  • 標準化の過程で、SSL 3.0にはいくつかの変更が加えられた
    • IETFがNetscapeのプロトコルを単に追認しているように見えないようにする目的があった
    • 同じ理由でプロトコル名も変更された
  • こうして誕生したTLS 1.0は、実際にはSSL 3.1に近いバージョンだった

関連記事

1件のコメント

 
GN⁺ 2025-06-16
Hacker Newsのコメント

  • バージョン番号がプロトコルの違いをうまく表しておらず、かえって混乱を招いている
    SSLv2は広く配布された最初のSSLだが問題が多く、SSLv3はほぼ新しいプロトコルだった
    TLS 1.0はSSLv3と似ているが、IETFの標準化過程で少し手直しされ、TLS 1.1はブロック暗号の使い方の問題を修正したごく小さな改訂版である
    TLS 1.2はMD5とSHA-1の弱点に対応するため、新しいハッシュやAES-GCMのようなAEAD暗号スイートを追加した中規模の改訂で、TLS 1.3はTLS 1.2以前の要素を一部再利用しているものの、その大半は新しいプロトコルに近い
    これらのプロトコルはすべてバージョンを自動ネゴシエーションできるよう設計されており、クライアントとサーバーが接続性を失うことなく独立してアップグレードできた

    • TLS 1.0は「拡張」という概念によってモジュール性を導入したため、些細な進化とは言いがたい
      その一つが、サーバー間で同期された状態保存なしにサーバー側のセッション再開を可能にしたセッションチケットで、もう一つがサーバーが複数の証明書を使えるようにしたServer Name Indicationである
    • 自動バージョンネゴシエーションは、数十年にわたりさまざまなダウングレード攻撃も可能にしてきた
    • TLS 1.0ではなく、単にTLS v4.0と呼ぶべきだった
      その後のバージョンをv1.1、v1.2、v1.3にしたのは、バージョン番号をリセットしたのが客観的に誤りだったと認めたくない意地のようにも見える
    • それでも少なくとも年号でバージョンを付けなかっただけましだ

  • 当時のMicrosoftはまったく別の生き物だったので、SSL/TLSの名称の混乱もそれほど不思議には感じない
    当時のM$はあらゆるものを支配しようとしており、オープンソースのインターネット技術を遅らせようとする試みを2010年代初頭までやめなかったと思う
    Java Appletを殺すことに成功し、JavaScriptとCSS全体も何年も遅らせたと思う
    2000年代初頭、会社でIEの最新「技術」をサポートするよう圧力を受けたが、主要なJSバグが修正されるとすぐにMozilla 3.0のサポートを始め、その後Fortune 500企業が社内アプリでMozilla/Firefoxを一般化するずっと前から使うようになり、結果として良い判断だった

    • Java Appletを殺したのはMicrosoftではないと思う
      IEでは常に動いており、それがMicrosoftが影響を与えられるほぼ唯一の経路だった
      Appletは「Javaは遅い」の代表例となって失敗したが、一般論としては必ずしも正しくなくても、Appletについてはダウンロード待ちとJVM起動待ちのせいでその通りだった
      結局、HTML/JSのほうが、以前はAppletが必要だった動的な機能をよりうまくこなすようになり、HTMLで足りない残りの領域はFlashが奪っていったため消えていった
    • Appletはいくつもの理由で死んだ
      ちょっとしたアニメーション一つでもJREの起動時間がばかげて長く、当時の基準でもメモリ要求量とクラッシュがひどく、Javaプラットフォーム初期リリースの互換性問題も奇妙だった
      CA証明書を取得できる主体は善良であるという前提に基づくセキュリティモデルもお粗末で、IEだけでなくブラウザ全般のサンドボックス技術も未熟だった
    • 「M$」というあだ名は、むしろ今のほうがふさわしいと思う
    • Microsoftは広報部門が良くなった以外、それほど多くは変わっていない
    • Amazonには https://github.com/aws/s2n-tls もあった
      s2nには期待が大きかったが、AWSの外ではそれほど定着しなかったように見える

  • TLSとSSLを厳密に区別する人は、その違いを知っていて相手も知っているべきだと考えているわけだが、実務的には.docと.docxの違いに近い
    根本的には異なるが、一般ユーザーには相互に置き換え可能に見え、現場ではたいていHTTPSが動くかどうかにしか関心がなく、内部の動作にはあまり気を配らない

    • 一般ユーザーにTLSv1.0はSSLv2/SSLv3より新しく、より優れていると説明するのが主な難しさだった
      数字が大きいほうが良いと思う人たちとかなり多く議論した記憶がある
    • SSLは廃止されて久しいのに、人々はいまだに暗号化されたネットワークトラフィックを指す名称としてSSLを使う
      現代的な暗号化ネットワークトラフィックはすべてTLSと呼び、本当にレガシーなシステムが理由でSSLを使うときだけSSLと言えば、ずっと分かりやすくなるだろう

  • たった今、自分の頭が無意識のうちにSSLとTLSを区別しにくがっていたことに気づいた
    20年たってようやく、なぜそうだったのか分かった

    • 自分も同じだ
      この業界に15年いて、sslとtlsが同じものだとちゃんと理解したのがようやくで、間抜けになった気分だ
    • 2010年ごろに知ったが、それまでは自分も知らなかった
      きっかけは、Javaで今日のTLSv1.3を使う場合でも、暗号化接続を始めるときには今でもSSLSocketを使うという点だった

  • 「Transport Layer Security」は名前としてはたしかにより良い
    「TLS」と言うのも良いし、Sが二つ続くSSLはヘビのように聞こえる

    • 問題は、TLSがすでにthread local storageの略語として広く使われていたことだ
      Transport Layer Securityは1999年に始まったものとして広く文書化されており、「Thread Local Storage」は少なくとも1996年までさかのぼる資料がある
      当時はMicrosoft界隈、あるいはIBM/OS/2界隈でより一般的な用語で、PthreadsやUnix全般では「thread-specific data」と呼ぶ傾向があった
      2001年のItanium ABI文書がこの用語をより広いUnixの世界に広めたのかもしれないが、Sunもそれ以前からSolarisやJava界隈でこの用語を使っていたようだ
    • むしろSSLのほうが、名前としてはしっくりくると思う
      理論上、TLSはIPSecのように任意のプロトコルを上に載せられるトランスポート層のセキュリティ機構であり得るが、実際にはほぼTCPソケットに縛られている
      UDP派生のDTLSやQUICもTLS仕様の一部ではなく、LinuxのカーネルTLSやWindowsの類似インフラもあるが、ソケットフラグ一つでTLSを有効にするほど簡単ではない
    • 「SSL」は3文字のあいだで舌の位置がほとんど変わらないので、「TLS」より発音しやすい
    • いちばん良い名前は、最初に出てきて定着した名前だ

  • 誰かにウェブサイトへ安全に接続すべきだと伝えるとき、あるいは TLS/SSL という用語を使いそうな場面で、普通は何と言うのか気になる

    1. SSL と言うのか TLS と言うのか
    2. 年齢はいくつか、あるいは 1999 年以前から働いていたかどうか
    • たいてい SSL と言う
      長い間、TLS が「同じもの」だということすら知らず、今では分かっていても 10 回中 9 回はやはり SSL と言ってしまう
      38 歳で 2011 年に仕事を始めたが、ネットワークプログラミングは 2004〜2005 年ごろに初めて触った
      今別の画面を見たら、数分前に if 文を追加した関数も sslCertNotBefore という名前を使っていた
      プログラマーが通常 TLS を直接扱わないことも、問題の一部のように思う
      HTTPS 接続から詳細な証明書情報を抽出するシステムを作ったが、Java 標準ライブラリから必要な情報を引き出すのはかなり骨が折れた
      自動的に見えない形で処理されるならミスはしにくいが、TLS が実際にどう動くのかについての深い理解が広まるうえでは、ブラックボックス化 はあまり役に立たない
    • ほとんどの人が SSL と呼ぶのは、セキュア通信を扱うライブラリ名に SSL が入っているからだと思う
      最も支配的な OpenSSL をはじめ、BoringSSL、LibreSSL、wolfSSL などがある
      名前に TLS が入るライブラリとしては GnuTLS、mbedTLS、s2n-tls、RustTLS があるが、相対的にあまり使われていない
    • たいてい SSL と言う
      より正確な TLS より理解される可能性が高く、実際に SSL 3.0 を使っている人はもういないからだ
      OpenSSL のような古典的なライブラリ名にも SSL が入っている
      ただ、1990 年代の 暗号戦争 の時代に SSL を覚え、まともな SSL 暗号化を使うには “US only” の Netscape 版を手に入れなければならなかった時代の癖なのかもしれない
    • たいてい “https” と言う
      一般の人でもその意味を知っていることがあるからだ
    • 最近はだんだん “TLS” と言うことが増えたが、ほんの 1〜2 年前まではほとんどいつも “SSL” と言っていた
      それでも時々 SSL が口をついて出る
      51 歳で、90 年代半ばに IT の仕事を始めた

  • TLS 1.0 は SSL 3.0 よりかなり大きな改善を含んでいたのではないかと思う
    文章だけ見ると、ただ違って見せるためにいくつか直しただけのように見える

    • 主な違いは パディング にある
      POODLE 攻撃が SSL3 にだけ影響し TLS1.0 には影響しないと事前公開されたとき、その情報だけでもパディングオラクルだろうと予測できた
      両者はかなり似ており、いくつかの「バグ修正」が入ったと見るのが妥当だ
      昔のことなのでいくつか忘れているかもしれないし、SSL3 と TLS1.0 はいつも一緒に実装していたので細部を見落としているかもしれない
    • 変更は小さく、ほかのどのバージョン改訂よりも小さかった
      おおむね IETF が SSL 3.0 プロトコルをそのまま承認せず、縄張りを主張した のに近かった
    • 意味のある変更や改善は確かにあったが、SSL 3.0 のような全面的な再設計ではなかった

  • 関連する文章として、1996 年 1 月の Dr. Dobb's Journal の “Randomness and the Netscape Browser” がある
    https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
    1996 年に書かれた文章だが、使われている言葉が今日の出版物とはすでにかなり違って感じられ、年季を感じる

    • どんな出版物を見るかによる
      1996 年でもそうだったように、今日でも LWN の記事 [1] のようなものはかなり近い文体で読める
      ただし、やや一般読者向けで少しだけ堅さが薄いかもしれない
      [1] https://lwn.net/
    • その記事の著者たちは、そのセキュリティ問題を発見して New York Times の一面 にも載った: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

  • Eric Rescorla の “SSL and TLS: Designing and Building Secure Systems” は、TLS の歴史と現在に至るまでの流れを理解するのに本当に役立った記憶がある
    2001 年に出た本だが、その後 CVE になったいくつかの問題をすでに警告しており、中古なら数ドルで手に入ることもある

  • 2014 年ごろには、SSL 2.0 には重大な欠陥がある という合意は非常に強固だったと思う
    ハンドシェイクでさえ適切に認証されていなかった