experimental patch: gnutls for the https dpi
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl. The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much! So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch Now we'll _have_ to have a release soon, because we're accumulating so many things to play with after release...
On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote:
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl.
The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much!
So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch
Quite interesting. AFAIS from the patch it's doing more or less the same as the current https dpi. It looks like this dpi's certificate handling code may be easier to complete with GNU TLS. What's the motivation for the switch? -- Cheers Jorge.-
Jorge wrote:
On Wed, Jan 20, 2010 at 09:52:31AM +0000, corvid wrote:
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl.
The answer is: If you borrow liberally from the public domain code in the gnutls manual, then not very much!
So here's a toy for anyone who would like one: http://www.dillo.org/test/gnutls.0.patch
Quite interesting.
AFAIS from the patch it's doing more or less the same as the current https dpi. It looks like this dpi's certificate handling code may be easier to complete with GNU TLS.
What's the motivation for the switch?
- It's pleasing to using something GPLed and not have special linking exceptions in the license. - I get the impression that people are starting to look at openssl a little like they did with gtk1 ("How many programs do I have that still require it? Can I get rid of it?")
On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid@lavabit.com> wrote:
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl.
The answer is: If you borrow liberally from the public domain code in ? ? ? ? ? ? ? the gnutls manual, then not very much!
So here's a toy for anyone who would like one: ?http://www.dillo.org/test/gnutls.0.patch
What about NSS? https://fedoraproject.org/wiki/FedoraCryptoConsolidation It might bring even more (FIPS) compared to gnutls.
Now we'll _have_ to have a release soon, because we're accumulating so many things to play with after release...
Michal
Michal wrote:
On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid@lavabit.com> wrote:
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl.
The answer is: If you borrow liberally from the public domain code in ? ? ? ? ? ? ? the gnutls manual, then not very much!
So here's a toy for anyone who would like one: ?http://www.dillo.org/test/gnutls.0.patch
What about NSS?
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
It might bring even more (FIPS) compared to gnutls.
Does gnutls lack it because it requires paying $$ and/or infinite bureaucratic hurdles, or is it a technical matter? The NSS documentation seems to say that applications would no longer have to know where a file full of certificates is because that would all be taken care of by NSS in some centralized thing. Is that the case? _That_ would definitely appeal to me.
On Wed, Jan 20, 2010 at 9:01 PM, corvid <corvid@lavabit.com> wrote:
Michal wrote:
On Wed, Jan 20, 2010 at 10:52 AM, corvid <corvid@lavabit.com> wrote:
A few hours ago, I started to wonder how much trouble it would be to make https.c understand gnutls instead of openssl.
The answer is: If you borrow liberally from the public domain code in ? ? ? ? ? ? ? the gnutls manual, then not very much!
So here's a toy for anyone who would like one: ?http://www.dillo.org/test/gnutls.0.patch
What about NSS?
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
It might bring even more (FIPS) compared to gnutls.
Does gnutls lack it because it requires paying $$ and/or infinite bureaucratic hurdles, or is it a technical matter?
Possibility #1: definitely Possibility #2: FWIH, crypto part is easy, mostly eliminating "unsafe" algorithms and it's settings but there might be others not that easy stuff, like centralized cert management, ...
The NSS documentation seems to say that applications would no longer have to know where a file full of certificates is because that would all be taken care of by NSS in some centralized thing. Is that the case?
I guess so https://fedoraproject.org/wiki/CryptoConsolidationEval#NSS
_That_ would definitely appeal to me.
NSS seems to be the future of crypto API, unless it's too heavy-weight for project like Dillo, consider it instead of gnutls.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
newman.x＠gmail.com