zlacker

[return to "BlueCoat and other proxies hang up during TLS 1.3"]
1. db48x+D2[view] [source] 2017-02-28 02:06:00
>>codero+(OP)
The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.
◧◩
2. wildmu+n4[view] [source] 2017-02-28 02:34:57
>>db48x+D2
Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective.

If you're using your company's network, then they have every right to monitor all of the activity on it. They're trying to protect trade secrets, future plans, customer data, employee records, etc. from attackers who would use that information to do harm to the company, its customers, and its employees. If you don't want your employer to know what you're doing, then don't use the company computer or company network to do it. And while you may think that you're too tech savvy to fall prey to malware 1) not everyone at your company is, and 2) no amount of savvy will protect you from all malware, especially ones that gain a foothold through an unpatched exploit. And there's also that whole other can of worms: malicious employees.

◧◩◪
3. ckuehl+m7[view] [source] 2017-02-28 03:13:53
>>wildmu+n4
Totally agreed they have the right to monitor your network traffic, but I still think in most cases employees should try to push back on this.

At least from my view, it's not so much that I don't want my company to know what I'm doing, as that I don't trust their software to securely MITM all of my traffic. This thread doesn't fill me with confidence about the competency of these corporate MITM proxies. And the recent Cloudflare news doesn't help either -- they're effectively the world's largest MITM proxy, and even they couldn't avoid leaking a huge amount of "secure" traffic.

There are surely sectors where it's necessary for a company to MITM all traffic, but I think most companies will do better security-wise by not messing with TLS. It's just too hard to get right.

◧◩◪◨
4. theluk+68[view] [source] 2017-02-28 03:24:10
>>ckuehl+m7
At my workplace where we have to do tls inspection for regulatory purposes we provide an internet-only wifi network for employee personal use where we don't intercept TLS. This network is fully isolated from the corporate network and corporate devices join a different, more monitored network. I believe this strikes the best balance between regulatory compliance and employee privacy. People can still use personal email or do online banking while at the office without inspection, but no corporate data can be moved en mass off company servers.
◧◩◪◨⬒
5. FireBe+pe[view] [source] 2017-02-28 04:47:04
>>theluk+68
> but no corporate data can be moved en mass off company servers.

How so?

1. Connect to Corp Wifi

2. git clone companyapp.git

3. Connect to Employee Personal Wifi

4. Email tgz'ed companyapp

?

◧◩◪◨⬒⬓
6. theluk+oh[view] [source] 2017-02-28 05:20:17
>>FireBe+pe
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.
◧◩◪◨⬒⬓⬔
7. deatha+bn[view] [source] 2017-02-28 06:48:51
>>theluk+oh
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?
◧◩◪◨⬒⬓⬔⧯
8. vidarh+Bz[view] [source] 2017-02-28 09:56:20
>>deatha+bn
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.

[go to top]