OpenSSL: problème d'extension SessionTicket TLS

Question

J'utilise une application qui utilise OpenSSL côté client TLS. Nous améliorons la version OpenSSL de 0.9.8e à 0.9.8k. Wireshark montre que la nouvelle version (avec OpenSSL 0.9.8k) envoie le paquet hello client avec une extension SessionTicket - et le côté serveur répond avec une erreur interne fatale.

La version précédente envoie un paquet Hello presque identique, mais sans SessionTicket ext.

Lorsque j'ai remplacé TLSv1_client_method avec SSLv23_client_method, tout a bien fonctionné - le client a envoyé bonjour paquet était un SSLv2 (Dans le sniffer) sans extension (? Car il n'a pas été TLS mais SSL)

Y at-il un meilleur moyen de désactiver cette extension ou de 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 avoir 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 souhaitant prendre en charge des clients RFC 4507 doit répondre à une extension SessionTicket vide codée de la même manière que celle qu'il a reçue. « 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.

Espérons que cela aidera quelqu'un ...

EDIT: Eh bien, cela peut être fait aussi avec le drapeau de configuration -no-tlsext. (Lors de l'exécution du script Perl Configure). Mais attention, dans OpenSSL 0.9.8n 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ée comme dangereuse par elle-même) l'exige.