Live data from Hacker News

HTTPS Interception Weakens TLS Security

us-cert.gov

71–80 of 105 posts

Re: HTTPS Interception Weakens TLS Security

#71
post #42

Earlier quoted context omitted.

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…

Snake-oil. If I MITM, I'll just add my own code that copies the plain-text to my server, I don't need to break any encryption. It's nothing more than an obfuscation layer.

We did think of that :) - we can detect your tampering with the forms we protect. But that said it doesn't stop everything if you can install a keylogger, or get the user to enter data somewhere else we can't stop it and it does depend on where in the user journey you try and protect things, as someone else here has pointed out if any of the journey is HTTP (or HTTPS being MITM) then they can send the user somewhere else.

However I'd also argue you don't actually need to stop people grabbing the data. Noticing achieves a large chunk of that, as (for example) I can notify the credit card system it's happened.

If you want to see exactly what it does and doesn't do see https://resources.irdeto.com/payments-banking/solution-overv...

Re: HTTPS Interception Weakens TLS Security

#72
post #67
post #52

Earlier quoted context omitted.

HTTPS is basically HTTP over TLS, so start with RFCs: - TLS v1.2 ( https://tools.ietf.org/html/rfc5246 ) - Certificate validation ( https://tools.ietf.org/html/rfc6960 ) - PKI is a little more tricky, as there's no single standard that defines it, though to get basic idea of what are certificates read RFC 5280 ( https://tools.ietf.org/html/rfc5280 ). Sure, you can dig as deep as you want, but these resources should g…

Don't forget RFC 2818 (HTTPS) which Chromium (and thus Chrome) recently broke mandatory features of: https://bugs.chromium.org/p/chromium/issues/detail?id=308330...

Is this a remake of that "embrace, extend, ..." movie of the 90s or this time it's cool?

Re: HTTPS Interception Weakens TLS Security

#73

I still find it unfortunately shallow analysis. I'm currently fighting a battle in a company in the middle of rolling out Blue Coat ProxySG. I only became aware of it because it began causing interruptions to our work since none of the development tools get the necessary root cert to validate the certs that the proxy is rewriting. The root cert is only installed into the Windows credentials to make browsers work and…

This is exactly what my company went through just a few months ago when we hired an IT security guy whose first order of business was setting up a Palo Alto Networks firewall. Before turning on the MITM functionality he gave a presentation to everyone about what it did, and nobody (support staff, developers, administrators, management...nobody) seemed to mind except for me.

This was what I sent to the HR lead immediately after the meeting:

I remember a while back we all signed some document regarding data security here. I don't remember what that document said specifically -- did it mention at all the possibility that all of our network traffic could be monitored? I ask because, while [new security guy] claims that with the new firewall "No data is stored or made available for other purposes," the fact is that it absolutely can be viewed and stored, and we as the end users have no way to verify whether it is or not. On Palo Alto Network's own website there are comments from other users of our firewall asking how to disable packet inspection in the logs because, "I can also see users passwords in some cases".

I understand and agree with the necessity of setting up a firewall that can inspect encrypted traffic. However, I also understand that this means everything we do or send on the office internet can be inspected by presumably anyone with access to the firewall's back end (including personal passwords and anything usually thought of as "secure"). I'm not sure how clear this is to some (or most) of the employees here. If the agreements that we signed don't reflect this, I think they should be updated and re-agreed to.

[some back and forth ensued, where she reminded me of a line in the agreement that does say we can be monitored at any time]

That may be fine then. All I know is that I heard some concern over being able to go to facebook and whatnot, which seemed to be relieved when we were told it would still work. I just don't know whether or not people realize that while they can still go to facebook, theoretically anything they say or do on it, including all of their login information, chats, and posts marked to be shown only to friends can (though not necessarily will) be viewed by the company as well.

I could be making a bigger deal out of this than it needs to be, I just tend to take online privacy matters pretty seriously. Assurances that the data will be treated responsibly (not viewed or cached) are all well and good, but at least for me, aren't good enough. I won't be going to any personal websites on the network here at all.

Re: HTTPS Interception Weakens TLS Security

#74
post #60
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…

There is a larger number of threads we are opposing. I want everything over HTTPS because that how I know its actually the site that I wanted. How many more cases do we need where some stupid ISP or middleware puts ads into other peoples webpage. Not to mention that those ads might also be a security problem. Privacy is another issue that HTTPS Everywhere at least helps considerably. The NSA literally tcpdumps the in…

> I want everything over HTTPS because that how I know its actually the site that I wanted.

That's why the poster said "the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with".

Re: HTTPS Interception Weakens TLS Security

#75
post #71

Earlier quoted context omitted.

Snake-oil. If I MITM, I'll just add my own code that copies the plain-text to my server, I don't need to break any encryption. It's nothing more than an obfuscation layer.

We did think of that :) - we can detect your tampering with the forms we protect. But that said it doesn't stop everything if you can install a keylogger, or get the user to enter data somewhere else we can't stop it and it does depend on where in the user journey you try and protect things, as someone else here has pointed out if any of the journey is HTTP (or HTTPS being MITM) then they can send the user somewhere…

I am confused, initially you said "you can prevent MITM" now you say "doesnt stop everything...(HTTPS being MITM)". So your claim is that your product can or can not prevent MITM?

Re: HTTPS Interception Weakens TLS Security

#76
post #2

The US government has basically declared "HTTPS/TLS Interception Considered Harmful". This is going to be interesting as all the major security load blanacer/appliances out there offer this as a standard service at this point.

No, they haven't. They say pretty plainly that you need to ensure that such products provide correct certificate validation, since the client cannot do so reliably.

>> The US government has basically declared "HTTPS/TLS Interception Considered Harmful".

> No, they haven't.

The original report headline from US-CERT: "HTTPS Interception Weakens TLS Security"

That seems pretty unambiguous, regardless of your personal feelings regarding CERT or whether it speaks for the broader US government.

Re: HTTPS Interception Weakens TLS Security

#77
post #71

Earlier quoted context omitted.

Snake-oil. If I MITM, I'll just add my own code that copies the plain-text to my server, I don't need to break any encryption. It's nothing more than an obfuscation layer.

We did think of that :) - we can detect your tampering with the forms we protect. But that said it doesn't stop everything if you can install a keylogger, or get the user to enter data somewhere else we can't stop it and it does depend on where in the user journey you try and protect things, as someone else here has pointed out if any of the journey is HTTP (or HTTPS being MITM) then they can send the user somewhere…

Frankly, regarding MITM, that paper is just nonsense. How can it "ensure contents of a message are secure on the 'wire', by encrypting with a secondary scheme between the JavaScript client and the server", when you can't even guarantee that the signing and encryption code isn't tampered with in-flight?

And you can't guarantee that you can notify either, and for the same reason. The code that leaves your server won't be the code that actually runs on the client - it'll be a mutated version that will say "everything is OK" and acts normally to your server while it sends all the data somewhere else.

Nothing has changed since [1] was written; I don't see how that is anything but DRM promising more than it can deliver.

[1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Re: HTTPS Interception Weakens TLS Security

#78
post #45
post #13

Earlier quoted context omitted.

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 sur…

> 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.

I can't say I haven't considered abusing PL/pgSQL to that point... ;)

Re: HTTPS Interception Weakens TLS Security

#79
post #2

The US government has basically declared "HTTPS/TLS Interception Considered Harmful". This is going to be interesting as all the major security load blanacer/appliances out there offer this as a standard service at this point.

US-CERT has very little influence, even in regulated industries. As usual, CERT is saying something formally that has been axiomatic among practitioners for many years. The only conclusion I'd draw from this is about CERT.

Obviously: what they're saying is broadly true. I also agree with the other commenters here who are pointing out that this is largely a response to endpoint TLS interception, and that the point is to focus attention on tools that intercept but don't validate certificates --- CERT is not telling every Fortune 500 company and every federal agency to stop deploying BlueCoat boxes.

But the more important thing to push back on in your comment is the notion that a proclamation from CERT has any real meaning. It doesn't, even within FedGov IT.

Re: HTTPS Interception Weakens TLS Security

#80
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…

We have MITM detection in the browser. It's called certificate validation.

Browser certificate validation hasn't been as simple as "check CA signature" for close to a decade, and even a decade ago you could configure your browser to trust only certain CAs, or, through the certificate exception manager, only certain specific certificates.

All of this functionality breaks MITM proxies.

Post reply on HN