[gnutls-devel] Speedup idea...

[Tim Ruehsen]

Hi Nikos, hi list.

Right after gnutls_init() the wget/wget2 code loads the certificate list - all 
available certs. That currently are 172 CA certs on Debian Sid right now.

This takes 15-20ms here (i3, 3.1GHz), when the files are already cached.

With session resumption (or False Start) and TCP Fast Open I just have 1xRTT 
tradeoff for TLS handshake. With slightly less than 33ms RTT that let's me 
theoretically fetch a file via HTTPS in ~66ms. But I have this damn load-them- 
all-CA (gnutls_certificate_set_x509_system_trust()) taking another 15ms, so I 
am at ~81ms for fetching a file. This is quite a big portion of the overall 
download time - having lower RTT makes this relation even worse.

My quick solution was (I thought it could work), why not load the certs during 
the handshake. Right after the first write(), when the handshake waits for the 
server answer, I have 33ms of time that I can use for loading.

But then... in ciphersuites.c/_gnutls_remove_unwanted_ciphersuites(), you 
"unload" all ciphersuites not needed by the certs, resulting in an error if no 
certs are loaded (because having 0 ciphersuites for client hello).

But everything works like a charm (I really have just 66ms total time) when I 
remove these lines from ciphersuites.c/_gnutls_remove_unwanted_ciphersuites():

		if (!session->internals.premaster_set &&
		    _gnutls_get_kx_cred(session, kx) == NULL) {
			continue;
		}

I guess, all cipher suites known by GnuTLS (or set via priorities) are offered 
by the client hello !?

What can we/I do to make the above scenario 'officially' work ?
Wouldn't it be good to offer all cipher suites set by gnutls_priority_set() ?
AFAIR, OpenSSL do not need certs to be loaded before client hello... but I 
might be wrong.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160802/ee6df24a/attachment-0001.sig>