10

We have a client/server running TLS v1.0 and keep getting the Encryption Alert 21 from the client after the initial handshake. They are using cipher block chaining and I've read where the block cipher input length being different than something other than a multiple of the block length would cause the Decryption Failed alert but how\where would I find these values to determine if that's the real cause for the alert?

I've attached the handshake sequence below...Thanks...Appreciate it

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

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

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

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

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

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

TLSv1 Record Layer: Encrypted Alert
    Content Type: Alert (21)
    Version: TLS 1.0 (0x0301)
    Length: 32
    Alert Message: Encrypted Alert
Improve this question
6
  • 1
    villican - please don't add edits that do nothing to help.
    – Rory Alsop
    Commented Jan 20, 2016 at 19:29
  • You do understand that TLS v1.0 is basically broken right? Is there a reason your client thinks its 1983?
    – Ramhound
    Commented Jan 20, 2016 at 19:58
  • 2
    @Ramhound: The TLS 1.0 standard was first released in 1999.
    – bwDraco
    Commented Jan 20, 2016 at 20:32
  • @bwDraco - I actually know that................ You entirely missed the point of that second unrelated question. GMT Unix Time: Jun 25, 1983 13:56:23.000000000 Eastern Daylight Time hence my question why the client thinks its Junt 25 1983 @ 1:53PM GMT the same of this post. The time is correct ( or close enough ) but the date is not correct. Its currently 14:39PM GMT, hence, how I know its close enough.
    – Ramhound
    Commented Jan 20, 2016 at 20:38
  • 3
    21 is not the alert number, and this is not an "encryption alert". 21 is the record type of all alert records but the alert record is encrypted and Wireshark can't decrypt it so it displays "Encrypted Alert". It might be a normal close_notify, but check the server logs to find out if it thinks there was an error and if so what.
    – dave_thompson_085
    Commented Jan 21, 2016 at 9:01

2 Answers 2

Reset to default
13

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

Improve this answer
2
  • 1
    For Wireshark to decrypt using server key you need suite without DH (including ECDH). Strictly speaking only DHE and ECDHE (and EC/DH_anon, rarely used) are ephemeral, and DH and ECDH could be decrypted with server key, but Wireshark doesn't do so. (And doing it yourself is a lot of work, although I have on occasion done a frame or two manually.)
    – dave_thompson_085
    Commented Jan 22, 2016 at 11:32
  • @dave_thompson_085 thanks. I've got no idea why I wrote "EC".
    – StackzOfZtuff
    Commented Jan 22, 2016 at 13:27
5

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

Improve this answer
1
  • The alert number is not known to be 21 and probably isn't; see my comment on the question. Notice the client is apparently doing 1/N-1 fragmentation which was widely implemented in response to BEAST putting it after late 2011. Note that merging alerts 20=MAC and 21='decrypt'=CBC to block the explicit oracle was already recommended in 1.1 in 2009, and that was after many had defacto implemented it in 1.0.
    – dave_thompson_085
    Commented Jan 21, 2016 at 9:07

You must log in to answer this question.