锐英源精品开源心得，转载请注明：“锐英源www.wisestudy.cn，孙老师作品，电话13803810136。需要全文内容也请联系孙老师。

TLS握手后警告21错误

前言

TSL协议里有不同的命令包，警告是一种常见的包，报告错误状态，可以对此包提供的属性进行分析找到错误。以前研究TLS里，找到了本文英文内容，翻译出来供自己和大家提高。

提问

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

我们有一个运行TLS v1.0的客户端/服务器，并在初始握手后继续从客户端获取加密警报21。他们正在使用密码块链接，并且我已经读过，块密码输入长度不同于块长度的倍数之外的地方将导致解密失败警报，但是如何在哪里找到这些值以确定这是否真实警报的原因？

我在下面附上了握手序列......谢谢......欣赏它

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

 

回答1

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.你完全错过了第二个不相关的问题。 GMT Unix Time: Jun 25, 1983 13:56:23.000000000 Eastern Daylight Time因此，我的问题为什么客户端认为它的Junt 25 1983 @ 1:53 PM GMT与此帖相同。时间是正确的（或足够接近），但日期不正确。它目前格林尼治标准时间下午14:39，因此，我怎么知道它足够接近

回答2

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

21不是警报号，这不是“加密警报”。21是所有警报记录的记录类型，但警报记录是加密的，Wireshark无法对其进行解密，因此显示“加密警报”。它可能是一个正常的close_notify，但检查服务器日志以查明它是否认为存在错误，如果是的话

回答3

It's a Mixup

This is NOT AlertDescription 21.

Instead this is ContentType 21.

这是一个误解

这不是AlertDescription21。

相反，这是ContentType21。

 

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

现在怎么办？所以我们知道这是一个警报，但是，好的是什么？一个AlertDescription字段是一个字节宽。这是哪一个？而且，遗憾的是，答案是

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.

我们只是不知道。它是加密的。

问：但如果我们使用私钥作为证书，我们是否能够解密此数据包转储？
答：不可以。此连接使用短暂的密码套件（即Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)），因此它是前向安全的，并且无法从证书的私钥重建会话批量加密密钥。

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

重新开始。

再做一次跟踪，但这一次确保您可以在之后解密。要做到这一点，要么准备好私钥并强制使用非前向安全套件（DHE名称中没有或ECDHE的任何东西），要么让软件在某处转储会话密钥。（Chrome和Firefox可以做到这一点。）

 

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.) 要使用服务器密钥解密Wireshark，您需要没有DH的套件（包括ECDH）。严格来说，只有DHE和ECDHE（以及很少使用的EC / DH_anon）是短暂的，DH和ECDH 可以用服务器密钥解密，但Wireshark没有这样做。（并且自己做很多工作，虽然我有时会手动完成一两帧。）

回答4

  ... we have a client/server running TLS v1.0 and keep getting the Encryption Alert 21 from the client after 
the initial handshake...
我们有一个运行TLS v1.0的客户端/服务器，并在初始握手后继续从客户端获取加密警报21

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:

客户端似乎处于低级别，需要进行升级。

根据RFC 5246，传输层安全性（TLS）协议版本1.2，警报21是decryption_failed_RESERVED。而警报的含义：

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.
decryption_failed_RESERVED 
   此警报在某些早期版本的TLS中使用，并且可能
   允许某些针对CBC模式的攻击[CBCATT]。它
   不能由兼容的实现发送。

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. 警报号码不知道是21，可能不是; 看我对这个问题的评论。请注意，客户端显然正在进行1 / N-1碎片，这是为了响应BEAST在2011年末之后推出而广泛实现的。请注意，合并警报20 = MAC和21 ='decrypt'= CBC以阻止明确的oracle已被推荐在2009年1.1版本，那是在许多人已经在1.0中实施了它之后。