[Dillo-dev] trustworthiness of dillo's TLS code at present

[eocene]

Currently I'd trust dillo for https about as much as I'd trust wget
for https. (Not that I've really examined wget, but just as a sort
of gauge here...)

Back in the DPI days, dillo didn't check hostnames on certificates
because that was an impossible nightmare with openssl unless you found
the code somewhere to modify for your own project.

[By the way, there was outrage a couple of years ago when people
realized that lots and lots of tools out there, and tls libraries
for popular languages, were using OpenSSL and not doing any hostname
validation.]

It was only with 3.0.5 that I had looked into TLS myself and learned
enough about what's insecure at present to disable old ciphers,
disable ssl3, disable tls compression.

When TLS moved into the browser with the OpenSSL version, I integrated
hostname checking code adapted from wget source. And now mbed TLS
does the checking itself.


At present, our weakness relative to something like chrome or firefox
would be in the area of certificate revocation. Dillo has never
had a way to know when a certificate has been revoked.


For a while, there were certificate revocation lists (CRLs) that
are generally published by the assorted certificate authorities,
although sometimes you have to click on agreements to get them.
The other problem is that those grow _huge_, and distributions
don't generally have packages for them (unlike ca-certificates
for root certificates). I wouldn't be surprised if the agreements
bar distribution.


And there was OCSP, which stands for.... Online Certificate Status
Protocol. Every time you get a certificate, you query some server,
often a third-party server, and ask it whether this certificate is
still valid. But those OCSP servers were/are nowhere near reliable
enough, and browsers couldn't very well fail everything when the
OCSP servers were being flaky..


So OCSP stapling has been coming along, where the OCSP data comes
from the original server along with the certificate. OpenSSL has
had OCSP code for a little while, but it's very buggy and not
documented, and maybe you could get it to work if your application
is exceedingly similar to the sample client, but good luck. mbed TLS
has OCSP on their roadmap, but it's not implemented yet.


As for what the firefoxes and chromes of the world are up to,
firefox ripped out their CRL code a while back and they have some
other mechanism where certificate authorities notify them of
revocations and they push it out. Because they're still big enough
to get certificate authorities to do things for them.

And they have 'public key pinning' where a server sends keys to
certificates, and the client checks that, when certificates are
presented in the future, they continue to use one or more of those
keys. My understanding is that this is not at all widely used
currently. Like if you go to google while claiming that you're
chrome, maybe.


_______________________________________________
Dillo-dev mailing list
Dill...@dillo.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev