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+を獲得するに成功しました。しかしながら、捨てられるデバイスが相当な割合を占めるようで、実際に適用するには難しいところがあります。

Windows Server IISにASPリモートデプロイメントする方法

Javaを長年続いてきたことがある方なら、Spring MVCでApache Tomcatに一気にアップロードできるEclipseの連動した環境が結構魅力的な場面だと同意すると思います。最近はファイル一つ一つをFTPでアップロードするより、パッケージにして一気にサイトの構築を済ませることが、マネジメントにも、問題発生の可能性も下げられるのでだんだん広まってくるでしょう。

この記事でIISでASPリモートデプロイメントが可能になる方法を紹介いたします。

持ち物

  • Windows Server 2012以上のサーバーOS
    • もちろんIIS役割は必須です。
    • Windows 8.0, 8.1はサポートされていないと書かれていますが、Windows 10ではこのようなことができるのかまだ確認しておりません。
  • Web Deployのインストールファイル (.msi)
  • 開発用のPCの場合、Visual Studio 2017 Community以上
    • パッケージを作れる他のパソコンでのことです。

手順

サーバー役割の選択

サーバーマネージャーで役割と機能の追加を押します。

IISマネージャーをすべて選んでインストールします。これを先にした方が成功につながるようです。

Web Deployのインストール

Web Deployソフトウェアをインストールします。Web PIで3.5、3.6バージョンをボタン一回クリックでインストールもできますが、これが問題の原因になりがちです。

一番大きい問題は接続テスト段階で404、550エラーのようなことが起こるということです。必要なコンポーネントがまったく一緒にインストールされないようです。

そういう恐れを逃れるため、自分でリンクをクリックしてインストールしてみましょう。ファイルは上記の持ち物にあります。

インストールウィザードですべてのコンポーネントインストールを必ず選んでください。インストール完了したら、サーバーも一回再起動します。できるならシステム再起動してですね。

IISメニューを読み直しする必要があるからです。

IISのエキストラ設定

再起動はいかがでしたか。IISでの仕事がまだ残っています。

もし、すべてが順調ならば、Management Servicec Delegation項目も見えるはずです。

今は何もすることはありませんが。

私がこれからリモートで管理するサイトを(作るか、既存のものを)選択して、デプロイ(Deploy)のウェブデプロイ設定(Configure Web Publish Deploying…)を押します。

ここでデプロイ権限を設定したら、このサイトにアップロードをもらえるようになります。

サイトの設定が終わったら、マネジメントサービス(Management Service)に入りましょう。

ID資格証明を適当に設定し、証明書も使えるようにhttpsの証明書を選んでおきます。

自分のドメインネームを合う証明書を事前にもらって置いたらさらに便利でしょう。

接続テスト

間違いなく設定したら、Visual Studioで接続を確かめられます。

ソリューションのプロジェクトのメニューで [公開(Publish)…]に入ります。すでにしたことがあるなら、保存されたプロフィールが先に出ると思います。

ターゲットメソッドはIISにしましょう。

Web Deployを選び、サーバー(IP / ホストネーム)、IISメニューで見えるサイトの名前(Default Web Siteなど)、ユーザー名、暗証番号、ターゲットURLを入力します。

ターゲットURLはコネクションに影響はないはずですが、プレビューのアドレスに活用するようです。

[テスト(Vaildate Connection)]ボタンを押すと、上記の設定に間違いがなく、通信に成功したが表示されます。

ファイアウォールの設定

接続失敗の場合、Windowsファイアウォールが邪魔になっている可能性があります。ファイアウォールのオプションと回線からの制限も確認します。ポート番号はトラブルシューティングをご覧ください。

トラブルシューティング

  • Web Deployを復元、アップグレードする時、命令プロンプトで次のコマンドを実行し、ハンドラーとエージェントの再起動を行います。
    • net stop msdepsvc & net start msdepsvc
    • net stop wmsvc & net start wmsvc
  • 回線にあるファイアウォールが通信を邪魔してはいけません。Web Deployment Agent Serviceは普通80番、Web Management Serviceは8172番ポートを使います。
  • MsDepSvcはAdministratorあるいはAdminグループのみで実行する必要があります。ローカルでは動作しません。
  • .NET 4.0がIISに登録されていない可能性もあります。
    • .NET 4.0がインストールされておりますが、IISのサービスプールに登録されていない可能性もあります。その原因は.NET 4.0がIISのインストール前の事前になかったからです。
    • 次のコマンドで解決できます。
      • %systemdrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -iru

結論

Springよりも強力なVisual Studioとサイトが繋がりました。SQLも一気にできそうですが、活用も知識次第だと思います。