1 ポイント 投稿者 GN⁺ 2025-06-16 | 1件のコメント | WhatsAppで共有
  • 1990年代半ばの NetscapeとMicrosoft のブラウザ競争の中で SSLプロトコル が登場した
  • SSL 2 には暗号学的および実用上の欠陥があり、これを踏まえてMicrosoftは PCTプロトコル を導入した
  • Netscapeは対抗策として SSL 3.0 を開発し、主導権の確保を図った
  • 業界とコミュニティはブラウザ間の 互換性 維持を望み、IETFに標準化の役割を委ねた
  • この過程で プロトコル名がTLS 1.0 に変更され、現在まで続いている

背景: ブラウザ競争とセキュリティプロトコルの誕生

  • 1990年代半ば、NetscapeとMicrosoft はブラウザ市場で激しい競争関係にあった
  • その競争の中で Netscape がSSLプロトコルを開発することになった

SSL 2 とその問題点

  • 最初のバージョンのSSLは暗号学的欠陥によってすぐに無効化され、リリースされなかった
  • 実際に配布された SSL 2 は数年間使われたが、複数の 暗号学的および実用上の欠陥 を抱えていた
  • これらの欠陥は直ちに致命的な危機を招くものではなかったが、継続的に改善の必要性が指摘されていた

Microsoftの対応: PCTプロトコル

  • 競争が激化する中で、MicrosoftはSSL 2に独自機能を追加 し、PCTというプロトコルを導入した
  • PCTは Internet Explorer(IE)IIS でのみサポートされていた

Netscapeの新たな戦略: SSL 3.0

  • Netscapeも SSL 2の問題点 を改善しようとしていたが、Microsoftに主導権を握られることは望まなかった
  • そこで SSL 3.0を開発 し、従来とは明確に区別される変化を目指した

ブラウザ業界の標準化交渉

  • 業界とコミュニティの関係者は、プロトコルが二分されることを望まなかった(フォークの回避)
  • Consensus Development(筆者の勤務先)が NetscapeとMicrosoftの代表者会議 を主導した
    • この会議には Bruce Schneier(有名になる前の時点)、Paul Kocher(SSL 3 の設計者)、Barbara Fox(Microsoft代表)らが参加した

IETFによる標準化と名称変更

  • NetscapeとMicrosoftはともに、IETF(Internet Engineering Task Force) がプロトコルの標準化プロセスを主導することに合意した
  • 筆者はIETF標準文書(RFC)の編集を担当した
  • 政治的妥協 の一環として、SSL 3.0にいくつかの変更を加え、名称も新たに定める必要があった(既存プロトコルをIETFが「無条件で承認」したという印象を避けるため)
  • その結果、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.0におけるブロック暗号の使い方の問題を解決するための小規模修正版。TLS 1.2は暗号技術の進歩に合わせて中規模の改訂が行われたバージョンで、最新のハッシュ対応(MD5とSHA-1の脆弱性への対応)やAEAD暗号スイート(AES-GCMなど)のサポートが追加された。TLS 1.3は大部分が新しく作られたプロトコルだが、TLS 1.2以前の特徴も一部取り込んでいる。各プロトコルは自動バージョンネゴシエーション機能を設計しており、クライアントとサーバーが独立してアップグレードしても接続性が失われないようになっている

  • 当時のMicrosoftは今とはまったく別の会社だったことを踏まえると、今の基準で見てもまったく不思議ではない印象。当時の「M$」はオープンソースのインターネット技術を牽制するためにあらゆる手段を使っており、2010年代初頭までこの姿勢は続いていた。Java Appletsが発展できず市場から退場する一因にもなったと思う。JavaScriptやCSSの発展も何年も停滞していた印象。会社ではIEの最新技術対応を押し付けられたが、自分は代わりにMozilla 3.0を選び、JSバグを直した後はエンタープライズSPA開発にMozillaを適用した。Fortune 500企業でもその後、社内アプリへのMozilla/Firefox導入が広がり、結果的によい選択だった記憶がある

    • あの時代を思えば、「M$」というあだ名は今でもふさわしいと思う
  • 次のバージョン名は、再びSSLに戻してもよいのではないかという意見。今でも誰もが「SSL」という名称を使っているのだから、そのまま使い続けても構わないと主張

    • 実際、「TLS」という名称もすでにさまざまな場所で使われている点に言及。設定や関数シグネチャなどの更新はかなり面倒だという点でも悩ましい

    • こういう意見は誰にもアイデアを与えたくないと強調

  • 誰かにWebサイト接続を安全にしろと案内するとき(つまり、TLS/SSLという用語を使うとき)、自分は普段どちらの名称を使うかという質問。また、何歳で、1999年以前に働いていたかも気になると付け加える。自分の答えもすぐ書くと案内

    • 自分はSSLと答える(27歳)。一方でコード上では tls を使い、文書では混乱防止のためSSL/TLS表記を好む

      1. SSLと言う。長い間、TLSが「同じもの」だとよく分かっておらず、知った後でも10回中9回はSSLと言う 2. 38歳(2011年から勤務しているが、ネットワークプログラミングは2004〜2005年から)。今しがた作業したコード画面を見ると、関数名にもsslCertNotBeforeのようにSSLが入っている。一般にプログラマーはTLSを直接扱わないからではないかと思う。自分のコードもHTTPSで証明書情報をパースする必要があり、かなり面倒な作業だった。すべて自動化・抽象化されているおかげでミスなく処理できるが、TLSの動作原理を深く理解するうえではむしろ妨げになる側面もある
    • 多くの人がOpenSSLのような、sslという名前の入ったライブラリで安全な通信を実装しているため、SSLという名称をよく使う傾向がある。OpenSSLのほかにも、BoringSSL、LibreSSL、wolfSSLなどのライブラリがある。TLSという名前の付いたライブラリは比較的有名ではなく、代表例としてGnuTLS、mbedTLS、s2n-tls、RustTLSなどがある

    • SSLという用語を使う主な理由は、SSLのほうが通じやすい気がするから。厳密にはTLSが正しいが(実際にはSSL 3.0を使っている人は誰もいない)、代表的なライブラリにもSSLという語が残っているので使い続けている。実際、90年代の暗号戦争の時代にSSLという名称を覚え、当時はまともなSSL暗号化のためにNetscapeの「US only」版を違法ダウンロードしなければならなかった記憶があるので、単に慣れで使っている感じ

    • 自分はたいてい「https」と言う。一般の人でも意味をだいたい理解している場合があるので、それを好む

  • むしろSSLとTLSという用語を無意識にきちんと区別できていなかったことに初めて気づいた。20年越しで本当の理由を知り、不思議な気分

    • まったく同じ感覚。業界で15年働いてきたのに、今になってようやくSSLとTLSが実質的に同じものだと知った気分
  • 「Transport Layer Security」は確かによりよい名称だと思う。TLSという呼び方も好む。Sの音を続けて2回出すとヘビみたいに聞こえて面白いとも感じる

    • ただしTLSはすでに「Thread Local Storage」という用語でも広く使われている。Transport Layer Securityが1999年から公式に使われている一方、Thread Local StorageはMSやIBMの開発環境などで1996年以前から存在していた。Unix業界ではpthreadが1995年に登場した頃からthread-specific dataという用語をより好んでいた面もある。2001年のItanium ABI文書の影響で「TLS」がさらに広まった背景もありそうで、Sun Microsystemsもすでに使っていたかもしれない。もし誰かOS/2のマニュアルを持っているなら参考資料を共有してほしい

    • 自分としては、むしろSSLのほうがしっくりくる名称だと思う。理論上はTLSは複数の層で動作する一般的なセキュリティ手段(たとえばIPSecとの統合も可能)であるべきだが、実際には主にTCPソケットのためにしか使われていない。UDP向けの派生はDTLSやQUICだが、TLS自体には含まれない。最近ではLinuxカーネルTLSやWindows特化インフラもあるが、単にソケットフラグを有効にするだけのように簡単には適用できない。そして正直に言えば、ヘビのように聞こえるSの音は響きとしてかっこいい

    • 「SSL」は「TLS」より発音しやすい。S-S-Lは発音時に舌の位置移動がほとんどなく、速く自然に言える

    • 『ジャングル・ブック』のKaaがTCPセキュリティをテーマにS〜S〜Lという名前について語ったら似合いそう。実際、Sの音をもう1つ足してSSSLと呼んでも面白そう

  • TLSとSSLを厳密に区別する人たちは、その違いをよく知っているとアピールしたいか、そう話したがるタイプ。実際の区別自体は.docと.docxの違い(基本的には異なるが、一般ユーザーにはほぼ互換)にも似ている。大多数はHTTPSがきちんと動けばよく、内部構造や動作方式にはあまり関心がない

  • 関連リンク:1996年に書かれた『Randomness and the Netscape Browser』(Dr. Dobb's Journal)の記事を共有 https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.html 1996年の文章なので、現代の論文や記事とは言葉の雰囲気そのものがかなり違う。古めかしい感じがする

    • どんな出版物を読むか(つまりターゲットやフォーマット次第)によって、1996年当時と同様にさまざまだ。LWNのようなところは今でも似たスタイルで記事を書いている(少し柔らかくなっただけ) https://lwn.net/
  • TLS 1.0はSSL 3.0と比べて実際にはかなり多くの改善点があったのではないかという質問。記事では単に「違いをつけるための小幅調整」と表現しているようなので気になったという指摘

    • 実質的に大きな変更や改善が多かったのはその通り。ただし、SSL 3.0のときほどの全面的な再設計ではないことを強調
  • インターネット上では今なお30万を超えるサービスがSSLv2をサポートしている。リンク: https://shodan.io/search/report/… 推移グラフ: https://trends.shodan.io/search?query=ssl.version%3Asslv2#overview 数はここ数年で大きく減ったが、完全になくなるにはまだ時間がかかりそう

    • だとすると、実際にSSLv2ベースのクライアントがどれほど残っているのか気になる。最近のソフトウェアやライブラリには、もはや意味のあるレベルのサポートはないと見ている