9 ms·

Ask HN: Intercepting HTTPS – How can we trust anything?

• speedgoose 5y ago
  The EFF had a project to collect certificates: https://www.eff.org/observatory https://www.eff.org/observatory 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.
• stavros 5y ago
  > The proxies like Squid can do HTTPS intercepting 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?
• outsomnia 5y ago
  Web PKI (or really, the web) is reasonably OK for peactime but is not going to survive very well at a "wartime footing". There are some attempts with Certificate Transparency https://en.wikipedia.org/wiki/Certificate_Transparency 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/Expect-CT 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.
  • wg0 5y ago
    That's interesting. But let's say I am a nation state hell bent on intercepting everything or even a major ISP in the region, can't I remove Except-CT header from all outgoing HTTPS responses?
    • rand846633 5y ago
      The requests containing Expect-CT headers are already encrypted, so how can you remove them?
• y7 5y ago
  Yes, if you have access to a root CA you can generally speaking man-in-the-middle HTTPS traffic. One defense is HPKP [1], where a certificate or root of trust is pinned so it cannot be substituted. But it's a bit tricky to implement, because if you make a mistake you can lock yourself out as server administrator. I think some browsers also hard-pin some certificates, like Chrome does for Google domains. 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 https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning 2. https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency
  • mgdm 5y ago
    I don’t believe any modern browser supports HPKP any more, due to how hard it was to set up and operate.
    • LinuxBender 5y ago
      They still honor it. I have to tell squid which domains to not MITM because some of Google's sub-domains, paypal, the EFF and a few others still use it.
      • toast0 5y ago
        I suspect all of those pins are from preloading (arranged by request with Chrome maintainers) and not HPKP. HPKP was supposed to allow for similar security after first use, without needing to interact with maintainers and wait for a browser release, but because of the probability of shooting your own foot, usage was extremely low and it was on the path to removal, last I checked.
  • fulafel 5y ago
    Note that most browsers allow MITM in presence of HPKP in certain circumstances to facilitate interception by schools and corporate IT. (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")
• GlitchMr 5y ago
  Browsers require certificates to be in Certificate Transparency logs. Therefore, a valid certificate would need to be submitted to CT logs, and a Certificate Authority found to generate certificates without permission would quickly find themselves removed out of browsers' trusted CA lists.
• judge2020 5y ago
  Certificate transparency effectively solves this because certain browsers (currently only Safari and Chrome) require all new certificates be submitted to multiple certificate transparency lists - if it encounters a certificate that isnt, it’ll show a warning page before establishing the TLS session. More info[0]. 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/main/net/docs/certificate-transparency.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... 1: https://news.ycombinator.com/item?id=25324951 https://news.ycombinator.com/item?id=25324951
  • georgyo 5y ago
    Does this actually work and in use? 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.
    • benjojo12 5y ago
      If the MITM CA is installed (maybe only via Group Policy) then browsers relax their requirements for CA's. But some domains (like google) are strictly locked down to a specific set of CA's in Chrome. 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/ https://malcolm.cloudflare.com/
• laumars 5y ago
  There’s a rabbit hole of what ifs one can descend down regarding this: - 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
  • number6 5y ago
    > All are possible 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
    • wg0 5y ago
      Consider this - All download URLs of top browsers get intercepted first and the binary fixed binary response gets returned which is actually patched version of the browser (as most major browsers are open source) containing additional CAs to be trusted. From that point onwards, every HTTPS interaction is just plain text.
      • landemva 5y ago
        'containing additional CAs to be trusted.' I continue to be surprised that most people seem OK to keep the junk CAs which are preloaded on phones.
        • jmholla 5y ago
          I realize I am one of those people. How do you tell legitimate/useful CAs apart from junk ones?
• fulafel 5y ago
  Not sure "nation states" are that interested or capable on doing this, but corporations actually routinely do this against employees and in some places a major portion of people even find it socially acceptable. (Nation state an interestingly often used term in these discussions btw, by chance it doesn't match the US or UK, which are prominent espionage actors on the world stage) 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)
  • mysterydip 5y ago
    If you're on company-owned equipment during hours the company is paying you to work, why wouldn't it be acceptable? Without such capabilities, people could hide any kind of traffic (from "I'll just check my social media while I'm here" to "I'll just upload some company secrets to my future employer" without recourse.
    • fulafel 5y ago
      Sounds like you are from one of those cultures I referenced! 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.
      • Hnrobert42 5y ago
        You are indeed entitled to privacy on your own equipment. Why should you be entitled to privacy on employer-owned equipment?
        • okasaki 5y ago
          Are you entitled to privacy on employer-owned toilets?
• test932184 5y ago
  Relevant: Russia wants to ban the use of secure protocols such as TLS 1.3, DoH, DoT, ESNI https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/ https://www.zdnet.com/article/russia-wants-to-ban-the-use-of...
  • wg0 5y ago
    That's the whole point of this discussion - they don't need to do anything like that and can be done transparently without any legislation. Just think of the scenario where you bribe certain CA staff and get a sub CA of your own or something like that. Now you sign the exact same certificates as with upstream website and you're going to appear pretty much genuine.
• btdmaster 5y ago
  There are some decentralised solutions for this issue such as Tor. With Tor, every domain generates their own public/private key pair (which represents the domain itself) hence making it impractical for actors to break all of them (in fact, breaking even one of the 128-bit ed25519 keys would be a breakthrough in cryptography). The primary issue with this is that centralised services have a much greater network effect so this cannot be relied upon for everything.
• exfil 5y ago
  Most of the nations have global TLS transparency solution in place. And CA's sign those intercept certificates by law.
  • wg0 5y ago
    It's just like encrypting EBS/block storage on AWS and clouds. You generate the keys and those keys are with the cloud provider nevertheless so it's not encrypted at all pretty much for all practical purposes.
    • igetspam 5y ago
      But it's good enough for compliance work. :)
      • wg0 5y ago
        Yeah, that's about it. It's just plain unencrypted otherwise. :)
• IceWreck 5y ago
  > How can we trust anything at all? Self host your software at home, and use a VPN like Wireguard to access it which helps with your MITM problem.
  • wg0 5y ago
    Self hosting won't solve much because even self hosted setup would have to talk to the outside world.
    • IceWreck 5y ago
      Which is why I said use Wireguard to talk to your self hosted services. HTTPS can be intercepted with a root certificate, a VPN cannot.
• cookiengineer 5y ago
  As a sidenote here: 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/ https://www.ccadb.org/
  • josephcsible 5y ago
    I don't think that's an authoritative source of trust.
    • cookiengineer 5y ago
      > I don't think that's an authoritative source of trust. 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/AllCertificateRecordsCSVFormat http://ccadb-public.secure.force.com/ccadb/AllCertificateRec...
      • josephcsible 5y ago
        I know that site has a copy of all the CA certificates. I'm saying it's not the authoritative copy of them. If someone hacked into that and added a rogue CA, your browser wouldn't magically start trusting it.
• beermonster 5y ago
  TLS mitigates against someone evil on the network to some extent. It is possible to snoop inside TLS connections in a variety of ways for a variety of reasons. If you care about your data you should client side encrypt it before you send it.
  • josephcsible 5y ago
    This makes no sense at all. TLS encryption does happen on the client side.
    • beermonster 5y ago
      Actually TLS happens client and server side and protects data in transit whilst established. But that means over the network. 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.
      • josephcsible 5y ago
        > If you don’t believe that try using mitmproxy or fiddler. But those will give a TLS error unless the endpoint is already pwned.
        • beermonster 5y ago
          Fiddler uses a certificate which you need to trust to intercept traffic. Enterprises also do this type of thing on a larger scale (see products from Bluecoat for e.g.) to monitor employees and for detecting exfiltration of data. 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.
• jhoelzel 5y ago
  Well thats an intersting thing with high availability no? 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.
  • wg0 5y ago
    > All you can really make sure is that your outgoing packet contains a desired destination. Exactly. I think that's about it. Nothing else can be guaranteed.
• miki123211 5y ago
  Another aspect of TLS I'm personally worried about is the ability of regulators to influence CAs. 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.
  • Capira 5y ago
    Indeed, a very real concern
• upofadown 5y ago
  > 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? 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-great-encryption-needs-great-authentication/ 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.
• tinus_hn 5y ago
  Most of these attacks are blocked by the use of certificates (basic proxying) and certificate pinning. 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-man-in-middle.html?m=1 https://security.googleblog.com/2011/08/update-on-attempted-... And with certificate transparency it becomes ever more obvious if try to pull tricks.
• cesarb 5y ago
  > 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? 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).
• throwaway984393 5y ago
  PKI isn't intended to be resistant to state actors. It's intended to keep your credit card safe from MITM by a wily hacker on your network.
• blablabla123 5y ago
  > The proxies like Squid can do HTTPS intercepting so I was wondering what's the point of TLS anyway? 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.
  • josephcsible 5y ago
    OP is talking about transparent/intercepting proxying, not proxying that you choose to use.
    • deleted 5y ago
      [deleted]
    • blablabla123 5y ago
      True which kind of excludes the usage of Squid, but that's even more effort because either one specific domain needs to be targeted or a whole cluster of domains. I mean the moment someone finds this out and publishes the public cert that has been used on HN the CA that issued it will be out of business within a month. Afterwards there would be a lot of fuzz and everybody might go all-in on CT. 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...
• imwillofficial 5y ago
  For awhile Symantec made MiTM proxies, and owned a CA. It was a ethically dubious position so they sold the CA.
• jusob 5y ago
  There are 3 ways to intercept HTTPS transparently (without a big SSL warning): 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.