Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BlueCoat and other proxies hang up during TLS 1.3

bugs.chromium.org

Post reply on HN
Print view View original

211–216 of 216 posts

Re: BlueCoat and other proxies hang up during TLS 1.3

#211

Post by quotemstr »

peterwwillis wrote: post #204
theamk wrote: post #182

Earlier quoted context omitted.

I disagree. We were living in the period of easy middleware (this was before HTTPS rollout), and it generally sucked -- there were supercookies, ads injection, general app breakage when you get a captive portal page instead of expected RPC response. The middleware should require effort to install, and it should be obvious when it is active. Otherwise, companies which have no business MITM'ing the traffic -- such as I…

And that's why the browser is at fault - they could have designed it to be more permissive or more secure, depending on the role. They decided instead on a one-size approach, once too permissive, now too restrictive. As a regular user, I can't just use a captive portal to get free wifi, because any site I go to has HTTPS, so they all break and I can't accept the god damn HTTP accept page unless I can conjure up a val…

Captive portal authentication functionality has no business being part of a browser anyway. Why should I have to start a browser to make my non-browser client application connect to my non-HTTP server?. A captive portal is a special case of rich network-level authentication, which belongs in the operating system. Also, 802.11u is specifically designed to help create uniformity in this area.

Re: BlueCoat and other proxies hang up during TLS 1.3

#212

Post by theamk »

peterwwillis wrote: post #204
theamk wrote: post #182

Earlier quoted context omitted.

I disagree. We were living in the period of easy middleware (this was before HTTPS rollout), and it generally sucked -- there were supercookies, ads injection, general app breakage when you get a captive portal page instead of expected RPC response. The middleware should require effort to install, and it should be obvious when it is active. Otherwise, companies which have no business MITM'ing the traffic -- such as I…

And that's why the browser is at fault - they could have designed it to be more permissive or more secure, depending on the role. They decided instead on a one-size approach, once too permissive, now too restrictive. As a regular user, I can't just use a captive portal to get free wifi, because any site I go to has HTTPS, so they all break and I can't accept the god damn HTTP accept page unless I can conjure up a val…

Yes, captive portals are the enemy. They break an important assumption: requests either succeed and return correct data, or fail and return an error.

Were you writing a forum post? It was lost because it got submitted to captive portal. Were you in dynamic app? It crashed because it got HTML instead of JSON. Does you page reload ads in the i-frames? Your page position and page itself is now lost, and you are in captive portal page. Did you have a native app which did HTTP requests and cached them? Congrats, you have invalid data in your cache now.

And I have seen captive portals which were broken. How about you get redirected to login page every time you go to your favorite website, because the redirect page got cached somehow?

Good riddance. Yes, the browsers should include better captive portal support like android does, possibly triggered by the SSL certificate mismatch errors, but even the current situation when I have to type "aaa.com" by hand all the time is great.

Re: BlueCoat and other proxies hang up during TLS 1.3

#213

Post by cesarb »

mbrumlow wrote: post #195
reacweb wrote: post #117

Earlier quoted context omitted.

Ssh is almost often available to connect through the firewall. Do IT people understand how easily you can work around proxy using ssh ? Just start a vm in the cloud (like a C1 at scaleway for 3.6€ per month), install squid (with default options). On your PC, run portable applications: putty connected to your vm with a forward of proxy port and portable firefox configured to use your forwarded proxy.

The problem is middleboxes like fortigate also do MITM on ssh connections. Assuming you are not bringing home devices into work and don't have your ssh server's fingerprint memorized you might be tempted to just type 'yes' when prompted. In any case you are left with no SSH, or somebody watching your ssh and have control over your ability to tunnel. The best you can do with these boxes is make a sub tunnel over one o…

From what I've read (http://www.gremwell.com/ssh-mitm-public-key-authentication), if you use public key authentication with SSH, the MITM will break the authentication (forcing ssh to ask for a password). It's the same as with TLS client certificate authentication: in the same way the server certificate authenticates the server to your browser, the client certificate authenticates your browser to the server, and the server will reject MITM connections as unauthenticated.

While unfortunately for TLS client certificates are not a solution against MITM due to their awful user experience and privacy concerns, for SSH public key authentication has a good user experience, and is very common.

Re: BlueCoat and other proxies hang up during TLS 1.3

#214

Post by cesarb »

peterwwillis wrote: post #201
dvorak42 wrote: post #183

Earlier quoted context omitted.

The problem with this fix is that then as long as you have the fallback, the user gains none of the security properties of TLS 1.3 (since the attacker can always force a downgrade by sending junk to the client during the handshake) and has the additional cost of a second TLS negotiation. While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to bugg…

Am I not correct that 1.3 got backed out of chrome for the current issue? So 1.3 isn't even there now... Which breaks anything that explicitly requires 1.3. My fix would support all cases and not break anything. Unless I missed something?

Nothing can require 1.3, since 1.3 isn't finished yet. They were doing interoperability testing with a draft version of TLS 1.3, and nobody should require a draft version of TLS 1.3 without having a fallback to TLS 1.2.

Re: BlueCoat and other proxies hang up during TLS 1.3

#215

Post by cesarb »

throw2016 wrote: post #170

There is a massive hypocrisy in browser vendors getting hysterical about self signed certs while letting MITM proxies operate with impunity or worse working with them. Why isn't there an effort to detect MITM proxies and post equally scary warnings? Surely users have a right to know. MITM is worse than self signed certs and if 'exceptions' can be found for MITM like corporate security, management etc then the same ex…

How can a browser distinguish between a self-signed server certificate, and a MITM proxy presenting a self-signed server certificate?

The scary warnings for self-signed certificates are in fact a protection against MITM. It's because of them that MITM proxies are forced to install a CA certificate. The main difference is that installing a CA certificate requires explicit action in the browser (and on some newer systems displays scary warnings), while if a MITM proxy could simply present a fake self-signed certificate, it could easily intercept anyone. Therefore, self-signed certificates are strictly worse.

Re: BlueCoat and other proxies hang up during TLS 1.3

#216

Post by hermitdev »

FireBeyond wrote: post #58
hermitdev wrote: post #24

Earlier quoted context omitted.

+1. I work in regulatory compliance at a financial firm. My current firm doesn't do this because we don't originate trades, but when I worked at a hedge fund, all forms of electronic communications were MITM'd & recorded for regulatory reasons (and to monitor for IP theft - we did sue a soon former employee after he emailed source for a quantitative model to his personal gmail) primarily to combat or defend against i…

> and to monitor for IP theft - we did sue a soon former employee after he emailed source for a quantitative model to his personal gmail That wouldn't be a certain Sergey Aleynikov and GS would it? ( https://en.wikipedia.org/wiki/Sergey_Aleynikov )

No. I've never worked for GS. In the case I'm talking about, the employee was sued 4 hours before he was fired. Federal criminal charges came a few months later.
Post reply on HN