Question TLS et Alert 21 après la poignée de main


Nous avons un client / serveur exécutant TLS v1.0 et continuons à recevoir l’alerte de chiffrement 21 du client après la prise de contact initiale. Ils utilisent le chaînage de blocs de chiffrement et j'ai lu que la longueur d'entrée du chiffrement de bloc différente de celle d'un multiple de la longueur du bloc entraînerait l'alerte Echec du déchiffrement, mais comment trouver ces valeurs pour déterminer si c'est le vrai cause de l'alerte?

J'ai attaché la séquence de poignée de main ci-dessous ... Merci ...

Secure Sockets Layer

TLSv1 Record Layer: Handshake Protocol: Client Hello ##
    Content Type: Handshake (22)###
    Version: TLS 1.0 (0x0301)
    Length: 254
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 250
        Version: TLS 1.2 (0x0303)
        Random
            GMT Unix Time: Jun 25, 1983 13:56:23.000000000 Eastern Daylight Time
            Random Bytes: 2761896c45978dc3868cd4858d7a3d5749f7218e40f5fd3f...
        Session ID Length: 0
        Cipher Suites Length: 100
        Cipher Suites (50 suites)
        Compression Methods Length: 1
        Compression Methods (1 method)
        Extensions Length: 109
        Extension: ec_point_formats
        Extension: elliptic_curves
        Extension: SessionTicket TLS
        Extension: signature_algorithms
        Extension: Heartbeat

Secure Sockets Layer

TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 1449
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 77
        Version: TLS 1.0 (0x0301)
        Random
        Session ID Length: 32
        Session ID: 569d341d4d75bc12b41fa995f22fea93a51d14fa1d612e69...
        Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
        Compression Method: null (0)
        Extensions Length: 5
        Extension: renegotiation_info
    Handshake Protocol: Certificate
        Handshake Type: Certificate (11)
        Length: 816
        Certificates Length: 813
        Certificates (813 bytes)
    Handshake Protocol: Server Key Exchange
        Handshake Type: Server Key Exchange (12)
        Length: 540
        Diffie-Hellman Server Params
            p Length: 128
            p: fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400...
            g Length: 20
            g: 9760508f15230bccb292b982a2eb840bf0581cf5
            Pubkey Length: 128
            Pubkey: 73f35da13f584ccb05901f5242f71da41b5f35cc185409a9...
            Signature Length: 256
            Signature: 3b8a31d223c149fb0af62f653be5d61af1297c11c4d6e925...
    Handshake Protocol: Server Hello Done
        Handshake Type: Server Hello Done (14)
        Length: 0

Secure Sockets Layer

TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 134
    Handshake Protocol: Client Key Exchange
        Handshake Type: Client Key Exchange (16)
        Length: 130
        Diffie-Hellman Client Params
            Pubkey Length: 128
            Pubkey: 76ef1851a1202c19b55aebc2cf830cbb023f15f75d7c963a...
TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.0 (0x0301)
    Length: 1
    Change Cipher Spec Message
TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 48
    Handshake Protocol: Encrypted Handshake Message

Secure Sockets Layer

TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.0 (0x0301)
    Length: 1
    Change Cipher Spec Message

Secure Sockets Layer

TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 48
    Handshake Protocol: Encrypted Handshake Message

Secure Sockets Layer

client-> serveur

TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Encrypted Application Data: 50c0d7383385d5ea8aa08c9a489904b20fb508a1b53ec017...
TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 480
    Encrypted Application Data: 18ad9fa298268b2da260c4873075d8116554d3067659a0f6...

Secure Sockets Layer

serveur-> client

TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 352
    Encrypted Application Data: a425edb24ceb1fab0516b7cf64e18d571db0f222e606d1a7...

Secure Sockets Layer

client-> serveur

TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Encrypted Application Data: 4952a32d5ca081870f74397b4b45d8af9017938b92db648a...
TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 480
    Encrypted Application Data: 3a97d944ddabc997a965cc75ed946aa0dd4b13e525f44aff...

Secure Sockets Layer

serveur-> client

TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Encrypted Application Data: 47f3838b409d33cfd039f51e432e7675095f6f724ba7c728...
TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 352
    Encrypted Application Data: 8bd4f772427b1bf25901b3cc59cff003d83b02bd11421e62...

Secure Sockets Layer

client-> serveur

TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Encrypted Application Data: 1a0750299f160c207a88d6d6b2bc794373b7d45ae845129f...
TLSv1 Record Layer: Application Data Protocol: http
    Content Type: Application Data (23)
    Version: TLS 1.0 (0x0301)
    Length: 480
    Encrypted Application Data: 094956aa5f580d500d9402bc84696748f6c008d8f75bcafc...

Secure Sockets Layer

client-> serveur

TLSv1 Record Layer: Encrypted Alert
    Content Type: Alert (21)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Alert Message: Encrypted Alert

4
2018-01-20 19:11


origine


villican - s'il vous plaît ne pas ajouter des modifications qui ne font rien pour aider. - Rory Alsop
Vous comprenez que TLS v1.0 est fondamentalement cassé droit? Y a-t-il une raison pour laquelle votre client pense à son 1983? - Ramhound
@Ramhound: La norme TLS 1.0 a été publiée pour la première fois en 1999. - bwDraco
@bwDraco - Je sais en fait que ................  Vous avez complètement manqué le point de cette deuxième question sans rapport. GMT Unix Time: Jun 25, 1983 13:56:23.000000000 Eastern Daylight Time d'où ma question pourquoi le client pense son Junt 25 1983 @ 1:53 PM GMT le même de cet article. L'heure est correcte (ou assez proche) mais la date n'est pas correcte. Il est actuellement 14h39 GMT, donc, comment je sais que sa proximité. - Ramhound
21 n'est pas le numéro d'alerte, et ce n'est pas une "alerte de chiffrement". 21 est le type d'enregistrement de tout enregistrements d'alerte mais l'enregistrement de l'alerte est crypté et Wireshark ne peut pas le décrypter pour afficher "Alerte cryptée". Il pourrait être un close_notify normal, mais vérifiez les journaux du serveur pour savoir s'il pense qu'il y a eu une erreur et si oui quoi. - dave_thompson_085


Réponses:


C'est un mix

Ce n'est pas AlertDescription 21.

Au lieu de cela c'est ContentType 21.

  enum {
      change_cipher_spec(20), alert(21), handshake(22),
      application_data(23), (255)
  } ContentType;

Et maintenant? Nous savons donc que C'EST une alerte, mais qu'est-ce que c'est? Un AlertDescription le champ est large d'un octet. Alors, lequel est-ce? Et, malheureusement, la réponse est ...

Alert Message: Encrypted Alert

... nous ne savons tout simplement pas C'est crypté.

Q: Mais ne serons-nous pas en mesure de décrypter ce vidage de paquet si nous utilisons la clé privée pour le certificat?
R: Non. Cette connexion utilisait une suite de chiffrement éphémère (à savoir Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)) alors c'est en avant sécurisé et la clé de chiffrement de masse de session ne peut pas être reconstruite à partir de la clé privée du certificat.

Prenez une nouvelle trace.

Prenez une autre trace, mais cette fois, assurez-vous de pouvoir le déchiffrer par la suite. Pour ce faire, soit avoir la clé privée prête et forcer une suite non sécurisée (rien sans DHE ou ECDHE dans le nom) ou demandez à votre logiciel de vider la clé de session quelque part. (Chrome et Firefox peuvent le faire.)


7
2018-01-21 07:41



Pour que Wireshark puisse déchiffrer en utilisant une clé de serveur, vous avez besoin d'une suite sans DH (y compris ECDH). Strictement parlant, seuls DHE et ECDHE (et EC / DH_anon, rarement utilisés) sont éphémèreet DH et ECDH pourrait être déchiffré avec la clé du serveur, mais Wireshark ne le fait pas. (Et le faire vous-même est beaucoup de travail, même si à l'occasion j'ai fait un cadre ou deux manuellement.) - dave_thompson_085
@ dave_thompson_085 merci Je n'ai aucune idée de pourquoi j'ai écrit "EC". - StackzOfZtuff


... nous avons un client / serveur exécutant TLS v1.0 et continuons à recevoir l'alerte de chiffrement 21 du client après la prise de contact initiale ...

Il semble que le client soit en panne et qu'il doit être mis à niveau.

Selon RFC 5246, Le protocole TLS (Transport Layer Security) version 1.2, l'alerte 21 est decryption_failed_RESERVED. Et le sens de l'alerte:

decryption_failed_RESERVED
    Cette alerte était utilisée dans certaines versions antérieures de TLS et peut avoir
    permis certaines attaques contre le mode CBC [CBCATT]. Il doit
    NE PAS être envoyé par des implémentations conformes.


4
2018-01-20 20:30



Le numéro d'alerte n'est pas connu pour être 21 et n'est probablement pas; voir mon commentaire sur la question. Notez que le client fait apparemment une fragmentation 1 / N-1 qui a été largement implémentée en réponse à la mise en place de BEAST après la fin de 2011. Notez que la fusion des alertes 20 = MAC et 21 = 'décrypter' = CBC pour bloquer l'oracle explicite était déjà recommandée. 1.1 en 2009, et cela après que de nombreuses entreprises l'aient implémenté dans la version 1.0. - dave_thompson_085