Вопрос TLS и Alert 21 после рукопожатия


У нас есть клиент / сервер, на котором запущен TLS v1.0, и после получения первоначального рукопожатия вы получите уведомление о шифровании 21 от клиента. Они используют цепочку блоков шифрования, и я прочитал, где длина ввода блока шифрования отличается от того, что несколько отличается от длины блока, приведет к предупреждению с расшифровкой Failed, но как \ где я могу найти эти значения, чтобы определить, является ли это реальным причина для предупреждения?

Я присоединил последовательность рукопожатия ниже ... Спасибо ... Оцените это

Уровень защищенных гнезд

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

Уровень защищенных гнезд

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

Уровень защищенных гнезд

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

Уровень защищенных гнезд

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

Уровень защищенных гнезд

client-> сервер

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...

Уровень защищенных гнезд

server-> клиент

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

Уровень защищенных гнезд

client-> сервер

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...

Уровень защищенных гнезд

server-> клиент

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...

Уровень защищенных гнезд

client-> сервер

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...

Уровень защищенных гнезд

client-> сервер

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


происхождения


villican - пожалуйста, не добавляйте изменения, которые ничего не помогают. - Rory Alsop
Вы понимаете, что TLS v1.0 в основном нарушена? Есть ли причина, по которой ваш клиент думает о своем 1983 году? - Ramhound
@Ramhound: стандарт TLS 1.0 был впервые выпущен в 1999 году. - bwDraco
@bwDraco - Я действительно знаю это ................  Вы полностью упустили суть этого второго не связанного вопроса. GMT Unix Time: Jun 25, 1983 13:56:23.000000000 Eastern Daylight Time поэтому мой вопрос, почему клиент считает своим Junt 25 1983 @ 1:53 PM GMT тем же самым сообщением. Время правильное (или достаточно близко), но дата неверна. Его сейчас 14:39 PM GMT, следовательно, как я знаю его достаточно близко. - Ramhound
21 - это не номер предупреждения, и это не «предупреждение о шифровании». 21 является типом записи все записи предупреждений но запись предупреждений зашифрована, и Wireshark не может ее расшифровать, поэтому отображает «Encrypted Alert». Это возможно нормальный close_notify, но проверьте журналы сервера, чтобы узнать, если он считает, что произошла ошибка, и если да, то что. - dave_thompson_085


ответы:


Это Mixup

Это не AlertDescription 21.

Вместо этого это ContentType 21,

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

Что теперь? Значит, мы знаем, что это тревога, но, ладно, какой? AlertDescription поле шириной в один байт, Итак, кто это? И, к сожалению, ответ ...

Alert Message: Encrypted Alert

... мы просто не знаем. Он зашифрован.

Вопрос. Но разве мы не сможем просто расшифровать этот дамп пакета, если мы используем закрытый ключ для сертификата?
A: Нет. В этой связи использовался эфемерный набор шифров (а именно Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)) так что это безопасный и ключ шифрования массива сеанса не может быть восстановлен из закрытого ключа сертификата.

Возьмите новый след.

Сделайте еще один след, но на этот раз убедитесь, что впоследствии сможете его расшифровать. Чтобы сделать это, либо запустите закрытый ключ, либо внесите безопасный пакет (что угодно без DHE или ECDHE в названии), или попросите ваше программное обеспечение сбросить ключ сеанса. (Chrome и Firefox могут это сделать.)


7
2018-01-21 07:41



Чтобы Wireshark расшифровывался с использованием ключа сервера, вам нужен пакет без DH (включая ECDH). Строго говоря, только DHE и ECDHE (и EC / DH_anon, редко используемые) являются эфемерный, и DH и ECDH мог дешифровать с помощью ключа сервера, но Wireshark этого не делает. (И делать это самостоятельно - это много работы, хотя я иногда делал кадр или два вручную). - dave_thompson_085
@ dave_thompson_085 спасибо. Я понятия не имею, почему я написал «EC». - StackzOfZtuff


... у нас есть клиент / сервер, работающий под управлением TLS v1.0 и продолжающий получать оповещение шифрования 21 от клиента после первоначального рукопожатия ...

Похоже, что клиент находится на низком уровне, и его необходимо обновить.

В соответствии с RFC 5246, Протокол безопасности транспортного уровня (TLS) Версия 1.2, предупреждение 21 - decryption_failed_RESERVED, И смысл предупреждения:

decryption_failed_RESERVED
    Это предупреждение использовалось в некоторых более ранних версиях TLS и могло иметь
    разрешены определенные атаки на режим CBC [CBCATT]. Это должно
    НЕ посылается совместимыми реализациями.


4
2018-01-20 20:30



Номер предупреждения не известен как 21, и, вероятно, нет; см. мой комментарий к вопросу. Обратите внимание, что клиент, по-видимому, делает фрагментацию 1 / N-1, которая была широко реализована в ответ на BEAST, поставив ее после конца 2011 года. Обратите внимание, что слияние предупреждений 20 = MAC и 21 = 'decrypt' = CBC для блокировки явного оракула было уже рекомендовано в 1.1 в 2009 году, и это было после того, как многие из них деактировали его в 1.0. - dave_thompson_085