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

@benjojo what the hell

@whitequark @benjojo cries in seceng

@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.

@coffee @benjojo The argument is probably something like “AIA makes SSL errors go away (and a better internet experience means more ad money for us), isn’t a big privacy issue, and is highly cacheable and” vs. “OCSP is bad for privacy and doesn’t help for most leaf revocations”. Or just https://www.imperialviolet.org/2014/04/29/revocationagain.html

ISTR Internet Explorer (Windows) filling in incomplete chains in the XP days, so it’s an old issue.

@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 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 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?

@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... 🤷‍♀️

@jamiemccarthy @benjojo I worked a little bit on this ~5 years ago. GSA had recently started scanning all of .gov every day, looking for (among other things) TLS implementation failures, and providing a public record of the results. Regrettably, that was later made private and transferred to CISA along with control of the .gov TLD. IDK what CISA is doing now to communicate to .gov domain owners about that.

@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!

@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

@benjojo @pkw I still like to use ssllabs.com for testing new https websites. Not only does it flag this issue, it tells you what browsers - and versions of browsers - your new TLS settings might have problems with