- Dillo-dev - lists.mailman3.com

trustworthiness of dillo's TLS code at present

by eocene＠gmx.com

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.

July 4, 2016

CSS parser bug

by sgeerken＠dillo.org

Hi! The CSS parser seems to have a bug handling shorthand properties. This example works well, both properties are handled correctly: <body style="background: url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Adding "transparent" (for "background-color"), however, causes the other parts not to be parsed: <body style="background: transparent url(http://www.gnu.org/graphics/heckert_gnu.small.png) repeat-y"> Not a regression, dillo 3.0.5 shows the same behaviour. Sebastian

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Mon, 4 Jul 2016 17:01:39 +0000 eocene <eocene at gmx.com> wrote: > Nick wrote: > > > Should be -lmbedtls, -lmbedx509 and -lmbedcrypto > > > > All really does build fine now :) > > > > mbedtls seems to work well - seems a tad quicker too. > > I don't know where you got the > "-libmbedtls -libmbedx509 -libmbedcrypto" from. > Mine has "-lmbedtls -lmbedx509 -lmbedcrypto", > and it says "-lmbedtls -lmbedx509 -lmbedcrypto when > I double-check on hg.dillo.org. Ummm. You are right. Maybe I was messing around late last night with the earlier error message - I can't remember now :) Sorry for the noise - all builds and works fine. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 4, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Nick wrote: > A bit premature here. I quickly ran ./configure before work and > configure worked OK. But tonight, run make, my linker bombed out with: > > /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find > -libmbedtls /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find > -libmbedx509 /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: > cannot find -libmbedcrypto > > Strange, as ldconfig -v reveals: > > /usr/local/lib: > libmbedcrypto.so.0 -> libmbedcrypto.so.2.3.0 > libmbedtls.so.10 -> libmbedtls.so.2.3.0 > libmbedx509.so.0 -> libmbedx509.so.2.3.0 > > Anyway, an hour of investing, it turns out the linker flags are > incorrect - changing in configure fixed it up: > > if test "x$ssl_ok" = "xyes"; then > LIBSSL_LIBS="-libmbedtls -libmbedx509 -libmbedcrypto" > > Should be -lmbedtls, -lmbedx509 and -lmbedcrypto > > All really does build fine now :) > > mbedtls seems to work well - seems a tad quicker too. I don't know where you got the "-libmbedtls -libmbedx509 -libmbedcrypto" from. Mine has "-lmbedtls -lmbedx509 -lmbedcrypto", and it says "-lmbedtls -lmbedx509 -lmbedcrypto when I double-check on hg.dillo.org.

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Mon, 4 Jul 2016 06:08:58 +0100 Nick Warne <nick at linicks.net> wrote: > On Sun, 3 Jul 2016 21:09:40 +0000 > eocene <eocene at gmx.com> wrote: > > > I wrote: > > > I wrote: > > > > Nick wrote: > > > > > OK, what do I need to do to build this after an hour of head > > > > > scratching: > > > Making the attached changes makes it succeed, although I've only > > > gotten just that far at the moment and haven't looked into whether > > > it's an error on their part or what... > > > > Their bug: https://github.com/ARMmbed/mbedtls/issues/522 > > Good catch - all builds fine now - thanks, A bit premature here. I quickly ran ./configure before work and configure worked OK. But tonight, run make, my linker bombed out with: /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedtls /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedx509 /usr/lib/gcc/i486-slackware-linux/4.8.2/../../../../i486-slackware-linux/bin/ld: cannot find -libmbedcrypto Strange, as ldconfig -v reveals: /usr/local/lib: libmbedcrypto.so.0 -> libmbedcrypto.so.2.3.0 libmbedtls.so.10 -> libmbedtls.so.2.3.0 libmbedx509.so.0 -> libmbedx509.so.2.3.0 Anyway, an hour of investing, it turns out the linker flags are incorrect - changing in configure fixed it up: if test "x$ssl_ok" = "xyes"; then LIBSSL_LIBS="-libmbedtls -libmbedx509 -libmbedcrypto" Should be -lmbedtls, -lmbedx509 and -lmbedcrypto All really does build fine now :) mbedtls seems to work well - seems a tad quicker too. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 4, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Sun, 3 Jul 2016 21:09:40 +0000 eocene <eocene at gmx.com> wrote: > I wrote: > > I wrote: > > > Nick wrote: > > > > OK, what do I need to do to build this after an hour of head > > > > scratching: > > Making the attached changes makes it succeed, although I've only > > gotten just that far at the moment and haven't looked into whether > > it's an error on their part or what... > > Their bug: https://github.com/ARMmbed/mbedtls/issues/522 Good catch - all builds fine now - thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 4, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wrote: > I wrote: > > Nick wrote: > > > OK, what do I need to do to build this after an hour of head scratching: > > > > > > checking mbedtls/ssl.h usability... no > > > checking mbedtls/ssl.h presence... yes > > > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > > > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > > > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > > > documentation configure: WARNING: mbedtls/ssl.h: section "Present > > > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > > > with the compiler's result checking for mbedtls/ssl.h... no > > > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > > > support. *** > > > > IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't > > been around. > > > > Is anything interesting in the mbedtls region of the config.log file? > > > > I don't remember ever seeing quite that sort of set of warnings out > > of autoconf before. > > I was able to reproduce the problem by uninstalling mbed tls and then > pointing to it during configuration with CPPFLAGS to the include dir > and LDFLAGS to the lib dir. > > Making the attached changes makes it succeed, although I've only > gotten just that far at the moment and haven't looked into whether > it's an error on their part or what... Their bug: https://github.com/ARMmbed/mbedtls/issues/522

July 3, 2016

an experiment using mbed TLS

by eocene＠gmx.com

I wrote: > Nick wrote: > > OK, what do I need to do to build this after an hour of head scratching: > > > > checking mbedtls/ssl.h usability... no > > checking mbedtls/ssl.h presence... yes > > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > > documentation configure: WARNING: mbedtls/ssl.h: section "Present > > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > > with the compiler's result checking for mbedtls/ssl.h... no > > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > > support. *** > > IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't > been around. > > Is anything interesting in the mbedtls region of the config.log file? > > I don't remember ever seeing quite that sort of set of warnings out > of autoconf before. I was able to reproduce the problem by uninstalling mbed tls and then pointing to it during configuration with CPPFLAGS to the include dir and LDFLAGS to the lib dir. Making the attached changes makes it succeed, although I've only gotten just that far at the moment and haven't looked into whether it's an error on their part or what...

July 3, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Nick wrote: > OK, what do I need to do to build this after an hour of head scratching: > > checking mbedtls/ssl.h usability... no > checking mbedtls/ssl.h presence... yes > configure: WARNING: mbedtls/ssl.h: present but cannot be compiled > configure: WARNING: mbedtls/ssl.h: check for missing prerequisite > headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf > documentation configure: WARNING: mbedtls/ssl.h: section "Present > But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding > with the compiler's result checking for mbedtls/ssl.h... no > configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS > support. *** IIRC, Jeremy was the closest we had to an autoconf expert, but he hasn't been around. Is anything interesting in the mbedtls region of the config.log file? I don't remember ever seeing quite that sort of set of warnings out of autoconf before.

July 3, 2016

an experiment using mbed TLS

by nick＠linicks.net

On Sun, 3 Jul 2016 19:03:42 +0100 Nick Warne <nick at linicks.net> wrote: > On Sun, 3 Jul 2016 16:37:56 +0000 > eocene <eocene at gmx.com> wrote: > > > Jorge wrote: > > > On Mon, Jun 20, 2016 at 10:10:54AM +0200, Johannes Hofmann > > > wrote: > > > > On Sun, Jun 19, 2016 at 08:48:28PM +0000, eocene wrote: > > > > > > > > > > I wanted to see what it would take to use mbed tls with dillo. > > > > > > > > > > I put a copy of the diff at > > > > > http://www.dillo.org/test/mbedtls.diff and I mention it here > > > > > in case someone should want that one day. > > > > > > > > Excellent. I like mbedtls (formerly known as PolarSSL). The code > > > > looks much saner to me than openssl. > > > > > > If you both agree it's a better lib than OpenSSL, +1. > > > > All right, then. *commits* > > > > If you need mbed TLS 2.x: https://tls.mbed.org/download > > Ha ha.... that got me. I updated Dillo, and found SSL sites don't > work. So I clicked on the above link... doesn't work as it is SSL :) OK, what do I need to do to build this after an hour of head scratching: checking mbedtls/ssl.h usability... no checking mbedtls/ssl.h presence... yes configure: WARNING: mbedtls/ssl.h: present but cannot be compiled configure: WARNING: mbedtls/ssl.h: check for missing prerequisite headers? configure: WARNING: mbedtls/ssl.h: see the Autoconf documentation configure: WARNING: mbedtls/ssl.h: section "Present But Cannot Be Compiled" configure: WARNING: mbedtls/ssl.h: proceeding with the compiler's result checking for mbedtls/ssl.h... no configure: WARNING: *** mbed TLS 2 not found. Disabling SSL/HTTPS/TLS support. *** Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

July 3, 2016