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

51455
jww

У нас есть клиент / сервер под управлением TLS v1.0, и мы продолжаем получать Encryption Alert 21 от клиента после первоначального рукопожатия. Они используют цепочку блоков шифров, и я прочитал, где длина входного шифра блоков, отличная от длины, кратной длине блока, вызовет предупреждение Decryption 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
villican - пожалуйста, не добавляйте правки, которые не помогают. Rory Alsop 8 лет назад 1
Вы понимаете, что `TLS v1.0` в основном сломан, верно? Есть ли причина, по которой ваш клиент считает свой 1983 год? Ramhound 8 лет назад 0
@Ramhound: стандарт TLS 1.0 был впервые выпущен в 1999 году. bwDraco 8 лет назад 2
@bwDraco - ** Я на самом деле знаю, что ................ ** Вы совершенно не поняли смысл второго не связанного с этим вопроса. «GMT Unix Time: 25 июня 1983 г. 13: 56: 23.000000000 по восточному летнему времени», поэтому мой вопрос, почему клиент считает, что его Junt 25 1983 г., 13:53 по Гринвичу, тоже самое из этого поста. Время правильное (или достаточно близкое), но дата неверная. Это в настоящее время 14:39 по Гринвичу, следовательно, насколько я знаю это достаточно близко. Ramhound 8 лет назад 0
21 не является номером предупреждения, и это не «предупреждение о шифровании». [21 - это тип записи * всех * записей предупреждений] (http://tools.ietf.org/html/rfc5246#section-6.2), но запись предупреждения зашифрована, и Wireshark не может ее расшифровать, поэтому она отображает «Зашифровано» Оповещение». Это * может быть * обычным close_notify, но проверьте журналы сервера, чтобы выяснить, считает ли он, что произошла ошибка, и если да, то что. dave_thompson_085 8 лет назад 1
Исправление: при перечитывании я вижу, что клиент оповещает, поэтому проверьте * client * logs dave_thompson_085 8 лет назад 0

2 ответа на вопрос

7
StackzOfZtuff

It's a Mixup

This is NOT AlertDescription 21.

Instead this is ContentType 21.

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

What now? So we know that it IS an alert, but, okay what kind? An AlertDescription field is one byte wide. So which one is this? And, sadly, the answer is...

Alert Message: Encrypted Alert

...we just don't know. It's encrypted.

Q: But won't we be able to just decrypt this packet dump if we use the private key for the certificate?
A: No. This connection used an ephemeral cipher suite (namely Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)) so it's forward secure and the session bulk encryption key can not be reconstructed from the certificate's private key.

Take a new trace.

Take another trace but this time make sure that you can decrypt it afterwards. In order to do that, either have the private key ready and force a non-forward-secure suite (anything without DHE or ECDHE in the name) or have your software dump the session key somewhere. (Chrome and Firefox can do this.)

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

... we have a client/server running TLS v1.0 and keep getting the Encryption Alert 21 from the client after the initial handshake...

It appears the client is down level and it needs to be upgraded.

According to RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, alert 21 is decryption_failed_RESERVED. And the meaning of the alert:

decryption_failed_RESERVED
   This alert was used in some earlier versions of TLS, and may have
   permitted certain attacks against the CBC mode [CBCATT]. It MUST
   NOT be sent by compliant implementations.

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

Похожие вопросы