問題タブ [schannel]

セキュリティ ライブラリの更新に取り組んでおり、SSL ハンドシェイクを完了してから querycontextattribute を呼び出してメッセージのヘッダー、最大サイズ、およびトレーラを取得するときに、奇妙な動作に気付きました。grbitEnabledProtocols を TLS 1_0 に設定すると、期待どおりにハンドシェイクが発生し、期待どおりに SSL パケットの 5 バイトのヘッダーが返されます。

ただし、ビット対応プロトコルを 0 に変更し、schannel が tls 1.2 を選択した場合、またはメッセージ サイズをクエリする関数が呼び出されたときに TLS 1.2 を使用するようにビット対応プロトコルを設定した場合、21 バイトのヘッダーが返されます。期待される。

TLS 1.0 を使用していた場合は不要だったので、TLS 1.2 に移行するときに行う必要がある追加の呼び出しはありますか? または、21 バイトのヘッダーを返すことは、initializesecuritycontext の処理中にエラーが発生したことを示していますか?

この質問に対する相反する答えを見てきました。DTLSを使用してセッションをアクティブにするにはどうすればよいInitializeSecurityContextですか?

クライアント証明書を使用して Web サービスを呼び出そうとしています。エラーが発生しました。安全な SSL/TLS チャネルを確立できませんでした。クライアント証明書の資格情報、アクセス許可を確認しました。すべて問題ありません。

schannel のログには、これが表示されます

1. 最初のschannelログは

CSP 名: Microsoft Strong Cryptographic Provider

CSP タイプ: 1 キー名: xxxxx キー タイプ: 不明 キー フラグ: 0x20

2. 2 番目の schannel ログはこの致命的なエラーです

schannel致命的アラート 80. 内部エラー状態は 301 です。

3. 3 番目の schannel ログは

SSL クライアント ハンドシェイクが正常に完了しました。ネゴシエートされた暗号パラメータは次のとおりです。 プロトコル: TLS 1.0 暗号スイート: 0x2f 交換強度: 2048

したがって、この致命的なエラーは私の論理を壊しています。SSLハンドシェイクが正常に完了したときにスローされる理由がわかりません。

助けてください！！！！

ありがとう

これに関する数日間のトラブルシューティング、ソリューションのグーグル検索、および必要な機能に関する Microsoft ドキュメントの再読。変数を変更し、何度も再試行します。ヘルプは非常に高く評価されています。これに遭遇したのは私だけではないと確信しています。

私は、SChannel を使用して SSL/TLS レイヤーと通信するネットワーク化されたクライアント & サーバー アプリの実装に取り​​組んでいます (後で、相互互換性のために OpenSSL と連携する予定です)。動作することがわかっているクライアントがあるので、サーバー側に集中できます。

今のところ、どちらの側にも証明書を提供せずに機能させることが目標です (必要に応じてオンザフライで生成する必要があります)。AcquireCredentialsHandle を実行し、(同じホストで実行されている) クライアントから初期トークンを読み込み、AcceptSecurityContext を呼び出します。

どの変数を変更しても、AcceptSecurityContext の最初の呼び出しで常に同じ 0x80090331 エラーが発生するようです。Windows 7 および Windows Server 2012 でテスト済み。

私のコードの外に、修正が必要な OS 設定があるに違いないと私には思えます。ウェブ上で相反する情報を見つけています。TLS 1.1 と TLS 1.2 が SecurityProviders\SCHANNEL\Protocols* の下のレジストリに追加され、データが DisabledByDefault=0 に設定されました。また、「SecurityProviders」に「,schannel.dll」を追加。

コードは次のとおりです。

... 中略 ... (AcquireCredentialsHandle を呼び出すコード)

... 中略 ... (AcceptSecurityContext を呼び出すコード)

私は、いくつかの Web ページを定期的にスクレイピングする個人使用のプログラムに取り組んでいます。そのうちの 1 つは SSL を使用する必要があり、そのメイン URL は実際には、少数のリストから毎回異なるドメインにリダイレクトするロード バランサーです (これが関連しているかどうかは不明です)。私は特に libcurl と SSL にかなり慣れていないので、明らかな何かが欠けているかもしれませんが、そうは思いません。

プログラムはしばらくの間 (これまでのところ、1 時間以上) 正常に動作しますが、初めて SSL 接続エラーが発生すると、毎回同じエラーが発生し続けます。失敗し始めるまでの時間と成功したリクエストの量は常に異なります。

エラー バッファーには常に次のものが含まれます。schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.

に役立つものは何もありませんeventvwr。そのエラー コードを検索すると、以前のバージョンの Windows Server での自己署名証明書の問題に関する結果が返されますが、それ以外はほとんどありません。接続しているサーバーを制御していませんが、それが Windows ボックスであるとは思えません。

ここではアイデアが不足しているので、関連する可能性のある詳細を説明します。すべてのcurl呼び出しをいくつかのクラスに抽象化したため、実際のソースコードを実際に投稿することはできません。他の人が理解できるようになる前に、多くのボイラープレートコードを貼り付ける必要があります. ただし、これが実際の呼び出しの結果であることを Visual Studio デバッガーで確認しました。

次のように、他のスレッドが作成される前に、メイン スレッドで libcurl を初期化します。curl_global_init(CURL_GLOBAL_WIN32 | CURL_GLOBAL_SSL);

次に、2 番目のスレッドで実際の curl ハンドルを作成して初期化し、そのスレッドでのみ次のようにします。

CURLOPT_SSL_VERIFYHOSTと の両方を0に設定して実験しましCURLOPT_SSL_VERIFYPEERたが、それは役に立ちませんでした。

Visual Studio 2013 でlibcurl をビルドcurl-7.43.0.tar.gzしました。nmake /f Makefile.vc mode=static VC=12 ENABLE_WINSSL=yes ENABLE_SSPI=yes MACHINE=x64 DEBUG=yes

ここで何が起こっていて、どうすれば修正できますか?

特定の暗号を無効にすることを検討しており、Windows でブロック暗号がどのように命名されているかについて頭を悩ませようとしています。具体的には、名前に続く数字の意味。たとえば、RC4 40/128、DES 56/56、AES 128/128、または AES 256/256 です。これはおそらくキーサイズ/ブロックサイズだと思いましたが、意味がありません。AES 256/256 を取ります。それがAESであるためには128のブロックサイズが必要であることは私の理解です。したがって、最後の数字はブロックサイズを指定できません。または、RC4 暗号を使用します。最初の数字は鍵のサイズのように見えますが、これはストリーム暗号なので、128 は何ですか? または DES 56/56。DES のキー サイズは 56 ビットで、ブロック サイズは 64 ビットだと思いましたか? 歴史やネーミングの理由を知っている人はいますか？