実際、SSLの方がしっくりくると思う。理論的には、TLSは任意のプロトコルがその上で動くことを可能にするトランスポート層のセキュリティメカニズムだけど（IPSecみたいに）、実際にはTCPソケットにほぼ縛られてる感じ。UDPのバリアント（DTLS、あとQUICもかな）は、TLSの仕様には含まれてないし。もちろん、今はLinuxにカーネルTLSがあって、Windowsにも似たようなインフラがあるけど、TLSをオンにするのがソケットのフラグを設定するだけってわけにはいかないんだよね。それに、たまにはヘビみたいに聞こえるのも悪くないよ。ヘビってかっこいいし。

問題は、TLSが「スレッドローカルストレージ」で広く使われていたことなんだよね。トランスポート層セキュリティは1999年から始まったと広く文書化されてるけど、「スレッドローカルストレージ」って用語は1996年まで遡ることができる。特にその用語は当時のMicrosoft（あとIBM、OS/2のプログラミングマニュアル持ってる人いる？）の世界でよく使われてたみたいで、Pthreads（1995年）やUnix全般では「スレッド特有のデータ」って呼ばれてた。2001年の影響力のあるItanium ABI文書（これがDrepperのTLS論文に直接つながった）で、この用語が広く使われるようになった可能性もあるけど、Sun（SolarisやJava用？）も以前からこの用語を使ってたみたい。でも、もしかしたら俺が参考資料を見逃してるだけかも。

ジャングルブックのカーがTCPセキュリティについて話しながら、SSLの名前を主張してる絵を想像してみて。もしかしたら、3つ目のSを追加するのもありかもね。

「SSL」の方が発音しやすいよね。三つの文字の間で舌の位置がほとんど変わらないから、「TLS」と比べて。

一番いい名前は、最初に使われてそのまま定着したものだよ。

同じく。今、すごくバカみたいに感じてる。15年この業界にいるのに、やっとSSLとTLSが同じだって気づいた。

これは1996年に書かれたものだね。使われている言葉が今の出版物とは全然違う感じがする。ああ、歳を感じるわ。どの出版物を見ているかによるよ、1996年と同じようにね。例えば、今日のLWNの記事はかなり似たスタイルで書かれているよ。ちょっと堅苦しさが減っているかも、もう少し一般向けだからね。[1] https://lwn.net/

確かに大きな変更や改善はあるけど、SSL 3.0のような完全な再設計ではないよ。

主な違いはパディングにあるんだ。POODLE攻撃がSSL3にだけ影響するって前もって発表されたとき、それがパディングオラクルになるって予測するのには十分だった。似てる部分が多いし、いくつかの「バグ修正」があるって言ってもいいと思う。ただ、最近はどちらについても考えてなかったから、いくつかのことを忘れてるかも。SSL3とTLS1.0を一緒に実装したことしかないから、忘れてる細かいこともあるかもしれない。

Reflex的にはSSLって言うけど、だいたいは自分でTLSに訂正するね。2006年にIT業界に入ったけど、その前に数年はオタクだったよ。

私はHTTPS証明書って言うよ。もし特にSSLかTLSを言わなきゃいけないときは、SSL（OpenSSL、LibreSSL、BoringSSL、SSL証明書、Qualys SSL Labs、SSLサーバーテストのように）って言うかな。TLSはSSLのために作られた名前だよ。特定のプロトコルを名前で言う必要があるときは「TLSv1.2」って言うけど、それくらいかな。1999年以前に働いてたよ。

最近は「TLS」って言うことが増えてきたけど、1、2年前まではほとんど「SSL」だったな。たまに「SSL」って言っちゃうこともあるし。俺は51歳で、90年代中頃からIT業界に入ったんだ。

「https」って言うことが多いかな。普通の人でもそれが何を意味するか知ってることがあるからね。

1. SSL。長いことTLSが「同じもの」だって知らなかったけど、今は知ってても10回中9回はSSLって言っちゃう。2. 38歳。2011年から働き始めたけど、ネットワークプログラミングに初めて触れたのは2004年か2005年くらいだった。別の画面を見たら、ほんの数分前にif文を追加した関数があったよ。public Builder sslCertNotBefore(Instant sslCertNotBefore) { if (sslCertNotBefore.isAfter(MAX_UNIX_TIMESTAMP)) { sslCertNotBefore = MAX_UNIX_TIMESTAMP; } this.sslCertNotBefore = sslCertNotBefore; return this; } たぶん、プログラマーとしてTLSを直接扱うことが少ないのが問題の一部なんだと思う。このコードはHTTPS接続から詳細な証明書情報を抽出するシステムの一部で、必要な情報をJavaの標準ライブラリから引き出すのが本当に面倒だった。自動化されて目に見えない方がミスが少ないのは確かだけど、TLSがどう機能しているかの理解が深まらないのも問題だよね。

普段はSSLって言うかな。正確なTLSよりも理解されやすいし（もうSSL 3.0なんて使ってる人いないし）。多くのSSL（つまりTLS）ライブラリの名前にも入ってるし、クラシックなOpenSSLなんかもそうだよね。そういえば、1990年代の暗号戦争の頃にSSLを学んだんだ。まともなSSL暗号化を使いたければ「アメリカ限定」版のNetscapeを海賊版で手に入れなきゃいけなかったから、古い用語を使ってるのは習慣かもしれない。

大多数の人はSSLって呼ぶと思う。だって、セキュアな通信を扱うために使ってるOpenSSLライブラリにはSSLが入ってるからね。OpenSSLが最も支配的だけど、他にもBoringSSL、LibreSSL、wolfSSLなんかがある。TLSが名前に入ってるライブラリはあまり使われてない。GnuTLS、mbedTLS、s2n-tls、RustTLSとか。

SSL、27。コードでは「tls」って呼ぶかな（ドキュメントでは「SSL/TLS」って書いて、わかりやすくするけど）。

誰も「TLS証明書」なんて言わないよね。「SSL証明書」って言うだけ。これだけでも、一貫性を持たせるために「SSL」って言った方が簡単だし、みんなが何を指してるか分かるし。

1. SSL、違いは知ってるけどね。正確には違いがあるってことは知ってるけど、SSLって言えば伝わるから。2) 1999年以前。確か、最初に関わったSSL証明書を取得するのにファックスが必要だったんだよね。

これらのプロトコルは、バージョンを自動的に交渉できるように設計されているから、クライアントとサーバーが独立してアップグレードできるし、接続が切れることもないんだ。数十年にわたるダウングレード攻撃を防ぐためにもね。

まあ、少なくとも年号だけでバージョン管理されてたわけじゃないからね。 ;)

M$（その時代にぴったりの名前だね）今ではさらにぴったりだと思うよ。

Javaアプレットを殺したのはマイクロソフトじゃないと思うな。だって、IEではちゃんと動いてたし、MSが影響を与えられたのはそこだけだったからね。アプレットが失敗したのは、「Javaは遅い」っていうイメージの代表になっちゃったからだよ。実際には全体的にそうじゃなかったけど、アプレットに関しては、ダウンロード待ちやJVMの起動待ちで遅かったのは確か。アプレットを殺したのは、1) HTML/JS自体が進化して、以前はアプレットが必要だったような動的なことができるようになったこと、2) FlashがHTMLでは足りない残りのニッチを奪ったことだね。

アプレットが死んだ理由は色々あるよ。例えば、JREの起動時間が異常に長かったり（しょーもないアニメーションのために）、当時としては異常なメモリ要件やそれに伴うクラッシュ、Javaプラットフォームの初期リリースでの変な互換性の問題、PCで好き勝手するためには良いユーザーだけがCA証明書を取得できるっていうバカげたセキュリティモデル、ブラウザ（IEだけじゃない）での未成熟なサンドボックス技術とかね。