全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。

そもそもSSL, TLSとは何か

SSL/TLSは暗号化技術である。

SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。

その手順は

1. <- HelloRequest
2. -> ClientHello
3. <- ServerHello
4. <- ServerCertificate
5. <- ServerKeyExchange
6. <- ServerHelloDone
7. -> ClientKeyExchange
8. -> Finished
9. -> ChangeCipherSpec
10. <- Finished
11. <- ChangeChiperSpec
12. <-> Application Data

Key Exchangeというのは非対称暗号鍵の交換である。 これもその場で生成するもので、RSA/DHE/ECDHEのいずれかを使用する。

非対称暗号というのは暗号化する鍵(公開鍵)と復号化する鍵(秘密鍵)のペアからなる。 公開鍵では暗号化はできるが復号化はできないため、公開鍵は相手に渡してしまうことができる。 これを利用してKeyExchangeでそれぞれ公開鍵を送りつけるわけである。

RSAの場合はServer Certificateで送りつけたサーバー証明書に含まれるサーバー公開鍵を使って共有する秘密を暗号化して送りつけるだけだが(ServerKeyExchangeは省略される)、DHEの場合はちょっと複雑だ。

サーバーは共通値という値とキーペアを作成する。 そして、クライアントに対して共通値と公開鍵を送信する。

クライアントは共通値に基づいてキーペアを作成する。そして公開鍵を送信することで共有秘密値を算出できるようになる。

そしてお互いが共有秘密値に基づいて暗号鍵を生成する。同じ値から同じ方法で生成するのでサーバーとクライアント双方が同じ鍵を持っている状態となり、これにより対称暗号によるやりとりが行える。

証明書とはなにか

SSLに付属しているのが証明書、という概念である。

これは中間者攻撃を防ぐための仕組みで、サーバーの証明書に第三者が署名する。 サーバーの署名にはサーバーのドメインが含まれている。

これによってどうやって信頼を保つのか? これは、予め「信頼できる者」を決めて、その信頼できる者が署名したものは信頼できるという考え方だ。

悪意ある第三者が証明書を偽造しようとしても、サーバーのドメインを含んだ証明書を、「信頼できる者」は署名してくれない。 だから通信相手になりすまして情報を掠め取ろうとしても、信頼できる署名された証明書を送ることができず発覚する、というわけだ。

「信頼できる者」が実は信頼できない、ということはないのか?

答えは、ある。最近ではGoogleがセキュリティ企業大手のSymantec傘下の認証局が署名した証明書を信頼しない、と決めた。

ドメインの正当性の確認方法

サーバーの証明書に署名するには、署名を要求された証明書が間違いなくドメイン所有者のものであることを確認しなくてはいけない。

ではそれをどうやって確認するか?

方法は色々あるのだが、ドメイン所有の確認方法は現在はウェブを使う方法が一般的だ。 指定されたファイルを指定されたアドレスでアクセスできるように配置する。 本当にドメインの所有者であればそのドメインのアドレスでアクセスできる場所にファイルを配置することが可能だが、そうでなければそんなことはできない、というわけだ。

この方法は割と簡単で合理的だ。

DVとOV

さて、一般に使われている証明書はDVとOVがある。

DVというのはそのドメインの所有者であることを認めた署名だが、OVというのはそのドメインを所有する組織の実在を確認したものである。

これは登記簿を提出したりする。 まあ、ドメインの所有者情報と企業情報が一致することを確認するのだ。案外簡単に通る。

で、OVのほうが価値がある、と言われるのだが。

• あなたはその証明書がDVであるかOVであるかを確認しているか?¹
• あなたはOVなら信頼するけどDVでは信頼しない、という対応をとっているか?
• 「その企業は実在する」という情報は「その相手を信用する」に値する情報か?

私は意味がないと思っている。

SSLの良いところ

まず、計算量的安全性という意味からいえば、解読できるようになったとき解読できる量が少ないというのは計算価値を下げることになる。

さらに解読しなければならない鍵が増えると計算量自体が増えることになる。

SSLの悪いところ

技術に罪はないが仕組みが問題だった。

予め信頼できる者を決めてしまう。 もちろん、大手セキュリティ企業などだ。

するとどうなったか。

第一に、「ボロい商売」になった。

SSLはかなり重要な技術だ。 SSLの重要性は主には暗号化だ。盗聴の難易度と中間者攻撃の難易度はまるで違う。 盗聴はとても簡単だが、中間者攻撃はそうそうできない。 だから重要度としては中間者攻撃を防ぐことよりも盗聴を防ぐこと、暗号化することなのだ。

ところが、SSLの価値は証明書にあるように言われた。 当然だ。SSLの採用自体は別に「信頼できる者」の力は必要ない。 「信頼できる者」が証明書を売るためには「署名がないと危険です!!」というしかない。 実際、中間者攻撃を防ぐ仕組みがある以上、有効な証明書のない証明書は警告されることになる。

となるとSSLを使うためには署名してもらわなくてはならない、という図式ができあがる。 これを利用して高額で売りつけるわけだ。

ちなみに、現在署名の値段は年間8万円から22万円ほどである。 昔はもっとずっと高かった。

ビジネスでやっているのならできなくはないが、個人的にやっているだけのところでは使えるわけがない。

結果として社会的に不可欠な技術であるにもかかわらず、SSLを使える者を限定する、という行為に走ったわけだ。 「SSLを採用することが特別なことになってしまった」ということはより問題として深く、重大である。

SSLの構造悪とLet’s Encrypt

このような問題への対応として、Let’s Encryptが誕生した。

セキュリティ的見地から言えば、重要なのは「高額なSSL署名を購入すること」ではなく、「社会的にSSLを使用すること」が重要である。² ウェブばかりが取り沙汰されるが、メールに至ってはSSL/TLSを使わなければパスワードも普通に平文で送りつけるのだ。³⁴

そこでMozillaやGoogleなどが主導してHTTPSを当たり前のものにするべく、誰にでも使えるSSL認証を開始した。⁵ これがLet’s Encryptである。

Let’s Encryptは無料なだけではない。 簡便で、かつ透明性が確保されている、というのも特徴だ。

Let’s Encryptはルート認証局のIdenTrustによって署名されている。 これによりLet’s Encryptの署名は信頼できるものとして取り扱うことができるようになっている。

Let’s Encryptが信頼できない、という謎の誤謬

まぁ、根拠は全く不明だ。

Let’s Encryptではドメインが正当なものかどうかわからないだろ、と言ったりするのだが、 ACMEトランザクションは公開されているし、ウェブを使って自ドメイン上に指定ファイルを設置するのでドメイン所有は間違いなく確認できる。

むしろ証明書発行過程が不透明な他のDVよりもはるかに信用できると思う。⁶

OVには劣る、というのはわかるが、そもそもOVを使っているところなんてとても少ないし、「DVだ!!信用できない!!!」という発言ではないので意味がない。 Let’s EncryptがDVとしての機能を満たしていないというのであれば、なぜ満たしていないのかぜひ私に説明してほしい。 もちろん、Let’s Encryptでドメイン所有を偽る具体的な手法を、だ。

基本的には、「○○が署名したやつがいいんだ、Let’s Encryptなんて格が低い!!!」みたいな、SSL証明書にワインのような味わい深さを求めているか、あるいはたくさんお金を出すと偉いとか安心できるとか考えている人だと思う。 いずれにせよ、権威主義的なのではなかろうか。⁷

ところで、Let’s EncryptはIdenTrustが署名しているのだけど、IdenTrustは信用できない、という発言なのだろうか? そうなると、Let’s Encryptに限らず相当たくさん敵を作ることになると思うのだけど、アメリカのことだから別にいいや、ということだろうか。

署名と検証

動機となったもののうちに「証明書の確認でパフォーマンスが」という発言がある。

基本的には、証明書には証明あるいは署名の有効期限がある。 切れたら再取得する。新しいものがあれば更新するし、なければ失効したということで信頼できないとみなす。

実際には「署名したけど不正がみつかったので取り消す」ということがあるので、もうちょっと頻繁に取りに行く。

検証するためにサーバーに問い合わせる必要は全くない。 なぜならば証明書が正しいかどうかは手元にある公開鍵で検証できるからだ。

目的を思い出せ

DV証明書を用いたSSLの目的は

• 安全な暗号化を行う⁸
• サーバーがドメインの所有者であることを確認する

の2点である。

別にその相手が信用できるかとか、そんなことは関係ない。 というか、そんなことはむしろOVによって確認されるように企業が実在したところで信用できるかどうかとは関係ない。 実在するけど健全じゃない企業なんてたくさんあるだろう?

Let’s Encryptはこれを満たしているはずだし、これを採用しない、 つまり暗号化を行うことも相手を確認することができない状態よりもずっと良いはずだ。

Let’s Encryptが他のDVに劣る点は一体なんだろう? 私には全く想像もつかない。

残念ながらLet’s Encryptは駄目だと言っている人が、この2点を満たしていない具体的な根拠を示しているのは見たことがない。⁹

認証について指摘があったので重ねて

example.comの証明書に署名をもらおうとすると、Let’s Encryptは「http://example.com/abcdefgとしてこのファイルをダウンロードできるようにしてください。ダウンロードできたら署名します」と求めると同時に、配置するための一時ファイルを送ってくる。

Let’s Encryptからファイルをもらう方法はHTTPSである。

Let’s Encryptが署名で保証しているのは、これを通過できた、という点に尽きる。

「Let’s EncryptのDNSを偽れたらどうなんだ」

という点については、まぁ、ものすごくハードルが高いので、完璧ではないけれど標準的にはとりあえず良しとできると思う。 そもそもそんなことはすぐバレるし、バレたら即座にLet’s Encryptの証明書がBANされることになるので、まぁ、大丈夫だろう。

そもそもSSLは暗号化が本筋であって、証明書が本体ではないので、そこに完璧を求める気もない仕様だ。

これは「DV一般の中でLet’s Encryptが駄目だという誤謬」に言及しているのでDV自体に問題があるという点については述べていないのだが、その場合はどう判断するか、ということについて言うと、 DV一般に不十分だとしたら(私はむしろそう考えている)、「SSLって駄目だよね」という話なので、認証が十分かどうかを論じる必要もない。そうなったらむしろSSLで十分かを論じることになるからだ。

他のDVの確認方法がどうなのか…という点については、全く標準化されておらず、手続きも事業者によって違うので、 ザルなところもあれば厳しいところもある。ただ、ACMEはその中では割と偽るハードルが高い(ただし、現状ではその価値も高いけれど)ことと、手続きの透明性が確保されていること(不当なドメインでないかをどうやってちゃんと確認してるのかよくわからないところもある)を考えれば 相対的には Let’s Encryptは悪くないと思う。

個人的な意見だが、SSLの証明書はお墨付きを与えているように感じる。 ドメイン自体に問題がある(例えばフィッシングドメインなど)場合でも正当な証明書は取れるわけで、そこで安心感を持ってしまうリスクを考えれば、「証明書の署名を必須にしてDVなんていう仕組みを導入したこと自体が失敗だったのではないか」と感じる。 「クレジットカードをとるようなところは取得した者を明らかにする」みたいなOVを拡張したような方式をオプショナルに採用すればよかったのではないか。

SSLの証明書の方式に問題があるということは、私は15年は言い続けているけれど、その話は長くなるので略。

SSHはSSLじゃない

SSHはSSとついているせいか、SSLを使っていると思っている人が結構いるようだ。

SSHはSSLを使っていない。別物だ。

ただし、SSH2では鍵交換の方法としてDHEを使っている。 非対称暗号でセッションを開始し、対称暗号でやりとりを暗号化する方式も同じだ。だから、似てはいる。

なお、鍵ログインに使用するRSA/ECDSA/Ed22519の鍵は通信の暗号化で使うわけではなく、通信を暗号化したあとにホストの真正性を問うために使う。¹⁰

SSHでもPKIを使用した認証が行える、という話もあるのだけど(SSLと全く同じ方式)、これは私が見たことがないのでわからない。

参考文献

Qiitaでかなり詳しい記事を見かけたので参考にしてほしい。