Let's Encrypt 10周年、SSL/TLS普及を目指した出発点
(letsencrypt.org)- インターネット上で個人情報やビジネス情報がより頻繁にやり取りされる状況の中、Let’s Encryptは無料のサーバー証明書によってTLS普及の参入障壁を下げようとする認証局として登場した
- ブラウザとサーバーはすでにTLSをサポートしているが、運用者にとっては証明書の発行・インストール・更新が複雑で、コストもかかる作業だった
- Mozilla、Cisco、Akamai、EFF、IdenTrust、University of Michiganの研究者らはISRGを通じて協力し、2015年第2四半期のインフラ提供を進めた
- 運用原則は無料、自動化、セキュリティ、透明性、オープン性、協力であり、発行・失効記録の公開とオープン標準プロトコルを含む
- 特定の組織が統制するセキュリティではなく、コミュニティ全体が使える普遍的で開かれたインターネットセキュリティを作ることに焦点を当てた
TLS普及を阻んでいたサーバー証明書の壁
- 個人情報やビジネス情報がインターネットを通じてより頻繁に行き交うようになっているが、ユーザーはそうした送信がいつ行われているのかを常に把握するのは難しい
- TLSはSSLの後継技術であり、あらゆるデバイスのブラウザとデータセンターのサーバーがすでにサポートしている
- TLSで保護された通信の中核は、ユーザーが意図したサーバーと実際に通信していることを証明する公開鍵証明書である
- 多くのサーバー運用者にとって、基本的なサーバー証明書でさえ負担として残っていた
- 申請手続きが分かりにくい場合がある
- 通常は費用がかかる
- 正しくインストールするのが難しい
- 更新が面倒である
Let’s Encryptが提案した無料・自動化の認証局
- Let’s Encryptは、協力とオープン性を基盤とする新しい無料の認証局である
- ドメイン所有者は、自分のドメインについて検証済みの基本サーバー証明書をワンクリック手続きで取得できるようになる
- Mozilla Corporation、Cisco Systems、Akamai Technologies、Electronic Frontier Foundation、IdenTrust、University of Michiganの研究者らがInternet Security Research Group(ISRG)を通じて協力した
- ISRGはカリフォルニア州の公益法人であり、同じ目標を持つ他の組織の参加も歓迎している
- 運用原則は次のとおり
- 無料: ドメイン所有者は、そのドメインについて検証済みの証明書を無料で取得できる
- 自動化: 証明書の登録はサーバーの基本インストールまたは設定プロセスの中で行われ、更新はバックグラウンドで自動的に実行される
- セキュリティ: 最新のセキュリティ手法とベストプラクティスを実装するためのプラットフォームの役割を果たす
- 透明性: 証明書の発行と失効の記録を、誰でも検査できるよう公開する
- オープン性: 自動発行・更新プロトコルはオープン標準として作り、可能な限り多くのソフトウェアをオープンソースで提供する
- 協力: インターネットプロトコルと同様に、コミュニティ全体に利益をもたらす共同の取り組みとして運営される
- ISRGとパートナーに関する情報はAboutページで確認できる
1件のコメント
Hacker News の意見
間違いなく最高のサービスの一つで、証明書ビジネスを終わらせ、インターネットをより安全にしてくれた。
かつて HTTPS 接続は、証明書の費用がドメインよりはるかに高く、「本気の」プロジェクトで使うものだった。まずは証明書なしで始めて、うまくいったら100ドルほど払って証明書を買う、という感じだった。
気づいたとき、最初に思ったのは「Let’s Encrypt にブロックされたらどうしよう」ではなく、「自分の怠慢な設定のせいで Let’s Encrypt に不要な負荷をかけて申し訳ない」だった。Let’s Encryptは、少なくともこの10年で Web に起きた最高の出来事だ。
それ以前は自分のサービスに SSL をまったく使っていなかった。費用対効果が合わなかったからだ。それ以降は使わないことがない。
個人プロジェクトの複数のサブドメインをカバーするワイルドカード証明書が必要になると急にとても高くなっていたので、この問題が完全に解決されたのはありがたい。
私たちの基準では10周年は2025年だと見ているが、ここでの温かい言葉には感謝している。
今日は Let’s Encrypt を立ち上げると公に発表してからおよそ10年の日で、来年が Let’s Encrypt が実際に最初の証明書を発行してから10年の年になる: https://letsencrypt.org/2015/09/14/our-first-cert/
2015年12月、つまり今日から約9年前には、招待なしで誰でも使えるようになった: [https://letsencrypt.org/2015/12/03/entering-public-beta/](https://letsencrypt.org/2015/12/03/entering-public-beta/）
そのときはドメインを買うお金しかなく、SSL の費用はなかったが、サイトには SSL が必要だった。Let’s Encrypt の無料 SSL のおかげでプロジェクトは成功した。
証明書にお金を払っていた時代がつい昨日のようで、もっと悪いことに、そもそも証明書なしで運用していた時期もあった。
もう 10年 になるなんて信じられない。
Let’s Encrypt については少し複雑な思いがある。
StartSSL のような怪しい業者に頼らず無料の TLS 証明書を取得できるようになったのは良いことだ。そのおかげでどんな Web サイトでも HTTPS に簡単に移行でき、ログインのような機密データが暗号化されていない接続で送信されることは事実上なくなった。
一方で、どの認証局でも自分の関与なしに自分のドメインの証明書を発行できてしまう、TLS 証明書の信頼モデルの根本的に壊れた構造を強化したとも思う。CAA レコードや Certificate Transparency のような緩和策は多いが、100% の解決策ではない。Let’s Encrypt がなければ、DNSSEC+DANE のように、ドメイン所有権を実際に判断する権限を持つ主体に証明書発行を制限する、より良い信頼メカニズムを実装する動機がもっと強かったかもしれない。
サイトを TLS に移行する過程で、後方互換性が意図的に不足していることも気がかりだ。これは単に TLS をオン/オフする一度きりの問題ではなく、プロトコルや暗号スイートが継続的に廃止されていく問題だ。銀行やメールのように安全であるべき対象には妥当だが、レシピのような静的で重要ではない情報を見るところまで必須だとは思わない。通信事業者が広告や変なものを挿入する問題は、規制で解決するほうがよいと思う。
証明書がずっと苦痛な状態のままだったなら、TLS より良い何かが出てきた可能性もあるが、そうは見えない。根本的な問題が今も難しいからだ。
いちばんありがたいのは ACME プロトコル
Let’s Encrypt 以前は、証明書をどう更新していたか覚えているだろうか？秘密鍵が ZIP 添付ファイルとしてメールでやり取りされることがよくあった。セキュリティ劇場に近く、私の知る限り複数の認証局でよくある慣行だった。Let’s Encrypt には感謝している
CSR 生成の過程でサーバー上に新しい鍵を作り、サーバー自身で実行して鍵がサーバー内部のストレージから出ないようにしている。CSR は GlobalSign に送り、大企業の手続き上、第三者を経由したあと、数日後に証明書を受け取ってサーバーに適用する
ACME を使って鍵をメモリ上の RAM ディスクなどに置きたいが、タンカーより機敏でない会社で働く欠点とはこういうものだ
それ以前は TLS 証明書をいくつか少し扱っただけだったが、少なくとも私が経験したところでは CSR 方式が強制されていた。ただ現実には、私が知っていた以上にこうしたひどい慣行が一般的だったのかもしれない
クラウド環境のロードバランサーは letsencrypt のような外部 ACME プロバイダーと簡単には統合できないことが多く、内部プロバイダーはドメインをそちらへ移せと要求するので、常に可能なわけでもない。そもそもすべてのクラウドプロバイダーがこうした機能を備えているわけではなく、多くは ACME を後付け機能のように扱っているように見える
terraform や cron ジョブなどでスクリプトをつなぎ合わせれば、ある程度ハックはできるが、汚くなる。失敗モードは、証明書更新に失敗するとサイトが止まることだし、証明書の有効期間が非常に短くなったおかげで、そういうことが頻繁に起きる。実際に経験した
だから数日前に ワイルドカード証明書税 を払った。これを避けるために頭を悩ませないよう数百ドル払ったので気分は悪いが、自分の時間で実質 2 時間にも満たない費用を節約するために何日も費やす価値はない。CSR の発行、証明書の受領、関連するロードバランサーへのコピーまで、20 分の作業だ
デスクトップ証明書の世界にも、こういうものができるといい
Microsoft は現在の要件で完全に狂気モードに入っており、その証明書販売業者たちは指一本動かさずに以前より多くの金を稼いでいる
笑えるのは、そのすべてのセキュリティ、審査、終わりのない検証が、いまだにメールで送られた パスポート写真 1 枚 の上に成り立っている点だ
Peter Eckersley（1978–2022）は、Let’s Encrypt の設立に関わった功績により、没後に Internet Hall of Fame 入りした
Peter と彼の多くの協力者・同僚たちのおかげで、インターネットはより良い場所になった
ここにいる人の中で聞いたことのある名前は一つもない。それが何を意味するにせよ
全リスト https://www.internethalloffame.org/inductees/all/ では、おそらく 7 人くらいは分かった。それでも一桁パーセントだ
ちょうど見込み客である オランダ政府機関 からメールを受け取ったのだが、Letsencrypt を使わないでほしいと言われた
彼らは証明書費用を自分たちが払う形を好むらしいが、なぜなのかは分からない。どうやら信頼していないようだ
多くの人は、HTTPS 証明書 が DNS インジェクションのような特定の攻撃タイプを必ず防いでくれるわけではないことをよく知らない
DNSPionage という攻撃キャンペーンが、攻撃に使う有効な証明書を取得した例は <https://www.youtube.com/watch?v=exy5JwAU8qk> で見られる
簡単に言えば、HTTPS 証明書の発行は自動化されており、DNS のセキュリティに依存している。それは DNSSEC で実現されるが、ほとんどは実装していない
問題は、ここでは CAA レコードも役に立たないという点だ。A レコードを偽装できるなら、CAA レコードも偽装できるからだ。DNSSEC がここで役に立つかどうかは、DNS を十分に知っているわけではないので確信できない
もう一つの攻撃は IP ハイジャック だ。この場合、一般的な ACME 方式である HTTP 認証のようなものは通過できるが、CAA レコードは迂回できない。自分の A や AAAA レコードが指す IP アドレスを所有していたとしても、自分の CAA に letsencrypt が承認済み発行者として載っていなければ、letsencrypt で証明書を発行することはできない
Let’s Encrypt は巨大な成果であり、今や必須インフラになった
単一障害点にならないようオープンなプロトコルを基盤にしたのは賢い選択で、どこか一つの組織が消えてもそのアイデアが生き残れるようにしている
こうした記念日が今後もたくさん続くことを願う