Cryptographically speaking, that's possible? Wouldn't it be possible for certain states hostile to their citizens to pay off some trusted CA to get a wide open arrangement of that sorts? Now someone thinking they're talking to gmail could be first talking to a data collection island in the middle?
Similarly, other vectors of attack are the IP routing and DNS. I do not understand the Noise protocol but couldn't an ISP or a government pretend to be man in the middle, between let us say a Signal user and its servers?
EDIT: Added IP and DNS aspects plus typos
This doesn’t stop interception, but the first time it happens that some huge company notices a certificate issuance they didn’t authorize and/or should be blocked by their CAA records, it’ll be a large event with disastrous consequences for the CA, likely triggering immediate (<48 hours) removal from publicly trusted CA lists.
Of course, if a country wants to intercept, they still can by intercepting all traffic with their own (new) CA - Kazakhstan tried this and asked all their citizens to install it if they wanted internet[1], but it shows that these efforts won’t go unnoticed and browser developers might fight back against government surveillance.
0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...
All CA certificates are accepted via emails, and are stored via a salesforce CRM that generates a csv spreadsheet. [1]
And yes, this is a system running since the 1990s and is very likely running on a heavily outdated UNIX machine.
So from a cyber security point of view, I wouldn't put much faith in the security of the SSL cert chains of the root store itself.
I don't know who maintains them, but I hope these services are not accessible from the internet, though it seems that the database was at least scanned by shodan, so yeah :-/
I really hope that distro maintainers in between validate what they push out as ca-certificates packages everywhere.
It gets increasingly more difficult to use websites that don't implement HTTPS. Some browsers will warn you if you try to enter a password on such websites, for example. Most users will not know what to do with such warnings, and will probably close the website upon seeing one. It's not impossible to imagine that, in ten or so years, some browsers might disallow plain HTTP entirely.
It's trivial for major governments (the US and the EU in particular) to impose know-your-customer requirements on CAs, or to force them to revoke the certificates of some unsavory websites.
Replacing your default browser with one that doesn't care about TLS support might not be trivial at that point, see Apple's restrictions on third-party browsers and Microsoft's recent tricks.
- what if a nation state has access to a CA
- what if a nation state creates a backdoor in TLS and the pull request gets merged
- what if a nation state creates a backdoor in your OS
- what if a nation state creates a backdoor in your hardware
All are possible but more likely is they’ll just use their influence to grab your data directly from the service providers themselves. Eg Google / Microsoft / Meta / Apple etc.
You could get around it by self hosting and using PGP but one has to ask what your personal risk is. With greater security comes greater hurdles and inconvenience
It involves subverting TLS by just the CA trick you mention, just with a private CA preinstalled in company supplied equipment. Worringly browser vendors seem to turn a blind eye to this, because it's not illegal in some countries. (Government espionage is also often legal but fortunately browser vendors haven't bent over there yet at least publicly)
Signal messenger uses the Signal Protocol.
Like most every other end to end encrypted messaging scheme, Signal uses cryptographic signatures (or the equivalent in the case of Signal) to insure that you are talking to who you think you are talking to. You end up with a sort of identity number (a really long one). As long as you can insure that you have the right identity number for your correspondent you can be sure that you are connected to that correspondent directly with no interlopers. In person you can use something like a QR code to do this. Otherwise you can try comparing numbers over the phone.
There is a whole discussion of Signal "safety numbers" and how they relate to a MITM attack here:
* https://sequoia-pgp.org/blog/2021/06/28/202106-hey-signal-gr...
From that I get that in most cases it would be possible to MITM a Signal connection because most users are unable to figure out how to verify their safety numbers.
https://en.wikipedia.org/wiki/Certificate_Transparency
to make it more visible if unreasonable but valid and trusted certificates (eg, a trusted Russian CA signed cert for google.com) are seen.
Sites can tell browsers what CA they should expect from that site
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ex...
if something else is seen, it tells the browser where to report it. This helps but if the attacker controls the victim routing it can suppress the reports.
Browsers ship trusting pretty much every country's CAs at the moment, which is convenient. If CAs are found to be mis-issuing certs, they will get distrusted from the browsers, which has happened several times already. But in wartime, they are not going to care about that if they can inflict massive damage first.
There's also Certificate Transparency [2] which maintains append-only logs of all issued certificates. I'm not really sure how widely it's implemented in browsers, or whether it can be bypassed somehow.
https://www.zdnet.com/article/russia-wants-to-ban-the-use-of...
They can only do it if you let them. If you trust someone malicious, nobody can save you, not TLS or anything else. What would the alternative be?
It was able to spotlights some inconsistencies.
But yes if you don't trust your government and its allies, HTTPS is not going to help a lot.
If you 1) choose to use a proxy and 2) that is a proxy you don't trust, then TLS is pointless for your use case. (Edit: you need to actually activate proxy usage)
I'm using home internet since the mid 90s and I think none of the ISPs I ever used required a proxy. (Mobile excluded, I'm certainly no mobile expert anyway) But I'm aware of ISPs in the late 90s that required ISP proxy usage.
Personally at some point I had set up a local squid to speed up my internet. But today? I think only really bad ISPs and some corporate networks use that. In the latter case it might make sense since you deal with corporate data/code that is owned by BigCorp anyway.
Regarding the CA stuff: yes sure but well, that's the point of the CA. You trust it, some OSs require you to explicitly install those if that matches your risk profile. But really, if you're at that point, maybe the far riskier attack vector is someone shoulder surfing or stealing your laptop?
That said, yes there's certificate transparency but I think it's still experimental and at that level of paranoia you might be optimizing/focussing on the wrong thing.
If you do TLs termination at the load balancer you can easily use any certificate down the line that you would like and thus this is a Feature.
I think the general gist of "i am connected to a server that I trust" is a mood point in general if you do not control the network that you are on. All you can really make sure is that your outgoing packet contains a desired destination.
I liked what mega and others have done, encrypting the data in the browser before sending it across the wire. Its an additional step but it almost solves the problem.
The way i solve this for me is to use a direct wireguard connected jump host in the cloud and a router at home that uses openwrt and at least can be checked completely.
1. Put the intercepting SSL cert root in your local trusted store. This is how it is done in enterprise. The certificate is typically pushed through an MDM installed on each computer/phone. This is also how Fiddler works. This requires administrative access to your device to push the certificate root as trusted.
2. Create a rogue certificate from an existing trusted certificate registrar. This is why is a risk with nations like China where "private" SSL registars mybe forced to issue certificates for Google or other sites to the government. This was supposed to be fixed with Certificate pinning (now deprecated), and now with certificate transparency log. But the later has a few weaknesses in practice: - rarely set as enforced by the websites, or set at at all - requires each company to monitor the transparency log and get rogue certificate canceled. I don't know of any company which actually does that.
3. Interception inside the browser through an extension or plugin, or plain process hijack. Since the browser does the HTTPS encryption/decryption, an application taht runs inside the browser with the right access can see all decrypted traffic.
As others have commented, it's a huge risk for that CA; once they're caught (and all that's needed as proof is the invalid certificate, which they have just sent to the user's browser), it's a death sentence for their CA business.
> Similarly, other vectors of attack are the IP routing and DNS. I do not understand the Noise protocol but couldn't an ISP or a government pretend to be man in the middle, between let us say a Signal user and its servers?
That used to be the case in the past, but nowadays most protocols (including Signal's) use some kind of cryptographic authentication, often the same TLS used by HTTPS. And since they are using a custom client instead of a generic browser, they can use some extra tricks like allowing only certificates signed by a couple of specific CAs, or even allowing only a specific set of trusted certificates, or using mutual certificate authentication (which breaks MITM since the proxy cannot forge the client's certificate to the server, even if the client trusts the forged server certificate).
The primary issue with this is that centralised services have a much greater network effect so this cannot be relied upon for everything.
It has been tried before; if you for instance generate certificates for the gmail domains Google will quickly find out because their applications refuse to connect to their sites using certificates that aren’t signed by the right authority.
https://security.googleblog.com/2011/08/update-on-attempted-...
And with certificate transparency it becomes ever more obvious if try to pull tricks.
Self host your software at home, and use a VPN like Wireguard to access it which helps with your MITM problem.
If you care about your data you should client side encrypt it before you send it.