Live data from Hacker News

HTTPS Interception Weakens TLS Security

us-cert.gov

41–50 of 105 posts

Re: HTTPS Interception Weakens TLS Security

#41
post #12

A while back I remember seeing on HN there was a issue with a certain vendor and ChromeBooks because Chrome used a newer TLS(And the mitm vendor vendor was noticed in advance too, and didn't update their product). I wonder how schools and banks plan to react to this... Apparently financial firms have to record everything their employees do for some regulations. To me, schools doing this sort of thing is wrong. I woul…

https://news.ycombinator.com/item?id=13751505

Re: HTTPS Interception Weakens TLS Security

#42
post #27

We need MITM detection in the browser. Yes, it's possible. The crypto bits the host is sending are different from the crypto bits the client is receiving. There are several ways to compare those, despite what the MITM box is doing. Out of band channels, timing, and order of data can be used. I sometimes refer to HTTPS Everywhere as "Security Theater Everywhere". Before the mania for HTTPS, many sites only used HTTPS…

You can prevent MITM from the browser - you 'simply' use Whitebox Crypto to create a secured channel - (shameless plug Irdeto who I work for sell this as solution https://irdeto.com/payments-and-banking/cloakedjs-code-prote...)

In that case even if you MITM it - all the bad guy gets is encrypted (AES) data. Whitebox does sound a bit like black magic, but it's widely deployed (over 5 billion devices for Irdeto's) and add a nice layer to ensure that you're actually talking to the end users browser, and it's your code that's running on it.

Re: HTTPS Interception Weakens TLS Security

#43
post #24

So how do I test if my workplace is doing a good job of this? The article mentions badssl.com. Do I just click all the red links in the certificate section and verify that my browser is refusing to display the pages?

Just wanted to say thanks for attempting to point the conversation in a useful direction; I hope someone who can help is willing to share the answer.

Re: HTTPS Interception Weakens TLS Security

#44
post #41
post #12

A while back I remember seeing on HN there was a issue with a certain vendor and ChromeBooks because Chrome used a newer TLS(And the mitm vendor vendor was noticed in advance too, and didn't update their product). I wonder how schools and banks plan to react to this... Apparently financial firms have to record everything their employees do for some regulations. To me, schools doing this sort of thing is wrong. I woul…

https://news.ycombinator.com/item?id=13751505

Yeah, https://news.ycombinator.com/item?id=13750379 is the original thread. I don't know that school personally, just talking in general I don't think I'd trust school admins with that level of access.

Re: HTTPS Interception Weakens TLS Security

#45
post #13
post #7

Earlier quoted context omitted.

As far as I can tell this is targetted at what I would expect: "antivirus" and compliance tools built into firewalls, not reverse proxies built into load balancers.

There is limited distinction there. Both terminate and re-establish TLS sessions.

I strongly disagree: who is in control, how it is implemented, and the purpose of the product are all both extremely important and fundamentally different between the two use cases. An "antivirus" filter ends up implemented as a man-in-the-middle attack between software I wrote and servers I contract and control, wherein protections that were actively put in place are stripped away in order to increase the attack surface. A reverse proxy is something that I actively implemented as part of my infrastructure, and I am contracting for it and paying for it like anything else I rent.

It became "extra cool" to hate on reverse proxies recently while everyone hates CloudFlare (and to be clear: I've hated CloudFlare since before it was cool to hate on CloudFlare, and you should check my comment and submission history to verify if you don't believe ;P), but what people are essentially complaining about are "it encourages you to do something insecure", which I think is actually largely true only of CloudFlare, and you have to remember that the vast majority of developers who are using CloudFlare are doing so because they don't know much about network administration.

But like, think about it this way: Apache is also an SSL termination point. The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML": it is just a dumb encoder/decoder, and pretty exactly analogous to an SSL termination point. If you really believe in true end-to-end encryption, then having this webserver in the middle is a bad idea: you should route requests directly to database servers and ensure that at no point does any non-database computer have a decrypted copy of the information that will eventually be rendered to the user.

Another thing to think about: if you are heavily concerned that the CDN or reverse proxy service you are using has access to your traffic, realize that they are no different than using a hosted server. We don't even need to invoke "the cloud" for this one: unless I built the machine myself, I have no way of knowing that the server I am renting to run my database server on isn't running under a hypervisor that is allowing dumps of my decrypted memory. A reverse proxy is just another piece of rented infrastructure that someone else is in control of, and I don't see many people (though if you are, that's great, and then I'd be really happy ;P) insisting that everyone build their own computers and host them at their office, to make sure decrypted data never touches a computer owned and operated by someone else.

The risk profile is also just so fundamentally different, in no small part due to these differences of "who is in control and how is it implemented". Let's say that CDNetworks is failing to check SSL certificates correctly: how exactly are you going to attack that against my website? I mean, sure: if you are a state-level actor, that is going to be easy, but otherwise, that's going to be extremely rough. An "antivirus" filter that, as described in this alert, is failing to correctly check SSL certificates... well, that opens you up to attack by amateur attackers that are "close to you", such as a stalker or an ex-spouse or a corporate competitor. You can't just claim "well, if I abstract away all of the details, they look the same"... you have to look at why you care and verify that you didn't strip away anything required and relevant.

Re: HTTPS Interception Weakens TLS Security

#46
post #13
post #7

Earlier quoted context omitted.

As far as I can tell this is targetted at what I would expect: "antivirus" and compliance tools built into firewalls, not reverse proxies built into load balancers.

There is limited distinction there. Both terminate and re-establish TLS sessions.

[deleted]

Re: HTTPS Interception Weakens TLS Security

#47
post #11

Earlier quoted context omitted.

Instead couldn't you just whitelist the online banking sites and intercept everything else?

That would defeat the whole point of a proxy, if I can't see what they're doing and report on people who are doing the wrong thing (according to their employment contract), then why bother?

So what are you going to report on if someone visits a banking website?

Re: HTTPS Interception Weakens TLS Security

#49
post #11

Earlier quoted context omitted.

Instead couldn't you just whitelist the online banking sites and intercept everything else?

That would defeat the whole point of a proxy, if I can't see what they're doing and report on people who are doing the wrong thing (according to their employment contract), then why bother?

"The whole point of a proxy" isn't to spy on people, even if that's the only reason you use it.

For instance, you could block lots of crap with the proxy, thus increasing your organizations security. Does your need to spy on employees watching porn outweigh the potential benefit of not having to deal with porn viruses?

You could also use the proxy to cache pages, so that your thousands of users don't waste bandwidth downloading the same pages over and over again. You can do this without harming your ability to spy on people.

Re: HTTPS Interception Weakens TLS Security

#50
post #13
post #7

Earlier quoted context omitted.

As far as I can tell this is targetted at what I would expect: "antivirus" and compliance tools built into firewalls, not reverse proxies built into load balancers.

There is limited distinction there. Both terminate and re-establish TLS sessions.

When running on the same machine, reverse TLS-terminating proxy isn't different from built-in TLS implementation, except for done in "microservice-like" way.

Most certainly, there's no difference whatsoever (or almost so, if the reverse proxy is "smart" and has some application logic in it) if your webapp doesn't speak HTTP natively, but talks FastCGI/uWSGI/SCGI protocols instead. Which is quite common.

I mean, the actual interface (passing buffer pointers in the local process or passing same data via local UNIX sockets) shouldn't matter much, right? As long as interfaces have similar security properties and all the necessary data is passed around properly. A sufficiently privileged user can introspect both (with ltrace or tcpdump), and insufficiently privileged one can't do anything anyway.

Post reply on HN