Ask HN: Intercepting HTTPS – How can we trust anything?
The proxies like Squid can do HTTPS intercepting so I was wondering what's the point of TLS anyway? What if a nation state is determined to intercept all traffic of its internet users or even a major ISP - can't they get a trusted CA colluding with them in such a way that they can generate certificates on the fly and hence replacing the SSL certificate of every website that's get visited, decrypt and encrypt back?
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
97 comments
[ 3.1 ms ] story [ 195 ms ] threadIt 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.
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?
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.
1. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
2. https://en.wikipedia.org/wiki/Certificate_Transparency
(Mentioned also in your linked WP article - "Most browsers disable pinning for certificate chains with private root certificates to enable various corporate content inspection scanners")
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/...
1: https://news.ycombinator.com/item?id=25324951
I worked on a transparent MITM proxy, a proxy that is configured in the firewall not at the application; IE applications were unaware they were using a proxy.
Simply adding the proxies CA key to the system trust store was all that was needed to make all applications, including browsers, to trust the certificates we were manufacturing.
There was no indication besides inspecting the certificate that the certificate was ours. Definitely no calls go check certificate transparency that we could see.
Since TLS Interception is critical for some places to achieve their duties (either auditing in banking, or content filtering in schools) we will always have some kind of legit use for MITM CA boxes.
It gets slightly worse if you look at how AntiVirus generally installs CA's to do malware content filtering. Cloudflare publishes stats on what % of traffic they think has been MITM'd: https://malcolm.cloudflare.com/
In Poland where I live, parental control basically doesn't exist. Children routinely watch movies, play games and visit websites that they're theoretically not supposed to visit. Parents know about it and don't really see an issue with it. I've seen several boarding school networks, none of them had any filtering whatsoever. The only filters I've seen were on computers in IT classrooms, but nobody uses those for non class-related activities anyway. As far as I know, we don't even have a law banning selling x-rated content to minors.
- Technically, certificates are not required to be recorded in CT logs. If not submitted, they're still perfectly valid, but they won't be accepted by clients who insist on CT (e.g., most browsers). They will work perfectly well in all other situations.
- At the point of use, certificates must be accompanied by proofs of submission to several CT logs. These proofs are better known as Signed Certificate Timestamps, or SCTs. SCTs are _promises_ by CT logs to publish, but there is no way to know if the certificates actually had been published. You have to trust the CT logs. This is largely where we're currently with CT.
The main improvement is that a certificate must now be endorsed by min. 3 parties for it to work in a browser (CA + 2 CT log operators at present; 2 parties if a CA also operates one of the logs). At this time, Google must operate one of the CT logs [for the certificate to work in Chrome].
The missing piece (currently in progress) is SCT auditing, where a portion of observed SCTs are continuously checked for presence in CT logs. I wrote a little about it here: https://www.hardenize.com/blog/certificate-transparency-sct-...
We could split each transparency log into blocks, issuing a new block every 24 hours. Every block header would contain a hash of the root node of it's Merkle tree, the hash of the previous header and a digital signature. Storing 1000 latest headers for 5 transparency logs would take less than a megabyte, so most browsers would be fine with this.
When sending a certificate, the server would also send the header hashes for the block the certificate appears in, as well as the contents of any intermediate merkle tree nodes.
In the rare case where we encounter a certificate issued in the latest 24 hours, we would directly ask the transparency log for a hash list of all certificates issued in a given 1 minute period (taken from the issuance date in the certificate).
- 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
All happened already:
1) Hacked Mongolia CA
2) Dual_EC_DRBG
3) Eternal Blue
4) "NSA Interception In Action? Tor Developer's Computer Gets Mysteriously Re-Routed To Virginia"
Ok technically not backdoors and most of them conspiracy myths.
Yeah there is a lot out there to go deep down the rabbit hole
From that point onwards, every HTTPS interaction is just plain text.
I continue to be surprised that most people seem OK to keep the junk CAs which are preloaded on phones.
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)
To explain it in plain words: It's not acceptable because I have a human right to privacy.
Yes, privacy allows people to "hide" stuff. It's not an overriding thing. Employment relationships, like rest of our society, are largely based on trust and respect.
The last corporate IT job I had, they expected me to use my personal cell phone for job-related tasks. No, I didn't want their malware running on my phone, nor did I want to upgrade to an expensive cellular data plan for the required connectivity. If they wanted me to have a phone for their business, they should provide one.
Management and HR were quite upset. I suggested they check the state Labor Board. Shortly after, I was given a purchase authorization to buy a company phone and service.
Also, if this is a legit concern, you may have a hiring problem (or you work for .gov or on .gov contracts exclusively.)
A better an analogy would be a desk phone. Does the employer have the right to record phone calls if an announcement is made to all parties?
E.g., in the US, you have a right to not have your picture taken indoors, but outside in public spaces you don't have this right.
You have a right to do more or less whatever you want with your personal laptop, but your agreement with your employer generally implies that you should only use a work computer for work tasks.
I am not trying to trap you. I am genuinely trying to figure out where the lines are.
Edit: I just want to add that I however wouldn’t agree with or work for a company that monitors my work computer to make sure I’m always ”working” (taking screenshots, tracking mouse and keyboard etc).
Somehow most people understand that swimsuit is appropriate on the beach and on the swimming pool and not in the office.
I think there is false dichotomy that all monitoring is bad.
Yes if they come to you and nag about browsing hacker news because they found out you are slacking here and there it is totally overstepping.
If company decrypts traffic and has automated scanners to find out/block malware/bad sites I don't see an issue with that.
It's strictly forbidden by law and only allowed in very constrained circumstances when the employer has a strong suspicion ("Anfangsverdacht") that the employee is doing things they aren't allowed to. Even then the work council has to be informed and a representative has to be present to ensure no laws will be broken and privacy is preserved.
In the financial industry, it is strictly forbidden by law to miss reps talking to customers from their homes, on their personal devices and accounts. Banks are in the news getting fined for this routinely.
But they're not snooping on your personal devices at home, so this wouldn't even catch that.
I had to spend time in front of them to literally beg them to let us install an EDR (and heard similar stories from others).
At some point I said fuck it, we will disconnect this country and they will have problems.
This helped me to understand that the work council is the last to fall with people routinely working to there, so they do not care. Also Germany of too big of a country.
The net effect is that some projects do not go there anymore because of the complications.
Note 1: the installation was for security reasons. They had a security problem once and I was calling the work council on daily calls (twice a day) to show them that I can be a pain on the ass as well (it was in the contract we signed with them). Calls were at 8 and 21.
I hope they understood a bit why I was asking for the security measures.
Note 2: I am grateful when they ( and the ones in my country) fight for employees protection. This is great to work in such a country. There is however a moment where they lose content with the reality.
https://www.zdnet.com/article/russia-wants-to-ban-the-use-of...
Now you sign the exact same certificates as with upstream website and you're going to appear pretty much genuine.
The primary issue with this is that centralised services have a much greater network effect so this cannot be relied upon for everything.
Self host your software at home, and use a VPN like Wireguard to access it which helps with your MITM problem.
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.
[1] https://www.ccadb.org/
The proof is literally in the URL when you click on Resources / CSV download which is the following URL [1]
[1] http://ccadb-public.secure.force.com/ccadb/AllCertificateRec...
If you care about your data you should client side encrypt it before you send it.
If you want to protect the actual contents you should encrypt it within your application and not rely on the TLS layer to protect it as various products, tools and services strip off this layer (for better or worse)
Lots of people think you can protect your data just by using TLS which is false. If you don’t believe that try using mitmproxy or fiddler.
But those will give a TLS error unless the endpoint is already pwned.
Of course outside of the enterprise phishers will use a variety of other tricks as they are not in control of your CA list you trust (as you mention here) on your device. So they’ll for e.g. use domain names that either look legit or are very close to a real domain.
Lookalike domain names don't imply that TLS is broken. The guarantee from TLS is that you're talking to the owner of the domain you connect to, which is still true if you connect to the wrong one.
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.
Exactly. I think that's about it. Nothing else can be guaranteed.
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.
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.
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.
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).
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.
IMHO the most realistic attack vector in this context is a bug in TLS or a popular implementation that is being leveraged to target an individual. Whoever is in this situation, should seriously consider the way he or she uses the internet...
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.