2 ms·

> I don't follow the "browsers and loops" argument. To log in to my banking account, I need the correct password. No problem, I keep it in a password manager.

> I don't follow the "browsers and loops" argument. To log in to my banking account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. And so on. Imagine that, but for “verifying the HTTPS connection”.

lstamour 6y ago
But there’s an easy fix. I use it with my password manager. To log in to my bank account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I already know it. If I don’t know it, I look it up from a less secure source. Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.
kortex 6y ago
TLS involves both cert checking (server is truly who they say they are and not MITM) and Diffie-Helman key exchange to set up session keys (messages are end-to-end encrypted). You can DH with an untrusted cert. It might be interceptable. HTTP is always interceptable. But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy. As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.

lstamour 6y ago

But there’s an easy fix. I use it with my password manager. To log in to my bank account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I already know it. If I don’t know it, I look it up from a less secure source. Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.

kortex 6y ago

TLS involves both cert checking (server is truly who they say they are and not MITM) and Diffie-Helman key exchange to set up session keys (messages are end-to-end encrypted). You can DH with an untrusted cert. It might be interceptable. HTTP is always interceptable. But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy. As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.