[gnutls-devel] Speedup idea...

[Tim Ruehsen]

On Sunday, August 28, 2016 3:08:45 PM CEST Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-08-03 at 10:19 +0200, Tim Ruehsen wrote:
> > > This violates the rule that the credentials must be read only after
> > > being
> > > set on a session, but on client side they are only used during
> > > verification. An alternative approach is to verify the peers
> > > certificates
> > > using a trust list.
> > 
> > My goal is to only load that CA cert(s) that really have to be
> > checked 
> > against. I need to create a hash from the server certs which 'point'
> > to the CA 
> > cert files on disk, like OpenSSL already does. Well, we talked about
> > that in 
> > the past and you pointed me to p11kit... but in fact, I so far do not
> > really 
> > have a 'big picture' - the p11kit docs are mostly technical details,
> > no 
> > understandable explanation what 's it all about.
> 
> I just realized, do you really need all of that? You can cache
> verification outputs and that would be much more performant than any
> optimization we discussed. You could for example save the
> certificate/hostname pair once verified for limited time and rely on
> that verification result instead. Pretty much similar to the trust on
> first use, but here you will only be adding to the trusted store once
> successfully verified, and for limited time.

Thanks for the suggestion.

Of course I could - but than we have to add that code to any application that 
uses GnuTLS. IMO, such a solution is just a temporary work around until it is 
'fixed' in the library.

A bigger solution would be to have a (local) infrastructure service/daemon 
that provides these and other kinds of shared information to any process. 
Right now every network application has it's own code for caching (OCSP, HSTS, 
HPKP, Session data, Cookies, ...) and static data (PSL, HSTS Preload, ...).
Something like a pimped-up DNS :-))

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/20160902/ac1b77fc/attachment.sig>