[HN Gopher] Stop Breaking TLS
___________________________________________________________________
Stop Breaking TLS
Author : todsacerdoti
Score : 139 points
Date : 2025-12-10 07:06 UTC (15 hours ago)
(HTM) web link (www.markround.com)
(TXT) w3m dump (www.markround.com)
| hacker_homie wrote:
| But I need to see what they are googling! /sarcasm
| MathMonkeyMan wrote:
| I remember at my first job, the internet stopped working at my
| workstation. I got on the phone with IT, and the guy said "looks
| like you don't have our new certificates." I asked why I would
| need my employer's certificates. He said "because we MITM every
| connection." I asked if that was even legal, and he said yes it's
| legal.
|
| At another job I was handling a support ticket where a customer
| was asking, in so many words, "can I get HTTP headers of requests
| flowing through my Envoy TLS reverse proxy?" I said that they
| could terminate TLS at the proxy and redo things that way, but
| then that wouldn't be a TLS proxy it'd be a MITM or a gateway.
| They could log the downstream/upstream and duration of
| connections, but that wouldn't help.
| phoronixrly wrote:
| Hey, allowing your employees to have secure connection to
| websites shows up in red in some Excel spreadsheet. We can't have
| Excel spreadsheets showing red in fintech. /s
| account42 wrote:
| > Consider this - what is the likelihood of every certificate
| authority on the Internet having their private keys compromised
| simultaneously? I'd wager that's almost at the whatever is the
| statistics equivalent of the Planck length level of probability.
|
| It doesn't matter if every certificate authority is compromised
| or just one. One is all that is needed to sign certificates for
| all websites.
| mark_round wrote:
| Author here, hi! Was just venting last night, but that's a very
| good point, I'll update it later with your correction :)
| acer4666 wrote:
| You should make it about CT logs. I believe you need to
| compromise at least three of them.
| tialaramex wrote:
| The whole point of the logs is that they're tamper-evident.
| If you think the certificate you've seen wasn't logged you
| can show proof. If you think the logs tell you something
| different from everybody else you can prove that too.
|
| It is striking that we don't see that. We reliably see
| people saying "obviously" the Mossad or the NSA are
| snooping but they haven't shown any evidence that there's
| tampering
| rnhmjoj wrote:
| > It is striking that we don't see that
|
| It probably just means they are asking the providers to
| hand over the data, no need to perform active attacks.
| dns_snek wrote:
| > We reliably see people saying "obviously" the Mossad or
| the NSA are snooping but they haven't shown any evidence
| that there's tampering
|
| Why would they use the one approach that leaves a
| verifiable trace? That'd be foolish.
|
| - They can intercept everything in the comfort of
| Cloudflare's datacenters
|
| - They can "politely" ask Cloudflare, AWS, Google cloud,
| etc. to send them a copy of the private keys for
| certificates that have already been issued
|
| - They either have a backdoor, or have the capability to
| add a backdoor in the hardware that generates those keys
| in the first place, should more convenient forms of
| access fail.
| tialaramex wrote:
| > Why would they use the one approach that leaves a
| verifiable trace?
|
| It is NSA practice to avoid targets knowing for sure what
| happened. However their colleagues at outfits like
| Russia's GRU have no compunctions about being seen and
| yet likewise there's no indication they're tampering
| either.
|
| Although Cloudflare are huge, a _lot_ of transactions you
| might be interested in don 't go through Cloudflare.
|
| > the hardware that generates those keys in the first
| place
|
| That's literally any general purpose computer. So this
| ends up as the usual godhood claim, oh, they're
| omniscient. Woo, ineffable. No action is appropriate.
| dns_snek wrote:
| That's the most naive take I've read online this year.
|
| So your stance is that spy agencies aren't spying on us
| because if they were, we'd know about it?
| mark_round wrote:
| That was what I was thinking of (but worded it badly in the
| middle of my rant!)
|
| If I wanted to intercept all your traffic to any external
| endpoint _without detection_ I would have to compromise the
| exact CA that signed your certificates each time, because
| it would be a clear sign of concern if e.g. Comodo started
| issuing certificates for Google. Although of course as long
| as a CA is in my trust bundle then the traffic could be
| intercepted, it 's just that the CT logs would make it very
| clear that something bad had happened.
| nly wrote:
| This is only relevant for active MITM attacks.
| sroussey wrote:
| Lame on user machines, but sometimes needed in a server
| environment. Easier to detect if someone is hauling off with your
| database as that will be the one you can't see what's going on.
| Of course, solve one problem and introduce three more.
| pimterry wrote:
| It's definitely annoying if you work in enterprise, but on the
| flip side: the fact that these enterprise requirements exist is
| the main reason that TLS certificate configurability is possible
| at all, without which it would be dramatically harder (or
| impossible) to reverse engineer or do security & privacy research
| on mobile apps, IoT, etc etc etc.
|
| Enterprise control over company devices and user control over
| personal devices are not so different.
|
| A few apps do use certificate pinning nowadays, which creates
| similar problems, but saying "you can never add your own MitM TLS
| cert" is not far from certificate pinning everything everywhere
| all the time. Good luck creating a new home assistant integration
| for your smart airfryer when you can't read any of the traffic
| from its app.
|
| Imo: let's make it easier! Standardize TLS configuration for all
| tools, make easy cert configuration of devices a legal
| requirement (any smart device sold with hardcoded CA certificates
| is a device with a fixed end date, where the CA certs expire and
| it becomes a brick), guarantee user control over their own TLS
| trust, and provide good tools to check exactly who you're
| trusting (and expose that clearly to users). Not really practical
| of course (and opens all sorts of risky games with nation state
| interception as well) but there are upsides here as well.
| samuel wrote:
| I agree with the sentiment, but I think it's a pretty naive view
| of the issue. Companies will want all info they can in case some
| of their workers does something illegal-inappropiate to deflect
| the blame. That's a much more palpable risk than "local CA
| certificates being compromised or something like that.
|
| And some of the arguments are just very easily dismissed. You
| don't want your employer to see you medical records? Why were you
| browsing them during work hours and using your employers' device
| in the first place?
| immibis wrote:
| In Europe they prefer not to go to jail for privacy violations.
| It turns out _most_ of these "communist" regulations are
| actually pretty great.
| johncolanduoni wrote:
| Does GDPR (or similar) establish privacy rights to an
| employee's use of a company-owned machine against snooping by
| their employer? Honest question, I hadn't heard of that
| angle. Can employers not install EDR on company-owned
| machines for EU employees?
| apexalpha wrote:
| Yes, at least in the Netherlands it is generally accepted
| that employees can use your device personally, too.
|
| Using a device owned by your company to access your
| personal GMail account does NOT void your legal right to
| privacy.
| johncolanduoni wrote:
| So does nobody in Europe use an EDR or intercepting proxy
| since GDPR went into force?
| samuel wrote:
| I have found a definite answer from the Dutch Protection
| Agency (although it could be out of date).
|
| https://english.ncsc.nl/binaries/ncsc-
| en/documenten/factshee...
| johncolanduoni wrote:
| What's the definitive answer? From what I can tell that
| document is mostly about security risks and only mentions
| privacy compliance in a single paragraph (with no
| specific guidance). It definitely doesn't say you can or
| can't use one.
| immibis wrote:
| That's probably because there is no answer. Many laws
| apply to the total thing you are creating end-to-end.
|
| Even the most basic law like "do not murder" is not "do
| not pull gun triggers" and a gun's technical reference
| manual would only be able to give you a vague statement
| like "Be aware of local laws before activating the
| device."
|
| Legal privacy is not about whether you intercept TLS or
| not; it's about whether someone is spying on you, which
| is an end-to-end operation. Should someone be found to be
| spying on you, then you can go to court and they will
| decide who has to pay the price for that. And _that_
| decision can be based on things like whether some
| intermediary network has made poor security decisions.
|
| This is why corporations do bullshit security by the way.
| When we on HN say "it's for liability reasons" this is
| what it means - it means when a court is looking at who
| caused a data breach, your company will have plausible
| deniability. "Your Honour, we use the latest security
| system from CrowdStrike" sounds better than "Your Honour,
| we run an unpatched Unix system from 1995 and don't
| connect it to the Internet" even though us engineers know
| the latter is probably more secure against today's most
| common attacks.
| johncolanduoni wrote:
| Okay, thanks for explaining the general concept of law to
| me, but this provides literally no information to figure
| out the conditions under which an employer using a TLS
| intercepting proxy to snoop on the internet traffic a
| work laptop violates GDPR. I never asked for a definitive
| answer just, you know, an answer that is remotely
| relevant to the question.
|
| I don't really need to know, but a bunch of people seemed
| really confident they knew the answer and then provided
| no actual information except vague gesticulation about
| PII.
| zeeZ wrote:
| They can, but the list of "if..." and "it depends..." is
| much longer and complicated, especially when getting to the
| part how the obtained information may be used
| Msurrow wrote:
| Yes. GDPR covers all handling of PII that a company does.
| And its sort of default deny, meaning that a company is not
| allowed to handle (process and/or store) your data UNLESS
| it has a reason that makes it legal. This is where it
| becomes more blurry: figuring out if the company has a
| valid reason. Some are simple, eg. if required by law =>
| valid reason.
|
| GDPR does not care how the data got "in the hands of" the
| company; the same rules apply. Another important thing is
| the pricipals of GDPR. They sort of unline everything. One
| principal to consider here is that of data minimization.
| This basically means that IF you have a valid reason to
| handle an individuals PII, you must limit the data points
| you handle to exactly what you need and not more.
|
| So - company proxy breaking TLS and logging everything?
| Well, the company has valid reason to handle some employee
| data obviously. But if I use my work laptop to access
| privat health records, then that is very much outside the
| scope of what my company is allowed handle. And logging
| (storing) my health data without valid reason is not GDPR
| compliant.
|
| Could the company fire me for doing private stuff on a work
| laptop? Yes probably. Does it matter in terms of GDPR?
| Nope.
|
| Edit: Also, "automatic" or "implicit" consent is not valid.
| So the company cannot say something like "if you access
| private info on you work pc the you automatically content
| to $company handling your data". All consent must be
| specific, explicit and retractable
| johncolanduoni wrote:
| What if your employer says "don't access your health
| records on our machine"? If you put private health
| information in your Twitter bio, Twitter is not obligated
| to suddenly treat it as if they were collecting private
| health information. Otherwise every single user-provided
| field would be maximally radioactive under GDPR.
| Msurrow wrote:
| If the employer says so and I do so anyway then that's a
| employment issue. I still have to follow company rules.
| But the point is that the company needs to delete the
| collected data as soon as possible. They are still not
| allowed to store it.
| johncolanduoni wrote:
| I'll give an example in more familiar with. In the US,
| HIPPA has a bunch of rules about how private health
| information can be handled by everyone in the supply
| chain, from doctor's offices to medical record SaaS
| systems. But if I'm running a SaaS note taking app and
| some doctor's office puts PHI in there without an express
| contract with me saying they could, I'm not suddenly
| subject to enforcement. It all falls on them.
|
| I'm trying to understand the GDPR equivalent of this,
| which seems to exist since every text fields in a
| database does not appear to require the full PII
| treatment in practice (and that would be kind of insane).
| immibis wrote:
| Many programmers tend to treat the legal system as if it
| was a computer program: if(form.is_public &&
| form.contains(private_health_records)) move(form.owner,
| get_nearest_jail()); - but this is not how the legal
| system actually works. Not even in excessively-
| bureaucratic-and-wording-of-rules-based Germany.
| johncolanduoni wrote:
| Yeah, that's my point. I don't understand why the fact
| that you could access a bunch of personal data via your
| work laptop in express violation of the laptop owner's
| wishes would mean that your company has the same
| responsibilities to protect it that your doctor's office
| does. That's definitely not how it works in general.
| immibis wrote:
| The legal default assumption seems to be that you _can_
| use your work laptop for personal things that don 't
| interfere with your work. Because that's a normal thing
| people do.
| immibis wrote:
| I suspect they should say "this machine is not
| confidential" and have good reasons for that - you can't
| just impose extra restrictions on your employees _just
| because you want to_.
|
| The law (as executed) will weigh the normal interest in
| employee privacy, versus your legitimate interest in
| doing whatever you want to do on their computers.
| Antivirus is probably okay, even if it involves TLS
| interception. Having a human watch all the traffic is
| probably not, even if you didn't have to intercept TLS.
| Unless you work for the BND (German Mossad) maybe? They'd
| have a good reason to watch traffic like a hawk. It's all
| about balancing and the law is never as clear-cut as
| programmers want, so we might as well get used to it
| being this way.
| samuel wrote:
| (IANAL) I don't think there is a simple response to that,
| but I guess that given that the employer:
|
| - has established a detailed policy about personal use of
| corporate devices
|
| - makes a fair attempt to block work unrelated services
| (hotmail, gmail, netflix)
|
| - ensures the security of the monitored data and deletes it
| after a reasonable period (such as 6-12 months)
|
| - and uses it only to apply cybersecurity-related measures
| like virus detection, UNLESS there is a legitimate reason
| to target a particular employee (legal inquiry, misconduct,
| etc.)
|
| I would say that it's very much doable.
|
| Edit: More info from the Dutch regulator https://english.nc
| sc.nl/publications/factsheets/2019/juni/01...
| immibis wrote:
| It has to have a good purpose. Obviously there are a lot of
| words written about what constitutes a good purpose.
| Antivirus is probably one. Wanting to intimidate your
| employees is not. The same thing applies to security
| cameras.
|
| Privacy laws are about the end-to-end process, not
| technical implementation. It's not "You can't MITM TLS" -
| it's more like "You can't spy on your employees". Blocking
| viruses is not spying on your employees. If you take the
| logs from the virus blocker and use them to spy on your
| employees, then you are spying on your employees. (Virus
| blockers aiming to be sold in the EU would do well not to
| keep unnecessary logs that could be used to spy on
| employees.)
| itopaloglu83 wrote:
| I'm all for privacy of individuals, but work network is not a
| public internet either.
|
| A solution is required to limit the network to work related
| activities and also inspect server communications for unusual
| patterns.
|
| In one example someone's phone was using the work WiFi to
| "accidentally" stream 20 GB of Netflix a day.
| sceptic123 wrote:
| What's the security risk of someone streaming Netflix?
|
| There are better ways to ensure people are getting their work
| done that don't involve spying on them in the name of
| "security".
| treesknees wrote:
| Security takes many forms, including Availability.
|
| Having branch offices with 100 Mbps (or less!) Internet
| connections is still common. I've worked tickets where the
| root cause of network problems such as dropped calls ended
| up being due to bandwidth constraints. Get enough users
| streaming Spotify and Netflix and it can get in the way of
| legitimate business needs.
|
| Sure, there's shaping/qos rules and dns blocking. But the
| point is that some networks are no place for personal
| consumption. If an employer wants to use a MITM box to
| enforce that, so be it.
| sceptic123 wrote:
| I think that's a very loose interpretation of
| Availability in the CIA triad.
|
| This looks a lot like using the MITM hammer to crack
| every nut.
|
| If this is an actual concern, why not deny personal
| devices access to the network? Why not restrict the
| applications that can run on company devices? Or provide
| a separate connection for personal
| devices/browsing/streaming?
|
| Why not treat them like people and actually talk to them
| about the potential impacts. Give people personal
| responsibility for what they do at work.
| itopaloglu83 wrote:
| Yes, but also it's not an employer's job to provide
| entertainment during work hours on a factory floor where
| there are machines that can kill you if you're not
| careful.
|
| There's a famous fable where everyone is questioning the
| theft victim about what they should've done and the
| victim says "doesn't the thief deserve some words about
| not stealing?"
|
| Similarly, it's a corporate network designed and
| controlled for work purposes. Connecting your personal
| devices or doing personal work on work devices is already
| not allowed per policy, but people still do it, so I
| don't blame network admins for blocking such connections.
| itopaloglu83 wrote:
| What's wrong with watching Netflix at work instead of
| working? That's not for me to say, but I understand
| employers not wanting to allow it.
| NicolaiS wrote:
| TLS inspection can _never_ be implemented in a good way, you
| will always have cases where it breaks something and most
| commonly you will see very bad implementations that break most
| tools (e.g. it is very hard to trust a new CA because each of
| OS/browser/java/python/... will have their own CA store)
|
| This means devs/users will skip TLS verification ("just make it
| work") making for a dangerous precedent. Companies want to
| protect their data? Well, just protect it! Least privilege,
| data minimization, etc is all good strategies for avoiding data
| leaking
| gschizas wrote:
| The fact that most tools have completely different ways to allow
| them to add certificates is the biggest pain. Git, Python and
| Rust also have large issues. Git doesn't default to
| "http.schannel". Python (or rather requests, or maybe urllib3)
| only looks at its own certificate store, and I have no idea how
| Rust does this (well, I use uv, and it has its own problems - I
| know about the --use-native-tls flag, but it should be a default
| at the least).
| nikanj wrote:
| And many things break in different, exciting ways. For example,
| we discovered that whilst the JVM can be configured to use
| system certificate store, that does not apply to websocket
| connections. So the product seems to be able to connect to the
| server, but all socket connections bork out with TLS errors.
|
| Fun!
|
| And so many of those products deliver broken chains, and your
| client needs to download more certificates transparently (
| https://systemweakness.com/the-hidden-jvm-flag-that-instantl...
| )
|
| Double the fun!
| sureglymop wrote:
| I have this similar gripe when it comes to http proxy
| configuration. It's invisible to you until you are in an
| execution environment where you are mandated to use the
| providers proxy configuration.
|
| Some software reads "expected" env variables for it, some has
| its own config or cli flags, most just doesn't even bother/care
| about supporting it.
| amiga386 wrote:
| Chiefly because "supporting it" requires a full JavaScript
| interpreter, and subscribing to changes in "system settings"
| during the lifetime of your program. Easier just to support
| http_proxy/https_proxy/no_proxy (and what standard for
| no_proxy? Does it support CIDR ranges?) or even less
| flexibility than that.
| noroot wrote:
| It's such a nightmare at my current job as well. Everything
| always just breaks and needs investigating how to fix.
|
| Even putting aside the MITM and how horrendous that is, the
| amount of time lost from people dealing with the fallout got to
| have cost so much time (and money). I can't fathom why anyone
| competent would want to implement this, let alone not see how
| much friction and safety issues it causes everywhere.
| dcminter wrote:
| > _I can 't fathom why anyone competent would want to
| implement this_
|
| Compliance. Big financial orgs. and the like _must_ show that
| they are doing something about "data loss" and this, sadly,
| is the easiest way to do that.
|
| There's money in it if you can show them a better way.
| dcminter wrote:
| Yeah, and Java has its nice cacerts file so that should have
| been easy, but then we were using Bazel which does the
| "hermetic builds" thing so that had to be told about it
| separately, and on and on with all the other special-snowflake
| tools.
|
| It added huge amounts of friction which was one reason I
| decided to move on from that gig.
| jeroenhd wrote:
| On Android, macOS/iOS, and Windows, this is a solved problem.
| Only on the extremely fragmented Linux/Posix runtimes do these
| problems surface.
|
| Rust's solution is "it depends". You can use OpenSSL (system or
| statically compiled) or rustls (statically compiled with your
| own CA roots, system CA roots, or WebPKI CA roots).
|
| I'm afraid that until the *ix operating systems come out with a
| new POSIX-like definition that stabilises a TLS API, regardless
| of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS,
| we'll have to keep hacking around in APIs that need to be
| compatible with arbitrary TLS configurations. Alternatively,
| running applications through Waydroid/Wine will work just fine
| if Linux runtimes can't get their shit together.
| dmm wrote:
| > Windows, this is a solved problem.
|
| Are you sure? It's been a few years, but last I tried Firefox
| used its own CA store on Windows. I'm pretty sure openjdk
| uses "<JAVA_HOME>/jre/lib/security/cacerts" instead of the
| system store too.
| dingaling wrote:
| I absolutely do not want to be constrained to a single system
| cert store controlled by the OS vendor.
| Daviey wrote:
| Honestly, the author is spot on about the normalisation problem.
| I've watched this play out at multiple organisations. You
| implement TLS inspection, spend ages getting certs deployed, and
| within six months `curl -k` is in half your runbooks because
| "it's just the corporate proxy again".
|
| He's also absolutely right about the architectural problems too,
| single points of failure, performance bottlenecks, and the
| complexity in cloud-native environments.
|
| That said, it can be a genuinely valuable layer in your security
| arsenal when done properly. I've seen it catch real threats, such
| as malware C2 comms, credential phishing, data exfiltration
| attempts. These aren't theoretical; they happen daily. Combined
| with decent threat intelligence feeds and behavioural analytics,
| it does provide visibility that's hard to replicate elsewhere.
|
| But, and this is a massive but, you can't half-arse it. If you're
| going to do TLS inspection, you need to actually commit:
|
| Treat that internal CA like it's the crown jewels. HSMs, strict
| access controls, proper rotation schedules, full-chain and
| sensible life-span. The point about concentrated risk is bang on,
| you've turned thousands of distributed CA keys into one single
| target. So act like it. Run it like a proper CA with proper key
| signing ceremonies and all the safeguards etc.
|
| Actually invest in proper cert distribution. Configuration
| management (Ansible/Salt/whatever), golden container base images
| with the CA bundle baked in, MDM for endpoints, cloud-init for
| VMs. If you can't reliably push a cert bundle to your entire
| estate, you've got bigger problems than TLS inspection.
|
| Train people properly on what errors are expected vs "drop
| everything and call security". Document the exceptions. Make
| reporting easy. Actually investigate when someone raises a TLS
| error they don't recognise. For dev's, it needs to just work
| without them even thinking about it. Then they don't need to work
| around it, ever. If they need to, the system is busted.
|
| Scope it ruthlessly. Not everything needs to go through the
| proxy. Developer workstations with proper EDR? Maybe exclude
| them. Production services with cert pinning? Route direct. Every
| blanket "intercept everything" policy I've seen has been a
| disaster. Particularly for end-users doing personal banking,
| medical stuff, therapy sessions, do you really want IT/Sec seeing
| that?
|
| Use it alongside modern defences. ie EDR, Zero Trust, behavioural
| analytics, CASB. It should be one layer in defence-in-depth, not
| your entire security strategy.
|
| Build observability, you need metrics on what's being inspected,
| what's bypassing, failure rates, performance impact. If you can't
| measure it, you can't manage it.
|
| But Yeah, the core criticism stands though, even done well, it's
| a massive operational burden and it actively undermines trust in
| TLS. The failure modes are particularly insidious because you're
| training people to ignore the very warnings that are meant to
| protect them.
|
| The real question isn't "TLS inspection: yes or no?" It's: "Do we
| have the organisational maturity, resources, and commitment to do
| this properly?" If you're not in a regulated industry or don't
| have dedicated security teams and mature infrastructure
| practices, just don't bother. But if you must do it, and plenty
| of organisations genuinely must, then do it properly or don't do
| it at all.
| dcminter wrote:
| Hallelujah!
|
| But I have to say, big regulated orgs are often _not_ competent
| to do things this (the right) way but don 't have the option of
| not doing it at all.
| nikanj wrote:
| Companies know that it's important to have Cybersecurity(tm). A
| vendor shows up with shiny brochures, and company is happy to
| purchase Cybersecurity(tm).
|
| Now they don't have to worry about it anymore, they bought a
| product that sits in the corner and delivers Cybersecurity(tm)
| Nextgrid wrote:
| You've perfectly summarized the entire industry.
|
| There's no actual market pressure to be secure, so nobody cares
| about threat modeling, cost/benefit of security solutions, etc.
| The only pressure in case of breach is political blame that you
| need to deflect. The point of a cybersecurity solution is to be
| there, remind you it is there, and allow you to deflect blame
| in case of disaster. Whether it actually increases security is
| merely a bonus side-effect.
| KaiserPro wrote:
| Our cyber team have installed zscaler on most people's laptop,
| and somewhere in the fabric of the office internet connection.[1]
|
| For those that don't know, its a MITM proxy with certificates so
| that it can inspect and unroll TLS traffic.
|
| ostensibly its there to stop data exfiltration, as we've had a
| number of incidents where people have stolen data and sent it to
| competitors. (our c-suite don't have as much cyber shit
| installed, despite them being the ones that are both targets
| more, and broken the rules more....)
|
| Now, I don't like zscaler, and I can sorta see the point of it.
| But.
|
| Our cyber team is not a centre of technical excellence. They
| somehow managed to configure zscaler to send out the certs for a
| random property company, when people were trying to sign into our
| VPN.
|
| this broke loads of shit _and_ made my team (infra) look bad. The
| worrying part is they still haven 't accepted that serving a
| random property company's website cert instead of our own/AWS's
| cert is monster fuckup, and that we need to understand _why_ that
| happened before trying anything again.
|
| [1] this makes automatic pen testing interesting because
| everything we scan has vulnerabilities for NFS/CIFS, FTP and TCP
| dns.
| a012 wrote:
| Security team in most of the corporates is just a bunch of
| checklists markers, so for zscaler, crowdstrike or whatever
| they're doing for compliance and/or certification and you can't
| say no to it because it's the company policy and who know
| better than "security" team?
| devdp430 wrote:
| This is 100% true.
| NicolaiS wrote:
| Got acquired by a Fortune 500 and recieved new laptop. First hour
| I'm seeing TLS errors everywhere except the browser. They'd half-
| baked their internal CA rollout, so wasn't trusted properly.
|
| By day two I started validating their setup. The CA literally had
| a typo in the company name, not a great sign.
|
| A quick check with badssl.com showed that any self-signed(!) cert
| was being transparently MITM'ed and re-signed by their trusted
| corporate cert. Took them 40 days to fix it.
|
| Another fun side-effect of this is that devs will just turned off
| TLS verification, so their codebase is full of `curl -k`,
| `verify_mode = VERIFY_NONE`, `ServerCertificateValidationCallback
| = () => true`, ... Exactly the thing you want to see at a big
| fintech company /s
| arianvanp wrote:
| Complains about TLS inspection, yet fronts their website on the
| biggest and most widely deployed TLS introspection middle box in
| the world ...
|
| Why do we all disdain local TLS inspection software yet half the
| Internet terminates their TLS connection at Cloudflare who are
| most likely giving direct access to US Intelligence?
|
| It's so much worse as it's infringing on the privacy and security
| of billions of innocent people whilst inspection software only
| hurts some annoying enterprise folks.
|
| I wish we all hopped off the Cloudflare bandwagon.
| phito wrote:
| I wish so too, same for all the self-hosters using tailscale...
| kreetx wrote:
| These are not the same thing, the parent is confused..
| dns_snek wrote:
| Tailscale connections don't get terminated by a middle box,
| it's just end-to-end encrypted Wireguard under the hood.
| Cloud-hosted control panel is a risk because they could push
| malicious configuration changes to your clients (ACLs and new
| nodes if you're not using the lock feature), but they can't
| do it without leaving a trace like Cloudflare can.
| progbits wrote:
| Tailscale cannot passively observe traffic.
|
| They could inject malicious keys into your config but would
| be hard to mask the evidence of that.
| treesknees wrote:
| Would it be hard? I thought the point of tailscale was not
| having to manage or concern yourself with key distribution.
| newdee wrote:
| Lookup the Tailnet Lock feature.
| apexalpha wrote:
| I'm not sure if you're serious but in case you are (or other
| people):
|
| TLS inspection is for EVERYTHING in your network, not just your
| publicly reachable URLs.
|
| Putting Cloudflare anti-DDoS in front of your website is not
| the same as breaking all encryption on your internal networks.
|
| Google can already see the content of this site since it's
| hosted... on the internet.
| dns_snek wrote:
| > Putting Cloudflare anti-DDoS in front of your website is
| not the same as breaking all encryption on your internal
| networks.
|
| You misunderstood, they're complaining about it as a user. If
| your website uses Cloudflare then our conversation gets
| terminated by Cloudflare, so they get to see our unencrypted
| traffic and share it with whomever they want, compromising my
| privacy.
|
| Which wouldn't be such a problem if it was just an odd
| website here or there, but Cloudflare is now essentially a
| TLS middle box for the entire internet with most of the
| problems that the article complains about, while behind
| hosted behind Cloudflare.
| arianvanp wrote:
| Given that 50-70% of the critical services I use in my daily
| life (healthcare, government, banking, insurance) all go
| through Cloudflare this practically means everything that is
| important to me as an individual is being actively
| intercepted by a US entity that falls under NSA's control.
|
| So for all intents and purposes it's equivalent.
|
| My point is: it's very hypocritical that we as industry
| professionals are complaining about poor cooperates being
| MITM'd whilst we're perfectly fine enabling the enfringement
| of fundamental human right to privacy of billions of people
| by all fronting the shit that we build by Cloudflare in the
| name of "security".
|
| I find the lack of ethical compass in this regard very
| disturbing personally
| kreetx wrote:
| Having an organization install custom root certificates
| onto your work or personal computer and hosting a public
| blog on Cloudflare are two entirely different topics.
|
| That your healthcare, government, bank, etc. are using
| Cloudflare, is a third. In an ideal world I guess I'd agree
| with you, but asking any of these institutions to deploy
| proper DDoS protection may just be too much of an ask.
| ForHackernews wrote:
| ...do you send private messages using services hosted on
| publicly reachable URLs?
| cornonthecobra wrote:
| Three of the banks I use have their websites/apps go through
| CloudFlare. So does the electronic records and messaging system
| used by my doctor. A lawyer friend uses a secure documents
| transfer service that is protect by guess who.
|
| Who needs to let CF directly onto their network when they
| already sit between client and provider for critically-private,
| privileged communications and records access?
| progbits wrote:
| NSAaaS and people even pay for it.
| port11 wrote:
| Do you have an alternative, potentially one that's less
| centralised or private or in bed with three-letter agencies? I
| ask because my last infra was probed for vulnerabilities
| hundreds of times per day; putting Cloudflare in front with
| some blocked countries and their captchas brought the attempted
| attacks down to _a few dozen per month_.
| halJordan wrote:
| I mean, is doing your own geo blocking actually a blocker for
| you?
| aprilnya wrote:
| I think it's misleading to imply hypocrisy considering the
| reasons listed in the article don't apply to the scenario of a
| site being behind Cloudflare.
| OptionOfT wrote:
| The certificate presented is not a Cloudflare one.
|
| So it might be that they're using a custom one, which I believe
| is passed through end-to-end.
| apexalpha wrote:
| I largely agree with the author. When our SOC wanted to implement
| TLS inspection I blocked it. Mostly because we not nearly at the
| security level for this, but also because it just _fucks_ with so
| many things.
|
| That said, we are not a business dealing with highly sensitive
| data or legal responsibilities surrounding data loss prevention.
|
| If you are a business like that, say a bank or a hospital, you
| want to be able to block patient / customer data leaving your
| systems. You can do this by setting up a regex for a known format
| like patient numbers or bank account numbers.
|
| This requires TLS inspection obviously.
|
| Though this makes it _harder_ to steal this data, not impossible.
|
| It does however allow the C-suite to say they did everything they
| could to prevent it.
| apexalpha wrote:
| Oh and the software (Netskope) was only able to decrypt our
| traffic _in the cloud_.
|
| Lmao not in a million fucking years will I upload our data to
| an American company in fucking plaintext.
| dcminter wrote:
| Netskope and the other DLP tools at my last gig would
| completely lock up my network connection for around 30
| seconds every hour or two while maxing out 100% of a core.
| Fun times. The issue was still there a year after I first
| encountered it so I have grave doubts about the competence of
| those vendors.
|
| On the other hand I am sympathetic to the needs of big
| regulated orgs to show they're doing something to avoid data
| loss. It's a painful situation.
| franga2000 wrote:
| I agree with the sentiment, but this part is complete bullshit:
|
| > what is the likelihood of every certificate authority on the
| Internet having their private keys compromised simultaneously
|
| Who cares? It's not like all CAs would have to be breached, just
| one. CA certs are not scoped, so the moment one CA gets breached,
| we're all fucked. CT helps, but AFAIK it's still not enforced
| everywhere yet
| nubinetwork wrote:
| This is why I don't use the computers at work for anything not
| work related. They've been spying on us for at least 10 years.
| nly wrote:
| "If you use my (private) network you follow my rules"
|
| And I find it hard to argue with that.
|
| I've been using a VPN habitually on my phone and my (personal)
| laptop for a decade now. Work, home, travel. Doesn't matter. It's
| always on.
| redrix wrote:
| How do you find your typical daily battery life with it always
| on?
|
| I've tried this in the past and had to revert as I found it
| made a noticeable difference in my day-to-day.
|
| Curious to hear the experience of others.
| hexbin010 wrote:
| Was it OpenVPN that you tried in the past? Wireguard seems
| much better
| letmetweakit wrote:
| I have the impression tailscale drains my battery on macOS
| and iOS, only turn it on when truly needed.
| newdee wrote:
| Yeah, it most certainly does. Very noticeable on iOS. I
| don't know if this is an Apple specific thing, or if it's a
| similar story on Android.
|
| It's WireGuard underneath, which is designed to not be very
| chatty when idle, so I'd put this down to regular back and
| forth with Tailscale's control plane, relays, etc.
|
| It's a shame really, because a huge value prop of TS is
| that it's a VPN you just leave on and forget about. I hate
| having to toggle it when I inevitably forget to and wonder
| why I'm getting connection errors to private resources.
| ectospheno wrote:
| I have an ipv6 wireguard vpn from my iOS phone to my home
| network. It routes all traffic through my home isp. I use the
| wireguard iOS client. Battery life has been fine for me. One
| caveat is that background updates are disabled for almost
| every app.
| Wowfunhappy wrote:
| I work for a school. My traffic is not MITM'd, but the _kids '_
| traffic is, because we don't want them using their school-issued
| laptops to play games or go shopping, and you can't adequately
| block stuff if it's all encrypted.
| TheChaplain wrote:
| I can't imagine the headache as a school when parents come
| yelling "why did you allow my child on site XXX?!"
| lousken wrote:
| Whitelists instead of blacklists?
| Wowfunhappy wrote:
| I'm pretty sure we'd still need to break TLS. Domain-level
| just isn't granular enough.
| kotaKat wrote:
| zScaler is a load of shit, especially with some of its absolutely
| dumb policies like "malicious TLDs".
|
| Because the Framework laptop site at frame.work is malicious, of
| course.
|
| God, I love CURLing crap from my workstation and not getting the
| files I needed but instead a bunch of mangled HTML telling me
| zScaler was going to scan what I was going to download.
|
| Bonus points that it puts me in the wrong country because I'm
| closer to Montreal than any American locations so half the time
| I'm stuck in French Canadian on the web from my New York office.
|
| Triple bonus points that I'm required to test speed at client
| sites and zScaler completely mangles our presentable results.
|
| Quadruple bonus points that I put in "because I feel like it"
| into every elevation request I make on my corporate machine and
| our "cyber team" has literally never looked at elevation reports
| to ask what the hell I'm doing...
| cornonthecobra wrote:
| > Consider this - what is the likelihood of every certificate
| authority on the Internet having their private keys compromised
| simultaneously?
|
| Considering that CloudFlare has managed to MitM a huge part of
| the internet, I'd say that probability is not just non-zero, but
| greater than by a worrying margin.
| kreetx wrote:
| The title should say "Stop inspecting TLS", the current title
| reads like the TLS standard or technology is modified in a way to
| not work properly.
| Wowfunhappy wrote:
| For what it's worth, I knew _exactly_ what this was going to be
| about before I clicked.
| voidUpdate wrote:
| I'm hoping this doesn't apply to things like Fiddler, because
| without the ability to see what's actually coming over the wire
| with a https connection, things can be a nightmare to debug
| sometimes
| bandie91 wrote:
| personally i'm happy that i can MITM my docker when it wants to
| pull gigs of images the 1000th time upstream and just serve them
| from a local OCI cache server instead.
| mirashii wrote:
| You don't need to MITM docker for this, you can just configure
| your containerd or equivalent backend properly.
| dminuoso wrote:
| One thing that has not quite been mentioned in the blog, is how
| much of the MITM spyware comes from very big and well known
| ,,security" companies.
|
| You know, the ones that really know about security. X-PAN-
| AUTHCHECK type of security.
|
| The amount of CVEs some of the big firewall companies collect
| make it seem like it is a competition for the poorest security
| hygiene.
|
| The real problem we have is compliance theatre where someone in
| management forces these solutions onto their IT department just
| so they can check a box on their sheets and shift all
| responsibilities away.
| YesThatTom2 wrote:
| More and more big customers (especially banks) are requiring this
| kind of self-inflicted-MITM attack from all their suppliers. Do
| you want to have customers? Get ready for zscaler!
|
| How do you propose compliance with their exfiltration protection
| requirements? (And "turn down $ from those customers" is not an
| answer)
| lousken wrote:
| As a sysadmin I also hate this. Instead, I do block stuff based
| on DNS requests and I also block any other DNS provider as well
| as malicious IPs.
|
| At this point in time, Microsoft is the bigger enemy here - some
| of their policies are just insane and none of this MITM will help
| [0][1]
|
| [0] https://www.microsoft.com/en-
| us/microsoft-365/roadmap?id=490...
|
| [1]
| https://techcommunity.microsoft.com/blog/microsoft365copilot...
| sqbic wrote:
| What changed my mind to be in favor of TLS inspection at work
| environments was seeing what kind of highly confidential stuff
| employees might be copy-pasting to random websites, LLM
| assistants, cloud-based "desktop applications" and such against
| the approved use policies of each of these tools without giving
| it a second thought.
|
| TLS inspection products can intercept the paste transaction
| before the data leaves the company network, hitting the user with
| a "No you didn't! Shame on you!"-banner and notify the admins how
| a user just tried to paste hundreds of customers' personal
| information and credit card details into some snooping website,
| or into otherwise allowed LLM chat which still is not allowed to
| be used with confidential information.
|
| There can even be automations to lock the user/device out
| immediately if something like this is going on, be it the user or
| some undetected malware in the user's device attempting the
| intercepted action. Being able to do these kinds of very
| specifically targeted interceptions can prevent potentially huge
| disasters from happening while still allowing users more freedom
| in taking advantage of the huge variety of productivity tools
| available these days. No need to choose between completely
| blocking all previously unseen tools or living in fear of
| disastrous leaks when there are fine-grained possibilities to
| control what kind of information can be fed to the tools and from
| where.
|
| There are plenty of organizations out there where it is
| completely justified to enforce such limitations and monitoring
| in company devices. Policies can forbid personal use entirely
| where it is deemed necessary and legal to do so. Of course the
| policies and the associated enforced monitoring needs to be
| clearly communicated and there needs to be carefully curated
| configurations to control where and how TLS is or isn't
| intercepted so employee privacy laws and regulations aren't
| breached either.
| iso1631 wrote:
| So deploy end point security, which sits in the kernel and can
| thus access the unencrypted communication
| treesknees wrote:
| Aren't most TLS implementations still using things like
| OpenSSL in userspace? How would the kernel get access to the
| request?
| iso1631 wrote:
| A process with kernel level permissions can patch into
| userspace process an intercept calls. For example
| https://github.com/SebastienWae/sslsnoop
| zbentley wrote:
| That's vastly more failure prone (crowdstrike crashes
| workstations) and abuse prone (kernel code has the highest
| privilege level) than processing network traffic at the
| network/TLS level.
| mirashii wrote:
| In practice you don't actually need kernel code on a bunch
| of platforms for this, e.g. NETransparentProxyManager on
| MacOS. This is not necessarily an endorsement, just worth
| not mixing in unrelated issues.
| iso1631 wrote:
| It's also normally deployed by companies who want this
| level of access anyway
|
| If you don't then you're simply open to encrypted comms
| over your deep inspection TLS breaking box anyway
| sqbic wrote:
| While eps, edr, etc. solutions have their role in security
| and some of the products can be used for "TLS inspection"
| within the localhost already, doing the inspection in
| separate network appliance brings benefits such as (but not
| limited to) not needing to care if the client operating
| system is supported by the eps product or if the eps is
| functioning correctly, offloading the "heavy lifting" and
| policy enforcement to the appliances and ensuring that only
| actual real egress connections to specific services are
| inspected.
| letmetweakit wrote:
| > TLS inspection products can intercept the paste transaction
| before the data leaves the company network, hitting the user
| with a "No you didn't! Shame on you!"-banner and notify the
| admins how a user just tried to paste hundreds of customers'
| personal information and credit card details into some snooping
| website, or into otherwise allowed LLM chat which still is not
| allowed to be used with confidential information."
|
| Are there tools that do this reliably today without a whole
| bunch of false positives?
| iamcalledrob wrote:
| This kind of TLS "man in the middle" tech is so frustrating to
| deal with, because it ends up _breaking_ things.
|
| For example, I've encountered zscaler setups in the wild which
| close TLS connections if non-HTTP traffic is encountered.
| Presumably the traffic inspection fails since there is no HTTP
| request, and this failure path closes the socket.
|
| It's hard to say whether it's due to the customer's IT dept's
| config, or zscaler itself -- but as far as the customer is
| concerned, it's my problem.
| wolfi1 wrote:
| a company, I worked for, had their own endpoint which you can
| easily introduce in windows, unfortunately every other tls
| connection which does not use the windows certificate store
| breaks because of that, so maven, npm et al won't work
| zmmmmm wrote:
| I'd like to know if there is any real world data about the
| effectiveness of TLS inspection in preventing harm. It's
| empirically a massive tax on any organisation that engages in any
| kind of software engineering or technical work. I estimate that
| something like 3% of all our engineering effort goes to working
| around the TLS inspection which breaks security on literally
| every piece of infrastructure we build. And it embeds all the
| harm that the article alludes to (and more). So it takes quite a
| significant balance of upside to counteract that.
|
| So is the benefit worth it? Is there data to prove it? Or is it
| just authoritarian IT departments drunk on power implementing
| this stuff?
|
| I'd love to know.
___________________________________________________________________
(page generated 2025-12-10 23:01 UTC)