OpenSSL: SessionTicket TLS problème d'extension

Question

J'utilise une application qui utilise OpenSSL pour le côté TLS client. Nous mettons à jour la version OpenSSL 0.9.8e à 0.9.8k. Et puis TLS ne fonctionne pas ...

Wireshark montre que la nouvelle version (avec 0.9.8k OpenSSL) envoie le paquet bonjour client avec une extension SessionTicket -. Et les répond côté serveur avec une erreur interne fatale

La version précédente envoie un paquet bonjour presque identique, mais sans le poste de SessionTicket.

Quand je l'ai remplacé TLSv1_client_method avec SSLv23_client_method, tout a bien fonctionné - le paquet client ENVOYÉ bonjour était un SSLv2 un (Dans le sniffer) sans aucune extension

(car il n'a pas été TLS mais SSL?)

Y at-il une meilleure façon de désactiver cette extension ou pour résoudre le problème d'une autre manière?

Merci à l'avance, rursw1

Answer 1

Citation de RFC 5077: « Notez que l'encodage d'une extension SessionTicket vide était    ambiguë dans la RFC 4507. Une implémentation RFC 4507 peut-être codé    comme:

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

ou il peut avoir codé la même manière que cette mise à jour:

    00 23      Extension type 35
    00 00      Length of extension contents

Un serveur qui souhaite aider les clients RFC 4507 doivent répondre à un    vide extension SessionTicket codé de la même manière qu'il a reçu. « Ainsi, le serveur j'ai travaillé avec des supports RFC 4507 et non le plus récent 5077.

L'enlever 'normalement' à l'aide SSL_CTX_set_options avec SSL_OP_NO_TICKET a résolu le problème.

Hope this quelqu'un d'aide ...

EDIT: Eh bien, cela peut être fait aussi avec le drapeau de configuration de-tlsext. (Lorsque vous exécutez le script de configuration perl). Mais, faire attention que 0.9.8n OpenSSL et OpenSSL 1.0.0, vous aurez besoin de commenter certaines parties du code source ou il ne compilera pas - comme la renégociation sécurisée (qui est considéré comme dangereux par lui-même) exige il.