zlacker

[parent] [thread] 12 comments
1. ckuehl+(OP)[view] [source] 2017-02-28 03:13:53
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.

replies(1): >>theluk+K
2. theluk+K[view] [source] 2017-02-28 03:24:10
>>ckuehl+(OP)
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.
replies(2): >>HappyT+52 >>FireBe+37
◧◩
3. HappyT+52[view] [source] [discussion] 2017-02-28 03:42:25
>>theluk+K
Perfectly sensible and reasonable. Difficult to have any objections.
◧◩
4. FireBe+37[view] [source] [discussion] 2017-02-28 04:47:04
>>theluk+K
> 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

?

replies(1): >>theluk+2a
◧◩◪
5. theluk+2a[view] [source] [discussion] 2017-02-28 05:20:17
>>FireBe+37
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.
replies(3): >>semi-e+kc >>buzer+Gc >>deatha+Pf
◧◩◪◨
6. semi-e+kc[view] [source] [discussion] 2017-02-28 05:56:33
>>theluk+2a
Is both SSH and USB key / USB DVD burner usage completely disabled on your corporate devices? If not, obvious workaround is obvious.
replies(2): >>rocqua+On >>ptaipa+5r
◧◩◪◨
7. buzer+Gc[view] [source] [discussion] 2017-02-28 06:01:36
>>theluk+2a
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?
replies(1): >>ptaipa+3r
◧◩◪◨
8. deatha+Pf[view] [source] [discussion] 2017-02-28 06:48:51
>>theluk+2a
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?
replies(1): >>vidarh+fs
◧◩◪◨⬒
9. rocqua+On[view] [source] [discussion] 2017-02-28 08:46:36
>>semi-e+kc
Even a full mitm solution doesn't MitM the sneakernet.
replies(1): >>Interm+3x
◧◩◪◨⬒
10. ptaipa+3r[view] [source] [discussion] 2017-02-28 09:35:11
>>buzer+Gc
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.
◧◩◪◨⬒
11. ptaipa+5r[view] [source] [discussion] 2017-02-28 09:36:15
>>semi-e+kc
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.
◧◩◪◨⬒
12. vidarh+fs[view] [source] [discussion] 2017-02-28 09:56:20
>>deatha+Pf
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.

◧◩◪◨⬒⬓
13. Interm+3x[view] [source] [discussion] 2017-02-28 11:10:43
>>rocqua+On
Ah yes, but a literal MitM solution could!
[go to top]