HTTPS Is a Privacy Nightmare(0x90.psaux.io)
0x90.psaux.io
HTTPS Is a Privacy Nightmare
https://0x90.psaux.io/2020/03/31/HTTPS-Is-A-Privacy-Nightmare/
2 comments
But what if it became like the situation in Kazakhistan where you can't connect to internet without installing state-issued certificate? Or a government forces that CA(assuming CA is in the same country) to sign another certificate? Or a stolen certificate is used in a MitM attack on specific individual?
Let's break this down.
What I'm proposing is:
Website A wants only SecurCA to issue certs. SecurCA uses Certificate Transparency (CT) and OCSP.
Website A uses Certificate Authority Authorization (CAA) to declare SecurCA as the only CA for that website and the Expect-CT header for enforcing Certificate Transparency checks.
We're assuming another mechanism to secure DNS here (DNSSEC? DoH? DoT? &c) -- more on that later.
----
- Government forces state-issued certificate on all computers.
If government MITMs all access, this is hard to detect except by shipping pre-pinned certificates with the OS (Microsoft). In that case, I'm not sure how to proceed. However, if the government only selectively MITMs, the CA not matching the site's CAA pinning would probably violate it.
- Government forces third-party CA to MITM.
The CA likely wouldn't add this to the CT logs. Expect-CT + strict browser CT checks would prevent the site from loading. If the CA does add it to the CT logs, the website owner can detect that the CA issued a bad cert on its behalf and this CA would be publicly shamed and removed from browser trust stores, (unless they revoked it via OCSP). And, with CAA, the CA the government would have to go to would have to be the same as the one in the CAA authorization records. Other CA's wouldn't work.
- A stolen certificate MITM.
This is the harder case. You have to trust that the website owner doesn't release their certificate. That's a harder problem that isn't currently solved. I'd argue it is nearly impossible. Things like HSMs help mitigate the risk to the highest profile targets but that leaves the wide middle at risk. There's no solution that will work for every website. That's not a TLS/PKI design flaw, but likely a fundamental cryptographic limitation.
But if the website operator did know that it was leaked, they could use OCSP to revoke it quickly.
---
All of TLS/PKI/... relies on DNS. Trust on first use + OS certificate stores is probably the best we can reasonably do when coupled with DNSSEC's questionable security and DoH/DoT. That, IMO, is a bigger problem than any HTTPS flaws.
Note that most of what you've argued in the blog post would happen to any protocol: when a great enough percentage X of traffic goes over it, either it'll be blocked (VPN/SSH/...) or there'll be mechanisms in place to enable Enterprises/... to access this data (TLS).
I think where we're getting to is a lot more secure than it was even 7 years ago when Snowden made his leaks.
What I'm proposing is:
Website A wants only SecurCA to issue certs. SecurCA uses Certificate Transparency (CT) and OCSP.
Website A uses Certificate Authority Authorization (CAA) to declare SecurCA as the only CA for that website and the Expect-CT header for enforcing Certificate Transparency checks.
We're assuming another mechanism to secure DNS here (DNSSEC? DoH? DoT? &c) -- more on that later.
----
- Government forces state-issued certificate on all computers.
If government MITMs all access, this is hard to detect except by shipping pre-pinned certificates with the OS (Microsoft). In that case, I'm not sure how to proceed. However, if the government only selectively MITMs, the CA not matching the site's CAA pinning would probably violate it.
- Government forces third-party CA to MITM.
The CA likely wouldn't add this to the CT logs. Expect-CT + strict browser CT checks would prevent the site from loading. If the CA does add it to the CT logs, the website owner can detect that the CA issued a bad cert on its behalf and this CA would be publicly shamed and removed from browser trust stores, (unless they revoked it via OCSP). And, with CAA, the CA the government would have to go to would have to be the same as the one in the CAA authorization records. Other CA's wouldn't work.
- A stolen certificate MITM.
This is the harder case. You have to trust that the website owner doesn't release their certificate. That's a harder problem that isn't currently solved. I'd argue it is nearly impossible. Things like HSMs help mitigate the risk to the highest profile targets but that leaves the wide middle at risk. There's no solution that will work for every website. That's not a TLS/PKI design flaw, but likely a fundamental cryptographic limitation.
But if the website operator did know that it was leaked, they could use OCSP to revoke it quickly.
---
All of TLS/PKI/... relies on DNS. Trust on first use + OS certificate stores is probably the best we can reasonably do when coupled with DNSSEC's questionable security and DoH/DoT. That, IMO, is a bigger problem than any HTTPS flaws.
Note that most of what you've argued in the blog post would happen to any protocol: when a great enough percentage X of traffic goes over it, either it'll be blocked (VPN/SSH/...) or there'll be mechanisms in place to enable Enterprises/... to access this data (TLS).
I think where we're getting to is a lot more secure than it was even 7 years ago when Snowden made his leaks.
Sorry, I should have written more clearly.
- Government forces state-issued certificate on all computers:
The government doesn't hide that it's MitM'ing all traffic. The traffic it can't read is blocked. All citizens must install a state-issued certificate to reach any content. There's nothing to do against it. This is what's happening in Kazakhistan now. If another country's government passes a bill, then they can enforce their certificates too. CAA and OCSP are irrelevant here.
- Website X issued a certificate from CA Y. CA Y is in government Z's jurisdiction. Government Z forces CA Y to issue that same certificate for itself. Because government Z make the laws fuck you:
This time the government hides that it's MitM'ing website X's traffic. No way to detect. The government decrypts traffic on the air. CAA and OCSP are irrelevant here.
- Stolen certificate:
Somebody stole the root certificate or stole a certificate given to specific website X. Now that somebody(maybe government) doesn't use this certificate widely but use it to attack to a specific target. It may be detectable but if the attacker uses it cleverly, it may also works. CAA and OCSP are relevant here.
- We deploy a new decentralized mechanism for TLS:
The government doesn't have a company or an organization to ask for a copy of a certificate. That authority is distributed among peers. Since the internet is built on this decentralized certification system, the government couldn't force its citizens to install a state-issued certificate because now the internet doesn't work that way. Now we can use this to secure DNS too.
Think it like this: The governments can't go and ask Open Whisper Systems to decrypt Signal messages, it would be ridiculous. We have to build HTTPS in a way that it would be ridiculous for a government to go to an organization and ask for certificates/keys.
I hope I made myself clear now.
- Government forces state-issued certificate on all computers:
The government doesn't hide that it's MitM'ing all traffic. The traffic it can't read is blocked. All citizens must install a state-issued certificate to reach any content. There's nothing to do against it. This is what's happening in Kazakhistan now. If another country's government passes a bill, then they can enforce their certificates too. CAA and OCSP are irrelevant here.
- Website X issued a certificate from CA Y. CA Y is in government Z's jurisdiction. Government Z forces CA Y to issue that same certificate for itself. Because government Z make the laws fuck you:
This time the government hides that it's MitM'ing website X's traffic. No way to detect. The government decrypts traffic on the air. CAA and OCSP are irrelevant here.
- Stolen certificate:
Somebody stole the root certificate or stole a certificate given to specific website X. Now that somebody(maybe government) doesn't use this certificate widely but use it to attack to a specific target. It may be detectable but if the attacker uses it cleverly, it may also works. CAA and OCSP are relevant here.
- We deploy a new decentralized mechanism for TLS:
The government doesn't have a company or an organization to ask for a copy of a certificate. That authority is distributed among peers. Since the internet is built on this decentralized certification system, the government couldn't force its citizens to install a state-issued certificate because now the internet doesn't work that way. Now we can use this to secure DNS too.
Think it like this: The governments can't go and ask Open Whisper Systems to decrypt Signal messages, it would be ridiculous. We have to build HTTPS in a way that it would be ridiculous for a government to go to an organization and ask for certificates/keys.
I hope I made myself clear now.
Fair, but what alternatives are there ?
I remember in the past Moxie Marlinspike developed something called Convergence. It's not alive now. He defined it as
"An agile, distributed, and secure strategy for replacing Certificate Authorities."
in his website(https://moxie.org/software.html). I don't remember how it worked but maybe we can develop something like that.
"An agile, distributed, and secure strategy for replacing Certificate Authorities."
in his website(https://moxie.org/software.html). I don't remember how it worked but maybe we can develop something like that.
This isn't in strict enforcement now, but in a couple of years when browsers have placed enough pressure on CAs, this could be workable and addresses most of the paranoia mentioned in the article.