gnutls async rehandshakes

Sat Sep 25 09:53:19 CEST 2010

|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[0x81f9038]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<2>| EXT[0x81f9038]: Sending extension CERT_TYPE
|<2>| EXT[0x81f9038]: Sending extension SERVER_NAME
|<2>| EXT[0x81f9038]: Sending extension SAFE_RENEGOTIATION
|<2>| EXT[0x81f9038]: Sending extension SESSION_TICKET
|<3>| HSK[0x81f9038]: CLIENT HELLO was sent [112 bytes]
|<4>| REC[0x81f9038]: Sending Packet[0] Handshake(22) with length: 112
|<2>| ASSERT: gnutls_record.c:450
|<2>| ASSERT: gnutls_buffers.c:933
|<2>| ASSERT: gnutls_buffers.c:957
|<2>| ASSERT: gnutls_handshake.c:2772
|<2>| ASSERT: gnutls_buffers.c:857
|<4>| REC[0x81f9038]: Sending Packet[1] Handshake(22) with length: 112
|<4>| REC[0x81f9038]: Sent Packet[1] Handshake(22) with length: 117
|<4>| REC[0x81f9038]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[0] Handshake(22) with length: 48
|<4>| REC[0x81f9038]: Decrypted Packet[0] Handshake(22) with length: 48
|<3>| HSK[0x81f9038]: SERVER HELLO was received [48 bytes]
|<3>| HSK[0x81f9038]: Server's version: 3.1
|<3>| HSK[0x81f9038]: SessionID length: 0
|<3>| HSK[0x81f9038]: SessionID: 
|<3>| HSK[0x81f9038]: Selected cipher suite: RSA_AES_256_CBC_SHA1
|<2>| EXT[0x81f9038]: Found extension 'SESSION_TICKET/35'
|<3>| HSK[0x81f9038]: Allowing unsafe initial negotiation
|<4>| REC[0x81f9038]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[1] Handshake(22) with length: 1098
|<4>| REC[0x81f9038]: Decrypted Packet[1] Handshake(22) with length: 1098
|<3>| HSK[0x81f9038]: CERTIFICATE was received [1098 bytes]
|<4>| REC[0x81f9038]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[2] Handshake(22) with length: 4
|<4>| REC[0x81f9038]: Decrypted Packet[2] Handshake(22) with length: 4
|<3>| HSK[0x81f9038]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1332
|<3>| HSK[0x81f9038]: CLIENT KEY EXCHANGE was sent [262 bytes]
|<4>| REC[0x81f9038]: Sending Packet[1] Handshake(22) with length: 262
|<4>| REC[0x81f9038]: Sent Packet[2] Handshake(22) with length: 267
|<3>| REC[0x81f9038]: Sent ChangeCipherSpec
|<4>| REC[0x81f9038]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<4>| REC[0x81f9038]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[48]:
0302e7de0ed59cc23c0c076f5e7e2a129d9a2bbcf616ba40e86d2c6887c04cfad540ae7e6b9725fe99661a0a48e45fb6
|<9>| INT: CLIENT RANDOM[32]:
4c9da96ad4b1f1311900c375822eb7a65c4a2f702b714f51bcc656d7528c7d9c |<9>| INT:
SERVER RANDOM[32]:
4c9da96a2e7cda3976a4116d2346be24e8fda32dc16cc1c9a6c7d75fe830af91 |<9>| INT:
MASTER SECRET:
a1f91917a565a52d362127fa7fecbf589ade4e92fa112e79536ddcddb6345991d00e4798043a3af3517ac84496969093
|<9>| INT: KEY BLOCK[136]:
9148f69667f9486ef9a2d23ee55f6b19fe3d3ffb99d9fc244d0ae53be4c9b959 |<9>| INT:
CLIENT WRITE KEY [32]:
7c013f2aa1be779eb06c5c4019dd05b2fa1497cf54552cb7502711dfce9a76b7 |<9>| INT:
SERVER WRITE KEY [32]:
b608e543ca1aa97a0af17cdfdabadee28815a70cf7385ae31d84089f319873ba |<3>|
HSK[0x81f9038]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x81f9038]:
Initializing internal [write] cipher sessions |<3>| HSK[0x81f9038]: FINISHED
was sent [16 bytes] |<4>| REC[0x81f9038]: Sending Packet[0] Handshake(22) with
length: 16 |<4>| REC[0x81f9038]: Sent Packet[1] Handshake(22) with length: 277
|<2>| ASSERT: ext_session_ticket.c:582
------repeats a large number of times--------
|<4>| REC[0x81f9038]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[0x81f9038]: Received Packet[3] Alert(21) with length: 2
|<4>| REC[0x81f9038]: Decrypted Packet[3] Alert(21) with length: 2
|<4>| REC[0x81f9038]: Alert[2|51] - Decrypt error - was received
|<2>| ASSERT: gnutls_record.c:695
|<2>| ASSERT: gnutls_record.c:1055
|<2>| ASSERT: ext_session_ticket.c:582
|<2>| ASSERT: gnutls_handshake.c:3146
ERR:EcoreCon ecore_con_ssl.c:455 _ecore_con_ssl_server_init_gnutls() Error at
ecore_con_ssl.c:_ecore_con_ssl_server_init_gnutls:455! ERR:EcoreCon
ecore_con_ssl.c:468 _ecore_con_ssl_server_init_gnutls() gnutls returned with
error: GNUTLS_E_FATAL_ALERT_RECEIVED - A TLS fatal alert has been received.
ERR:EcoreCon ecore_con_ssl.c:470 _ecore_con_ssl_server_init_gnutls() Also
received alert: Decrypt error ERR:EcoreCon ecore_con_ssl.c:471
_ecore_con_ssl_server_init_gnutls() last out: Finished ERR:EcoreCon
ecore_con_ssl.c:472 _ecore_con_ssl_server_init_gnutls() last in: Server hello
done |<2>| ASSERT: gnutls_record.c:262 ERR:EcoreCon ecore_con.c:1870
_ecore_con_cl_handler() ssl handshaking failed!


On Sat, 25 Sep 2010 09:02:00 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On 09/25/2010 06:30 AM, Michael Blumenkrantz wrote:
> > Hi,
> > I am working on an asynchronous server/client api using gnutls, and there
> > are two things that are stumping me.  I have emailed you directly because
> > some of the information here I would prefer not to be public, though I
> > apologize if I have broken protocol in doing so.  My issues are as follows:
> 
> Hello,
>  I prefer having the mailing list CC for future reference and for
> someone to read when having similar problems.
I have CCed the mailing list now and removed all references to the data I
mentioned.

> > 1) asynchronous rehandshake detection
> > It seems that if a rehandshake request is sent, it is not possible to detect
> > this once I am at the point of calling gnutls_record_send?  As soon as I
> > get to this part, instead of not performing the send and returning
> > GNUTLS_E_REHANDSHAKE as expected, the data is actually sent and so my
> > client/server is lost. Is there a method of preventing this?
> 
> I don't quite understand. Is the case that you have a server that
> continuously sends, and you want to detect the GNUTLS_E_REHANDSHAKE?
> Couldn't you also recv() when you detect data in the input buffer?
The case I am talking about is simply running my server and then running
gnutls-cli -e on it to test a rehandshake.  I was more curious as to whether
there is a function to peak at the fd to see if a rehandshake request has just
been received, or something of that nature.


> > 2) certain cipher types don't seem to work at times
> > There are certain ssl servers which I do not seem to be able to connect to,
> > such as a mail server.  I have a small
> > client app which tests connections to a site, and I am unable to
> > successfully handshake with this server for some reason.  I am, however,
> > able to handshake using gnutls-cli.  After several days of googling and
> > trying to figure it out on my own, I have admitted defeat!  Attached are
> > two logs of trying to connect to the server - one for gnutls-cli and one
> > using the small client app and api that I have been working on.
> 
> I'd suggest that you start with a very basic client such as:
> http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support
> test if works and then try augmenting it for your needs. The fact that
> you get a decryption error is strange, it could mean that data were
> rearranged or straw bytes were inserted.
> 
> regards,
> Nikos
> 
My problem is that I am able to connect to all other types of servers with
whichever ciphers/macs/kx, and receiving/sending certificates works fine.  It is
just this one specific type of server which does not seem to work and I have no
idea why.
The code found at
https://svn.enlightenment.org/svn/e/trunk/ecore/src/lib/ecore_con/ecore_con_ssl.c
specifically the function _ecore_con_ssl_server_init_gnutls is where all of the
session/priority setup occurs.

-- 
Mike Blumenkrantz
Zentific: Our boolean values are huge.