Austinにある University of Texasと Stanford Universityの研究生が、我々が非常にセキュアである、と思っている非ブラウザーアプリケーションのSSLライブラリの使用において、重大な脆弱性のあることを明らかにした、彼らの研究結果を公開した 。高い安全性と重要なサービスには、電子商取引向けの銀行サービスと商業SDKが含まれており、相対的に重要度の低いソフトウェアには、クラウド・ストレージ・サービスやメッセージングサービスなどのサービスが含まれている。論文が問題視しているのは、敵対的テストの貧弱な状態、安全でないSSLライブラリ、安全なSSLライブラリの安全でないプログラム上の使用法、スタックの深い所に隠れている脆弱性のトラブルシューティングにおける複雑さ、開発者による証明書検証の無効化、という普及しているが、安全でないプラクティスである。
チームによる脅威モデルは、アクティブな介入者攻撃である。シミュレートされた介入者攻撃は、3つの証明書を使った。(1)クライアントが接続を試みているホストと同じ共通名を持つ自己署名された証明書(2)間違った共通名を持つ自己署名された証明書(3) AllYourSSLAreBelongTo.usと呼ばれるドメインに、信頼された証明機関から発行された有効な証明書 。介入者攻撃は、信頼の検証とホスト名検証のつながりに焦点を当てているが、証明書の失効とX.509の拡張のためのテストをしない。脅威モデルシミュレーションに使われたコードは、ここからダウンロードできる。
論文には、開発者がSSLライブラリを使うための、適切な実装の詳細が載せられている。その中には、OpenSSL 、JSSE、データトランスポートライブラリ、 Apache HttpClient, Weberknecht, cURL, PHPの fsockopen メソッド、 cURL バインディング、 Pythonの urllib, urllib2、httplibが含まれている。ほとんどのSSLライブラリは、証明書の検証を行うが、ホスト名検証の周りの一部のオプションは、クライアントにオープンのままで、このことは、ほとんどの開発者によって無視されている。例えば、アルゴリズムフィールドがnullである場合、JSSE低レベルAPI、SSLSocketFactoryクラスは、自動的に、ホスト名検証をオフにする。今度は、ほとんどのクライアントは、セキュリティリスクを招いたApacheのHttpClientを含んで、独自のホスト名検証スキームを実装していない。SSLSocketFactoryの証明書検証メソッドからの以下のコード片がこの事実を示している。
private void checkTrusted(X509Certificate[] chain, String authType, Socket socket, boolean isClient)
throws CertificateException {
...
/ / che c k e n d p o i n t i d e n t i t y
String identityAlg = sslSocket.getSSLParameters().
getEndpointIdentificationAlgorithm();
if (identityAlg != null && identityAlg.length != 0)
{
String hostname = session.getPeerHost();
checkIdentity(hostname, chain[0], identityAlg);
}
}
そのような脆弱性は、これらのライブラリを使うことで、あらゆる非ブラウザーアプリケーション用のスタックに浸透していく。SSLとデータトランスポートライブラリを使った、クライアントの正しい実装についての特定したアドバイスに関しては、論文の作者が提供しているFAQを参照のこと。
論文の後半が説明しているのは、クラウドクライアントAPI(AWS EC2 と ELB API ツール）、アプリケーション（Chaseモバイルバンキングアプリ、Rackspace IOS アプリ,Groupon android アプリ, TextSecure)、SDK(Amazon Flexible Payments Service SDK,PayPal Payments Standards SDK,), Web サービス ミドルウェア（(Apache Axis, Axis2, CodeHaus XFire、Pusher) そしてMobile Advertising(AdMob) に対する攻撃シミュレーションからの研究結果である。論文は、アプリケーション開発者に対して以下のような勧告で締めくくっている。
ファジング（必要ならブラックボックス）と敵対的テストを使って、異常なSSL証明書を提示された時にアプリケーションがどのように振る舞うかを見る。脆弱性が僅かであっても、症状は普通、そうではない。我々の事例研究の多くで、問題のソフトウェアは、意図したサーバーの証明書以外のいかなる証明書も使ってテストされていない。期待される Amazon 、 PayPal あるいは Chase の証明書の代わりに AllYourSSLAreBelongTo.usに発行された証明書を提示すると、これらのプログラムは、しきりにSSL接続を確立し、彼らの秘密を吐き出した。これらの脆弱性は、テスト中に明らかになるべきだった。
アプリケーションコードを修正したり、自己署名した そして／あるいは信用できない証明書を使ってテストするために、アプリケーションコードを修正したり、証明書検証を無効にしたりしてはいけない。我々の事例研究でわかったのは、開発者は、ソフトウェアの製品バージョン用でさえ、これらの修正を無効にすることを忘れる、ということだ。そうではなく、一時的なキーストア作成し、信頼できないCAの公開キーをその中に入れるのだ。自己署名した、あるいは信用できない証明書を使ってコードをテストする間、そのキーストアを信頼できるキーストアとして使う。
SSL接続を安全に設定するためにライブラリのデフォルトに頼ってはいけない。デフォルト設定値は、異なるライブラリ、あるいは同じライブラリの異なるバージョン間でさえ、変わる可能性がある。例えば、バージョン7.1以前の cURLは、既定では証明書を検証しなかったが、7.10以降では行う。セキュアな接続の確立に必要なオプションは、常に明示的に設定する。
そしてSSLライブラリ開発者に対して：
SSLライブラリをAPIのセマンティクスについてもっと明白にせよ。多くの場合、アプリケーション開発者は、様々なオプションやパラメータの意味を理解していないのは明白だ。例えば、 Amazon Flexible Payments Services やPayPal Payments Standard用のPHPライブラリは、cURLでホスト名検証を有効にしようとするが、そうではなく誤って、正しい既定値を上書きし、それを無効にしてしまう（セクション7.1 と7.2)。このことは安全な既定値でも不十分の可能性があることを示している。Lynxは、自己署名の証明書をチェックしようとするが、 GnuTLSの証明書検証の関数から返り値の意味を誤解釈して、チェックが実行されない（セクション7.4)。SSLライブラリAPIの正確なセマンティクスを公式化し、アプリケーションとライブラリ間の「契約」を厳密に検証することは、将来の研究の面白いトピックであり、プログラミング言語のサポートが必要かもしれない。
SSL接続を管理する責任をアプリケーションに移譲してはならない。既存のSSLライブラリは、多くのオプションをよりハイレベルのソフトウェアに公開している。これは、危険をはらんでいる。アプリケーション開発者は、証明書検証を有効化するために、あるオプションを明示的に選ばなければならないことを認識していないだろう。従って、ライブラリは、できるだけ安全な既定値を使うべきである。更に、アルゴリズムフィールドがNULL,あるいは空文字列の時に、JSSEがやっていたように、ホスト名検証のような重要な機能を黙ってスキップしてはならない（セクション4.1を参照）。その代わりに、実行時例外を上げるか、何らかの他の方法でアプリケーションに知らせるべきである。
綺麗で、一貫したエラーをレポートするインターフェースを設計せよ。 OpenSSLや GnuTLSのようなライブラリは、関数の返り値を介してあるエラーをレポートする。一方、同じ関数からの別のエラーは、引数として渡されるフラッグを通してレポートされる。一貫性を欠いたインターフェースは、開発者を混乱させ、誤ってアプリケーションでいくつかのエラーチェックを省略してしまう。
幾つかのベンダーは、論文で指摘されたバグに取り組み、FAQで公開した研究者にその結果をレポートしている。SSLに取り組んでいる開発者の便益のために、ISec Partnersは、論文で公開された脆弱性をテストできる3つのツールをリリースした。しかし、これらをSSL実装の完全な検証や著者達が推奨している敵対的テストの代用として使うことはできない。