はじめに： TLS / SSLハンドシェイクの失敗によって引き起こされる異常な接続の問題に対処するにはどうすればよいですか？アリババクラウドSREエンジニアがトラブルシューティングをお手伝いします。
1. TLS / SSLハンドシェイクの基本的なプロセス
*写真はインターネットからのものです
2.ケースの共有
2.1CFCA証明書の過去の問題
2.1.1背景
顧客は、CFCAが発行した生産現場の証明書を申請しました。関連するドメイン名が証明書で正しく構成され、HTTPSが有効になっていると、テストの結果、クライアントアプリが下位バージョンの携帯電話（iOS <10.0、Android <6.0）の関連するサイトに接続できないことがわかりました。
クライアントのデバッグにより、証明書が無効であるというエラーメッセージ（無効な証明書または証明書が不明）がコンソールに表示されることがわかりました。
2.1.2調査
最初、エンジニアは誰がクライアントの証明書を発行したのか、何が間違っているのかを知りませんでした。この種の問題の場合、通常、クライアントネットワークパッケージでさらに分析と判断を行う必要があります。したがって、お客様は、影響を受けるデバイスで問題の再現およびクライアント側のパケットキャプチャ操作を実行するように調整されます。
ネットワークパケットを取得した後、クライアント接続障害の直接の原因が、以下に示すように、TLSハンドシェイクプロセスの異常終了であることが最初に確認されます。
暗号化アラートの内容を確認してください。エラーメッセージは0x020x2Eです。TLS 1.2プロトコル（RFC5246）の定義によると、エラーはcertificate_unknownが原因です。
引き続き証明書の特定情報を確認してください。ServerHelloフレームに記載されている証明書情報によると、証明書は認証機関である中国金融認証局（CFCA）によって発行されていることがわかります。次に、証明書情報のAuthority Information Access（AIA）情報に従って、中間CAおよびルートCA証明書を確認します。証明書発行機関のルート証明書がCFCAEVROOTであることを確認してください。
問題のあるモバイルデバイス（Android 5.1）に戻り、システムに組み込まれている信頼できるCAルート証明書リストを確認しますが、CFCA EV ROOT CA証明書が見つかりません。通常接続されている携帯電話では、CAルート証明書とデフォルトを見つけることができます。 「信頼」に設定します。
CFCA証明書の関連する説明を参照してください。この組織の証明書は、iOS10.1およびAndroid6.0以降でのみルート化できます。
*参照：https：//www.cfca.com.cn/upload/20161101.pdf
2.1.3まとめ
上記の分析から、問題の根本的な原因は、低バージョンのクライアントデバイスにCFCACAルート証明書が組み込まれていないことであることがわかります。したがって、基本的なソリューションは次のとおりです。
- 別のCA組織によって発行された証明書を置き換えて、特定のデバイスでCAルート証明書がデフォルトで信頼されるようにします。
- 影響を受けるデバイスにCAルート証明書と中間証明書を手動でインストールし、ステータスを信頼するように構成します。
- クライアントアプリはCAルート証明書を事前設定し、クライアントコード構成を通じて証明書を信頼します。
さまざまなビジネスシナリオと組み合わせて、合理的なソリューションを選択する必要があります。
2.2証明書チェーンの信頼モードに起因する問題
2.2.1背景
顧客は、災害復旧バックアップアクセスアドレスを追加し、新しいドメイン名をアクティブ化し、新しい証明書を構成しました。テストでは、代替アドレスに切り替えると、Androidクライアントが正常に接続できず、証明書不明エラー（Certificate Unknown）が報告されたことがわかりました。iOSクライアントは正常に動作しました。
2.2.2調査
2.1の問題と同様に、最初に、影響を受けるデバイスで問題の再現とクライアント側のパケットキャプチャ操作を実行します。
ネットワークパケットを取得した後、クライアント接続障害の直接の原因がTLSハンドシェイクプロセスの異常終了であることが確認されました。理由は、2.1の問題である証明書不明と同じです。
質問2.1のトラブルシューティングアクションと同様に、証明書のCAルート証明書とルート証明書の信頼状況を確認します。
証明書は中間CA組織であるSecureSite Pro CA G2によって発行され、そのルートCAはDigiCertグローバルルートCAであることが判明しました。
DigiCertグローバルルートCAは、広くサポートされている証明書発行機関であり、そのルートCA証明書はほとんどのデバイスで信頼されており、影響を受けるデバイスでも確認されています。ルートCAの証明書は信頼できる状態にあるのに、なぜ証明書の検証が失敗するのですか？これが次の調査の焦点となっています。
通常の環境に切り替えられた同じデバイスも、パケットキャプチャ操作を完了しました。新しいネットワークパッケージを入手した後、比較分析を行ったところ、2つの場合のネットワークパッケージの違いは次のとおりです。
通常の環境では、サーバーから返される証明書には完全なCA証明書チェーンが含まれています。
異常な状況では、サーバーから返される証明書には、リーフノードのCA証明書のみが含まれます。
上記の手がかりによると、調査と調査により、他のプラットフォームとは異なり、AndroidクライアントはデフォルトでAIA拡張機能を使用して証明書チェーンを検証しないことがわかりました。
*参照：https：//tools.ietf.org/html/rfc3280#section-4.2.2.1 ; https://developer.android.com/training/articles/security-ssl#UnknownCa
したがって、中間CA証明書がインストールまたはキャッシュされていない場合、クライアントアプリは中間CA証明書をアクティブにプルせず、さらに信頼チェーンの検証を実行しないため、証明書の検証が失敗します。
2.2.3まとめ
上記の調査と分析から、問題はAndroidプラットフォームの証明書検証メカニズムと証明書パッケージ化方法に関連していることがわかります。ソリューションは次のとおりです。
検証プロセスをカスタマイズするには、コードレベルでTrustManagerを手動でカスタマイズします。
または、証明書を再パッケージ化し、中間CA証明書とルートCA証明書をサーバー証明書にパッケージ化します。
顧客は開発コストと環境ステータスを統合し、証明書を再パッケージ化することを選択しました。新しい証明書の構成が完了すると、問題は解決されます。
2.3暗号スイートのネゴシエーションによって引き起こされる問題
2.3.1背景
ある顧客から、iOSクライアントのアプリユーザーが特定のオペレーターのネットワーク環境で特定のビジネスサイト（HTTPSサイト）を開くことができないと報告されました。クライアントは白い画面の待機状態にあり、最終的にエラーを報告します。同じネットワーク環境で、システムブラウザはサイトを開くことができます。同じデバイスを別のネットワークオペレータに切り替えて、サイトにアクセスできます。
2.3.2調査
問題はWebレイヤーに直接現れるため、最初にCharlesを使用して分析用のHTTPレイヤーパッケージを取得してみてください。HTTPログは、関連するHTTP要求が送信されなかったことを検出しました。
したがって、TCP層で問題が発生している可能性があり、問題が再現され、影響を受けるデバイスでクライアントパケットキャプチャ操作が実行されます。
ネットワークパッケージを入手したら、まず問題を確認します。
- DNS解決結果を検索すると、ページドメイン名でネットワークパッケージが検索されます。
- DNS解決の結果に従ってサイトIPを見つけ、クライアントとIP間のアクセスを除外します。
- クライアントとサーバー間のネットワークアクティビティを観察し、TLSハンドシェイクが失敗することを確認します。
上記のネットワークパケットから、サーバー（コンピュータールームPのサーバーがアクセスサービスを提供）がClient Helloを受信した後、直接ハンドシェイク障害を返すことがわかります。この場合、サーバーは通常、ハンドシェイク障害のトラブルシューティングに協力する必要があります。理由。クライアントの状況では、トラブルシューティングをさらに絞り込むことができます。
お客様の問題の状況を再検討してください。同じネットワーク条件で、システムブラウザーがページを開くことができ、同じデバイスが別のオペレーターに切り替えられ（サイトは、アクセスサービスを提供するためにコンピュータールームQのサーバーによって提供されるようになりました）、通常どおりアクセスできます。パケットをキャプチャし、これら2つの通常の状況をさらに分析します。
3つの状況でのネットワークの観察を通じて：
- 問題のあるアプリから送信されたClientHelloは、17の暗号スイートがサポートされていることを示しています。
- 通常のアプリによって送信されたClientHelloは、26の暗号スイートがサポートされていることを示しています。
- 通常のアプリとコンピュータールームのPサーバー間でネゴシエートされる暗号スイートは次のとおりです。TLS_RAS_WITH_3DES_EDE_CBC_SHA（0x000a）（問題のあるアプリでサポートされている暗号スイートの範囲外）。
- 問題のあるアプリとサーバールームQの間でネゴシエートされる暗号スイートは次のとおりです。TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384（0xc030）（問題のアプリでサポートされている暗号スイートの範囲内）。
上記の状況に基づいて、問題の基本的な状況は次のとおりであると推測できます。
- 問題のあるアプリによって送信されたハンドシェイク要求は、17の暗号スイート（Aセット）をサポートします。
- 通常のアプリによって送信されるハンドシェイク要求は、26の暗号スイート（Bセット）をサポートします。
- コンピュータルームPのアクセスサーバーは、セットBの少なくとも1つの暗号スイートをサポートできますが、セットAのすべての暗号スイートをサポートするわけではありません。
- コンピュータルームQのアクセスサーバーは、セットAの少なくとも1つの暗号スイートとセットBの少なくとも1つの暗号スイートをサポートします。
最終的に、問題のあるアプリは、コンピュータールームPのサーバーを介してサイトにアクセスできなくなります。
2.3.3まとめ
上記の分析の結論から、クライアントとサーバーの暗号スイート間の不一致が原因で、特定の状況下でハンドシェイクが失敗することがわかります。その他の問題の解決策は次のとおりです。
クライアント暗号スイートを調整し、サポートされる暗号スイートを増やします（クライアントの基盤となるTLS / SSLライブラリのアップグレードを含みます）。
サーバー側の暗号スイートを調整し、サポートされる暗号スイートを増やします（サーバー側のTLS / SSLアクセス構成を含む）。
顧客は最終的にサーバー側の暗号化スイートを調整することを選択し、問題は解決されました。
3.まとめ
上記のケースの共有と実践から、TLSレベルの問題はクライアントの症状で類似していることがわかりますが、問題の根本的な原因はまったく異なります。ここにリストされている問題はすべての問題シナリオを網羅しているわけではありませんが、基本的なトラブルシューティングのアイデアは次のとおりです。
問題がTLS / SSLレベルにあるかどうかを判別します。
ネットワークパケットをキャプチャします。ある条件下では、その後の比較分析のために、正常な状態と異常な状態の2つのネットワークパケットをキャプチャできます。
ネットワークパケットに基づいて問題の直接的な原因を調査し、次に問題の根本的な原因をさらに調査します。
分析の結論に従って、ビジネスシナリオと組み合わせて、適切なソリューションを選択します。
このような問題のトラブルシューティングの基礎は、HTTPSおよびTLS / SSLプロトコルの理解と、分析ツールの習得です。モバイル分野では、この種の問題には一定の共通点があります。上記の結論と分析方法を直接理解することで、開発者はすぐに「穴から抜け出す」ことができます。
参照
- Webパッケージを入手する方法、https：//help.aliyun.com/document_detail/159169.html
- HTTPSとSSLによるセキュリティ、https：//developer.android.com/training/articles/security-ssl
- インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル、https：//tools.ietf.org/html/rfc5280
色（カントン）卵（レポート）
mPaaSの「モバイルセキュリティ強化」は、市場のモバイルアプリケーションで一般的なクラッキング、改ざん、海賊行為、フィッシング詐欺、メモリデバッグ、データ盗難などのさまざまなセキュリティリスクに対応し、Alibaba CloudGroupのモバイルセキュリティ強化テクノロジーに依存しており、何億ものアプリケーションのセキュリティテスト。
モバイルアプリケーションに安定した、シンプルで効果的なセキュリティ保護を効果的に提供し、アプリの全体的なセキュリティレベルを向上させ、アプリケーションが逆にクラックされないようにし、セキュリティの信頼性の高い保証を提供します。
元のリンク
この記事は、AlibabaCloudの元のコンテンツです。