5 votes

Chris Taylor avatar

Pourquoi le serveur FIN'ing après le démarrage de la session TLS ?

Demandé el 30 de Septembre, 2015
Quand la question a-t-elle été
15388 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Le serveur TLS fait quelque chose que je ne comprends pas.

  1. La poignée de main TCP s'exécute normalement.
  2. SSL Client Hello s'exécute normalement.
  3. SSL Server Hello semble normal. Fournit le certificat, dit "Server Hello Done".
  4. La dissection montre les problèmes du client "Échange de clés du client, changement de spécification de chiffrement, message chiffré de poignée de main".
  5. La dissection montre que le serveur émet "Change Cipher Spec" puis "Encrypted Handshake Message".

Le client envoie un ACK et commence à envoyer des données. Mais le serveur ACKs puis envoie un "Encrypted Alert" et FIN's out.

Cela s'est produit juste après avoir changé de certificat. Le certificat présenté dans la poignée de main SSL est la nouvelle clé.

Un indice, quelqu'un ?

Demandé el 30 de Septembre, 2015 par Chris Taylor

1 votes

Avatar de Falcon Momot

Il semble qu'il y ait eu une violation du protocole quelque part, ou qu'il y ait un problème avec le nouveau certificat... creusez un peu en utilisant openssl peut-être ? En particulier, essayez d'utiliser openssl s_client ?

Commenté el 30 de Septembre, 2015 par Falcon Momot

Réponses

Trop de publicités?

3voto

Rob Howard avatar
Rob Howard Points 636

C'est probablement dû à un problème de SNI avec le client ou un dispositif au milieu, comme un équilibreur de charge. Le dispositif d'équilibrage de charge doit être en mesure de présenter le nom du serveur à l'hôte backend dans le cadre du Client Hello initial. voir https://en.m.wikipedia.org/wiki/Server_Name_Indication

Répondu el 30 de Septembre, 2015 par Rob Howard (636 Points )

1voto

jcollum avatar
jcollum Points 10236

Le paquet le plus important est l'"alerte cryptée" car il contient la raison pour laquelle la connexion est fermée.

Il semble s'agir d'une erreur de validation. Cela signifie que le certificat n'est pas fiable ou qu'il n'est pas valide. Mais la vraie raison est envoyée via le Protocole d'alerte TLS

Répondu el 30 de Septembre, 2015 par jcollum (10236 Points )

1 votes

Avatar de Rob Howard

Il ne s'agit pas d'une erreur de validation du côté du certificat, sinon vous n'obtiendriez pas "change cipher spec" et le handshake, ce qui ne laisse que SNI - très bonne remarque sur l'alerte TLS - qui fournirait bien sûr la réponse définitive.

Commenté el 1 de Octobre, 2015 par Rob Howard

0 votes

Avatar de Chris Taylor

L'alerte TLS montre en hex 15 03 01 00 12 e1 54 de 28 35 56 9d d6 d1 1e 25 e7 6e 00 dc bd a7 e5. Je pense que cela signifie 0x15 == alerte, 03 01 == TLS 1.0, 0x0012 == longueur de 18, et ensuite nous devrions voir le niveau et la description, mais je n'arrive pas à comprendre ce que cela me dit.

Commenté el 10 de Décembre, 2015 par Chris Taylor

0 votes

Avatar de jcollum

Utilisez Wireshark. Il a un dissecteur de protocole pour TLS. S'il ne reconnaît pas le flux comme SSL/TLS, vous pouvez changer cela avec : "Decode As..." dans le menu contextuel d'un paquet SSL/TLS.

Commenté el 10 de Décembre, 2015 par jcollum

0voto

ulidtko avatar
ulidtko Points 376

J'ai rencontré un problème similaire avec pure-ftpd en mode TLS explicite (serveur FTPS).

Dans mon cas, cependant, il y avait pas de Encrypted Alert envoyé par le serveur ; il est juste terminé immédiatement après l'échange de clés ( Change Cipher Spec, Finished message du serveur FIN du serveur). Suivant, le client a envoyé le Encrypted alert niveau 1 code 0 Close Notify (ce qui est attendu - contrairement au serveur FIN).

Cela ne s'est produit qu'avec un seul client spécifique (un firmware de périphérique), et ne s'est pas reproduit avec d'autres clients ftps.

Je n'ai pas creusé la racine du problème, mais je pense qu'on est tombé sur un bug du serveur . pure-ftpd utilise un modèle de fork par connexion semblable à celui d'Apache ; et j'ai observé que le processus enfant se bloque dans gdb (sortie avec le code -1) - ce qui conduit bien sûr le système d'exploitation à fermer le socket FD et à envoyer FIN.

Une raison de plus pour dire que c'est un bug du serveur dans mon cas - le comportement a cessé de se reproduire dès que nous avons remplacé le serveur ftps par une implémentation différente, proftpd .

Je ne pense pas que cela corresponde au cas du PO - dans ce cas, le serveur met fin à la connexion d'une manière appropriée à TLS, avec une alerte cryptée - mais néanmoins, c'est un élément à prendre en compte pour tous ceux qui consultent cette page.

Répondu el 10 de Mars, 2020 par ulidtko (376 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X