Hilbertのハッシュアルゴリズムマップ（Ian Boyd）
信用されているWebのほとんどで安全性の低いアルゴリズムが使われている中、Googleが不急の緊急事態を宣言しました。
Webサイトの約90%は、なりすましを防ぐためにSHA-1というアルゴリズムを使ったSSL暗号化を使用しています。この暗号化により、例えば
にアクセスした場合、そのサイトが本物のFacebookであること、そしてパスワードが攻撃者に漏洩しないことが保証されます。
残念ながら、SHA-1には危険な脆弱性が長い間存在していました。この危険性は年々高まっていますが、インターネット上では今も広く利用されています。この代替となるSHA-2は安全性が高く、多くの製品でサポートされています。
Googleが最近発表したところによると、Chromeでは今後、信用されている多くのWebサイトに対する警告が段階的に表示されるようになります。
2017年に有効期限が切れるSHA-1証明書を利用した場合にChromeで起こるWebサイトの表示の変化
一連の警告はクリスマス前から始まり、その後6か月の間にさらに厳格なものになります。最終的には、SHA-1証明書の有効期限が2016年に切れるサイトでも黄色の警告が表示されるようになります。
一連の警告を段階的に実施することで、Googleは不急の緊急事態を宣言しています。そして状況が悪化する前に、Webサイトのアップデートを急ぐよう勧めています。これはいいことです。SHA-1は廃止されることが決まっていますが、このことを誰も真剣に考えていないからです。
もしあなたがSSLを利用してWebサイトを運営しているなら、私が作った簡単なSHA-1テストツールを使って自分のWebサイトをテストしてみてください。そうすれば、取るべき対策が分かります。
このテストを行わない人も、この記事を読み進めることをお勧めします。この記事では、WebでSSLとSHA-1が連携する仕組みや、Googleが言うように急務である理由、各Webブラウザの対応について説明します。
重要なのは、セキュリティコミュニティが証明書の変更に伴う煩わしさを大幅に軽減させるべきだということです。なぜなら、緊急事態だと感じてWebのセキュリティ対策を実施しなければならないのはおかしいからです。
SHAとは
SHA-1を置き換えることがなぜそれほど重要なのかを理解するには、ブラウザの身になって考える必要があります。
を利用しているWebサイトを表示する場合、Webサイトはブラウザにファイル（SSL”証明書”）を渡します。この証明書は2つの処理に使用されます。Webサイトへの接続を暗号化する処理と、本物のWebサイトに接続したことを確認する処理です。
どんな証明書でも接続を暗号化できます。ただし、本物のFacebookにアクセスしたことを確認できるように、ブラウザは証明書が信頼できるかどうかを判断して、ユーザに緑色の鍵を表示する必要があります。
ブラウザは、Webサイトの証明書ファイルが”認証局”（CA）によって発行されたものかどうかを判断することでこの表示を行います。一般に、CAからこのファイルの交付を受けるときはWebサイトの所有者が費用を支払います。ブラウザは、VerisignやGoDaddyを含む50以上のさまざまな機関を、証明書の作成や保証を行うCAとして信頼しています。また、数百の中間CAがその50以上のCAに認証を受けています。ご想像のとおり、大変な欠陥がある制度ですが、これが現行の制度なのです。
当面、このWebサイトのCAはComodoです。証明書はNamecheapから購入しました。
Chromeでこのサイトの緑色の鍵をクリックした場合の表示
ブラウザには他に極めて重大な試練があります。特定のCAがWebサイトのSSL証明書を発行したときにその証明書でそれを証明できるかどうかということです。
インターネットの世界では、計算によって証明を行います。証明書を発行する際、CAは秘密鍵を使って暗号化した”署名”を証明書に付けます。これは本物のCAにしかできない方法で、またブラウザに確認できる方法でもあります。
ただし、CAは加工されていない証明書に署名するわけではありません。署名の前に、MD5、SHA-1、SHA-256などの”一方向のハッシュ”アルゴリズムを実行し、証明書をユニークなスラグに要約します。
Chromeで証明書情報の詳細を表示した場合の抜粋
一方向のハッシュを使用すると、小さいサイズを維持できます。例えば、3.2MBの『戦争と平和』にSHA-1を使用すると、baeb2c3a70c85d44947c1b92b448655273ce22bbという結果が得られます。
MD5file.com（オンラインハッシュ計算機）を使った計算結果。
SHA-1のような一方向のハッシュアルゴリズムは、不可逆性を持つユニークなスラグを生成するように設計されています。baeb2c3a70c85d44947c1b92b448655273ce22bbを逆方向に計算して、元の『戦争と平和』に戻せるべきではありません。別のファイルが同じスラグを生成することはありません。たとえピリオドを1つ変更しただけだとしても、SHA-1の使用結果は大幅に変わるはずです。
SHA-1のような一方向のハッシュを使用するとき、2つのファイルが同じスラグを生成した場合、これを”衝突”といいます。衝突は、理論上はいつでも起こりますが、実際に起こる可能性はほぼないと考えられています。
ブラウザは証明書を確認するときに、その証明書の情報をSHA-1で計算した値と、証明書に証拠として付いているSHA-1の署名を比較します。SHA-1がユニークなスラグを保証することから、ブラウザはそれらの値が一致すれば、提示された証明書がCAによって署名されていると信頼します。
もし、本物の証明書と”衝突”する証明書を作成してその証明書をCAに発行させることができれば、証明書の偽造が可能になり、ブラウザが本物と区別することはできないでしょう。
基本的な情報：署名アルゴリズムやSSL証明書について詳しく知りたい場合は、Joshua Daviesが技術情報を非常に詳しく説明しています。
SHA-1への攻撃は十分に可能ではないだろうか
2005年に、暗号研究者のグループがSHA-1の解読は従来の予測よりも2,000倍の速度で可能であることを証明しました。実際にはまだ時間も費用もかかりますが、コンピュータは日々高速化し、安価になっているため、SHA-1をインターネットで使用するのをやめるいい機会でした。
しかし、インターネットではSHA-1の使用が続きました。Bruce Schneierは2012年、Jesse Walkerが以前出したSHA-1証明書の偽造にかかるコストの推定値を転載しました。この推定値はAmazon Web Servicesの価格とムーアの法則を基に算出されたものです。
Walkerは、SHA-1の衝突にかかるコストは、2012年に約2億円、2015年に約8,000万円、2018年に約2,000万円、2021年には約500万円と推定しました。Schneierはこれらの金額に基づいて、”犯罪組織”は2018年に、大学は2021年に証明書の偽造が可能になることを示唆しました。
Walkerの推定値とSchneierの解釈は、SHA-1からの移行に関する計画や議論において広く引用されるようになりました。最近、主要なCAのグループであるCA Security CouncilはGoogleのスケジュールに抗議するためにこれを引用しました。グループはその抗議文でこれらの推定値を用いて、”2018年までは実際に攻撃されることはない”としています。
私は、CA Security Councilのこの姿勢が2014年のうちに非現実的なものになることは間違いないと思います。彼らは、早期の移行は都合が悪いという考えに基づき、明らかにこの議論を正当化しています。
WalkerとSchneierが推定値を発表したのは、スノーデンが告発する前で、関連機関も敵対者であるということを国民が正しく理解していなかった時でした。彼らの推定によれば、2014年のうちに2億円よりも少ないコストで証明書の偽造が可能になり、それは実行を決意した多くの人たちがおそらく支払う金額です。
なぜ彼らが支払うと思うのでしょうか？ 彼らにはそれだけの資金があるからです。
Flameの影響を受けたコンピュータの数（Kaspersky Labが分析）
2012年、研究者たちはFlameと呼ばれるマルウェアを発見しました。Washington Postの報道によると、これはイランの核開発を妨害するために機密情報を入手する目的で、アメリカとイスラエルが協力して開発したものでした。さらに、これを裏付けるようなNSAの文書も流出しました。
Flameは、SHA-1の前身とも言えるMD5で衝突を起こして偽造したSSL証明書を使用していました。不気味なことに、長年のMD5に関する合同研究にもかかわらず、当時は一般に知られていなかった手法でした。このニュースは、最悪の脆弱性は公表されないということを私たちに気付かせました。
また、このMD5の話は不思議な話です。SHA-1と同様に随分前から脆弱性が発見されていたのに、SHA-1と同様にインターネットから排除するまでに恐ろしく長い年月がかかったからです。
MD5に理論上の脆弱性があることが初めて指摘されたのは1995年で、長い間にさらなる脆弱性も指摘されました。しかし一部のCAは2008年までMD5の使用を続け、これは研究者たちが衝突を起こすことに成功し、偽造証明書の発行に成功した時でした。”MD5 Collisions, Inc.”に発行されたこの証明書は、ブラックリストに載せられるようにブラウザ内部で無効化されています。
Chromeでchrome://settings/certificatesにアクセスすると表示できます。
それは緊急事態でしたが、ChromeはMD5のサポートを2011年まで廃止できませんでした。MD5の信頼性が低いことが最初に指摘されてから16年経っていました。
その理由は、現在のインターネット上の署名アルゴリズムをアップデートするにあたって特殊な問題があるからです。利用者のためにブラウザでSHA-1をサポートする必要がある限り、証明書がSHA-1で偽造される可能性があるのです。SHA-1で署名を偽造して、SHA-2の署名付き証明書に見せかけることができます。ブラウザは偽造された証明書しか調べないので、”本物の”証明書が存在することやその証明書がSHA-2で署名されている”はずだ”ということは分からないからです。
つまり、SHA-1を使った証明書の偽造を防ぐには、SHA-1のサポートを廃止するしか方法がありません。腫瘍と同じで、すべて取り除かなければならないのです。
各ブラウザの対応
MicrosoftはSHA-1の廃止予定を最初に発表しました。2016年以降、WindowsとInternet ExplorerでSHA-1証明書を信頼しないという内容でした。Mozillaも同様の決定をしました。MicrosoftとMozillaの両者は、ユーザインターフェースを変更してユーザに問題があることを知らせる計画については言及していません。
一方、Googleは最近、Chromeユーザへの警告の表示ををすぐに開始することを発表して、衝撃を与えました。理由はSHA-1の脆弱性が高いためだとしています。
我々はChromeのHTTPSセキュリティインジケータで、SHA-1がChromeの設計保証を満たしていないことを示す計画を立てています。我々は計画的な方法を取っており、セキュリティインジケータを徐々に減らして、スケジュールを前倒ししています。
GoogleのRyan SleeviがChromeの今後のポリシーを初めて公表したのは2、3週間前のことですが、ディスカッションの内容をすべて読むことを強くお勧めします。CAや大規模サイトの運営者たちが、脆弱性の高い証明書の発行を来年の後半ではなく今すぐ停止するよう求めるような無謀な彼を、イライラしながら説得しようとしているのが分かります。
これはGoogleの精力的な動きですが、かなりのリスクでもあります。ブラウザにとって署名アルゴリズムの移行がこれほど難しい大きな理由の1つは、信用されているサイトの暗号が破られているとユーザに知らせることになるからです。ユーザは、ブラウザの暗号が破られているのだと判断し、別のブラウザに乗り換えます。Googleにとって、Chromeのセキュリティが十分に信頼されること、そして最初に移行することによるデメリットを我慢してくれるユーザに好まれることは、賭けのようなものなのです。
OperaもGoogleの計画を支持しています。Safariチームは成り行きを見守っているとして、計画は発表していません。
各自でできること
移行を支援するために、あなたのサイトがSHA-1を使用しているかどうか、アップデートの必要があるかどうかをチェックする簡単なWebサイト（shaaaaaaaaaaaaa.com）を作りました。
Aの数は推測されにくい大きな素数にしました。
各自で新しい証明書のリクエストを生成して、SHA-2を使用した新しい証明書をCAに発行してもらう必要があります。
既存の秘密鍵を使用する方法は以下のとおりです。
openssl req -new -sha256 -key your-private.key -out your-domain.csr
-sha256フラグはCSR自体にSHA-2で署名しますが、SHA-2で署名した証明書を発行するかどうはCAによって異なります。証明書のプロセスの間に、CAのWebサイトでコントロールを探してください。
私は、さまざまなCAからSHA-2証明書を取得する場合に備えて問題と対処法の追跡を続けています。もしここに記載されていない問題に遭遇した場合は、こちらでお知らせいただければ後でサイトを更新します。
また、SHA-1中間証明書も、デジタル署名を使用して検証されるのでアップデートする必要があるかもしれません。これは、CAがSHA-2中間証明書を発行しているかどうか、またその発行場所を特定するということです。私はさまざまなCAのSHA-2中間証明書の発行場所の調査を続けています。ここに記載がないものがある場合や、利用しているCAの記載がない場合は、こちらでお知らせください。
あなたが所有しているサイトの証明書管理を別の企業が行っている場合は、カスタマーサポートにメールで連絡して、ツイートしましょう。Googleの発表にリンクを貼った上で、その企業のスケジュールを確認します。
また、shaaaaaaaaaaaaa.comがいくらか助けになるかもしれません。もしあなたの力を借りられる場合は、未解決の問題をチェックして、手を貸してください。
SHA-1ルート証明書：ブラウザに組み込まれているSHA-1ルート証明書の心配をする必要はありません。その完全性は、デジタル署名を使用せずに検証されているからです。
証明書の変更がここまで大変なのはおかしい
ここにさらに大きな問題があります。セキュリティの問題を修正することが状況をさらに悪化させる訳がありません。WebサイトやCAがSHA-2へのアップデートを進めない大きな理由は、それが証明書の再発行を意味し、皆がSSL証明書の置き換えを嫌がっているからです。
個人の場合、証明書のプロセスというのは慣れていないし、難解な用語がたくさんあり、ユーザインターフェースも分かりにくいのです。
企業の場合、一般に証明書というのはできるだけ長期にわたって取得するもの、どこででも繰り返し利用するもの、そして本当に困ったことになるまで忘れられているものです。証明書の管理は外部に委託されることが多く、手が届きません。
Chromeの新しいポリシーに関する議論で、GoogleのRyan Sleeviが強調した点は、現在のセキュリティで証明書の変更がそれだけ面倒なのはおかしいということです。
5年間変更していないUIは、攻撃に耐えられなくなっています。サイトは、セキュリティの脅威に対する対応と適応が求められています。これは、BEASTなどのTLSプロトコルレベルの攻撃や、証明書発行に関わる暗号攻撃、矛盾するコンテンツといったアプリケーションレベルの攻撃にも当てはまります。
我々のユーザの大多数にとって、セキュリティはCAが確認するという問題ではなく、1～2ビットの状態の問題です。このモデルでは、我々が安全性を信頼するかどうかを正確にユーザに示すことが必要です。
もし12週間以内にサイトの証明書を変更できなければ、（Heartbleedが私たちに教えてくれたような）はるかに深刻なセキュリティの問題が起きると思います。
GoogleのSSL構成を調べてみれば、SHA-1で署名した証明書を利用していることが分かります。ただし、それぞれの証明書の有効期間は3か月で、この短い有効期間によって証明書が偽造される可能性が低くなる上に、2015年にはSHA-2に移行します。
重要なのは、3か月という期間によってGoogleが行う証明書の一連の作業がシンプルになるということです。これはNetflixのChaos Monkeyと同じで、わざと無秩序な状態を起こして緊急事態が日常的になるようにすることで、深刻な状況を変えています。
Googleは、GeoTrustから認証を受けて自分たちのプライベート中間CAをセットアップすることで、簡単に証明書を作成できるようにし、また必要に応じて証明書を再発行できるようにしました。だからと言って、業務プロセスの一部である証明書の一連の作業を頻繁に行うために、あなたが中間CAを所有する必要はありません。必要なのはその作業を優先させることです。それはGoogleが実行していることであり、また私たち皆が行うべきだとGoogleは主張しています。
詳細について：アイデアは他にもあります。MozillaやGoogleなどによる活発なディスカッションから出たアイデアで、有効期間が2、3日程度と非常に短い証明書を利用するというものです。そうすれば、証明書の取り消しチェックに時間を取られずに済むので、ブラウザのパフォーマンスが向上します。また、上で書いたとおり、証明書の一連の作業を頻繁に行うとセキュリティ全般の向上につながり、運用上のメリットも得られます。
最後に
SHA-1の移行は何年も前に始めるべきでした。Googleへのプレッシャーを高めるための不快感は、むしろ長年何も行っていないCAに対して向けられるべきです。
個人の場合、証明書の取得はドメイン名を買うのと同じように、証明書のインストールはWebサイトを始めるのと同じように簡単であるべきです。証明書の置き換えは自動で行われるべきです。この分野にかなりのビジネス機会が存在していることは明らかですが、オープンソースのツールとのギャップも存在しています。
組織の場合、頻繁に行う証明書の一連の作業を、組織のインフラストラクチャ設計やアップデートプロセスで優先させる必要があります。既にこの取り組みに成功している組織は、その話を公表するべきです。
一方、サイトの運営者は証明書をアップデートする必要があります。Heartbleedなどの脅威を、SSL構成を再検討するきっかけにするべきです。さらにForward Secrecyなども実装するべきです。