Re: TODO: GNU TLS

Поиск
Список
Период
Сортировка
От David Boreham
Тема Re: TODO: GNU TLS
Дата
Msg-id 459AC61D.6070905@boreham.org
обсуждение исходный текст
Ответ на Re: TODO: GNU TLS  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Upcoming back-branch releases
Следующее
От: uwcssa
Дата:
Сообщение: SearchSysCache