HTTPS Interception Weakens TLS Security • Hacker News Board

Re: HTTPS Interception Weakens TLS Security

#51

Post by spacemanmatt » Fri, Mar 17, 2017, 11:08 AM UTC

synicalx wrote: 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.

This makes me feel nostalgic for the custom IT job I did at this oil-patch vendor a while back. They had a failing Win2k server and a SonicWall residential-class router "securing" their business. I replaced it with a linux based firewall and a linux based file/app server.

We basically had to protect the executive network/fileserver from outside and inside threats, keep porn/facebook/twitter off the production floor, and the rest was my design to streamline development/production operations. I've never had so much fun writing iptables rules. It's probably swiss cheese by today's security standards and known vulnerabilities, but it was hot stuff in 2008. :)

I guess I cared an awful lot about users of my infrastructure. Now people consumer my relational schemas but I still care.

Re: HTTPS Interception Weakens TLS Security

#52

Post by kbart » Fri, Mar 17, 2017, 11:21 AM UTC

seasonalgrit wrote: post #48

any recommendations on tutorials/guides for better understanding the world of TLS, certificates, and so on? i don't feel like i have a healthy mastery of the ideas discussed in articles like this one.

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 give you a good starting point.

Re: HTTPS Interception Weakens TLS Security

#53

Post by tgasson » Fri, Mar 17, 2017, 11:28 AM UTC

tofflos wrote: 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?

You want to do that both on your intercepted LAN and with a direct connection and compare the results. If they both give the same results you can be happy your MitM proxy is at least treating insecure sites equivalently. You still lose the advantage that you browser will tell you why the site is insecure

Re: HTTPS Interception Weakens TLS Security

#54

Post by tgasson » Fri, Mar 17, 2017, 11:33 AM UTC

jusob wrote: post #3

It does not have to be. Done correctly, SSL interception can pass through all the errors to the client: * certificate issues (expiration, domain mismatch, etc.) * OCSP/CRL verification * validation of HPKP header I understand that few vendors may be doing it (I know one which does at least the first 2). Probably the worst offense is choosing the weakest TLS version + cipher to save resources, like using TLS 1.0 becau…

Do you have any links to how the errors are passed through to the client? Do you mean that they imitate the incoming certificate exactly or send the information by some other method?

Re: HTTPS Interception Weakens TLS Security

#55

Post by icebraining » Fri, Mar 17, 2017, 11:44 AM UTC

4ad wrote: post #36

ancarda wrote: post #30

Earlier quoted context omitted.

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.

Logins? 99% of the websites I visit don't have user accounts.

Not even for the person managing them?

Re: HTTPS Interception Weakens TLS Security

#56

Post by [deleted] » Fri, Mar 17, 2017, 11:46 AM UTC

Animats wrote: 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

#57

Post by icebraining » Fri, Mar 17, 2017, 11:50 AM UTC

Animats wrote: 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 still do the exact same thing: have a specific (sub)domain for those crucial transactions, while the main domain gets served by the CDN.

Alternatively, and in my opinion better, is to have a (sub)domain for static assets, served from the CDN, and keep the main one free from man-in-the-middle.

Re: HTTPS Interception Weakens TLS Security

#58

Post by icebraining » Fri, Mar 17, 2017, 11:57 AM UTC

bgidley wrote: post #42

Animats wrote: 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…

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.

Re: HTTPS Interception Weakens TLS Security

#59

Post by nickik » Fri, Mar 17, 2017, 12:00 PM UTC

saurik wrote: post #45

hueving wrote: 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…

> The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML"

My live seems more trivil now.

Re: HTTPS Interception Weakens TLS Security

#60

Post by nickik » Fri, Mar 17, 2017, 12:05 PM UTC

Animats wrote: 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 internet and uses sophisticated tools to analyse it. I prefer to have a internet that makes it hard for the NSA and company.