zlacker

[return to "BlueCoat and other proxies hang up during TLS 1.3"]
1. JoshTr+w[view] [source] 2017-02-28 01:38:28
>>codero+(OP)
Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0.

In this case, it doesn't sound like they're reverting it because of overall breakage, but rather because it breaks the tool that would otherwise be used to control TLS 1.3 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.

◧◩
2. quotem+d1[view] [source] 2017-02-28 01:50:07
>>JoshTr+w
Ridiculously conservative middleboxes are why we can't have nice things and why we need to encrypt all new protocols, security properties aside.
◧◩◪
3. peterw+JN[view] [source] 2017-02-28 13:13:20
>>quotem+d1
Actually, no, that would just make everything more difficult. Browsers need to start coming to terms with the fact that they do not get do dictate how www networking operates for every organization around the world.

There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations.

Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.

◧◩◪◨
4. theamk+h01[view] [source] 2017-02-28 15:10:03
>>peterw+JN
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 ISPs and free wifi providers -- will start to do it just because it's so simple.

For example, Google may require MDM app on the Android devices which is used to access corporate data. This app ensures that the device has the right policy (screen lock, encryption) and I think it may also check for malware apps. This is how it should be -- if you need corporate control over devices, install special application on it, it will be more efficient and it will do more.

◧◩◪◨⬒
5. peterw+ru1[view] [source] 2017-02-28 18:16:30
>>theamk+h01
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 valid domain that has no HTTPS like I'm Svengali. Now all the OSes have special checks to see if there's a captive portal because the browsers couldn't be troubled to build a function for it, even though it would improve their security and usability at the same time.

Captive portals are not the enemy. Shitty UX and a bad attitude toward the needs of real users is. Locking browsers/protocols down more is just doubling down on this mentality.

◧◩◪◨⬒⬓
6. quotem+N62[view] [source] 2017-02-28 21:59:54
>>peterw+ru1
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.
[go to top]