zlacker

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

>>JoshTr+w
BlueCoat are an incredibly evil company that are breaking the internet.

>>mrmond+w1
BlueCoat makes me cry. We have an application running inside the firewall of one of our clients that communicates with a HTTPS REST API hosted by a server in our datacenter. The connection must be encrypted because it handles confidential information, but when it passes through BlueCoat's TLS proxy, the Authorization header gets mangled and it can't authenticate against our backend. Higher-ups decided that it would be better to try to convince the client to let our app bypass their proxy than to implement a custom workaround for BlueCoat users, but the client never let us through, so the only solution we could implement involved manually SCPing the required data between client and server.

>>rossy+Y7
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.

>>reacwe+Ex
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 of the protocols that they do allow through, you just can't rely on the primary encryption provided by the protocol that the middle box is executing MITM on. If somebody actually looks at the traffic they will see that you are not transferring plain text at the middle box, so that might raise some eyebrows.

>>mbruml+Gb1
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.