Pourquoi Wireshark affiche-t-il la version TLS 1.2 ici au lieu de TLS 1.3?

J'accède au serveur de test TLS 1.3 " https://tls13.pinterjann.is " via un client java http utilisant TLS 1.3. Tout semble bien fonctionner comme l'indique la réponse html:

Ce que je ne comprends pas: pourquoi Wireshark apparaît-il dans l'aperçu Protocole TLSv1.3 mais dans les détails Version TLS 1.2?

Est-ce que Wireshark affiche simplement la mauvaise version ou est-ce que j'utilise réellement TLS 1.2?

Merci d'avance pour ton soutien.

Désolé, pour la confusion, il me manquait la sémantique exacte de TLS 1.3: Par exemple, dans le client Bonjour, le champ "version" doit contenir la valeur fixe 0x0303 (TLS 1.2), tandis que la version préférée est contenue dans l'extension "prise en charge" versions ".

De RFC 8446 (spécification TLS 1.3):

struct {
      ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
      Random random;
      opaque legacy_session_id<0..32>;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^8-1>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

legacy_version: Dans les versions précédentes de TLS, ce champ était utilisé pour la négociation de version et représentait le numéro de version le plus élevé pris en charge par le client. L'expérience a montré que de nombreux serveurs n'implémentent pas correctement la négociation de version, conduisant à une «intolérance de version» dans laquelle le serveur rejette un ClientHello par ailleurs acceptable avec un numéro de version supérieur à celui qu'il prend en charge. Dans TLS 1.3, le client indique ses préférences de version dans l'extension "supported_versions" (Section 4.2.1) et le champ legacy_version DOIT être défini sur 0x0303, qui est le numéro de version pour TLS 1.2. TLS 1. 3 ClientHellos sont identifiés comme ayant une version héritée de 0x0303 et une extension prise en charge_versions présente avec 0x0304 comme la version la plus élevée qui y est indiquée. (Voir l'annexe D pour plus de détails sur la compatibilité descendante.)

Cela correspond à ce que Wireshark affiche:

Pourquoi Wireshark apparaît dans l'aperçu Protocol TLSv1.3 mais dans les détails Version TLS 1.2?

Wireshark signale TLS 1.3 dans la colonne de protocole en raison de Server Hello contenant une extension de versions prises en charge avec TLS 1.3.

Rappelez-vous que les sessions TLS commencent par une poignée de main pour négocier des paramètres tels que la version du protocole et les chiffres. Le client envoie un message de négociation Client Hello dans un enregistrement TLS contenant:

• Enregistrement TLS - Version: version TLS minimale prise en charge (dans TLS 1.2 et versions antérieures). Dans TLS 1.3, ce champ n'est pas vraiment utilisé et DOIT être 0x0303 ("TLS 1.2") ou 0x301 ("TLS 1.0") à des fins de compatibilité. Référence: RFC 8446 (page 79)
• Client Hello - Version: version TLS maximale prise en charge (dans TLS 1.2 et versions antérieures). Dans TLS 1.3, ce champ n'est pas utilisé mais DOIT être défini sur 0x0303 ("TLS 1.2"). Référence: RFC 8446 (4.1.2. Client Bonjour)
• Client Hello - Extension des versions prises en charge: liste des versions prises en charge. Il s'agit de la seule valeur utilisée par les implémentations TLS 1.3 (qui peuvent convenir à TLS 1.3, 1.2 ou à d'autres versions). Référence: RFC 8446 (4.2.1. Versions prises en charge)

Le serveur envoie un message d'établissement de liaison Server Hello avec:

• Server Hello - Version: version négociée (pour TLS 1.2 et avant). Si TLS 1.3 est négocié, il DOIT être réglé sur 0x0303 ("TLS 1.2").
• Server Hello - Versions prises en charge: une seule version négociée (pour TLS 1.3). Ne peut pas être utilisé pour négocier des versions antérieures.

Ainsi, dans TLS 1.2, le client envoie une gamme de versions prises en charge tandis qu'un client TLS 1.3 envoie une liste de versions prises en charge. Le serveur choisira alors une seule version, mais à des fins de compatibilité, il utilisera un nouveau champ pour sélectionner TLS 1.3 ou plus récent.

(Même si un client annonce la prise en charge d'une certaine version (par exemple via une version d'enregistrement TLS contenant "TLS 1.0"), il pourrait toujours échouer la poignée de main si le serveur accepte cette version basse.)

Une autre chose à savoir: Wireshark essaie d'interpréter un paquet immédiatement lors de sa réception. Au moment où le Client Hello est reçu, il ne connaîtra pas la version finale et assumera donc la version d'enregistrement TLS. Lorsque le serveur Hello est reçu, il peut ajuster la version en conséquence:

$ tshark -r test/captures/tls13-rfc8446.pcap 
    1   0.000000     10.9.0.1 → 10.9.0.2     TLSv1 304 Client Hello
    2   0.002634     10.9.0.2 → 10.9.0.1     TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
    3   0.005266     10.9.0.1 → 10.9.0.2     TLSv1.3 130 Change Cipher Spec, Application Data
    4   0.005772     10.9.0.2 → 10.9.0.1     TLSv1.3 468 Application Data
...

Dans une dissection en deux passes (qui inclut également l'interface graphique Wireshark), la version convenue sera connue lorsqu'elle imprimera les résultats de la deuxième passe:

$ tshark -r test/captures/tls13-rfc8446.pcap -2
    1   0.000000     10.9.0.1 → 10.9.0.2     TLSv1.3 304 Client Hello
    2   0.002634     10.9.0.2 → 10.9.0.1     TLSv1.3 658 Server Hello, Change Cipher Spec, Application Data
    3   0.005266     10.9.0.1 → 10.9.0.2     TLSv1.3 130 Change Cipher Spec, Application Data
    4   0.005772     10.9.0.2 → 10.9.0.1     TLSv1.3 468 Application Data
...

Capture de test utilisée ci-dessus: https://github.com/wireshark/wireshark/blob/master/test/captures/tls13-rfc8446.pcap