From joke at seiken.de  Tue Apr  2 14:40:32 2013
From: joke at seiken.de (Joke de Buhr)
Date: Tue, 02 Apr 2013 14:40:32 +0200
Subject: [gnutls-help] heartbeat procedure
In-Reply-To: <6962721.bkq5QQDH06@localhost.localdomain>
References: <7933709.k2DEecuHSZ@localhost.localdomain>
 <CAJU7zaLDBXML-qyYEXmtBff_bsbJARj5X0L5LAtQZRo-C-6mCA@mail.gmail.com>
 <6962721.bkq5QQDH06@localhost.localdomain>
Message-ID: <1458218.FGVH02a0MI@localhost.localdomain>

despite my previous statement i think there may be other problems with the 
handshake procedure.

just to recall the test mini-dtls-heartbeat.c is working correctly. 
i enabled heartbeats:

    gnutls_heartbeat_enable(session, GNUTLS_HB_PEER_ALLOWED_TO_SEND);

and i'm pinging the peer with

    gnutls_heartbeat_ping(session, 256, 0, 0);

changing it to 

    gnutls_heartbeat_ping(session, 256, 5, GNUTLS_HEARTBEAT_WAIT);

doesn't change the reported errors.

i tried various parameters but it change the odd heartbeat behavior.

i also tried sending out a ping request every 100ms in an endless loop. most 
of the time the pinged peer reports a -9 error during gnutls_receive() but 
sometimes a correct -293 error is reported. i tried increasing the size of the 
ping every ping request but it's not related to the problem.


the error originates in

    hb_len = _gnutls_read_uint16 (msg + 1);
    if (hb_len > len - 3)
      return gnutls_assert_val (GNUTLS_E_UNEXPECTED_PACKET_LENGTH);

and with hb_len being >10000 most of the time an len being 257.
if the correct -293 error is returned hb_len is 103 and len 257.

any ideas why the correct hb_len size might be calculated?


regards joke


|<7>| READ: Got 317 bytes from 0x1eaadc0
|<7>| READ: read 317 bytes from 0x1eaadc0
|<7>| RB: Have 0 bytes into buffer. Adding 317 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x1eb1a60]: SSL 254.255 HeartBeat packet received. Epoch 1, length: 
304
|<4>| REC[0x1eb1a60]: Expected Packet Application Data(23)
|<4>| REC[0x1eb1a60]: Received Packet HeartBeat(24) with length: 304
|<4>| REC[0x1eb1a60]: Decrypted Packet[1.315] HeartBeat(24) with length: 257
|<2>| ASSERT: /build/lib/src/libgnutls/lib/ext/heartbeat.c:298
|<2>| ASSERT: /build/lib/src/libgnutls/lib/gnutls_record.c:1247
|<2>| ASSERT: /build/lib/src/libgnutls/lib/gnutls_record.c:1350
!!!!! receive(): -9
|<7>| READ: Got 317 bytes from 0x1eaadc0
|<7>| READ: read 317 bytes from 0x1eaadc0
|<7>| RB: Have 0 bytes into buffer. Adding 317 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x1eb1a60]: SSL 254.255 HeartBeat packet received. Epoch 1, length: 
304
|<4>| REC[0x1eb1a60]: Expected Packet Application Data(23)
|<4>| REC[0x1eb1a60]: Received Packet HeartBeat(24) with length: 304
|<4>| REC[0x1eb1a60]: Decrypted Packet[1.316] HeartBeat(24) with length: 257
|<2>| ASSERT: /build/lib/src/libgnutls/lib/ext/heartbeat.c:313
|<2>| ASSERT: /build/lib/src/libgnutls/lib/gnutls_record.c:1247
|<2>| ASSERT: /build/lib/src/libgnutls/lib/gnutls_record.c:1350
!!!!! receive(): -293
|<4>| REC[0x1eb1a60]: Preparing Packet HeartBeat(24) with length: 222 and 
target length: 222
|<9>| ENC[0x1eb1a60]: cipher: AES-128-CBC, MAC: SHA1, Epoch: 1
|<7>| WRITE: enqueued 285 bytes for 0x1eaadc0. Total 285 bytes.
|<7>| WRITE FLUSH: 285 bytes in buffer.
|<7>| WRITE: wrote 285 bytes, 0 bytes left.
|<4>| REC[0x1eb1a60]: Sent Packet[4] HeartBeat(24) in epoch 1 and length: 285



On Wednesday 27 March 2013 15:47:22 you wrote:
> Thanks for pointing out the test file. It ran successfully and upon further
> investigation I discovered a flow in the pull function i wrote which only
> affected heartbeats. This fixed heartbeats are working.
> 
> regards
> Joke
> 
> On Tuesday 26 March 2013 13:09:43 you wrote:
> > On Tue, Mar 26, 2013 at 12:34 PM, Joke de Buhr <joke at seiken.de> wrote:
> > > sorry, during writing the email the function names got mixed up. i'm
> > > setting>
> > > 
> > >     gnutls_heartbeat_enable(session, GNUTLS_HB_LOCAL_ALLOWED_TO_SEND);
> > > 
> > > and on the client side and
> > > 
> > >     gnutls_heartbeat_enable(session, GNUTLS_HB_PEER_ALLOWED_TO_SEND);
> > 
> > Then my advice would be to focus on the second part of the initial answer.
> > 
> > >> Check tests/mini-dtls-heartbeat.c.
> > 
> > Does this test run successfully? If yes, did you try to send
> > heartbeats the same way it does?
> > 
> > regards,
> > Nikos


From nmav at gnutls.org  Tue Apr  2 22:13:38 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 02 Apr 2013 22:13:38 +0200
Subject: [gnutls-help] heartbeat procedure
In-Reply-To: <1458218.FGVH02a0MI@localhost.localdomain>
References: <7933709.k2DEecuHSZ@localhost.localdomain>
 <CAJU7zaLDBXML-qyYEXmtBff_bsbJARj5X0L5LAtQZRo-C-6mCA@mail.gmail.com>
 <6962721.bkq5QQDH06@localhost.localdomain>
 <1458218.FGVH02a0MI@localhost.localdomain>
Message-ID: <515B3BF2.3050404@gnutls.org>

On 04/02/2013 02:40 PM, Joke de Buhr wrote:

> despite my previous statement i think there may be other problems with the 
> handshake procedure.
> just to recall the test mini-dtls-heartbeat.c is working correctly. 


You are right. It seems there is a bug in the library which was hidden
due to a bug in the test. I've committed a fix for the library at:

https://gitorious.org/gnutls/gnutls/commit/fed208e129ccd61b19b0036d1ff5f55b62b496c2/diffs/c2793ea302bc5e499c19f8969ca473045ca8d768

regards,
Nikos


From mk at cognitivedissonance.ca  Sun Apr  7 21:36:38 2013
From: mk at cognitivedissonance.ca (MK)
Date: Sun, 7 Apr 2013 15:36:38 -0400
Subject: [gnutls-help] Using password encrypted keys with certificates
Message-ID: <20130407153638.dd7d6a22071f9e4d267d8d33@cognitivedissonance.ca>

I've been developing an http(s) server in my spare time for a few years
and last fall converted it to use gnutls.

Up until now I've been using certificates with keys that are not
password encrypted, via gnutls_certificate_set_x509_key_mem(), but I
need to add functionality to deal with keys that are encrypted
with a password.   What is the basic procedure for doing this?

Thanks -- MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)



From nmav at gnutls.org  Mon Apr  8 17:41:10 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 08 Apr 2013 17:41:10 +0200
Subject: [gnutls-help] Using password encrypted keys with certificates
In-Reply-To: <20130407153638.dd7d6a22071f9e4d267d8d33@cognitivedissonance.ca>
References: <20130407153638.dd7d6a22071f9e4d267d8d33@cognitivedissonance.ca>
Message-ID: <5162E516.4050502@gnutls.org>

On 04/07/2013 09:36 PM, MK wrote:

> I've been developing an http(s) server in my spare time for a few years
> and last fall converted it to use gnutls.
> 
> Up until now I've been using certificates with keys that are not
> password encrypted, via gnutls_certificate_set_x509_key_mem(), but I
> need to add functionality to deal with keys that are encrypted
> with a password.   What is the basic procedure for doing this?


The simplest way is to use gnutls_certificate_set_x509_simple_pkcs12_file().

http://gnutls.org/manual/html_node/Core-TLS-API.html#index-gnutls_005fcertificate_005fset_005fx509_005fsimple_005fpkcs12_005ffile


regards,
Nikos


From joke at seiken.de  Tue Apr  9 22:02:25 2013
From: joke at seiken.de (Joke de Buhr)
Date: Tue, 09 Apr 2013 22:02:25 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
Message-ID: <4948934.xC52EFgUjU@oberon>

hi,

i'm not use but a have to questions regarding the dtls implementation.

first of all i'm using the multiple threads and every thread can receive 
packets from the udp socket. each thread calls the receive() and the packet is 
copied into the correct gnutls of the correct session.

if i'm using only one thread it's more or less guarantied gnutls receives the 
data in the correct order. reodering of udp packets is still possible though.
everything works fine and the handshake completes.

but if the packet are received out of order gnutls doesn't seem to write all 
the outgoing packet. check the log "Discarded duplicate message[0]: 
Handshake?.

since udp/ip doesn't use sequence numbers reordering can always be an issue 
and gnutls should handle it during the handshake procedure. even if the 
reordering is caused by threads.

and other problem seems to be a problem with the dtls retransmission. each 
side doesn't seem to honer the timeout. if the timer run out both side just 
try to pull data with doesn't work and causes a EGAIN. which 


regards
joke


|<7>| READ: Got 208 bytes from 0x7f618c004cc0
|<7>| READ: read 208 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 208 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0, 
length: 195
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 195
|<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.1] Handshake(22) with length: 
195
|<6>| BUF[REC]: Inserted 195 bytes of Data(22)
|<3>| HSK[0x7f618c004ea0]: CLIENT HELLO (1) was received. Length 183[183], 
frag offset 0, frag length: 183, sequence: 1
|<3>| HSK[0x7f618c004ea0]: Client's version: 254.255
|<2>| ASSERT: /libgnutls/lib/gnutls_db.c:278
|<3>| EXT[0x7f618c004ea0]: Found extension 'STATUS REQUEST/5'
|<3>| EXT[0x7f618c004ea0]: Found extension 'CERT TYPE/9'
|<3>| EXT[0x7f618c004ea0]: Found extension 'SAFE RENEGOTIATION/65281'
|<3>| EXT[0x7f618c004ea0]: Found extension 'HEARTBEAT/15'
|<3>| EXT[0x7f618c004ea0]: Found extension 'SESSION TICKET/35'
|<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC/10'
|<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
|<3>| EXT[0x7f618c004ea0]: Found extension 'STATUS REQUEST/5'
|<3>| EXT[0x7f618c004ea0]: Found extension 'CERT TYPE/9'
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 
bytes)
|<3>| EXT[0x7f618c004ea0]: Found extension 'HEARTBEAT/15'
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'SESSION TICKET/35' (0 bytes)
|<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC/10'
|<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'CERT TYPE/9' (2 bytes)
|<3>| HSK[0x7f618c004ea0]: Selected certificate type OPENPGP (2)
|<3>| EXT[0x7f618c004ea0]: Found extension 'SAFE RENEGOTIATION/65281'
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'HEARTBEAT/15' (1 bytes)
|<2>| HB: received parameter 1 (1 bytes)
|<3>| EXT[0x7f618c004ea0]: Found extension 'SESSION TICKET/35'
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
|<3>| HSK[0x7f618c004ea0]: Selected ECC curve SECP192R1 (5)
|<3>| EXT[0x7f618c004ea0]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' 
(2 bytes)
|<2>| ASSERT: /libgnutls/lib/ext/server_name.c:300
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP 
(2)
|<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype: 
OPENPGP (2)
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: 
ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: 
ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: 
ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: 
ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 
(C0.13)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 
(C0.27)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 
(C0.2F)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 
(C0.14)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 
(C0.30)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 
(C0.12)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 
(00.41)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 
(00.84)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 
(00.33)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 
(00.67)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 
(00.45)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 
(00.9E)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 
(00.39)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 
(00.6B)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 
(00.88)
|<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 
(00.16)
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Requested cipher suites[size: 74]: 
|<3>|   0xc0, 0x09 ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>|   0xc0, 0x23 ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>|   0xc0, 0x2b ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>|   0xc0, 0x0a ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>|   0xc0, 0x24 ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>|   0xc0, 0x2c ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>|   0xc0, 0x08 ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>|   0xc0, 0x13 ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x7f618c004ea0]: Selected Compression Method: NULL
|<3>| HSK[0x7f618c004ea0]: Safe renegotiation succeeded
|<2>| ASSERT: /libgnutls/lib/ext/status_request.c:197
|<3>| EXT[0x7f618c004ea0]: Sending extension CERT TYPE (1 bytes)
|<3>| EXT[0x7f618c004ea0]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| HB: sending parameter 1
|<3>| EXT[0x7f618c004ea0]: Sending extension HEARTBEAT (1 bytes)
|<3>| EXT[0x7f618c004ea0]: Sending extension SUPPORTED ECC POINT FORMATS (2 
bytes)
|<3>| HSK[0x7f618c004ea0]: SessionID: 
a9a8d07103670e3b14aad8e1e316f6fb41f1a6298b2ae96b7126ada49201db51
|<3>| HSK[0x7f618c004ea0]: SERVER HELLO was queued [105 bytes]
|<7>| HWRITE: enqueued [SERVER HELLO] 105. Total 105 bytes.
|<3>| Sending PGP key ID d223dc8428ac7593 (subkey)
|<3>| HSK[0x7f618c004ea0]: CERTIFICATE was queued [1134 bytes]
|<7>| HWRITE: enqueued [CERTIFICATE] 1134. Total 1239 bytes.
|<3>| HSK[0x7f618c004ea0]: signing handshake data: using RSA-SHA1
|<9>| Looking keyid: d223dc84.28ac7593
|<9>| Found keyid: d223dc84.28ac7593
|<9>| Signing using PGP key ID d223dc8428ac7593
|<9>| Looking keyid: d223dc84.28ac7593
|<9>| Found keyid: d223dc84.28ac7593
|<3>| HSK[0x7f618c004ea0]: SERVER KEY EXCHANGE was queued [195 bytes]
|<7>| HWRITE: enqueued [SERVER KEY EXCHANGE] 195. Total 1434 bytes.
|<3>| HSK[0x7f618c004ea0]: CERTIFICATE REQUEST was queued [18 bytes]
|<7>| HWRITE: enqueued [CERTIFICATE REQUEST] 18. Total 1452 bytes.
|<3>| HSK[0x7f618c004ea0]: SERVER HELLO DONE was queued [12 bytes]
|<7>| HWRITE: enqueued [SERVER HELLO DONE] 12. Total 1464 bytes.
|<7>| HWRITE FLUSH: 1464 bytes in buffer.
|<6>| DTLS[0x7f618c004ea0]: Start of flight transmission.
|<6>| DTLS[0x7f618c004ea0]: Sending Packet[1] fragment SERVER HELLO(2) with 
length: 93, offset: 0, fragment length: 93
|<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 105 and 
target length: 105
|<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 118 bytes for 0x7f618c004cc0. Total 118 bytes.
|<4>| REC[0x7f618c004ea0]: Sent Packet[2] Handshake(22) in epoch 0 and length: 
118
|<6>| DTLS[0x7f618c004ea0]: Sending Packet[2] fragment CERTIFICATE(11) with 
length: 1122, offset: 0, fragment length: 1122
|<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 1134 
and target length: 1134
|<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 1147 bytes for 0x7f618c004cc0. Total 1265 bytes.
|<4>| REC[0x7f618c004ea0]: Sent Packet[3] Handshake(22) in epoch 0 and length: 
1147
|<6>| DTLS[0x7f618c004ea0]: Sending Packet[3] fragment SERVER KEY EXCHANGE(12) 
with length: 183, offset: 0, fragment length: 183
|<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 195 and 
target length: 195
|<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 208 bytes for 0x7f618c004cc0. Total 1473 bytes.
|<4>| REC[0x7f618c004ea0]: Sent Packet[4] Handshake(22) in epoch 0 and length: 
208
|<6>| DTLS[0x7f618c004ea0]: Sending Packet[4] fragment CERTIFICATE REQUEST(13) 
with length: 6, offset: 0, fragment length: 6
|<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 18 and 
target length: 18
|<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 31 bytes for 0x7f618c004cc0. Total 1504 bytes.
|<4>| REC[0x7f618c004ea0]: Sent Packet[5] Handshake(22) in epoch 0 and length: 
31
|<6>| DTLS[0x7f618c004ea0]: Sending Packet[5] fragment SERVER HELLO DONE(14) 
with length: 0, offset: 0, fragment length: 0
|<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 12 and 
target length: 12
|<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 25 bytes for 0x7f618c004cc0. Total 1529 bytes.
|<4>| REC[0x7f618c004ea0]: Sent Packet[6] Handshake(22) in epoch 0 and length: 
25
|<7>| WRITE FLUSH: 1529 bytes in buffer.
_______________________________ send(): 118
_______________________________ send(): 1147
_______________________________ send(): 208
_______________________________ send(): 31
_______________________________ send(): 25
|<7>| WRITE: wrote 1529 bytes, 0 bytes left.
________________________________-timeout: 0 dtlstm: 0 :: bytes_available: 0
|<7>| READ_TIMEOUT: -1 returned from 0x7f618c004cc0, errno=11 (timeout: 0)
|<2>| ASSERT: /libgnutls/lib/gnutls_dtls.c:380
|<6>| DTLS[0x7f618c004ea0]: End of flight transmission.
_______________________________ handshake(): -28
_______________________________ receive(): 1138
|<7>| HWRITE FLUSH: 0 bytes in buffer.
|<6>| DTLS[0x7f618c004ea0]: Start of flight transmission.
|<7>| WRITE FLUSH: 0 bytes in buffer.
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:610
________________________________-timeout: 0 dtlstm: 1 :: bytes_available: 1138
________________________________ pull(): 1138
|<7>| READ: Got 1138 bytes from 0x7f618c004cc0
|<7>| READ: read 1138 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 1138 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0, 
length: 1125
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 1125
|<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.2] Handshake(22) with length: 
1125
|<6>| BUF[REC]: Inserted 1125 bytes of Data(22)
|<3>| HSK[0x7f618c004ea0]: CERTIFICATE (11) was received. Length 1113[1113], 
frag offset 0, frag length: 1113, sequence: 2
|<6>| DTLS[0x7f618c004ea0]: End of flight transmission.
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1192
|<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
|<9>| Looking keyid: b4fad0a3.3fa33930
|<9>| Found keyid: b4fad0a3.3fa33930
|<2>| ASSERT: /libgnutls/lib/openpgp/pgp.c:172
|<9>| Looking keyid: b4fad0a3.3fa33930
|<9>| Found keyid: b4fad0a3.3fa33930
________________________________ verify()
|<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
________________________________ pull(): 0
|<7>| READ: -1 returned from 0x7f618c004cc0, errno=11 gerrno=11
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
________________________________ handshake(): gnutls:-28
________________________________ receive(): 155
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
________________________________ pull(): 155
|<7>| READ: Got 155 bytes from 0x7f618c004cc0
|<7>| READ: read 155 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 155 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0, 
length: 142
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 142
|<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.4] Handshake(22) with length: 
142
|<6>| BUF[REC]: Inserted 142 bytes of Data(22)
|<3>| HSK[0x7f618c004ea0]: CERTIFICATE VERIFY (15) was received. Length 
130[130], frag offset 0, frag length: 130, sequence: 4
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ handshake(): gnutls:-28
__________________________________________ session::receive(): 14
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ pull(): 14
|<7>| READ: Got 14 bytes from 0x7f618c004cc0
|<7>| READ: read 14 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 14 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 ChangeCipherSpec packet received. Epoch 
0, length: 1
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet ChangeCipherSpec(20) with length: 1
|<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.5] ChangeCipherSpec(20) with 
length: 1
|<6>| BUF[REC]: Inserted 1 bytes of Data(20)
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ handshake(): gnutls:-28
__________________________________________ receive(): 77
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ pull(): 77
|<7>| READ: Got 77 bytes from 0x7f618c004cc0
|<7>| READ: read 77 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 77 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 1, 
length: 64
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 64
|<1>| Discarded duplicate message[0]: Handshake
|<2>| ASSERT: /libgnutls/lib/gnutls_record.c:1263
__________________________________________ handshake(): -28
_________________________________ dtls timeout:0
_________________________________ dtls direction: 0
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ pull(): 0
|<7>| READ: -1 returned from 0x7f618c004cc0, errno=0 gerrno=11
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
__________________________________________ handshake(): gnutls:-28
__________________________________________ receive(): 75
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ pull(): 75
|<7>| READ: Got 75 bytes from 0x7f618c004cc0
|<7>| READ: read 75 bytes from 0x7f618c004cc0
|<7>| RB: Have 0 bytes into buffer. Adding 75 bytes.
|<7>| RB: Requested 13 bytes
|<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0, 
length: 62
|<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
|<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 62
|<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.3] Handshake(22) with length: 62
|<6>| BUF[REC]: Inserted 62 bytes of Data(22)
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
|<3>| HSK[0x7f618c004ea0]: CLIENT KEY EXCHANGE (16) was received. Length 
50[50], frag offset 0, frag length: 50, sequence: 3
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1192
|<2>| ASSERT: /libgnutls/lib/ext/signature.c:308
|<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
|<9>| Looking keyid: b4fad0a3.3fa33930
|<9>| Found keyid: b4fad0a3.3fa33930
|<2>| ASSERT: /libgnutls/lib/openpgp/pgp.c:172
|<9>| Looking keyid: b4fad0a3.3fa33930
|<9>| Found keyid: b4fad0a3.3fa33930
|<3>| HSK[0x7f618c004ea0]: verify cert vrfy: using (null)
|<9>| INT: PREMASTER SECRET[24]: 
5bf7c4f4932f4e85ea2d75b4e8acec9bb5c7a95634887c7e
|<9>| INT: CLIENT RANDOM[32]: 
51646c5e454b65370f2f2b265bfd9f7c25c54e683e87283273e14c25124bab3c
|<9>| INT: SERVER RANDOM[32]: 
51646c5ee466356814339cf4c241559f76826764c4b9eecf542fc3ce5ae780b9
|<9>| INT: MASTER SECRET: 
92fae9b24a6a51e8eee862698118b09edbe8e9cd73e46aae411aa4915a10d8d56a29694e5f7898c2c8d593017cc5b933
|<4>| REC[0x7f618c004ea0]: Initializing epoch #1
|<9>| INT: KEY BLOCK[104]: 
7bce9e55f7b05fa76535a96ce713f3a4c22dabce8d72bc933a0d2775930865fd
|<9>| INT: CLIENT WRITE KEY [16]: 977ad535ba37537ce8482d5bd53424be
|<9>| INT: SERVER WRITE KEY [16]: 038ebacb3af16c5cfa0f7f1770e5e6d1
|<4>| REC[0x7f618c004ea0]: Epoch #1 ready
|<3>| HSK[0x7f618c004ea0]: Cipher Suite: ECDHE_RSA_AES_128_CBC_SHA1
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
__________________________________________ pull(): 0
|<7>| READ: -1 returned from 0x7f618c004cc0, errno=11 gerrno=11
|<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
|<2>| ASSERT: /libgnutls/lib/gnutls_handshake.c:739
|<2>| ASSERT: /libgnutls/lib/gnutls_handshake.c:2937
__________________________________________ handshake(): gnutls:-28


From joke at seiken.de  Wed Apr 10 00:27:06 2013
From: joke at seiken.de (Joke de Buhr)
Date: Wed, 10 Apr 2013 00:27:06 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <4948934.xC52EFgUjU@oberon>
References: <4948934.xC52EFgUjU@oberon>
Message-ID: <1476006.DovPIM7CIC@oberon>

according to rfc4347 section 3.2.2 gnutls should be robust against reordering 
during handshaking by queuing packages and process them in the right order.


regards
joke


On Tuesday 09 April 2013 22:02:25 you wrote:
> hi,
> 
> i'm not use but a have to questions regarding the dtls implementation.
> 
> first of all i'm using the multiple threads and every thread can receive
> packets from the udp socket. each thread calls the receive() and the packet
> is copied into the correct gnutls of the correct session.
> 
> if i'm using only one thread it's more or less guarantied gnutls receives
> the data in the correct order. reodering of udp packets is still possible
> though. everything works fine and the handshake completes.
> 
> but if the packet are received out of order gnutls doesn't seem to write all
> the outgoing packet. check the log "Discarded duplicate message[0]:
> Handshake?.
> 
> since udp/ip doesn't use sequence numbers reordering can always be an issue
> and gnutls should handle it during the handshake procedure. even if the
> reordering is caused by threads.
> 
> and other problem seems to be a problem with the dtls retransmission. each
> side doesn't seem to honer the timeout. if the timer run out both side just
> try to pull data with doesn't work and causes a EGAIN. which
> 
> 
> regards
> joke
> 
> |<7>| READ: Got 208 bytes from 0x7f618c004cc0
> |<7>| READ: read 208 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 208 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0,
> 
> length: 195
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 195
> 
> |<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.1] Handshake(22) with length:
> 195
> 
> |<6>| BUF[REC]: Inserted 195 bytes of Data(22)
> |<3>| HSK[0x7f618c004ea0]: CLIENT HELLO (1) was received. Length 183[183],
> 
> frag offset 0, frag length: 183, sequence: 1
> 
> |<3>| HSK[0x7f618c004ea0]: Client's version: 254.255
> |<2>| ASSERT: /libgnutls/lib/gnutls_db.c:278
> |<3>| EXT[0x7f618c004ea0]: Found extension 'STATUS REQUEST/5'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'CERT TYPE/9'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SAFE RENEGOTIATION/65281'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'HEARTBEAT/15'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SESSION TICKET/35'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC/10'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'STATUS REQUEST/5'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'CERT TYPE/9'
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1
> 
> bytes)
> 
> |<3>| EXT[0x7f618c004ea0]: Found extension 'HEARTBEAT/15'
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'SESSION TICKET/35' (0 bytes)
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC/10'
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'STATUS REQUEST/5' (5 bytes)
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'CERT TYPE/9' (2 bytes)
> |<3>| HSK[0x7f618c004ea0]: Selected certificate type OPENPGP (2)
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SAFE RENEGOTIATION/65281'
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'HEARTBEAT/15' (1 bytes)
> |<2>| HB: received parameter 1 (1 bytes)
> |<3>| EXT[0x7f618c004ea0]: Found extension 'SESSION TICKET/35'
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
> |<3>| HSK[0x7f618c004ea0]: Selected ECC curve SECP192R1 (5)
> |<3>| EXT[0x7f618c004ea0]: Parsing extension 'SUPPORTED ECC POINT
> |FORMATS/11'
> (2 bytes)
> 
> |<2>| ASSERT: /libgnutls/lib/ext/server_name.c:300
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: EC (4) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP
> 
> (2)
> 
> |<3>| HSK[0x7f618c004ea0]: certificate[0] PK algorithm: RSA (1) - ctype:
> OPENPGP (2)
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> |ECDHE_ECDSA_AES_128_CBC_SHA1
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> ECDHE_ECDSA_AES_128_CBC_SHA256
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> ECDHE_ECDSA_AES_128_GCM_SHA256
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> |ECDHE_ECDSA_AES_256_CBC_SHA1
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> ECDHE_ECDSA_AES_256_CBC_SHA384
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> ECDHE_ECDSA_AES_256_GCM_SHA384
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> |ECDHE_ECDSA_3DES_EDE_CBC_SHA1 <3>| HSK[0x7f618c004ea0]: Keeping
> |ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1
> (C0.13)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
> 
> (C0.27)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
> 
> (C0.2F)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1
> 
> (C0.14)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
> 
> (C0.30)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
> 
> (C0.12)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
> |(00.3C) <3>| HSK[0x7f618c004ea0]: Keeping ciphersuite:
> |RSA_CAMELLIA_128_CBC_SHA1
> (00.41)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256
> |(00.9C) <3>| HSK[0x7f618c004ea0]: Keeping ciphersuite:
> |RSA_AES_256_CBC_SHA1 (00.35) <3>| HSK[0x7f618c004ea0]: Keeping
> |ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D) <3>| HSK[0x7f618c004ea0]:
> |Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
> (00.84)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
> |(00.0A) <3>| HSK[0x7f618c004ea0]: Keeping ciphersuite:
> |DHE_RSA_AES_128_CBC_SHA1
> (00.33)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
> 
> (00.67)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite:
> |DHE_RSA_CAMELLIA_128_CBC_SHA1
> (00.45)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256
> 
> (00.9E)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
> 
> (00.39)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
> 
> (00.6B)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite:
> |DHE_RSA_CAMELLIA_256_CBC_SHA1
> (00.88)
> 
> |<3>| HSK[0x7f618c004ea0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
> 
> (00.16)
> 
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
> |<3>| HSK[0x7f618c004ea0]: Removing ciphersuite:
> |DHE_DSS_CAMELLIA_128_CBC_SHA1 <3>| HSK[0x7f618c004ea0]: Removing
> |ciphersuite: DHE_DSS_AES_128_GCM_SHA256 <3>| HSK[0x7f618c004ea0]: Removing
> |ciphersuite: DHE_DSS_AES_256_CBC_SHA1 <3>| HSK[0x7f618c004ea0]: Removing
> |ciphersuite: DHE_DSS_AES_256_CBC_SHA256 <3>| HSK[0x7f618c004ea0]: Removing
> |ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 <3>| HSK[0x7f618c004ea0]:
> |Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 <3>| HSK[0x7f618c004ea0]:
> |Requested cipher suites[size: 74]:
> |<3>|   0xc0, 0x09 ECDHE_ECDSA_AES_128_CBC_SHA1
> |<3>|   0xc0, 0x23 ECDHE_ECDSA_AES_128_CBC_SHA256
> |<3>|   0xc0, 0x2b ECDHE_ECDSA_AES_128_GCM_SHA256
> |<3>|   0xc0, 0x0a ECDHE_ECDSA_AES_256_CBC_SHA1
> |<3>|   0xc0, 0x24 ECDHE_ECDSA_AES_256_CBC_SHA384
> |<3>|   0xc0, 0x2c ECDHE_ECDSA_AES_256_GCM_SHA384
> |<3>|   0xc0, 0x08 ECDHE_ECDSA_3DES_EDE_CBC_SHA1
> |<3>|   0xc0, 0x13 ECDHE_RSA_AES_128_CBC_SHA1
> |<3>| HSK[0x7f618c004ea0]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
> |<3>| HSK[0x7f618c004ea0]: Selected Compression Method: NULL
> |<3>| HSK[0x7f618c004ea0]: Safe renegotiation succeeded
> |<2>| ASSERT: /libgnutls/lib/ext/status_request.c:197
> |<3>| EXT[0x7f618c004ea0]: Sending extension CERT TYPE (1 bytes)
> |<3>| EXT[0x7f618c004ea0]: Sending extension SAFE RENEGOTIATION (1 bytes)
> |<2>| HB: sending parameter 1
> |<3>| EXT[0x7f618c004ea0]: Sending extension HEARTBEAT (1 bytes)
> |<3>| EXT[0x7f618c004ea0]: Sending extension SUPPORTED ECC POINT FORMATS (2
> 
> bytes)
> 
> |<3>| HSK[0x7f618c004ea0]: SessionID:
> a9a8d07103670e3b14aad8e1e316f6fb41f1a6298b2ae96b7126ada49201db51
> 
> |<3>| HSK[0x7f618c004ea0]: SERVER HELLO was queued [105 bytes]
> |<7>| HWRITE: enqueued [SERVER HELLO] 105. Total 105 bytes.
> |<3>| Sending PGP key ID d223dc8428ac7593 (subkey)
> |<3>| HSK[0x7f618c004ea0]: CERTIFICATE was queued [1134 bytes]
> |<7>| HWRITE: enqueued [CERTIFICATE] 1134. Total 1239 bytes.
> |<3>| HSK[0x7f618c004ea0]: signing handshake data: using RSA-SHA1
> |<9>| Looking keyid: d223dc84.28ac7593
> |<9>| Found keyid: d223dc84.28ac7593
> |<9>| Signing using PGP key ID d223dc8428ac7593
> |<9>| Looking keyid: d223dc84.28ac7593
> |<9>| Found keyid: d223dc84.28ac7593
> |<3>| HSK[0x7f618c004ea0]: SERVER KEY EXCHANGE was queued [195 bytes]
> |<7>| HWRITE: enqueued [SERVER KEY EXCHANGE] 195. Total 1434 bytes.
> |<3>| HSK[0x7f618c004ea0]: CERTIFICATE REQUEST was queued [18 bytes]
> |<7>| HWRITE: enqueued [CERTIFICATE REQUEST] 18. Total 1452 bytes.
> |<3>| HSK[0x7f618c004ea0]: SERVER HELLO DONE was queued [12 bytes]
> |<7>| HWRITE: enqueued [SERVER HELLO DONE] 12. Total 1464 bytes.
> |<7>| HWRITE FLUSH: 1464 bytes in buffer.
> |<6>| DTLS[0x7f618c004ea0]: Start of flight transmission.
> |<6>| DTLS[0x7f618c004ea0]: Sending Packet[1] fragment SERVER HELLO(2) with
> 
> length: 93, offset: 0, fragment length: 93
> 
> |<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 105
> |and
> target length: 105
> 
> |<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
> |<7>| WRITE: enqueued 118 bytes for 0x7f618c004cc0. Total 118 bytes.
> 
> |<4>| REC[0x7f618c004ea0]: Sent Packet[2] Handshake(22) in epoch 0 and 
length:
> 118
> 
> |<6>| DTLS[0x7f618c004ea0]: Sending Packet[2] fragment CERTIFICATE(11) with
> 
> length: 1122, offset: 0, fragment length: 1122
> 
> |<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 1134
> 
> and target length: 1134
> 
> |<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
> |<7>| WRITE: enqueued 1147 bytes for 0x7f618c004cc0. Total 1265 bytes.
> 
> |<4>| REC[0x7f618c004ea0]: Sent Packet[3] Handshake(22) in epoch 0 and 
length:
> 1147
> 
> |<6>| DTLS[0x7f618c004ea0]: Sending Packet[3] fragment SERVER KEY
> |EXCHANGE(12)
> with length: 183, offset: 0, fragment length: 183
> 
> |<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 195
> |and
> target length: 195
> 
> |<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
> |<7>| WRITE: enqueued 208 bytes for 0x7f618c004cc0. Total 1473 bytes.
> 
> |<4>| REC[0x7f618c004ea0]: Sent Packet[4] Handshake(22) in epoch 0 and 
length:
> 208
> 
> |<6>| DTLS[0x7f618c004ea0]: Sending Packet[4] fragment CERTIFICATE
> |REQUEST(13)
> with length: 6, offset: 0, fragment length: 6
> 
> |<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 18
> |and
> target length: 18
> 
> |<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
> |<7>| WRITE: enqueued 31 bytes for 0x7f618c004cc0. Total 1504 bytes.
> 
> |<4>| REC[0x7f618c004ea0]: Sent Packet[5] Handshake(22) in epoch 0 and 
length:
> 31
> 
> |<6>| DTLS[0x7f618c004ea0]: Sending Packet[5] fragment SERVER HELLO DONE(14)
> 
> with length: 0, offset: 0, fragment length: 0
> 
> |<4>| REC[0x7f618c004ea0]: Preparing Packet Handshake(22) with length: 12
> |and
> target length: 12
> 
> |<9>| ENC[0x7f618c004ea0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
> |<7>| WRITE: enqueued 25 bytes for 0x7f618c004cc0. Total 1529 bytes.
> 
> |<4>| REC[0x7f618c004ea0]: Sent Packet[6] Handshake(22) in epoch 0 and 
length:
> 25
> 
> |<7>| WRITE FLUSH: 1529 bytes in buffer.
> 
> _______________________________ send(): 118
> _______________________________ send(): 1147
> _______________________________ send(): 208
> _______________________________ send(): 31
> _______________________________ send(): 25
> 
> |<7>| WRITE: wrote 1529 bytes, 0 bytes left.
> 
> ________________________________-timeout: 0 dtlstm: 0 :: bytes_available: 0
> 
> |<7>| READ_TIMEOUT: -1 returned from 0x7f618c004cc0, errno=11 (timeout: 0)
> |<2>| ASSERT: /libgnutls/lib/gnutls_dtls.c:380
> |<6>| DTLS[0x7f618c004ea0]: End of flight transmission.
> 
> _______________________________ handshake(): -28
> _______________________________ receive(): 1138
> 
> |<7>| HWRITE FLUSH: 0 bytes in buffer.
> |<6>| DTLS[0x7f618c004ea0]: Start of flight transmission.
> |<7>| WRITE FLUSH: 0 bytes in buffer.
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:610
> 
> ________________________________-timeout: 0 dtlstm: 1 :: bytes_available:
> 1138 ________________________________ pull(): 1138
> 
> |<7>| READ: Got 1138 bytes from 0x7f618c004cc0
> |<7>| READ: read 1138 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 1138 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0,
> 
> length: 1125
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 1125
> 
> |<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.2] Handshake(22) with length:
> 1125
> 
> |<6>| BUF[REC]: Inserted 1125 bytes of Data(22)
> |<3>| HSK[0x7f618c004ea0]: CERTIFICATE (11) was received. Length 1113[1113],
> 
> frag offset 0, frag length: 1113, sequence: 2
> 
> |<6>| DTLS[0x7f618c004ea0]: End of flight transmission.
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1192
> |<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
> |<9>| Looking keyid: b4fad0a3.3fa33930
> |<9>| Found keyid: b4fad0a3.3fa33930
> |<2>| ASSERT: /libgnutls/lib/openpgp/pgp.c:172
> |<9>| Looking keyid: b4fad0a3.3fa33930
> |<9>| Found keyid: b4fad0a3.3fa33930
> 
> ________________________________ verify()
> 
> |<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> ________________________________ pull(): 0
> 
> |<7>| READ: -1 returned from 0x7f618c004cc0, errno=11 gerrno=11
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
> 
> ________________________________ handshake(): gnutls:-28
> ________________________________ receive(): 155
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> ________________________________ pull(): 155
> 
> |<7>| READ: Got 155 bytes from 0x7f618c004cc0
> |<7>| READ: read 155 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 155 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0,
> 
> length: 142
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 142
> 
> |<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.4] Handshake(22) with length:
> 142
> 
> |<6>| BUF[REC]: Inserted 142 bytes of Data(22)
> |<3>| HSK[0x7f618c004ea0]: CERTIFICATE VERIFY (15) was received. Length
> 
> 130[130], frag offset 0, frag length: 130, sequence: 4
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ handshake(): gnutls:-28
> __________________________________________ session::receive(): 14
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ pull(): 14
> 
> |<7>| READ: Got 14 bytes from 0x7f618c004cc0
> |<7>| READ: read 14 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 14 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 ChangeCipherSpec packet received.
> |Epoch
> 0, length: 1
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet ChangeCipherSpec(20) with length:
> |1 <4>| REC[0x7f618c004ea0]: Decrypted Packet[0.5] ChangeCipherSpec(20)
> |with
> length: 1
> 
> |<6>| BUF[REC]: Inserted 1 bytes of Data(20)
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ handshake(): gnutls:-28
> __________________________________________ receive(): 77
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ pull(): 77
> 
> |<7>| READ: Got 77 bytes from 0x7f618c004cc0
> |<7>| READ: read 77 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 77 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 1,
> 
> length: 64
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 64
> |<1>| Discarded duplicate message[0]: Handshake
> |<2>| ASSERT: /libgnutls/lib/gnutls_record.c:1263
> 
> __________________________________________ handshake(): -28
> _________________________________ dtls timeout:0
> _________________________________ dtls direction: 0
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ pull(): 0
> 
> |<7>| READ: -1 returned from 0x7f618c004cc0, errno=0 gerrno=11
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
> 
> __________________________________________ handshake(): gnutls:-28
> __________________________________________ receive(): 75
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ pull(): 75
> 
> |<7>| READ: Got 75 bytes from 0x7f618c004cc0
> |<7>| READ: read 75 bytes from 0x7f618c004cc0
> |<7>| RB: Have 0 bytes into buffer. Adding 75 bytes.
> |<7>| RB: Requested 13 bytes
> |<4>| REC[0x7f618c004ea0]: SSL 254.255 Handshake packet received. Epoch 0,
> 
> length: 62
> 
> |<4>| REC[0x7f618c004ea0]: Expected Packet Handshake(22)
> |<4>| REC[0x7f618c004ea0]: Received Packet Handshake(22) with length: 62
> |<4>| REC[0x7f618c004ea0]: Decrypted Packet[0.3] Handshake(22) with length:
> |62 <6>| BUF[REC]: Inserted 62 bytes of Data(22)
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1119
> |<3>| HSK[0x7f618c004ea0]: CLIENT KEY EXCHANGE (16) was received. Length
> 
> 50[50], frag offset 0, frag length: 50, sequence: 3
> 
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1192
> |<2>| ASSERT: /libgnutls/lib/ext/signature.c:308
> |<2>| ASSERT: /libgnutls/lib/opencdk/stream.c:1035
> |<9>| Looking keyid: b4fad0a3.3fa33930
> |<9>| Found keyid: b4fad0a3.3fa33930
> |<2>| ASSERT: /libgnutls/lib/openpgp/pgp.c:172
> |<9>| Looking keyid: b4fad0a3.3fa33930
> |<9>| Found keyid: b4fad0a3.3fa33930
> |<3>| HSK[0x7f618c004ea0]: verify cert vrfy: using (null)
> 
> |<9>| INT: PREMASTER SECRET[24]:
> 5bf7c4f4932f4e85ea2d75b4e8acec9bb5c7a95634887c7e
> 
> |<9>| INT: CLIENT RANDOM[32]:
> 51646c5e454b65370f2f2b265bfd9f7c25c54e683e87283273e14c25124bab3c
> 
> |<9>| INT: SERVER RANDOM[32]:
> 51646c5ee466356814339cf4c241559f76826764c4b9eecf542fc3ce5ae780b9
> 
> |<9>| INT: MASTER SECRET:
> 92fae9b24a6a51e8eee862698118b09edbe8e9cd73e46aae411aa4915a10d8d56a29694e5f78
> 98c2c8d593017cc5b933
> |<4>| REC[0x7f618c004ea0]: Initializing epoch #1
> 
> |<9>| INT: KEY BLOCK[104]:
> 7bce9e55f7b05fa76535a96ce713f3a4c22dabce8d72bc933a0d2775930865fd
> 
> |<9>| INT: CLIENT WRITE KEY [16]: 977ad535ba37537ce8482d5bd53424be
> |<9>| INT: SERVER WRITE KEY [16]: 038ebacb3af16c5cfa0f7f1770e5e6d1
> |<4>| REC[0x7f618c004ea0]: Epoch #1 ready
> |<3>| HSK[0x7f618c004ea0]: Cipher Suite: ECDHE_RSA_AES_128_CBC_SHA1
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:1019
> 
> __________________________________________ pull(): 0
> 
> |<7>| READ: -1 returned from 0x7f618c004cc0, errno=11 gerrno=11
> |<2>| ASSERT: /libgnutls/lib/gnutls_buffers.c:508
> |<2>| ASSERT: /libgnutls/lib/gnutls_handshake.c:739
> |<2>| ASSERT: /libgnutls/lib/gnutls_handshake.c:2937
> 
> __________________________________________ handshake(): gnutls:-28


From nmav at gnutls.org  Wed Apr 10 09:48:29 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 10 Apr 2013 09:48:29 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <4948934.xC52EFgUjU@oberon>
References: <4948934.xC52EFgUjU@oberon>
Message-ID: <CAJU7zaJjZghhKYPdVEVU92qbNZBZHQB9o2dQBh+hJE5aAQW1Og@mail.gmail.com>

On Tue, Apr 9, 2013 at 10:02 PM, Joke de Buhr <joke at seiken.de> wrote:

> hi,
>
> i'm not use but a have to questions regarding the dtls implementation.
>
> first of all i'm using the multiple threads and every thread can receive
> packets from the udp socket. each thread calls the receive() and the
> packet is
> copied into the correct gnutls of the correct session.
>
> if i'm using only one thread it's more or less guarantied gnutls receives
> the
> data in the correct order. reodering of udp packets is still possible
> though.
> everything works fine and the handshake completes.
>
> but if the packet are received out of order gnutls doesn't seem to write
> all
> the outgoing packet. check the log "Discarded duplicate message[0]:
> Handshake?.
>

That is because you are re-arranging the messages in a way for encrypted
messages (i.e., the finished packet) is received before the handshake is
complete. That packet is dropped because the sliding window code detects it
as duplicate (its sequence number is the same as the first handshake
message sequence number). So if you receive the Finished message before the
handshake is complete you should rely on retransmission to receive it
again. Doesn't retransmission work in your case?

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130410/2eb0f29f/attachment-0001.html>

From joke at seiken.de  Wed Apr 10 18:07:49 2013
From: joke at seiken.de (Joke de Buhr)
Date: Wed, 10 Apr 2013 18:07:49 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <51657DA7.1070502@gnutls.org>
References: <4948934.xC52EFgUjU@oberon> <1822135.YcrX9Kr7rO@oberon>
 <51657DA7.1070502@gnutls.org>
Message-ID: <2534929.AfKmJZC4hq@oberon>

yes i'm using the non-blocking mode. for client and server sesssion.

  gnutls_init(&session_, GNUTLS_DATAGRAM | GNUTLS_NONBLOCK | ...);


here is a stack trace where the pull function is called:

#0 _gnutls_io_check_recv() at /lib/gnutls_buffers.c:677
#1 _dtls_wait_and_retransmit() at /lib/gnutls_dtls.c:414
#2 _gnutls_recv_handshake_final() at /lib/gnutls_handshake.c:2883
#3 _gnutls_handshake_client() at /lib/gnutls_handshake.c:2730
#4 gnutls_handshake() at /lib/gnutls_handshake.c:2450
#5 session<server::gateway<server::server<boost::asio::ip::udp> > 
>::handshake() at /home/joke/Projects/vpn/src/session.t++:175

the pull timeout function returns GNUTLS_E_AGAIN.

but _dtls_retransmit is called only if the return value was GNUTLS_E_TIMEDOUT.

in _dtls_wait_and_retransmit around gnutls_dtls.c:416.


i noticed around /lib/gnutls_handshake.c:2879
_dtls_is_async(...) returns 0

i don't know if that's any kind of problem.


regards
joke



On Wednesday 10 April 2013 16:56:39 Nikos Mavrogiannopoulos wrote:
> On 04/10/2013 04:30 PM, Joke de Buhr wrote:
> > thanks for the hint.
> > 
> > i did some debugging and discovered why no data was retransmitted.
> > 
> > if the timer runs out and calls handshake() gnutls calls the pull timeout
> > function a couple of times to check the io state before it checks if a
> > retransmission needs to take place.
> > since my pull timeout function doesn't block and always returns EAGAIN
> > unless there are actually packets which can be pulled in gnutls got stuck
> > and didn't consider the timer ran out already.
> > i'm not entirely sure if this is the correct behavior. especially if
> > gnutls is running in non-blocking dtls mode it might be wise to check for
> > retransmission if the pull timeout function returns EAGAIN.
> 
> But do you use it in non-blocking mode? The behavior of gnutls is
> different in that mode, it shouldn't have called this function.
> btw. if possible please follow up on the original thread on the list
> with the solution.
> 
> regards,
> Nikos


From nmav at gnutls.org  Wed Apr 10 22:20:23 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 10 Apr 2013 22:20:23 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <2534929.AfKmJZC4hq@oberon>
References: <4948934.xC52EFgUjU@oberon> <1822135.YcrX9Kr7rO@oberon>
 <51657DA7.1070502@gnutls.org> <2534929.AfKmJZC4hq@oberon>
Message-ID: <5165C987.70802@gnutls.org>

On 04/10/2013 06:07 PM, Joke de Buhr wrote:

> yes i'm using the non-blocking mode. for client and server sesssion.
> 
>   gnutls_init(&session_, GNUTLS_DATAGRAM | GNUTLS_NONBLOCK | ...);
> 
> 
> here is a stack trace where the pull function is called:
> 
> #0 _gnutls_io_check_recv() at /lib/gnutls_buffers.c:677
> #1 _dtls_wait_and_retransmit() at /lib/gnutls_dtls.c:414
> #2 _gnutls_recv_handshake_final() at /lib/gnutls_handshake.c:2883
> #3 _gnutls_handshake_client() at /lib/gnutls_handshake.c:2730
> #4 gnutls_handshake() at /lib/gnutls_handshake.c:2450
> #5 session<server::gateway<server::server<boost::asio::ip::udp> > 
>> ::handshake() at /home/joke/Projects/vpn/src/session.t++:175
> 
> the pull timeout function returns GNUTLS_E_AGAIN.
> but _dtls_retransmit is called only if the return value was GNUTLS_E_TIMEDOUT.


That's pretty correct. _gnutls_io_check_recv() returns
GNUTLS_E_TIMEDOUT, zero or fatal error values.

Your pull timeout function should return 0 on timeout, a positive number
if data can be received and -1 on error. I'll make the documentation
more clear on that, but in your case you should have returned zero
instead of EAGAIN.

regards,
Nikos


From joke at seiken.de  Wed Apr 10 23:10:02 2013
From: joke at seiken.de (Joke de Buhr)
Date: Wed, 10 Apr 2013 23:10:02 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <5165C987.70802@gnutls.org>
References: <4948934.xC52EFgUjU@oberon> <2534929.AfKmJZC4hq@oberon>
 <5165C987.70802@gnutls.org>
Message-ID: <6194804.K7OzKN9bMd@oberon>

On Wednesday 10 April 2013 22:20:23 Nikos Mavrogiannopoulos wrote:
> On 04/10/2013 06:07 PM, Joke de Buhr wrote:
> > yes i'm using the non-blocking mode. for client and server sesssion.
> > 
> >   gnutls_init(&session_, GNUTLS_DATAGRAM | GNUTLS_NONBLOCK | ...);
> > 
> > here is a stack trace where the pull function is called:
> > 
> > #0 _gnutls_io_check_recv() at /lib/gnutls_buffers.c:677
> > #1 _dtls_wait_and_retransmit() at /lib/gnutls_dtls.c:414
> > #2 _gnutls_recv_handshake_final() at /lib/gnutls_handshake.c:2883
> > #3 _gnutls_handshake_client() at /lib/gnutls_handshake.c:2730
> > #4 gnutls_handshake() at /lib/gnutls_handshake.c:2450
> > #5 session<server::gateway<server::server<boost::asio::ip::udp> >
> > 
> >> ::handshake() at /home/joke/Projects/vpn/src/session.t++:175
> > 
> > the pull timeout function returns GNUTLS_E_AGAIN.
> > but _dtls_retransmit is called only if the return value was
> > GNUTLS_E_TIMEDOUT.
> That's pretty correct. _gnutls_io_check_recv() returns
> GNUTLS_E_TIMEDOUT, zero or fatal error values.
> 
> Your pull timeout function should return 0 on timeout, a positive number
> if data can be received and -1 on error. I'll make the documentation
> more clear on that, but in your case you should have returned zero
> instead of EAGAIN.

i see the point especially if i would use a traditional select based approach 
while waiting for a timeout.


but let's assume:

the handshake timeout isn't set at all. my pull timeout function should never 
block. 

as a consequence the pull_timeout_function() will always get called with an 
timeout value of 0. should i return 0 or set gnutls EAGAIN value and return -1 
if no new data is available? i can't wait using select. the function can't 
block. if data is available handshake() or receive() will be called.


now the handshake() will return a value of GNUTLS_EAGAIN and i use 
gnutls_dtls_get_timeout() and set a timer waiting for this particular session 
to run out while in the mean time i handle other session. if the timer for 
this particular session runs out the handshake function is called again.


regards
joke

> regards,
> Nikos


From nmav at gnutls.org  Wed Apr 10 23:31:18 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 10 Apr 2013 23:31:18 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <6194804.K7OzKN9bMd@oberon>
References: <4948934.xC52EFgUjU@oberon> <2534929.AfKmJZC4hq@oberon>
 <5165C987.70802@gnutls.org> <6194804.K7OzKN9bMd@oberon>
Message-ID: <5165DA26.1000700@gnutls.org>

On 04/10/2013 11:10 PM, Joke de Buhr wrote:


>> Your pull timeout function should return 0 on timeout, a positive number
>> if data can be received and -1 on error. I'll make the documentation
>> more clear on that, but in your case you should have returned zero
>> instead of EAGAIN.
> i see the point especially if i would use a traditional select based approach 
> while waiting for a timeout.
> but let's assume:
> the handshake timeout isn't set at all. my pull timeout function should never 
> block. 


Indeed. It should return 0 when it has no data because it is called with
a parameter of 0 ms.


> as a consequence the pull_timeout_function() will always get called with an 
> timeout value of 0. should i return 0 or set gnutls EAGAIN value and return -1 
> if no new data is available? i can't wait using select. the function can't 
> block. if data is available handshake() or receive() will be called.


The pull timeout function is set so gnutls can wait when needed. However
in your case (you use non-blocking mode) it should be called with a
parameter of 0 ms, so you should return 0 (timeout) when no data are
there. That's similar to what select does.

> now the handshake() will return a value of GNUTLS_EAGAIN and i use 


EAGAIN doesn't imply that no data are there. It merely says call me
again sometime. That's why you see no action there.

regards,
Nikos


From joke at seiken.de  Wed Apr 10 23:58:15 2013
From: joke at seiken.de (Joke de Buhr)
Date: Wed, 10 Apr 2013 23:58:15 +0200
Subject: [gnutls-help] DTLS and retransmission and reordering
In-Reply-To: <5165DA26.1000700@gnutls.org>
References: <4948934.xC52EFgUjU@oberon> <6194804.K7OzKN9bMd@oberon>
 <5165DA26.1000700@gnutls.org>
Message-ID: <7128152.CEx7otSrT9@oberon>

thanks for the clarification.


regards
joke

On Wednesday 10 April 2013 23:31:18 you wrote:
> On 04/10/2013 11:10 PM, Joke de Buhr wrote:
> >> Your pull timeout function should return 0 on timeout, a positive number
> >> if data can be received and -1 on error. I'll make the documentation
> >> more clear on that, but in your case you should have returned zero
> >> instead of EAGAIN.
> > 
> > i see the point especially if i would use a traditional select based
> > approach while waiting for a timeout.
> > but let's assume:
> > the handshake timeout isn't set at all. my pull timeout function should
> > never block.
> 
> Indeed. It should return 0 when it has no data because it is called with
> a parameter of 0 ms.
> 
> > as a consequence the pull_timeout_function() will always get called with
> > an
> > timeout value of 0. should i return 0 or set gnutls EAGAIN value and
> > return -1 if no new data is available? i can't wait using select. the
> > function can't block. if data is available handshake() or receive() will
> > be called.
> The pull timeout function is set so gnutls can wait when needed. However
> in your case (you use non-blocking mode) it should be called with a
> parameter of 0 ms, so you should return 0 (timeout) when no data are
> there. That's similar to what select does.
> 
> > now the handshake() will return a value of GNUTLS_EAGAIN and i use
> 
> EAGAIN doesn't imply that no data are there. It merely says call me
> again sometime. That's why you see no action there.
> 
> regards,
> Nikos


From mk at cognitivedissonance.ca  Tue Apr 16 21:36:51 2013
From: mk at cognitivedissonance.ca (MK)
Date: Tue, 16 Apr 2013 15:36:51 -0400
Subject: [gnutls-help] confusion regarding private key encryption
Message-ID: <20130416153651.59d776cfb5ee670e1e5f3b3d@cognitivedissonance.ca>

I have a password encrypted private key associated with an x509
certificate. The key can be read with:

openssl rsa -in keyfile

And providing the password.  I am trying to import this for use with
gnutls:

	gnutls_datum_t key_raw;
	key_raw.size = slurpfile("crt/prv.key", (char**)&
(key_raw.data));

// slurpfile works, but to verify key data has been read in correctly:
fprintf(stderr,"%s", key_raw.data);  // no issue here

	gnutls_x509_privkey_t key;
	check = gnutls_x509_privkey_import2 (
		key,
		&key_raw,
		GNUTLS_X509_FMT_PEM,
		argv[1],
		0
	);       

I inevitably get a -302, GNUTLS_E_PARSING_ERROR.  I have also tried
"gnutls_privkey_import_x509_raw()" (although I have no idea what the
difference is) and "gnutls_x509_privkey_import_openssl
()"; they all return the same error.

Because I don't know what cipher was used on the key (nor how to find
out), I have not tried any gnutls_pkcs_encrypt_flags_t flags.  However,
I did try an openssl decrypted copy (RSA PRIVATE KEY), this made no
difference.

What am I confused about here?

Thanks -- MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)



From nmav at gnutls.org  Wed Apr 17 09:29:37 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 17 Apr 2013 09:29:37 +0200
Subject: [gnutls-help] confusion regarding private key encryption
In-Reply-To: <20130416153651.59d776cfb5ee670e1e5f3b3d@cognitivedissonance.ca>
References: <20130416153651.59d776cfb5ee670e1e5f3b3d@cognitivedissonance.ca>
Message-ID: <CAJU7zaJOtN1sBESgCSDvK=jENWQ23x4iWC7Z0pbiDQ07BeB=jQ@mail.gmail.com>

On Tue, Apr 16, 2013 at 9:36 PM, MK <mk at cognitivedissonance.ca> wrote:

> I have a password encrypted private key associated with an x509
> certificate. The key can be read with:
> openssl rsa -in keyfile
> And providing the password.  I am trying to import this for use with
> gnutls:
>

This doesn't provide much information. Openssl supports many encryption
schemes, and some of them are long time obsolete and not supported by
gnutls. Which one did you use? I'd suggest that you use the PKCS #8 with
the PBES2 scheme.


> I inevitably get a -302, GNUTLS_E_PARSING_ERROR.  I have also tried
>

Try "certtool -k" on that key and enable verbosity to see more details on
the error. What are the headers of you key?

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130417/da8285d6/attachment-0001.html>

From mk at cognitivedissonance.ca  Wed Apr 17 14:59:29 2013
From: mk at cognitivedissonance.ca (MK)
Date: Wed, 17 Apr 2013 08:59:29 -0400
Subject: [gnutls-help] confusion regarding private key encryption
In-Reply-To: <CAJU7zaJOtN1sBESgCSDvK=jENWQ23x4iWC7Z0pbiDQ07BeB=jQ@mail.gmail.com>
References: <20130416153651.59d776cfb5ee670e1e5f3b3d@cognitivedissonance.ca>
 <CAJU7zaJOtN1sBESgCSDvK=jENWQ23x4iWC7Z0pbiDQ07BeB=jQ@mail.gmail.com>
Message-ID: <20130417085929.2cbca1d33d4afd10d513e290@cognitivedissonance.ca>

On Wed, 17 Apr 2013 09:29:37 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> Try "certtool -k" on that key and enable verbosity to see more
> details on the error. 

Certtool worked without error, so I ran it inside gdb to try and find
some code to cargo cult ;) But privkey_info() was doing exactly what I
did, and the decrypt flags were 0.

What was also odd is that I got the same -302 parsing error even with
no password or the wrong password, which should be "decryption
failed".  Then (facepalm) it occurred to me that gnutls needs to be
initialized. The previous gnutls code I've written was last year, so I
had forgotten this and did not bother to look.

I do have one more question for you though.  WRT the cipher scheme used
with the password encrypted key, is there anyway to find this out?
Neither certtool -V nor openssl report this, I think.

Public Key Info:
	Public Key Algorithm: RSA
	Key Security Level: Legacy (2048 bits)

Nothing about how the private key was encrypted, although I presume
at some point some part of the program must know since it decrypted it.
It seems to me that is useful information and there is no reason for it
to be "secret" if I have the password.

Thanks -- MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)



From nmav at gnutls.org  Wed Apr 17 17:09:23 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 17 Apr 2013 17:09:23 +0200
Subject: [gnutls-help] confusion regarding private key encryption
In-Reply-To: <20130417085929.2cbca1d33d4afd10d513e290@cognitivedissonance.ca>
References: <20130416153651.59d776cfb5ee670e1e5f3b3d@cognitivedissonance.ca>
 <CAJU7zaJOtN1sBESgCSDvK=jENWQ23x4iWC7Z0pbiDQ07BeB=jQ@mail.gmail.com>
 <20130417085929.2cbca1d33d4afd10d513e290@cognitivedissonance.ca>
Message-ID: <CAJU7zaLauC9wPHF3Mc1H0EhHmMXpT9=esh_k7hSMBHQZ7v=0-g@mail.gmail.com>

On Wed, Apr 17, 2013 at 2:59 PM, MK <mk at cognitivedissonance.ca> wrote:
> On Wed, 17 Apr 2013 09:29:37 +0200
> Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> Try "certtool -k" on that key and enable verbosity to see more
>> details on the error.
> Certtool worked without error, so I ran it inside gdb to try and find
> some code to cargo cult ;) But privkey_info() was doing exactly what I
> did, and the decrypt flags were 0.
> What was also odd is that I got the same -302 parsing error even with

Did you use gnutls_global_init()?

regards,
Nikos


From mk at cognitivedissonance.ca  Wed Apr 17 22:39:45 2013
From: mk at cognitivedissonance.ca (MK)
Date: Wed, 17 Apr 2013 16:39:45 -0400
Subject: [gnutls-help] Get cipher used to encrypt key
Message-ID: <20130417163945.20e35294b79d401d216985a6@cognitivedissonance.ca>

This is derived from my previous problem with a password encrypted key
but does not rely upon it.  The context is, I have a password encrypted
private key for which I have the password, and gnutls (certtool, etc.)
will read it (eg. via gnutls_x509_privkey_import2()).  I would
like to find out what cipher was used to encrypt the key; the gnutls
functions "auto-detect" the format, but do not report it. If I read it
with "certtool -k -V", there is information about what public key
encryption scheme this key is for:

Public Key Info:
	Public Key Algorithm: RSA
	Key Security Level: Legacy (2048 bits)

But not how the key itself was encrypted with a password.  "openssl rsa"
similarly will decrypt and print information about the key, but not
the cipher it was encrypted with.  It seems to me this is useful
information that has no reason to be secret if I have the password
anyway.  For example, if someone else is using my software and
complains their key doesn't work, but doesn't know or can't remember
the cipher used, it would be nice to have a commonplace tool (such as
certtool) that I could refer them to ("Find out via certtool what form
of password encryption is used.").

I am pretty ignorant about all this, so hopefully my question makes
sense.

Sincerely, MK.

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)



From mw at atomicode.de  Thu Apr 18 19:49:57 2013
From: mw at atomicode.de (mw at atomicode.de)
Date: Thu, 18 Apr 2013 19:49:57 +0200
Subject: [gnutls-help] Corrupted data when reading from gnutls input buffer
Message-ID: <22d6fd7e6d3b781fab2d71ac0e7d8455@atomicode.de>

Hello,

I am developing a software using gnutls 3.1.0 and got a little problem,
which I hope somebody can help me get rid of.

On client side I am using a non-blocking socket and to check it for 
read readiness
I call "gnutls_record_check_pending" to see if there is data in the 
input buffer
remaining from the last read process. If not I call "select" on the 
socket to
see if data is available to be read by "gnutls_record_recv".

Every time when data is read from the internal input buffer of gnutls
I get corrupted data.

It seems to be sporadically that data is read into the input buffer of 
gnutls,
and varies in size.

Here some code:

bool Client::readable(uint32_t ms)
{
     // check for data to be read from the gnutls input buffer

     uint32_t r = gnutls_record_check_pending(m_session);

     if (r > 0) {

         return true;
     }

     // check for socket read readiness

     fd_set fds;
     FD_ZERO(&fds);
     FD_SET(m_socket, &fds);

     struct timeval tv;
     tv.tv_sec = 0;
     tv.tv_usec = ms * 1000;

     int res = select(m_socket+1, &fds, NULL, NULL, &tv);

     if (res <= 0) {

         return false;
     }

     return true;
}

uint32_t Client::recv(uint8_t* data, uint32_t size)
{
     uint32_t s = 0;

     while (s < size) {

     	// wait for read readiness

     	if (!readable(200)) {

     	    continue;
     	}

     	// read data

         int32_t ret = gnutls_record_recv(m_session, &data[s], size - 
s);

         if (gnutls_error_is_fatal(ret) != 0 || ret == 0) {

             if (ret == 0) {

                 return 0;
             }
             else {

                 std::cerr << "Error: " << gnutls_strerror(ret) << "\n";

                 return ret;
             }
         }

         if (ret == GNUTLS_E_INTERRUPTED || ret == GNUTLS_E_AGAIN) {

             continue;
         }

         s += ret;
     }

     return s;
}

Hope somebody can give me a hint what I may be doing wrong.

Thanks in advance.

Marc


From bavariasound at chiemgau-net.de  Fri Apr 19 10:10:08 2013
From: bavariasound at chiemgau-net.de (Alexander Ausserstorfer)
Date: Fri, 19 Apr 2013 10:10:08 +0200
Subject: [gnutls-help] gnutls_certificate_set_x509_trust_file and Cygwin
Message-ID: <20130419101008.13095objohkgac4c@webmail.chiemgau-net.de>

Under Cygwin I set gnutls_certificate_set_x509_trust_file to

#define CAFILE "/usr/ssl/certs/ca-bundle.trust.crt"

gnutls_certificate_set_x509_trust_file (cert_cret, CAFILE,  
GNUTLS_X509_FMT_PEM);

ca-bundle.trust.crt was part of Cygwin. Now, the function  
gnutls_certificate_set_x509_trust_file returns 0 and all later  
verification of certificates fails. I suppose that the function should  
return another number as 0. Is that mind right?

A.

-- 
http://home.chiemgau-net.de/ausserstorfer/


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From bavariasound at chiemgau-net.de  Sat Apr 20 08:03:51 2013
From: bavariasound at chiemgau-net.de (Alexander Ausserstorfer)
Date: Sat, 20 Apr 2013 08:03:51 +0200
Subject: [gnutls-help] gnutls_certificate_set_x509_trust_file and Cygwin
In-Reply-To: <20130419101008.13095objohkgac4c@webmail.chiemgau-net.de>
References: <20130419101008.13095objohkgac4c@webmail.chiemgau-net.de>
Message-ID: <20130420080351.871238almpgr8w4k@webmail.chiemgau-net.de>

Zitat von Alexander Ausserstorfer <bavariasound at chiemgau-net.de>:

> Under Cygwin I set gnutls_certificate_set_x509_trust_file to
>
> #define CAFILE "/usr/ssl/certs/ca-bundle.trust.crt"
>
> gnutls_certificate_set_x509_trust_file (cert_cret, CAFILE,  
> GNUTLS_X509_FMT_PEM);
>
> ca-bundle.trust.crt was part of Cygwin. Now, the function  
> gnutls_certificate_set_x509_trust_file returns 0 and all later  
> verification of certificates fails. I suppose that the function  
> should return another number as 0. Is that mind right?

Yesterday the staff kicked me out the computer room, and today the  
wireless network access here doesn't work, so sorry for the  
circumstances.

The first question is if I use the right certificates. The file  
ca-bundle.trust.crt at cygwin/usr/ssl/certs/ sais:

############################################################################

This is a bundle of X.509 certificates of public Certificate  
Authorities. It was generated from the Mozilla root CA list. These  
certificates are in the OpenSSL "TRUSTED CERTIFICATE" format and have  
trust bits accordingly.

Source: mozilla/security/nss/lib/ckfw/builtins/certdata.txt

[...]

############################################################################

Then I use the function

gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,  
GNUTLS_X509_FMT_PEM)

to add the list but the function returns zero. It is the first time I  
try GnuTLS. It seems to me that the function does nothing. I work with  
Cygwin. May be Cygwin is the problem?

Here is all the code I wrote (I hope copy & paste work here correctly):

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h> // AF_INET, SOCK_STREAM, connect()
#include <netdb.h>      // struct hostent
#include <netinet/in.h> // struct sockadd_in
#include <gnutls/gnutls.h>
#include <gnutls/x509.h>
#include <string.h>

#define MAX_BUF 1024
#define MAXMSG 512
#define CAFILE "/usr/ssl/certs/ca-bundle.trust.crt"

struct hostent *hostinfo;
struct sockaddr_in name;

static int _verify_certificate_callback (gnutls_session_t session);

void IP_number(struct sockaddr_in *name, char *servername, uint16_t port)
{
  char serverIP[16];
  if(hostinfo=gethostbyname(servername))
  {
   // converting name in IP number
   inet_ntop(PF_INET,hostinfo->h_addr_list[0],serverIP,16);
   printf("IP: %s\n",serverIP);
   name->sin_family = PF_INET;
   name->sin_port = htons(port);
   name->sin_addr = *(struct in_addr *) hostinfo->h_addr;
  }
   else
    {
      fprintf(stderr, "Unknown host %s.\n",servername);
      exit (EXIT_FAILURE);
    }
}

main()
{
  int ret, sd, ii;

  gnutls_session_t session;
  gnutls_srp_client_credentials_t srp_cred;
  gnutls_certificate_credentials_t cert_cred;

  char buffer2[MAX_BUF + 1];
  const char *err;

  // Required data
  char server[30];
  printf("Server: ");
  scanf("%s",server);

  char USER[30]="";
  printf("User: ");
  scanf("%s",USER);

  char *password;
  password=(char *)getpass("Password: ");

  char buffer[MAXMSG];
  uint16_t port=110;
  int sock=-1;
  size_t size;

  // converting server name in IP number
  IP_number(&name, server, port);

  // Creating socket for connection to this server
  sock = socket(AF_INET, SOCK_STREAM, 0);
  if (sock == -1)
  {
   perror("socket");
   exit (EXIT_FAILURE);
  }

  // Making the connection
  if (connect(sock, (struct sockaddr *) &name, sizeof (struct  
sockaddr_in)) < 0)
  {
   perror ("connect");
   exit (EXIT_FAILURE);
  }

  // Reading
  int amount = read(sock, buffer, MAXMSG);
  printf("%.*s", amount, buffer);
  write(sock,"CAPA\r\n",6);
  amount = read(sock, buffer, MAXMSG);
  printf("%.*s", amount, buffer);
  write(sock,"STLS\r\n",6);
  amount = read(sock, buffer, MAXMSG);
  printf("%.*s", amount, buffer);

// Security connection

gnutls_global_init();

gnutls_srp_allocate_client_credentials (&srp_cred);
gnutls_certificate_allocate_credentials (&cert_cred);
printf("\nAnzahl der verarbeiteten Zertifikate:  
%d\n",gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE,  
GNUTLS_X509_FMT_PEM));
gnutls_certificate_set_verify_function (cert_cred,  
_verify_certificate_callback);
gnutls_srp_set_client_credentials (srp_cred, USER, password);

gnutls_init (&session, GNUTLS_CLIENT);

gnutls_session_set_ptr (session, (void *) server);
gnutls_server_name_set (session, GNUTLS_NAME_DNS, server, strlen(server));

/* Use default priorities */
ret = gnutls_priority_set_direct (session,  
"NORMAL:+SRP:+SRP-RSA:+SRP-DSS", &err);
if (ret < 0)
   {
      if (ret == GNUTLS_E_INVALID_REQUEST)
	    {
		   fprintf (stderr, "Syntax error at: %s\n", err);
		}
	 exit(1);
   }

gnutls_credentials_set (session, GNUTLS_CRD_SRP, srp_cred);
gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, cert_cred);
gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sock);

do
    {
      ret = gnutls_handshake (session);
    } while (ret < 00 && gnutls_error_is_fatal (ret) == 0);

if (ret < 0)
{
  fprintf (stderr, "*** Handshake failed\n");
  gnutls_perror (ret);
  goto end;
}
else
{
  printf ("- Handshake was completed\n");
}

gnutls_record_send(session, "USER ########\r\n",15);
ret = gnutls_record_recv(session,buffer2,MAX_BUF);
  if (gnutls_error_is_fatal (ret) != 0 || ret == 0)
  {
    if (ret == 0)
      {
	   printf ("- Peer has closed the GnuTLS connection\n");
	   goto end;
	 }
	else
	 {
	   fprintf (stderr, "*** Error: %s\n", gnutls_strerror (ret));
	   goto end;
	 }
  }

     if (ret > 0)
	 {
	   printf ("- Reveived %d bytes: ", ret);
	  for (ii = 0 ; ii < ret; ii++)
	   {
	    fputc (buffer2[ii], stdout);
	   }
       fputs ("\n", stdout);
    }

gnutls_record_send(session, "PASS ########\r\n",15);
ret = gnutls_record_recv(session,buffer2,MAX_BUF);
  if (gnutls_error_is_fatal (ret) != 0 || ret == 0)
  {
    if (ret == 0)
      {
	   printf ("- Peer has closed the GnuTLS connection\n");
	   goto end;
	 }
	else
	 {
	   fprintf (stderr, "*** Error: %s\n", gnutls_strerror (ret));
	   goto end;
	 }
  }

     if (ret > 0)
	 {
	   printf ("- Reveived %d bytes: ", ret);
	  for (ii = 0 ; ii < ret; ii++)
	   {
	    fputc (buffer2[ii], stdout);
	   }
       fputs ("\n", stdout);
    }

gnutls_record_send(session, "RETR 1\r\n",8);
ret = gnutls_record_recv(session,buffer2,MAX_BUF);
  if (gnutls_error_is_fatal (ret) != 0 || ret == 0)
  {
    if (ret == 0)
      {
	   printf ("- Peer has closed the GnuTLS connection\n");
	   goto end;
	 }
	else
	 {
	   fprintf (stderr, "*** Error: %s\n", gnutls_strerror (ret));
	   goto end;
	 }
  }

     if (ret > 0)
	 {
	   printf ("- Reveived %d bytes: ", ret);
	  for (ii = 0 ; ii < ret; ii++)
	   {
	    fputc (buffer2[ii], stdout);
	   }
       fputs ("\n", stdout);
    }


   gnutls_bye (session, GNUTLS_SHUT_RDWR);

end:

  // Closing socket
  close(sock);

  gnutls_deinit(session);

  gnutls_srp_free_client_credentials (srp_cred);
  gnutls_certificate_free_credentials (cert_cred);

  gnutls_global_deinit();

  printf("Ready\n");

}

static int _verify_certificate_callback (gnutls_session_t session)
{
     unsigned int status;
	const gnutls_datum_t *cert_list;
	unsigned int cert_list_size;
	int ret;
	gnutls_x509_crt_t cert;
	const char *hostname;

	/* read hostname */
	hostname = gnutls_session_get_ptr (session);

	/* This varification function uses the trusted CAs in the credentials
	 * structure. So you must have installed one or more CA certificates.
	*/

	ret = gnutls_certificate_verify_peers2 (session, &status);
	if (ret < 0)
	  {
	    printf ("Error\n");
		return GNUTLS_E_CERTIFICATE_ERROR;
       }

	if (status & GNUTLS_CERT_SIGNER_NOT_FOUND)
	  printf ("The certificate hasn't got a known issuer\n");

	if (status & GNUTLS_CERT_REVOKED)
	  printf ("The certificate has been revoked\n");

	if (status & GNUTLS_CERT_EXPIRED)
       printf ("The certificate has expired\n");

     if (status & GNUTLS_CERT_NOT_ACTIVATED)
       printf ("The certificate is not yet activated\n");

     if (status & GNUTLS_CERT_INVALID)
       {
         printf ("The certificate is not trusted\n");
         return GNUTLS_E_CERTIFICATE_ERROR;
       }

     /* Up to here the process is the same for X.509 certificates and
      * OpenPGP keys. From now on X.509 certificates are assumed. This can
      * be easily extended to work with openpgp keys as well.
     */

     if (gnutls_certificate_type_get (session) != GNUTLS_CRT_X509)
       return GNUTLS_E_CERTIFICATE_ERROR;

     if (gnutls_x509_crt_init (&cert) < 0 )
       {
        printf ("error in initialization\n");
        return GNUTLS_E_CERTIFICATE_ERROR;
       }

     cert_list = gnutls_certificate_get_peers (session, &cert_list_size);
     if (cert_list == NULL)
       {
         printf ("No certificate was found!\n");
         return GNUTLS_E_CERTIFICATE_ERROR;
       }

     if (gnutls_x509_crt_import (cert, &cert_list[0], GNUTLS_X509_FMT_DER) < 0)
        {
          printf ("error parsing certificate\n");
          return GNUTLS_E_CERTIFICATE_ERROR;
        }

      if (!gnutls_x509_crt_check_hostname (cert, hostname))
        {
          printf ("The certificate's owner does not match hostname  
'%s'\n", hostname);
		 return GNUTLS_E_CERTIFICATE_ERROR;
	   }

	gnutls_x509_crt_deinit (cert);

	/* notify gnutls to continue handshake normally */
     return 0;
}

Some sensible data were replaced by ########. Thanks for any help / hints.

Alex'


-- 
http://home.chiemgau-net.de/ausserstorfer/


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From shaunmurphy at outlook.com  Sat Apr 20 19:48:16 2013
From: shaunmurphy at outlook.com (Shaun Murphy)
Date: Sat, 20 Apr 2013 13:48:16 -0400
Subject: [gnutls-help] Support for via quadcore SHA512 hw acceleration
Message-ID: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>

The limited literature for the newer VIA QuadCore E-Series embedded platform says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384, SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel modules or gnutls. I would appreciate some pointers on what I need to do to access that SHA512 acceleration in gnutls.
Here's my setup:Via Artigo A1250 Ubuntu 12.04 x86_64Gnutls - built from git (built nettle from source, everything else installed from apt)Kernel modules: padlock_aes, padlock_sha
Here's my dmesg output for the loaded modules:[    2.345061] padlock_aes: Using VIA PadLock ACE for AES algorithm.[    2.364105] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
Benchmark Soft Ciphers:Checking SHA1 (16kb payload)...  Processed 464.73 MB in 5.00 secs: 92.95 MB/secChecking SHA256 (16kb payload)...  Processed 180.04 MB in 5.00 secs: 36.01 MB/secChecking SHA512 (16kb payload)...  Processed 267.39 MB in 5.00 secs: 53.48 MB/sec
Benchmark Ciphers:Checking SHA1 (16kb payload)...  Processed 1.51 GB in 5.00 secs: 0.30 GB/secChecking SHA256 (16kb payload)...  Processed 1.30 GB in 5.00 secs: 0.26 GB/secChecking SHA512 (16kb payload)...  Processed 267.45 MB in 5.00 secs: 53.49 MB/sec
The SHA256 numbers are great but I really need SHA512 for my application.
Thank you.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130420/62b5a278/attachment.html>

From dkg at fifthhorseman.net  Sat Apr 20 21:23:21 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 20 Apr 2013 15:23:21 -0400
Subject: [gnutls-help] Support for via quadcore SHA512 hw acceleration
In-Reply-To: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>
References: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>
Message-ID: <5172EB29.8050802@fifthhorseman.net>

On 04/20/2013 01:48 PM, Shaun Murphy wrote:
> The limited literature for the newer VIA QuadCore E-Series embedded platform says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384, SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel modules or gnutls. I would appreciate some pointers on what I need to do to access that SHA512 acceleration in gnutls.
> Here's my setup:Via Artigo A1250 Ubuntu 12.04 x86_64Gnutls - built from git (built nettle from source, everything else installed from apt)Kernel modules: padlock_aes, padlock_sha

I suggest following up on the nettle mailing list about this; gnutls
should be able to use whatever acceleration nettle can provide:

  Nettle Crypto Library <nettle-bugs at lists.lysator.liu.se>

hth,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130420/82e88d6b/attachment.sig>

From nmav at gnutls.org  Sun Apr 21 12:20:32 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 21 Apr 2013 13:20:32 +0300
Subject: [gnutls-help] Support for via quadcore SHA512 hw acceleration
In-Reply-To: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>
References: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>
Message-ID: <CAJU7zaLVvr-u95dQZONqLwjXYntda3SMbNg=Sd9JGFZD2ov5yg@mail.gmail.com>

On Sat, Apr 20, 2013 at 8:48 PM, Shaun Murphy <shaunmurphy at outlook.com> wrote:
> The limited literature for the newer VIA QuadCore E-Series embedded platform
> says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384,
> SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel
> modules or gnutls. I would appreciate some pointers on what I need to do to
> access that SHA512 acceleration in gnutls.

Hello Shaun,
 I am not aware of this kind of CPUs. Do they use similar instructions
and detection as in nano? If yes, the current detection mechanism is
in lib/accelerated/x86/aes-padlock.c in check_phe_sha512() function.
It could be that a different capability bit is now enabled.

regards,
Nikos


From nmav at gnutls.org  Sun Apr 21 12:22:13 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 21 Apr 2013 13:22:13 +0300
Subject: [gnutls-help] Support for via quadcore SHA512 hw acceleration
In-Reply-To: <5172EB29.8050802@fifthhorseman.net>
References: <BAY176-W21579C0B658D6B1042BE22B6C90@phx.gbl>
 <5172EB29.8050802@fifthhorseman.net>
Message-ID: <CAJU7zaLfuzgXLSeS-B7Q5tZ3p8bM2zwc5f_o+ou6P=0bGvV1Lw@mail.gmail.com>

On Sat, Apr 20, 2013 at 10:23 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On 04/20/2013 01:48 PM, Shaun Murphy wrote:
>> The limited literature for the newer VIA QuadCore E-Series embedded platform says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384, SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel modules or gnutls. I would appreciate some pointers on what I need to do to access that SHA512 acceleration in gnutls.
>> Here's my setup:Via Artigo A1250 Ubuntu 12.04 x86_64Gnutls - built from git (built nettle from source, everything else installed from apt)Kernel modules: padlock_aes, padlock_sha
> I suggest following up on the nettle mailing list about this; gnutls
> should be able to use whatever acceleration nettle can provide:

Unfortunately that is not the case, even though I'd prefer that :(
Nettle does not provide accelerated code for AES-NI and via padlock,
thus that is currently done in gnutls.

regards,
Nikos


From austin_chi at amit.com.tw  Tue Apr  9 05:40:39 2013
From: austin_chi at amit.com.tw (Austin)
Date: Tue, 09 Apr 2013 03:40:39 -0000
Subject: [gnutls-help] about SSL VPN
Message-ID: <003301ce34ce$17f9fe90$47edfbb0$@com.tw>

Hello,

 

I want to find library (SSL VPN) for my company.

Could any products support SSL VPN which the function like openVPN?

 

If support this function, please contact to me.

Thanks

 

Austin Chi 
R&D Engineer 
Advance Multimedia Internet Technology Inc. 
+886-6-5058026 Ext. 630 
Skype: austin.chi.amit.com.tw

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130409/4e727909/attachment-0001.html>

From r.korthaus at sirrix.com  Tue Apr 16 16:15:27 2013
From: r.korthaus at sirrix.com (=?ISO-8859-15?Q?Ren=E9_Korthaus?=)
Date: Tue, 16 Apr 2013 14:15:27 -0000
Subject: [gnutls-help] Signature scheme for RSA signatures using
	gnutls_x509_crt_sign2
Message-ID: <516D4FD1.50902@sirrix.com>

Hi,

I need to know which signature scheme for RSA signatures from PKCS#1
v2.1 is used when signing a certificate using gnutls_x509_crt_sign2.
Unfortunately, I couldn't find an answer through source code analysis.
>From the Google Summer of Code page (http://gnutls.org/soc.html) it
seems that RSASSA-PSS is not yet supported and RSASSA-PKCS1-V1_5 is
currently used. Is this information still accurate?

Best regards,
Ren?

-- 
Sirrix AG security technologies - http://www.sirrix.com
Ren? Korthaus      eMail: r.korthaus at sirrix.com
Tel +49(681) 959 86-163    Fax +49(681) 959 86-5163
PGP Key ID 0x688EF9C8    Fingerprint 1FB6 2405 51C4 79DB C008 D1D2 C2E0 1A14 688E F9C8
Vorstand: Ammar Alkassar (Vors.), Christian St?ble, Markus Bernhammer
Vorsitzender des Aufsichtsrates: Harald St?ber
Sitz der Gesellschaft: Homburg/Saar, HRB 3857 Amtsgericht Saarbr?cken

This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and
delete this message. 



From shaharb at stanford.edu  Thu Apr 11 20:10:34 2013
From: shaharb at stanford.edu (Shahar Barak)
Date: Thu, 11 Apr 2013 18:10:34 -0000
Subject: [gnutls-help] can't find libnettle
Message-ID: <CAL6UvMrj-Wz5BTLVd=YWEQJGZzaU7A+8T1WJe7mdhnNT9eBb7A@mail.gmail.com>

Hi,

When I run ./configure I get the following error:
checking for libnettle... no
configure: error:
  ***
  *** Libnettle 2.5 was not found. Note that you must compile nettle with
gmp support.

Even though I have libnettle. It is in:
/usr/local/lib/libnettle.a

Please help. I'm a novice in these things.


Thanks,

Shahar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130411/ebf82197/attachment.html>