TLS1.1 handshake problem (demonstrated with gnutls-cli)

Vivek Dasmohapatra vivek at
Thu Oct 15 20:13:04 CEST 2009

While investigating a report of a problem connecting to a particular 
server when using the gnutls backend of our XMPP library, we (collabora)
stumbled across this problem :

/usr/local/src/gnutls26-2.8.4/src/gnutls-cli --priority "NORMAL:%COMPAT" \
     -p 5223
Resolving ''...
Connecting to ''...
proto  [0] = 3 TLS1.1
        [1] = 2 TLS1.0
        [2] = 1 SSL3.0
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.

(the proto lines are some extra debugging I added myself)

/usr/local/src/gnutls26-2.8.4/src/gnutls-cli \
     --priority "NORMAL:%COMPAT:-VERS-TLS1.1"  -p 5223
Resolving ''...
Connecting to ''...
proto  [0] = 1 SSL3.0
        [1] = 2 TLS1.0
- The hostname in the certificate matches ''.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- Compression: NULL
- Handshake was completed

Now I'm not sure who's in the wrong here, the server or the client 
library: fwiw openssl negotiates TLS1 with the server out of the box,
but s_client doesn't state which explicit TLS minor version it's using,
so it could just be that it doesn't implement TLS 1.1 or 1.2 yet.

Enabling 1.2 and disablinng 1.1 also causes the error above (Unexpected 

Disabling %COMPAT (padding) triggers:

*** Received alert [20]: Bad record MAC


So, is this a bug in the TLS1.1/TLS1.2 implementation in gnutls, or
is it the server doing something wrong, or both?

More information about the Gnutls-devel mailing list