Loading credentials in verify callback just as needed ?

[Tim Ruehsen]

Am Wednesday 29 August 2012 schrieb Nikos Mavrogiannopoulos:
> On Tue, Aug 28, 2012 at 12:23 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi, maybe you can help me or point me to the right direction.
> > 
> > My problem:
> > GnuTLS initialization - as used in tools like wget - loads ALL .pem files
> > from e.g. /etc/ssl/certs/. This takes 'ages' on slow computers (there
> > are hundreds of certificates).
> > I can't believe that all these certs are needed to handshake one single
> > HTTPS connection.
> 
> In the current Internet trust situation most probably you need all of
> those.
>
> > I am looking for a way to just load the needed certs (very likely with
> > the verification callback function).
> > The current code is mainly taken from the GnuTLS example client code.
> > It's initialization looks like
> > gnutls_global_init();
> > gnutls_certificate_allocate_credentials(&credentials);
> > gnutls_certificate_set_verify_function(credentials,_verify_certificate_ca
> > llback);
> > 
> >   * now loading all files in ca_directory by calling
> > 
> > gnutls_certificate_set_x509_trust_file(credentials, fname,
> > GNUTLS_X509_FMT_PEM);
> 
> You may also use gnutls_certificate_set_x509_system_trust() for this
> purpose.
> 
> > To reduce startup load, my idea is leaving away
> > 
> >         gnutls_certificate_set_x509_trust_file()
> > 
> > while initialization and call it right before
> > 
> >         gnutls_certificate_verify_peers2()
> > 
> > while handshaking.
> 
> I'm surprised that this function takes long for you. How many
> certificates do you have an which version of gnutls is that?

There are 150 certs at the moment.
GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in.
OpenSSL just ~5.000.

On my rather old AMD 2000+ it takes ~1s to load these.
Using valgrind for development (wget1.14), it takes around 30-40s.
See some output at the end of my inital post (i meant to write Wget1.14 there, 
not mget1.14).


> > But how do I know which files to load right here.
> > There must be some way to find that out which files/certs are needed.
> > As far as I know, OpenSSL is doing something similar using some kind of
> > hashes (c_rehash).
> > Does anyone can help ?
> 
> GnuTLS doesn't have something similar to that, like loading the CA
> file on demand.
> You could of course simulate that functionality by using the
> certificate's authority key identifier, or the issuer's name.

Here is exactly the point, where you could help me.
I would like to do that.
But when the verification callback function is called (set by 
gnutls_certificate_set_verify_function()), information about the key id or 
issuer seem not to be available.
The function is being called somewhere while handshaking.
After handshaking at least some info seems to be available:

Here is some output from the *_get_name() functions after handshake.
At the beginning of the verfify callback function, these fields are empty.

Key Exchange: ECDHE-RSA
Certificate info [0]:
  Certificate is valid since: Thu Jan  1 00:59:59 1970
  Certificate expires: Thu Jan  1 00:59:59 1970
  Certificate fingerprint: 83c997fda1c6a2b8d60ade7de771cc66
  Certificate public key: UNKNOWN
  Certificate version: #1
  DN: 
  Certificate Issuer's DN: 
Certificate info [1]:
  Certificate is valid since: Thu Jan  1 00:59:59 1970
  Certificate expires: Thu Jan  1 00:59:59 1970
  Certificate fingerprint: 33a0ea980e3d6e261d772d82df66007d
  Certificate public key: UNKNOWN
  Certificate version: #1
  DN: 
  Certificate Issuer's DN: 
Ephemeral ECDH using curve SECP256R1
Protocol: TLS1.2
Certificate Type: X.509
Compression: NULL
Cipher: AES-128-CBC
MAC: SHA1

Which of these informations can be used for my purpose.


> What I'd do if loading time was an issue, is to delegate verification to a
> special process that has the CAs loaded already.

Wget is in most cases a short time runner. Starting/Stopping a process/thread 
to load the CA files would even increase the impact on CPU load.

> regards,
> Nikos

Regards, Tim