1

クライアント TLS 側に OpenSSL を使用するアプリケーションを使用しています。OpenSSL のバージョンを 0.9.8e から 0.9.8k にアップグレードします。そして、TLSが機能しません...

Wireshark は、新しいバージョン (OpenSSL 0.9.8k を使用) が SessionTicket 拡張子を持つクライアントの hello パケットを送信し、サーバー側が致命的な内部エラーで応答することを示しています。

以前のバージョンは、ほぼ同じ hello パケットを送信しますが、SessionTicket ext はありません。

TLSv1_client_method を SSLv23_client_method に置き換えたところ、すべて正常に動作しました。送信されたクライアントの hello パケットは、拡張子のない SSLv2 パケット (スニファ内) でした (TLS ではなく SSL だったので?)。

この拡張機能を無効にする、または別の方法で問題を解決するより良い方法はありますか?

前もってありがとう、rursw1

4

1 に答える 1

5

RFC 5077 からの引用: 「空の SessionTicket 拡張のエンコードは、RFC 4507 ではあいまいであることに注意してください。RFC 4507 の実装では、次のようにエンコードされている可能性があります。

    00 23      Extension type 35
    00 02      Length of extension contents
    00 00      Length of ticket

または、この更新と同じ方法でエンコードされている可能性があります。

    00 23      Extension type 35
    00 00      Length of extension contents

RFC 4507 クライアントをサポートしたいサーバーは、受信したのと同じ方法でエンコードされた空の SessionTicket 拡張に応答する必要があります。「そのため、私が使用したサーバーは RFC 4507 をサポートしていますが、新しい 5077 はサポートしていません。

SSL_CTX_set_options と SSL_OP_NO_TICKET を使用して「通常」に削除すると、問題が解決しました。

これが誰かを助けることを願っています...

編集:まあ、これは構成フラグ-no-tlsextでも実行できます。(perl 構成スクリプトを実行する場合)。ただし、OpenSSL 0.9.8n および OpenSSL 1.0.0 では、ソース コードの一部をコメント アウトする必要があることに注意してください。そうしないと、コンパイルされません。これは、安全な再ネゴシエーション (それ自体は安全ではないと見なされます) が必要になるためです。それ。

于 2010-04-21T13:40:06.327 に答える