Matt Palmer
Apr 18, 2018 • 5 min read
Discourse World HQでは、セキュリティの価値を強く信じています。私たちは公開バグバウンティプログラムに資金を提供し、セキュリティポリシーと手順をリポジトリ上でドキュメント化しています。フォーラムのサーバーとユーザー間のトラフィックを保護することも重要であり、Let’s Encryptが一般公開されたほぼ初日から、セルフホスト型DiscourseサーバーへのLet’s Encryptの統合に対するファーストクラスのサポートを提供してきました。
これらすべては、なぜ私たちがこの発表をこれほど大変誇りに思っているかを説明するためです。すべての新しいホスト型Discourseインスタンスは、デフォルトでHTTPSが設定され（HSTSポリシーにより強制）、既存のお客様の大多数はHTTPS強制へと透過的に移行されました。一部のお客様は自動的にHTTPSを強制することができません。サイトがまだHTTPで読み込まれている場合は、サポートチームにご連絡ください。必要な変更についてご案内いたします。
これまでの経緯
HTTPSは常に私たちのホスティングでサポートされていましたが、長い間、すべてのユーザーに自動的に展開することは実現不可能でした。暗黒時代（2015年頃まで）には、CAと特別な契約を結べるほど大きな組織でない限り、SSLを大規模に実施することは非常に手間のかかるものでした。確かに証明書はお金がかかりましたが、それが最大の問題ではありませんでした。正直なところ、私たちを阻んでいたのは自動化にまつわる辛い現実でした。基本的に、エンドツーエンドの自動化は存在していませんでした。
SSL手順の進化を、ランブックのタイトルの変遷をたどることで振り返るのは興味深いことです。暗黒時代には、いくつかの反復を経ました。「お客様のSSL証明書のインストール方法」から始まり、「お客様のSSLワークフロー（手動版）」、「半自動お客様SSLワークフロー」、そして最終的に「お客様のSSLワークフロー（99.5%自動化版）」となりました。プロセスをできる限り自動化しようと懸命に努力しましたが、SSL証明書の取得には常にどこかで人間の介在が必要でした。そして自動トライアルサインアップを提供している場合、そのプロセスの途中に人間を介在させることはすべてを台無しにしてしまいます。
ありがたいことに、Let’s Encryptが登場し、私たちを証明書の啓蒙時代へと導いてくれました。私たちは長い間、Let’s Encryptの大きな支持者であり続けています。最初の公開発表以来、実質的にLet’s Encryptコミュニティフォーラムのホスティングを寄付しており、証明書に費やしていたであろう費用を現金でも寄付しています。Let’s Encryptが一般公開されたとき、私たちはそれをベースにSSL証明書の発行パイプラインを再実装し、すべてはかなり順調に進みました。
現実が立ちはだかる
Let’s Encryptのおかげで、お客様が求めるSSL証明書の取得を完全に自動化することが容易になりました。ただし、お客様のリクエストに応じて稼働中のサイトの証明書をリクエストすることと、サイトのDNSが設定された直後に証明書が発行されるようにすることの間には大きな違いがあります。DNSが正しく設定されているかどうかを検出するだけでも、一部の方々が行う、いわゆる「興味深い」設定の選択の多様さを考えると、課題となり得ます。これは、発行を機能させることよりもはるかに多くの時間と工夫を要しました。Let’s Encryptに証明書をリクエストし、バリデーションを処理することは、acme-client gemの助けとHAProxyのマジックを使えば約10行のRubyコードで済みます。しかし、人々のDNSやプロキシ設定における特殊なケースや例外に対処するのは、かなり多くのコードを必要とします。
さらなる課題として、チームの大部分が昨年半ばから、大手ゲーム会社向けに完全カスタムの超大規模AWSベースのホスティング環境を構築する作業に取り組んできました。その作業は今や実を結んでいますが、望んでいたよりも迅速にユニバーサルSSLを構築する時間と注意を他に振り向けることになりました。
最後のハードル
最後のハードルは移行の問題です。既存のすべてのお客様に、私たちのSSLの取り組みの恩恵を自動的に受けていただきたいと考えています。長い間ご利用いただいているお客様に対して、単純にスイッチを切り替えることを妨げる要因がいくつかあります。
まず、リダイレクトとHSTSの設定を通じて全員にHTTPSの使用を強制すると、一部のものが壊れてしまいます。最大の問題は、HTTPクライアントに「このまったく同じリクエストを、別のURLに対して透過的に再実行してください」と伝える普遍的にサポートされた方法がないことです。「同じHTTP動詞でリダイレクトする」ための新たに標準化されたHTTPレスポンスコードがありますが、すべてのブラウザやHTTPライブラリでサポートされているわけではなく、「これを再実行しますか？」というプロンプトが表示されることがあります。これはスムーズな移行には望ましくありません。
外部認証プロバイダーも障害となります。それらはよく、受け入れる返却URLをホワイトリスト化しています。認証サービスを呼び出す際には、通常、認証完了後にブラウザがリダイレクトされるべきリンクを送信します。認証プロバイダーがHTTPのリンクを期待しているときにHTTPSのリンクを送信すると、認証エラーが発生します。これは非常に困ります。また、私たち自身で修正することもできません。お客様のGoogle、Facebook、TwitterアプリケーションにアクセスしてホワイトリストのURLを更新する手段がないからです。
最後に、HTTPSサイトを立ち上げたことのある人なら誰もが一度は経験したことのある、混在コンテンツの警告という古くからの問題があります。ありがたいことに、その大部分はお客様に代わって修正できます。リンク先のサイトがHTTPSをサポートしていることを確認し、サイト設定を変更して戦略的に「s」を追加することで対応しています。
セキュリティはもはや任意ではない
デフォルトでのHTTPS展開は、まさに適切なタイミングで実現しています。ChromeやFirefoxなどの主要ブラウザは、HTTPのみのサイトを以下のように「安全でない」と表示する変更を展開中です。
このトレンドは続き、他のブラウザも追随し、警告はますます深刻になっていくと考えるのが合理的です。したがって、どこでホストされているかに関わらず、今こそすべてのWebプロパティがHTTPSで提供されるようにし始めるべき良いタイミングです。
大きな成果
多少の紆余曲折はありましたが、最終的には目指していた場所に到達しました。新規のお客様はデフォルトでHTTPSが強制され、既存のお客様の大多数は気づかないうちにデフォルトでHTTPSが強制されるようになり、残りのお客様についても、アップグレードを完了するために何が必要かを正確に把握しています。
原文はこちら：
Good Loopでは、Discourseのセルフホスティングを安価で提供しています。開発元であるCDCK社の協力のもと、公式ブログ記事の翻訳・公開など、日本での普及にも努めています。