
問題: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
アプリ トランスポート セキュリティの要件は次のとおりです。
サーバーは少なくともトランスポート層セキュリティ (TLS) プロトコル バージョン 1.2 をサポートする必要があります。接続暗号は、前方秘匿性を提供するものに限定されます (以下の暗号のリストを参照してください)。証明書は、2048 ビット以上の RSA キーまたは 256 ビット以上の楕円曲線 (ECC) キーのいずれかを使用して、SHA256 以上の署名ハッシュ アルゴリズムを使用して署名する必要があります。証明書が無効な場合は、ハード エラーが発生し、接続できません。受け入れられる暗号は次のとおりです。
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
試したこと:
- モバイル アプリに例外を追加してドメインを許可することはできますが、この安全でない方法は使用したくないので、SSL を修正したいと思います。
- 使用済みIIS 暗号化「ベストプラクティス」を使用するために、「pci」とカスタム設定を試しました。暗号スイートを上記のリストだけに変更し、順序を変更してみました。試行するたびにサーバーが再起動され、SSLラボが実行されました (キャッシュをクリアした後)。評価が F から A、さらには A- に上がることに成功しましたが、iOS 8 と 9 では安全な接続を確立できませんでした。(NSURLErrorDomain Code=-1200 および _kCFStreamErrorCodeKey=-9806)
- VMを復元し、PowerShellスクリプトを試しましたIIS を SSL Perfect Forward Secrecy と TLS 1.2 用に設定するさらに、パワー スクリプトから暗号を削除して、必要なものの最小限のリストにするという 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 Client Hello メッセージを送信するものであり、TCP 接続を介して TLS 接続を確立する最初のステップです。このメッセージを分析したところ、十分に妥当な内容であることがわかりました。5 番目のパケットでは、サーバーは単に接続を切断します (RST を送信することによって)。
IIS 7.5 が RST を実行する理由を知っている人はいますか?
答え1
この質問は古いものですが、検索すると見つかります。私は同じ問題の解決策を見つけるのに時間を費やしました。そこで、他の人と結果を共有するために回答を書くことにしました。
短い答え: 暗号スイートの順序を指定するために IIS Crypto を使用しないでください。以前に設定した順序を削除するには、「既定値」ボタンをクリックしてから、グループ ポリシー (「コンピューターの構成」\「管理用テンプレート」\「ネットワーク」\「SSL 構成設定」) を使用して、ローカル ポリシー経由で暗号スイートを構成することをお勧めします。
「プロトコルまたは暗号スイートが一致しません」というエラーの原因は以下のいずれかです。:
- あなたのサーバーは「不適切な暗号スイート」をサポートしています
- サーバーは TLS 仕様に準拠してサポートされている必要がある一部の暗号スイートをサポートしていません。
- サーバーはHTTP/2をサポートしており、ブラックリスト その上リストにない他のプロトコル通常、問題を解決するには、暗号スイートの順序を変更するだけで十分です。
正確なブラックリストはシステムによって異なる場合があります。インターネットでブラックリストを見つけることができます。たとえば、付録ARFC 7540 (ハイパーテキスト転送プロトコルバージョン2 (HTTP/2)) には1つのリストが含まれています。暗号スイートはTLS_RSA_WITH_AES_128_CBC_SHA
TLS 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の設定例を示します。IIS 10を次のように設定しました。Qualys SSL Labs による A+ 評価、RSA 2048 キー、Let's Encrypt の無料 SSL 証明書。
DES 56/56、RC2 128/128、RC2 40/128、RC2 56/128、RC4 128/128、RC4 40/128、RC4 56/128、RC4 64/128、トリプル DES 168/168、NULL、MD5、マルチプロトコル統合 Hello、PCT 1.0、SSL 2.0、SSL 3.0、TLS 1.0/1.1 を無効にしました。レジストリで手動で(見るKB245030TLS 1.0とTLS 1.1プロトコルを無効にしたのは、今のところIISでTLS_FALLBACK_SCSV(ダウングレード攻撃)を防ぐことができず、A+評価を得ることができないためです。ホームページ。これは欠点だと思いますが、TLS 1.2 は現在非常に幅広くサポートされています。ちなみに、 はDisabledByDefault: 1
TLS Enabled: 1
1.0 と TLS 1.1 に使用できます。コンピューターで SQL Server 2008/2012 を実行すると役立つ場合があります。Web サーバーは TLS 1.0 と TLS 1.1 を使用しませんが、SQL Server は使用します。
最も重要なステップは、暗号スイートの構成でした。これは私にとって多くの時間を費やし、主な問題でもありました。私はこれを使用して作成しましたgpedit.msc
。「コンピュータの構成」\「管理用テンプレート」\「ネットワーク」\「SSL構成設定」を選択し、「SSL暗号スイートの順序」の値を次のように構成しました。
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
上記の順序は最適ではない可能性があり、上記のすべてのプロトコルが IIS 7.5 でサポートされているかどうかはわかりません (私は Windows 10 から IIS 10.0 を使用しました)。それでも、暗号スイートのリストに関する実験中に、あなたが説明したのとまったく同じ問題が発生したため、あなたの問題は暗号スイートのリストに関連していると確信しています。
いずれにしても、グループポリシーで上記の設定を構成した後、コンピュータを再起動する(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 をサポートしていないクライアントは、私にとってはそれほど重要ではないように思われ、上記の構成は、従来のクライアントのサポートと安全なプロトコルの使用との間の適切な妥協点であると思います。
答え2
IIS Crypto イメージが最近のものである場合は、設定をそのままにして、SHA、Diffie-Hellman、および PKCS を有効にします。これにより、A 評価が得られますが、iOS 8 以前のバージョンでも接続できるようになります。
答え3
私は数日間これに苦労しました。具体的には、Xamarin Forms PCL を使用して iOS アプリから接続し、OAuth2 Bearer Token 認証を使用して ASP.NET Web Api 2 REST サービスに接続していました。
最終的に私にとってうまくいったのは、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_ECDH E_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_CB C_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_SH A256_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_WI TH_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 クライアントではサポートされていないもので、REST サービスと再ネゴシエートしていたようです。
多くの暗号スイートは、ssllabs のさまざまな iOS/OSX デバイスの推奨スイートの仕様から取得されたことに注意してください。 上記の値は、XP上のIE 6以外のすべてとハンドシェイクするはずです。ssllabs によると、A 評価です。