IISのcipherセキュリティーを改善してSSLLabsの高得点を目指そう

IISのSSLは不完全?

Windows 10 1607、しかもServer 2016 1607というそれなりの最新1バージョンを使用しながら、IISを先週の記事で設定したことがあります。なのに、Let’s encryptに設定したのにもかかわらず、SSLLabsではこんな酷い点数になってしまったんでしょうか。

RC4を使ってはいけない理由

RC4暗号化は1987年設計されたストリーム暗号です。ストリーム暗号である分、速く適用できるし、今まで幅広く使われてきましたが、今は使用はお勧めきないそうです。いろいろ脆弱さが発見されたこと、暗号は十分に複雑ではないこと、したがって無線LANの暗号化形式の一つであるWEPを信用できなくなった原因でもあります。よって、新しいSSLプロトコルでは導入されたこともないし、そんな古いものをIISではまだサポートしていることでセキュリティーの点数に損をしてしまったわけです。

Cipher選択によって左右されるセキュリティー

SSLについての今までの記事で申しあげたとおりに、セキュリティー cipherは暗号化方法を意味します。サーバーだけではなく、クライアント側もサポートしているアルゴリズムがなければ、正しく情報通信ができないはずです。Cipherとは暗号化アルゴリズムとして定義されており、その種類は多様であります。中には、最新型セキュリティーもあれば、脆弱点を誰もが知り尽くしている古いものもあります。

もちろん、一番最新のアルゴリズムのみ使えば安全なのは当然ですが、すべてのブラウザに合わせないので、昔のOSやソフトではエラーだけが迎えてくれるでしょう。そのすべてを考慮して交換制とセキュリティー両方に近づいてみましょう。つまり、これは前回のリトライと言っても間違っていません。

IISでCipherの選択

[スタート]→[実行]に入って‘gpedit.msc’を起動するとグループ製作が出ます。グループ製作で次のパスに入ります。

パソコン管理\管理テンプレート\ネットワーク\SSL構成設定

SSL Cipher Suite Order項目を押して‘使用’を選択すると、下に入力欄があります。デフォルトはこのようになっています。

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_MD5,
TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_NULL_SHA,
TLS_PSK_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_GCM_SHA256,
TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_PSK_WITH_NULL_SHA384,
TLS_PSK_WITH_NULL_SHA256

RSA + PSK WITH NULLってなんでしょう

高順位ではありますが、RC4はもちろん、別途の暗号化アルゴリズムを持っていないものも見えます。これが保安の弱点になりうるところです。

Windowsのドキュメントでの提案

Windows公式ドキュメントからも関わっている情報を公開しています。この通りなら、大きく2つに注意しましょう。

  • 一部cipherはHTTP/2バージョンのコネクトをサポートしていないので、通信に失敗します。バージョンが2になると同時リクエストができるので、速度に必要です。
  • SCH_USE_STRONG_CRYPTOのYesバリューになっているものは安全だとみられております。なのに、SSLLabsは厳しく見るので、WEAKが付く可能性があることを忘れてはいけません。

ここでSCH_USE_STRONG_CRYPTOがYesになっているののみ入れてみます。

TLS_PSK_WITH_AES_256_GCM_SHA384,
TLS_PSK_WITH_AES_128_GCM_SHA256,
TLS_PSK_WITH_AES_256_CBC_SHA384,
TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

再びSSLLabsテストを受けてみたら、未だにWEAK判定はあります。RC4を消すことでランクもAにアップしました。

報告書を見ながら問題となったcipherを強調してみます。

TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA

このcipherさえなければ、問題ないってことですね。 さらに、ブラウザの優先順位に合わせて順番も変えました。

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

HSTS設定をすることでA+を目指そう

Cipherも無欠になったところなので、最後にもう一押しでA+を撮る裏ワザを紹介いたします。

SSLが強制されるサイトでHTTP Response Headersを設定します。

[追加(Add)…]を押して新しいアイテムを追加しましょう。

ご覧になってるように、Strict-Transport-Securityを設定します。このバリューを設定したうえで、ヘッダーに転送されたら、ユーザークライアントブラウザでは今後このサイトに対するリクエストをすべてHTTPSのみに制限し、一時的にHTTPになる可能性を防げるので、より安全な通信ができます。

ただし、これからは証明書の抹消、期限切れの問題があった場合、サイトにまったく接続できなくなるかもしれません。証明書の管理に特に気を付けなければなりません。

Name: Strict-Transport-Security
Value: max-age=31536000

SSLLabsは少なくとも120日(10368000秒)以上を要求し、理想的な値は1年(31536000秒)だそうです。

また、平文伝送の場合、このようなヘッダーは望ましくないので、リダイレクトの専用サービス一つを作り、SSL専用サイトのみこのような設定をした方がいいそうです。

あら、まだA+が出ておりません。

IISの限界というか残念なところがあります。これに対する対策も立てましょう。

  • SHA1とRC4とRCがCipherに存在しないことを確認しました。
  • OCSP StaplingはIISのデフォルト状態で問題はなさそうです。ただし、Must Stapleオプションの決め方はまだ分かっておりません。
  • Forward SecrecyはECDHEとDHEさえサポートしていれば、適切にrobust supportができるはずです。
  • TLS_FALLBACK_SCSV: ブラウザがフォールバックトライができるようにして、古いセキュリティ標準にダウングレードする攻撃につながる可能性を断つ必要があります。この脆弱でPOODLE攻撃につながることもあります。残念ながら、この機能はIISではサポートされてないそうです。
    • 代わりにTLS1.2バージョンのみサポートすることで、低いバージョンで繋がる可能性を遮断できます。
    • TLS1.2のみ許容すると次のようなデバイスでは接続できません。
      • Android 4.3以前の機器
      • Baidu 2015年1月以前バージョン
      • XPでのIE62~IE8
      • VistaでのIE7~IE8
      • Windows 7でのIE8~IE10 (Windows 7での最新バージョンはIE11)
      • Windows Phone 8.0でのIE8
      • Java 6, Java 7
      • OS X 10でのSafari 6.x

この作業の結果、A+を獲得するに成功しました。しかしながら、捨てられるデバイスが相当な割合を占めるようで、実際に適用するには難しいところがあります。

Footnotes

  1. 現時点では1703という最新バージョンがあります。
  2. IE6はSSLv3以降のコネクションがまったくサポートされておりませんので、そろそろ諦めてほしいです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です