It sounds like if you run a web server, you should think about only supporting TLS 1.3 with no downgrade support, to ensure security without the possibility of your visitors' being subject to interception by a third party (even if it is their own enterprise).
BlueCoat and other proxies hang up during TLS 1.3
121–130 of 216 posts
Re: BlueCoat and other proxies hang up during TLS 1.3
#122Earlier quoted context omitted.
When connecting a corporate device to any non-corporate network (including the employee wifi) you can't go anywhere until the vpn is connected. The vpn routes you through all the same inspection points as being on premise.
So you cannot access the portal page that quite a few more or less public wifi networks require you to access in order to gain internet access?
The VPN clients offer a "hotspot login" or such functionality so that you can open the access. It doesn't work for other use, just opening that VPN so that your company computer can connect to company network.
Re: BlueCoat and other proxies hang up during TLS 1.3
#123Earlier quoted context omitted.
When connecting a corporate device to any non-corporate network (including the employee wifi) you can't go anywhere until the vpn is connected. The vpn routes you through all the same inspection points as being on premise.
Is both SSH and USB key / USB DVD burner usage completely disabled on your corporate devices? If not, obvious workaround is obvious.
That obvious workaround doesn't give you a 24/7 hole from the Internet. To copy information, you need a person to knowingly do it. This decreases the attack surface tremendously.
Re: BlueCoat and other proxies hang up during TLS 1.3
#124Earlier quoted context omitted.
It might backfire and your company forbids HTTPS "so that employees can't disclose company secrets without IT having traceability".
Uhh, what do you do for sites that don't offer HTTP? Many sites force a 301 redirect when hit on HTTP, and won't downgrade.
Open a ticket with IT?
Re: BlueCoat and other proxies hang up during TLS 1.3
#125Earlier quoted context omitted.
> still doesn't protect you against (...) malware written by people who have SSL MITM proxies in mind Exactly this is what I don't get. Since these abominations are becoming ubiquitous, surely malware writers are starting to work on workarounds? And in this case, it's as easy as setting up an SSH tunnel and running your malware traffic through that, which is a few days of work at best for a massive ROI?
Depending on the threat model and how serious you are about locking things down, you might just block all such traffic.
In which case your malware can do DNS lookups against a suitable domain: Just chop your file into suitable sized strings, encode them as suitable hostnames and look up [chunk of file].evilmalwaredomain.com, and soon enough the server handling evilmalwaredomain.com will have the whole file.
Or plain HTTP POSTs with encrypted content. If it reject stuff that looks encrypted, plain HTTP POSTs encoding the binary files by taking a suitably sized file of words and encode it as nonsensical rants to a suitable user-created sub-reddit.
Or e-mails made using the same mechanism.
If you want low latency two way communication doing this can be a bit hard, but you basically have no way of stopping even a generic way of passing data this way unless you only whitelist a tiny set of trusted sites and reject all other network traffic (such as DNS lookups). And keep in mind you can't just lock down client traffic out of the network - you also would need to lock down your servers and filter things like DNS - the above mentioned DNS approach will work even through intermediary recursive resolvers (malware infected desktop => trusted corporate recursive resolver => internet), unless they filter out requests for domains they don't trust.
But basically, if you allow data out, it's almost trivial to find ways to pass data out unless the channel is extremely locked down.
Re: BlueCoat and other proxies hang up during TLS 1.3
#126Earlier quoted context omitted.
When connecting a corporate device to any non-corporate network (including the employee wifi) you can't go anywhere until the vpn is connected. The vpn routes you through all the same inspection points as being on premise.
And how can your inspection points verify that data isn't being exfiltrated? Arbitrary pipes can be made over SSH, over DNS , and I don't really consider these advanced. How do you handle techniques like chaffing and winnowing, steganography, or someone who knows how to transmit an arbitrary number of bits using only two bits?
DNS is my favourite hack in that respect because so few people are aware of it.
For those who don't know, there are even full IP proxies that uses DNS [1], but you can hack up a primitive one using shell script by basically setting up a nameserver for a domain, turning on all query logging and using a shell script that splits your file up, encodes it into valid DNS labels and requests [some encoded segment].[yourdomain]. Now your file will be sitting in pieces in your DNS query log and all you need is a simple script to re-assemble it.
Best of all is that it works even if it passes through intermediary DNS servers, such as a corporate proxy, unless it's heavily filtered (e.g. whitelisting domains) or too rate limited to be useful.
Re: BlueCoat and other proxies hang up during TLS 1.3
#127It sounds like if you run a web server, you should think about only supporting TLS 1.3 with no downgrade support, to ensure security without the possibility of your visitors' being subject to interception by a third party (even if it is their own enterprise).
That is entirely doable - if you don't care about enterprise/gov/school users using such proxies.
Re: BlueCoat and other proxies hang up during TLS 1.3
#128Earlier quoted context omitted.
Ridiculously conservative middleboxes are why we can't have nice things and why we need to encrypt all new protocols, security properties aside.
This is precisely the conclusion Google reached and has used as they work on QUIC. Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
It is really sad that one reason why QUIC encrypts protocol states is to prevent excessively eager middleboxes from meddling with the traffic.
Re: BlueCoat and other proxies hang up during TLS 1.3
#129Earlier quoted context omitted.
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 b…
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.
There's not even a need for installing a proxy! SSH has native SOCKS proxy support, so all you need to do is set up an SSH connection and set the browser connection to a dynamic SSH port forward.
This also prevents leaking DNS requests : with a standard proxy your computer might be trying to look up domains using the company DNS system. With a SOCKS proxy, you can forward all DNS traffic as well!
Re: BlueCoat and other proxies hang up during TLS 1.3
#130Earlier quoted context omitted.
There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes. https://jhalderm.com/pub/papers/interception-ndss17.pdf How do you fix this when you're naught but a humble employee? Well, a friend of mine worked at a fairly large tech company where a salesguy for these boxes had convinced the CTO they had to have them. Every tech-person "on the floo…
Yeah. This is a firable offense. The solution to your company MITM your traffic is not to use your work computer for anything personal that matters. It's not like if we had a shortage of devices to connect to the internet.
If you live in a third-world country (or the US) which lacks basic functions of society like employee protection, a sensible minimum wage, universal healthcare, paid parental leave, etc., then yes, I don't recommend doing what my friend did with employing a little "civil disobedience" in such cases.
TBH, for most techies I don't think opposition to MITM boxes comes down to "I don't want them to catch me looking at cat photos" but more along the lines of "this will actually reduce security as much as it improves it, and the companies providing these products are also aiding repressive regimes and human rights violations across the globe". Personally, I would find it unethical for the company I work for to buy these products.