Live data from Hacker News

HTTPS Interception Weakens TLS Security

us-cert.gov

21–30 of 105 posts

Re: HTTPS Interception Weakens TLS Security

#21

Earlier quoted context omitted.

On the other hand, a MITM proxy can also do upgrade "attacks"(?!), communicating with remote servers over the Internet using a stronger protocol than the clients on the LAN behind it support. In fact it seems to me that having the validation happening in one place may potentially be easier to maintain than across many different clients' software.

My experience with browser companies vs. proxy software companies is that the browser vendors give a much bigger shit about end user security.

You're assuming people on the LAN can upgrade to recent browsers. A lot of them are stuck on Windows XP. I realize that's a "you have bigger problems" type of scenario, but you also have to play the hand you're dealt.

Re: HTTPS Interception Weakens TLS Security

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

I don't think that's the correct interpretation of this document. A better title would be "Most TLS Proxies Considered Harmful", not TLS interception as a whole.

US-CERT is explicitly calling out that many appliances and applications often are weakening security vs. the common TLS clients, by way of not properly validating certificate chains by proxy for the client and otherwise masking SSL/TLS issues from being surfaced to the end user.

I believe this is CERT trying to get software companies to get their act together on solving security-detrimental UX/UI issues vs. a blanket statement not to add TLS interception proxies to a corporate network.

Re: HTTPS Interception Weakens TLS Security

#23
post #9

It might weaken TLS, but it also stops the 3000 head of cattle I managed from being able to watch porn (6 incidents) and torrent movies (47 copyright notices). If their internet banking, which they're not supposed to be doing at work, gets compromised then I really couldn't care less.

You don't need HTTPS interception to block sites. Passive observation of the negotiation is sufficient for most purposes, much simpler, and much less risky.

Re: HTTPS Interception Weakens TLS Security

#25
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?

Because if you block it then they can't do it and you have nothing to report. Everyone wins.

Re: HTTPS Interception Weakens TLS Security

#26

Earlier quoted context omitted.

> financial firms have to record everything their employees do for some regulations Phone calls, emails, instant messages and other forms of client contact, yes. Internet browsing history? No. Rest assured, many firms do this. But it's because they decided to, not because of regulation.

Worked for Big 4. They did not log my phone calls or sniff my TLS traffic.

Why isn't it enough to do the tracking/audit log in the server side? I can't imagine even the JP Morgan Chase CEO lives under surveillance of JP Morgan Chase Bank 24/7. Just require them to use centralized services and keep audit log of that? Sounds simple enough. I don't get the need to monitor all traffic. Surely the sensitive servers have audit log independent of network?

Re: HTTPS Interception Weakens TLS Security

#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 only for crucial transactions such as logins and credit cards. Those were infrequent enough that they didn't have to go through a CDN. Now, with HTTPS Everywhere, there's no distinction between the stuff that has to be hidden from observers, and the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with. So now the secure channel over which credit card numbers and logins are passed is exposed at the CDN.

Re: HTTPS Interception Weakens TLS Security

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

[deleted]

Re: HTTPS Interception Weakens TLS Security

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

Then those organizations using MITM boxes will install a patch or special modified browser on their members' computers instead of installing a certificate. What's the difference? They still control the computer and can bypass whatever security it has.

Re: HTTPS Interception Weakens TLS Security

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

It's not safe to do only logins over HTTPS because if the initial site is served over HTTP, an attacker could rewrite the URL or inject JavaScript to leak your password.

Also, once you're signed in, every request sends a cookie which is also valuable to steal as it's an active session.

Every request needs to be encrypted. We haven't made TLS worse by deploying it everywhere.

Post reply on HN