web-dev-qa-db-fra.com

Déterminer la version SSL / TLS à l'aide de Wireshark

À l'aide de Wireshark, j'essaie de déterminer la version de SSL/TLS qui est utilisée avec le chiffrement des données entre un poste de travail client et un autre poste de travail sur le même LAN exécutant SQL Server. La documentation à ce sujet suggère de regarder les messages ServerHello et ClientHello mais je ne vois aucun de ces messages dans le flux de messages Wireshark. J'utilise ce filtre d'affichage:

tcp.len> 1 && tcp.port == 1433

Je peux confirmer que le cryptage des données est en cours et que les paquets affichés à l'aide du filtre ci-dessus sont liés au transfert de données SQL Server que je souhaite examiner. Voici à quoi ressemble le flux de messages Wireshark:

enter image description here

ÉDITER:

Voici le volet des détails du paquet du 4e paquet après avoir appelé une connexion à la base de données et sélectionné Follow -> TCP Stream:

Packet Details Pane

C'est ce que je vois lors de l'analyse à l'aide de Microsoft Message Analyzer. Le volet d'informations TLS est destiné au paquet Client Hello.

Microsoft Message Analyzer Main Pane

Microsoft Message Analyzer TLS Details Pane

13
Guru Josh

(Ajouter une nouvelle réponse qui devrait être définitive, en laissant l'ancienne comme un débogage utile pour la façon dont nous sommes arrivés ici. Le crédit pour pointer vers la réponse réelle dans les commentaires va à @ P4cK3tHuNt3R et @ dave_thompson_085)

À l'aide de Wireshark, j'essaie de déterminer la version de SSL/TLS qui est utilisée avec le chiffrement des données entre un poste de travail client et un autre poste de travail sur le même LAN exécutant SQL Server.

Vous consultez une connexion qui utilise MS-TDS ("Tabular Data Stream Protocol"):

...the Tabular Data Stream Protocol, which facilitates interaction with
a database server and provides for authentication and channel encryption
negotiation; specification of requests in SQL (including Bulk Insert);
invocation of a stored procedure, also known as a Remote Procedure Call
(RPC); returning of data; and Transaction Manager Requests. It is an 
application layer request/response protocol.

Si vous affichez la documentatio de protocole TDS n, cela spécifie que les paquets SSL sont encapsulés dans un wrapper TDS:

A TLS/SSL negotiation packet is a PRELOGIN (0x12) packet header encapsulated
with TLS/SSL payload.

Dans la capture d'écran Microsoft Message Analyzer que vous avez publiée, nous pouvons voir l'en-tête TDS (encadré en rouge, commence par 0x12), suivi plusieurs octets plus tard par le paquet TLS CLIENT_HELLO (encadré en bleu, commence par 0x16 0x03 0x03):

TDS and encapsulated TLS headers

  • 0x16 est l'indicateur d'en-tête TLS "Handshake",
  • 0x03 0x03 est la version TLS (TLS 1.2, selon RFC 5246 ):

    La version du protocole utilisée. Ce document décrit TLS version 1.2, qui utilise la version {3, 3}. La valeur de la version 3.3 est historique, dérivant de l'utilisation de {3, 1} pour TLS 1.0.

Donc, la réponse simple à votre question, "déterminer la version de SSL/TLS", est "TLS 1.2".

Maintenant, j'ai vu différents rapports sur la capacité de Wireshark à analyser correctement les paquets TDS avec TLS codé. Je pense que la réponse est ce que vous avez commencé - cela vous dira que TLS est là, mais n'analysera pas les détails comme il le ferait avec une session TLS native.

Selon cette question StackOverflow , il semble que Microsoft Network Monitor est capable d'analyser les deux niveaux d'encapsulation. Et un commentaire y indique que Microsoft Message Analyzer est le nouvel équivalent de cet outil.

12
gowenfawr

(Ignorez cette réponse, que je laisse pour les données historiques, et lisez mon autre réponse, qui explique ce qui se passe réellement)

Mettre à jour après qu'un exemple de paquet a été ajouté à la question -

Le paquet que vous avez fourni n'est clairement pas un paquet TLS. En regardant l'hex que vous avez fourni, les trois premiers octets des données TCP sont 12 01 00, mais pour un paquet TLS, les trois premiers octets doivent être 16 03 0X, où 0x16 signifie le type d'enregistrement TLS "Handshake", 0x03 signifie SSLv3/TLSv1. *, et 0x0X indique la version TLS - 0x01 pour TLS 1.0, 0x02 pour TLS 1.1 et 0x03 pour TLS 1.2.

De plus, il y a une chaîne en texte clair "sqlexpress2012" dans le paquet, qui ne serait pas là s'il s'agissait d'un client TLS Hello.

Marked up copy of provided packet

(Comment ai-je décidé 12 01 00 était le début des données? Les 14 premiers octets du paquet sont l'en-tête Ethernet. Les 20 octets suivants sont l'en-tête IP. Le 13e octet de l'en-tête TCP est 0x50, et le premier quartet de cet octet fois 4 est la longueur de l'en-tête TCP, donc 5 * 4 = 20). Ainsi, les premiers octets de données réelles commencent par 54 octets à 12 01 00 6c 00 00 ...)

Donc, si Wireshark ne l'affichera pas comme TLS, c'est parce que ce n'est pas le cas. Vous devez revoir votre configuration de serveur.


Réponse originale:

Parce que ces paquets ne sont pas sur un port TLS standard (par exemple, 443), vous devez dire à Wireshark de les interpréter comme des paquets TLS. Par défaut, le port 1433 n'est pas interprété comme ayant TLS; la valeur par défaut pour TDS doit être non chiffrée. Par conséquent, Wireshark ne le analysera pas en tant que TLS:

Wireshark default decoding for port 1433

Pour changer cela, faites un clic droit sur l'un des paquets et sélectionnez "Décoder comme". Assurez-vous que la "valeur" du port est définie sur 1433, puis définissez "Actuel" sur SSL:

Wireshark "Decode As" dialog

Cliquez sur OK et lorsque vous revenez aux paquets, vous verrez qu'ils sont maintenant interprétés plus en détail:

Packets with SSL decoding turned on

Enfin, si vous regardez le volet de détails de l'un des paquets (je suggère d'utiliser le serveur bonjour, pas le client bonjour, au cas où le protocole a été ajusté), vous verrez la version TLS assez clairement:

Packet detail showing TLS version

4
gowenfawr

J'utilise simplement ce filtre dans Wireshark pour trouver le trafic TLS 1.0:

ssl.handshake.version==0x0301

0x0302 est TLS 1.1 et 0x0303 est TLS 1.2.

1
Brett Smith