iOS 9 ATSで動作するようにIIS 7.5 SSL \ TLSを構成する方法

問題： iOS 9がATSを使用するようになったため、モバイルアプリはWebサービスへの安全な接続を確立できなくなりました。

背景： iOS 9にはApp Transport Securityが導入されています

サーバーのセットアップ： Windows Server 2008 R2 SP1（VM）IIS 7.5、digicertからのSSL証明書。Windowsファイアウォールがオフ。

キーRSA 2048ビット（e 65537）

発行者DigiCert SHA2セキュアサーバーCA

署名アルゴリズムSHA512withRSA

App Transport Securityの要件は次のとおりです。

サーバーは、少なくともTransport Layer Security（TLS）プロトコルバージョン1.2をサポートする必要があります。接続暗号は、前方秘匿性を提供するものに限定されます（以下の暗号のリストを参照してください）。証明書は、2048ビット以上のRSAキーまたは256ビット以上のElliptic-Curveで、SHA256以上の署名ハッシュアルゴリズムを使用して署名する必要があります（ECC）キー。証明書が無効な場合、ハード障害が発生し、接続できなくなります。これらは受け入れられた暗号です：

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

試行されたもの：

1. ドメインが機能するようにモバイルアプリに例外を追加しますが、このセキュリティで保護されていない方法を使用したくないので、SSLを修正します。
2. 使用IIS暗号を「ベストプラクティス」を使用するには、「PCI」を試してみました、およびカスタムセットアップ。暗号スイートを上記のリストだけに変更して、並べ替えを試みました。各試行の後、サーバーが再起動され、SSL Labsが実行されました（キャッシュをクリアした後）。私はFからA、さらにはA-に移行することに成功しましたが、これはiOS 8と9が安全な接続を確立できないという結果に終わりました。（NSURLErrorDomain Code = -1200および_kCFStreamErrorCodeKey = -9806）
3. VMを復元し、PowerShellスクリプトを試しましたSSL Perfect Forward SecrecyおよびTLS 1.2用にIISをセットアップしました。電源スクリプトから必要なものの最小限のリストに暗号を編集する2回目の試行も行いました。

結果：常に類似、AまたはA-の評価。iOS8およびiOS9は、安全な接続をネゴシエートできません。ハンドシェイクシミュレーションの結果、SafariおよびiOS製品で「プロトコルまたは暗号スイートの不一致」が発生します。

更新 Appleサポートと連携した後、パケットトレースキャプチャを行いました。

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

最初の3つのパケットは、TCP接続をセットアップする従来のSYN-SYN-ACK-ACK 3ウェイハンドシェイクです。4番目のパケットは、iOSがサーバーにTLSクライアントHelloメッセージを送信することです。これは、そのTCP接続を介してTLS接続をセットアップする最初のステップです。私はこのメッセージをバラバラにしましたが、それは十分に合理的です。5番目のパケットでは、サーバーは（RSTを送信して）接続を単にドロップします。

IIS 7.5がRSTを実行する理由を誰もが知っていますか？

質問は古いですが、検索中に見つかります。私は同じ問題の解決策を見つけるために時間を費やしました。したがって、結果を他の人と共有するために答えを書くことにします。

簡単な答え：IIS Cryptoを使用して暗号スイートの順序を指定しないでください。「デフォルト」ボタンをクリックして以前に設定した順序を削除し、グループポリシー（「コンピューター構成」\「管理用テンプレート」\「ネットワーク」\「SSL構成設定」）を使用してローカルポリシー経由で暗号スイートを構成することをお勧めします。

「プロトコルまたは暗号スイートの不一致」というエラーの理由は、以下のいずれかです。

• サーバーが「不正な暗号スイート」をサポートしている
• サーバーは、TLS仕様に対応する必要がある暗号スイートをサポートしていません。
• サーバーはHTTP / 2をサポートし、リストにない他のプロトコルの上にあるブラックリストの プロトコルをいくつか持っています。通常は、問題を解決するために暗号スイートの順序を変更するだけで十分です。

正確なブラックリストは、システムによって異なる場合があります。インターネットでいくつかのブラックリストを見つけることができます。たとえば、RFC 7540（ハイパーテキスト転送プロトコルバージョン2（HTTP / 2））の付録Aには1つのリストが含まれています。暗号スイートは、TLS_RSA_WITH_AES_128_CBC_SHATLS 1.2のために（参照ここ）とTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256し、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256（参照TLS 1.3のためにここに）。TLS_ECDHE_ECDSA_*唯一あなたが楕円曲線で証明書を使用している重要です。他の非常に優れた暗号スイートTLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256は、Microsoftによってまだ実装されていません。さらに、少なくともTLS_ECDHE_RSA_WITH_AES_256_CBC_SHA古いシステムからの接続TLS_RSA_WITH_AES_128_CBC_SHAをサポートし、非常に古いシステム（Android 2.3.7、Java 6u45、OpenSSL 0.9.8y）をTLS_RSA_WITH_3DES_EDE_CBC_SHAサポートするために、IE 8 / XPをサポートする必要がある場合にのみ追加することを検討できます。したがって、たとえば、今日使用することができます

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS 1.0、TLS 1.1を無効にすると、セキュリティが向上します

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

優れたセキュリティと最高のパフォーマンスが必要な場合。

たとえば、問題を解決するために、次の短い暗号スイートのセットを設定できます。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

以下に、Windows 10での構成例を示します。RSA2048キーとLet's Encryptの無料SSL証明書を使用して、Qualys SSL LabsのA +評価を持つようにIIS 10を構成しました。

DES 56/56、RC2 128/128、RC2 40/128、RC2 56/128、RC4 128/128、RC4 40/128、RC4 56/128、RC4 64/128、Triple DES 168/168、NULL、 MD5、マルチプロトコルユニファイドハロー、PCT 1.0、SSL 2.0、SSL 3.0、およびTLS 1.0 / 1.1 をレジストリに手動で追加（KB245030を参照）。TLS 1.0およびTLS 1.1プロトコルを無効にしたのは、TLS_FALLBACK_SCSV（ダウングレード攻撃）がこれまでIISで防止できなかったためです。これにより、www.ssllabs.comの A +評価を取得できなくなりました。私はそれを欠点として見ていますが、TLS 1.2は現在非常に広くサポートされています。ちなみにを使用できますDisabledByDefault: 1がEnabled: 1、TLS 1.0およびTLS 1.1用です。コンピューターでSQL Server 2008/2012を実行する場合に役立ちます。WebサーバーはTLS 1.0とTLS 1.1を使用しませんが、SQL Serverは使用します。

私の多くの時間を費やし、あなたの主な問題である最も重要なステップは、暗号スイートの構成でした。を使用して作成しましたgpedit.msc。「コンピューター構成」\「管理用テンプレート」\「ネットワーク」\「SSL構成設定」を選択し、「SSL Cipher Suite Order」値を次のように構成しました

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

上記の順序は最適ではない可能性があり、上記のすべてのプロトコルがIIS 7.5でサポートされているかどうかはわかりません（Windows 10のIIS 10.0を使用しました）。それでも、私はあなたの問題がCipher Suiteのリストに関連していると確信しています。CipherSuiteのリストを使った私の実験で説明したのとまったく同じ問題があったからです。

いずれにせよ、Group Polityで上記の設定を構成し、コンピューターを再起動した後（gpupdate /force /target:computerテストでは不十分でした）、A +評価と「ハンドシェイクシミュレーション」部分のテスト結果の次のリストが表示されます。

次のクライアントでiOSが正常にサポートされていることがわかります。

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

TLS 1.2をサポートしていないクライアントは今ではそれほど重要ではないと思われ、上記の構成はレガシークライアントのサポートと安全なプロトコルの使用との間の良い妥協点だと思います。

IIS Cryptoイメージが最新の場合、設定はそのままにして、SHA、Diffie-Hellman、およびPKCSを有効にします。これにより、評価はAになりますが、iOS 8以下では接続できます。

私はこれに数日間苦労しました。特に、Xamarin Forms PCLを使用してiOSアプリから接続し、OAuth2 Bearer Token認証を使用してASP.NET Web Api 2レストサービスに接続していました。

最終的に私にとってうまくいったのは、IIS Cryptoのベストプラクティスを使用することでした。次に、暗号スイートの順序用に設定したレジストリキーを編集します。

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

次の値で成功しました。

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256、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_256_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256、TLS_DHE_RSA_WITH_AES_256_GCM_SHA384、TLS_DHE_RSA_WITH_AES_128_GCM_SHA256、TLS_DHE_DSS_WITH_AES_256_CBC_SHA256、TLS_DHE_DSS_WITH_AES_256_CBC_SHA、TLS_DHE_DSS_WITH_AES_128_CBC_SHA256、TLS_DHE_DSS_WITH_AES_128_CBC_SHA、TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_RC4_128_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_RC4_128_MD5、TLS_RSA_WITH_DES_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

最後の1つは、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256を自動的にネゴシエートしたCharles Proxyを使用して検出されました。これにつながったのは、Charles Proxyがオン（シミュレーター証明書がインストールされている）で接続は成功していましたが、それ以外の場合は失敗したことです。ネゴシエーションで使用したスイートを追加すると、うまくいきました。iOSクライアントではなく、サーバーでサポートされているものを使用して、プロキシが残りのサービスと再ネゴシエートしているようです（？）。

暗号スイートの多くは、さまざまなiOS / OSXデバイス用の優先スイートのssllabsの仕様から取得したことに注意してください。 上記の値は、ssllabsによるXP上のIE 6以外のすべてとハンドシェークする必要があり、評価はAです。