The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3:
honk

@benjojo wow nice, that’s super interesting, thanks for doing it :D

@benjojo We spent a lot of time debating whether to do intermediate preloading in Firefox… but Chrome followed AIA, and we didn’t want to do third party resource loads for TLS.

I guess I missed the new behavior of Chrome, but it was always weird that it’d do AIA but not OCSP.

Good lightning talk.

@benjojo Ahh, I made this mistake not too long ago. It's pretty infuriating. I was using my cert for web and an application. So surely if the cert works in web but not in the application and I'm using a bog-standard LE cert, the issue has to be with the application, right? Because it works in the browser.

:)
@benjojo A person walks down the street wearing Office XP? You know they're not scared of anyone.
@benjojo this is wild! i feel like i've the chrome behaviour at work for internal sites a couple of times (doesn't for colleague work, but works for me...)
@benjojo Yes, it's a PITA; especially when I access sensitive sites in a freshly booted VM and it's not seen the cert from elsewhere. I've got at least a couple of banks and financial sites that do this.
@benjojo it was a good talk!
@benjojo doesn't chrome also do AIA fetching? (I.e. try to download the intermediate from the "CA Issuers" URL in the leaf cert.) I tried to analyze this a while ago, as it "looked like it might breed bugs", (but I haven't found any).
@benjojo Can you recommend any documentation (for example using openssl tools) for how to check / get / extract /add the intermediate certificates from / to chains or certificate files?
@basisbit @[email protected] I wrote a tool which searches intermediates because it was a common mistake which our customers made.

Most certs have an url which can be used to retrieve the intermediate. The majority of certs have this. I used this and Mozillas approach.

Similar tool:
https://github.com/muchlearning/cert-chain-resolver-py

You can check your intermediates that your server sends with openssl s_connect.
GitHub - muchlearning/cert-chain-resolver-py: SSL certificate chain resolver

SSL certificate chain resolver. Contribute to muchlearning/cert-chain-resolver-py development by creating an account on GitHub.

GitHub
@benjojo I didn't know about this, thanks for sharing!

@benjojo it gets worse, unfortunately. Firefox's first technique to deal with this was to cache intermediates from successful connections in case they'd ever be useful when a different server sent an incomplete chain. That leads to the same kind of inconsistent results you mentioned in Chrome.

gross as it is, though, all that matters to the user is that the site loads, so... 🤷‍♀️

@benjojo did you try using this for fingerprinting browsers?
@benjojo this is completely nuts. This same mistake happened with a large company website here but I was fortunately able to convince the Twitter person over DMs by showing them sslabs results and they fixed it in a few hours. As you said browsers work, everything else doesn't so it's a big pain.
@benjojo
That’s nuts.
Great lightning talk though! ❤️
@benjojo Very valid talk, this bugs the hell out of me too 😂
@benjojo so browsers are too helpful with TLS. I understand the 'happy user' aspect (and the resulting "I don't see the same SSL error" reports) but I think security technology should fail / succeed in a way that can be reproduced!

@benjojo nice.

But I have something to pick with LE as well: the "full chain" includes the root CA certificate. You do not want to have that in the file you give your webserver (especially nonGnuTLS clients are picky about that).

A hook can fix this if the root cert is known, but still…

dehydrated/docs/examples at stable · MirBSD/dehydrated

mksh‑ and MirBSD-compatible and feature-enhanced fork of the original dehydrated, a letsencrypt/acme client written in shell - MirBSD/dehydrated

GitHub
@mirabilos @benjojo Not LE user, for some reasons I am my own CA, but possibly have the same "issue". So how these files should be? I thought all certs should be in web server file and always make them this way. Is it wrong?
@madargon Uhhh, if you are using your own CA then that can be quite a hard question to answer.

If you have your certs directly signed by the CA, then you have no issue, you can serve the direct certificate and call it a day.

IF you have a intermediate then you also need to provide the intermediate in the "full chain" that you provide to TLS servers, otherwise you are praying that Chrome (FireFox's logic wont save you here) will fix it for you (Not even sure it will), There are some extra caveats for AIA, but that quickly gets into a huge can of worms

Madiana A. Argon :qurio: (@[email protected])

2.06K Meows, 2.64K Following, 2.03K Followers · Chief Emoji Officer on is-a.cat instance Too chaotic for a paladin. Probably a lich (https://is-a.cat/@madargon/112705760563792903). Amateur artist and junior IT administrator. Mostly self-trained in chaotic and often destructive ways. Opponent of mainstream social media and nasty digital surveillance, wanna-be cypherpunk. Linux user since 2013. Fully degoogled since December 2019. Fully BigTech-free since March 2024. Synesthete. That weird freak who sometimes uses Daedric alphabet. Even weirder freak who uses bare IP address instead of some server name. Cryptography is my only religion - does Church of Wael look for new members? In my free time I draw or write stories, first of all for my fun. I publish my works under CC BY-SA 4.0 license. Writing here in English/Polish. Migrated from @[email protected] Indexed in tootfinder (https://www.tootfinder.ch). #sysadmin #linux #degoogle #corpfree #privacy #cypherpunk #drawing #art #fedi22

I'm a cat!

@benjojo @madargon the root CA certificate must be in the browser (or /etc/ssl/certs etc.), the server certificate and any intermediates must be in the SSL server and returned to the client by it.

Order may also be important. In my Apache httpd setups, I always put things in the following order into the certificate file:

  • server certificate
  • intermediate certificate
  • DH parameters
  • I think that if you have multiple intermediates, put them in signatory chain order (i.e. always the one signing certificate x below x).

    @mirabilos @benjojo Update: Because my main server cert expired two days ago, I had to update it anyway. So this time I put only server cert and intermediate in the file for nginx. And was scared as hell something would stop working when root cert wouldn't be there. But everything seems to work correctly, my friends using my Matrix server didn't notice anything crashing 
    @madargon @benjojo because LE has ruined that term, I don’t like speaking about "full chain" because with LE the full chain includes the root certificate but that one must not be presented by the SSL server.