SSL通信でクロック同期が果たす役割
最近、クライアント/サーバー通信にSSLを介したWS Trustセキュリティを実装しました。私たちのアプリケーションは世界中に広がる何千ものお客様に使用されています。安全な通信でこれまでに発生した問題の1つは、クロックが同期されていない顧客は接続が困難であり、その結果、顧客からの電話と不満が生じることです。残念ながら、これまでの反応は、このチェックを無効にするか、許容可能なクロックスキューを無限に近づけることです。
私はシステムのセキュリティが危険にさらされることを望んでおらず、サーバーの時刻（インターネット時刻に同期される）とクロックが密接に同期していない顧客からの苦情の流入を引き起こしたくありません。同期チェックが事実上無効になるのを防ぐために、まずこれが悪い考えであり、クロック同期の利点が顧客の不満や混乱のコストを上回っている理由を上司に説明する必要があります。
- SSL通信でクロック同期はどのような役割を果たし、無効にするとどのような脆弱性が発生しますか？
- 安全な顧客向けアプリケーションでのクロック同期の最大許容範囲と通常考えられるものは何ですか？
SSLでは、クロックは証明書の検証に使用されます。クライアントは、適切なサーバーと通信することを確認する必要があります。そのため、クライアントはサーバーの証明書をvalidateします。検証は多くのことを検証することを意味します。それらの2つは時計を含みます：
サーバーの証明書（および関連するすべてのCA証明書）には、現在の時刻が有効期間の範囲に含まれている必要があります。
notBeforeおよびnotAfterフィールドとしての各証明書。現在時刻は、これら2つの日付の間にある必要があります。クライアントは、適切な発行者（証明書の失効リスト）からCRL（証明書失効リスト）を取得（および検証）することにより、各証明書の失効ステータスを取得することになっています。 CA）。 CRLは、（特に）「古すぎない」場合に許容可能と見なされます。CRLには、生成された日時を示す
thisUpdateフィールドと、それ以上のnextUpdateフィールドがありますor-lessはCRLの有効期限として機能します。
クライアントのクロックがオフの場合、これらの機能のいずれかまたは両方が中断されます。たとえば、サーバーの証明書は「期限切れ」または「まだ使用不可」と見なされ、拒否されます。
クライアントのクロックがオフであることを受け入れると、クライアントが証明書とCRLの日付を無視するように変更されます。セキュリティの最終的な結果は、攻撃者がサーバーの秘密キーを盗むことに成功した場合、その攻撃者はそのサーバーを永久に偽装できることです。失効のポイントは、そのような妥協から回復するための検証済みの方法を持つことです。証明書の有効期限のポイントは、CRLが無制限に大きくなるのを防ぐことです。クライアントが失効および/または有効期限を無視する場合、生の結果は妥協が発生すると、あなたは永遠に運命づけられます。これは通常悪いことだと考えられています。
明るいことに、これはサーバーではなくクライアントの問題です。サーバーを操作する場合、証明書を適切に検証するのは、あなたではなくクライアントの仕事です。クライアントが本当に安全ではなく脆弱であることを主張している場合、少なくとも技術的にはそれを実際に防ぐことはできません（クライアントは契約上できます：クライアントの能力不足が違反、クライアントはそれを支払う必要があります）。
同様に、クライアントがサーバーと通信できる場合、クライアントはある種のネットワークに接続されています。つまり、 インターネットベースの時刻同期 が考えられます。正確なクロックを要求することは、一部の組み込みデバイスにとっては挑戦的なことですが、ネットワーク化されたコンピューター（スマートフォンを含む）にとってはそうではありません。
シンプルなバージョン（マネージャー向け）：時間同期により、リプレイ攻撃を防ぐことができます。それらがなければ、誰かがクライアントとサーバー間で送信されたパケットを記録し、データを復号化して変更してから、パケットストリームを再送信することができ、誰も賢くなりません。ただし、復号化には時間がかかるため、タイムスタンプ（両側で検証済み）は、ストリームが「リプレイ」であることを示している可能性があります。
おそらく、会社/アプリケーションのタイムアウト期間を長くすることを検討できますか？狭いウィンドウの代わりに、ウィンドウを広げることによっていくつかの利点を実現できます。もちろん、これはシステムへの完全な影響について分析する必要があります。