Re: TODO: GNU TLS - Mailing list pgsql-hackers

From David Boreham
Subject Re: TODO: GNU TLS
Date
Msg-id 459AC61D.6070905@boreham.org
Whole thread Raw
In response to Re: TODO: GNU TLS  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout wrote:

>- Thread safety (GnuTLS is thread-safe by design, no locks needed)
>- Proper layering (creating your own I/O function is trivial)
>- Seperate namespace
>- Non-blocking support from the get-go
>
>were taken care of. Since people are citing maintainability as a
>concern, I think you really have wonder whether NSS is a better
>choice.
>  
>
Well...IMO NSS has some things that GNU TLS does not (correct me if
wrong on this, since my knowledge of GNU TLS is not extensive):

1. Very widely deployed, hence high level of confidence in its
interoperability, higher level of trust by the crypto community.

2. Backed by several large commercial organizations, hence
has support for new-fangled ciphers (elliptic curve ciphers for example, 
Suite B, etc)
and also hardware crypto accelerators and hard tokens.

3. Used in a popular web browser, hence subject to a reasonably
high level of effort to find and fix security bugs.

4. FIPS-140 certified. Used widely by US gubment.

5. Much work done over the years on crypto performance.

BTW NSS is also thread-safe, has layering (perhaps not the kind
of layering that everyone needs though) and supports non-blocking
sockets. NSS and NSPR functions are sensibly prefixed so
naming collisions should not occur.

Note that I'm not pushing NSS for PG - my choice would be OpenSSL.
Just presenting some info for balance, since I happen to know a something
about NSS.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Upcoming back-branch releases
Next
From: uwcssa
Date:
Subject: SearchSysCache