Employer VPNs, what are your legal, technical rights?

giatttt

War Hero
My daughter works for a global outfit and they only supplied a RSA dongle, she uses her laptop.

How they can be happy with no assurance over the state of her OS wrt malware including keyloggers, trojans, etc or even the patch state completely escapes me.
 

Sarastro

LE
Kit Reviewer
Book Reviewer
Oh I am listening alright, it's persuading a particularly stingy Chinese-owned company which fired half the workforce last year to do so that's the problem.

So if I simply chose not to install the regedit would there be a problem?
Yes, the regedit is what sets the security permissions of your machine to allow a VPN tunnel in Windows.

As in previous post, you can use regedit to set permissions for certain user accounts, rather than the machine as a whole. Do it only for one account and the settings for other user accounts remain the same.
 

ThunderBox

On ROPS
On ROPs
Chinese firm wants you to log on to their VPN for everything, unless you are smart as you appear to be questioning it….

Sounds a bit fishy to me, as has been said, if they want you to use your IT (and this is fair as it is tax deductible) but want you to install a VPN without explaining how to do as a ‘work user’ access as @Sarastro has explained, it sounds like you should contact someone other than ARRSE.
 
Oh I am listening alright, it's persuading a particularly stingy Chinese-owned company which fired half the workforce last year to do so that's the problem.

So if I simply chose not to install the regedit would there be a problem?
Likely the VPN won't work. Try this:

"Boss, my laptop died last night, can IT send me a new one which I can use?"
 
Chinese firm wants you to log on to their VPN for everything, unless you are smart as you appear to be questioning it….

Sounds a bit fishy to me, as has been said, if they want you to use your IT (and this is fair as it is tax deductible) but want you to install a VPN without explaining how to do as a ‘work user’ access as @Sarastro has explained, it sounds like you should contact someone other than ARRSE.
As regards the technical details I figured that ARRSE would be a decent place to ask and sure enough I have received more helpful information and suggestions in the past two hours in this thread than I have from an afternoon of googling and asking colleagues, who mostly seemed resigned to accepting it.

For all the bickering and bitching that goes on here, if you have some technical query relating to some abstruse issue at work or elsewhere you can be pretty certain someone here will have some detailed knowledge about the situation.
 

ThunderBox

On ROPS
On ROPs
As regards the technical details I figured that ARRSE would be a decent place to ask and sure enough I have received more helpful information and suggestions in the past two hours in this thread than I have from an afternoon of googling and asking colleagues, who mostly seemed resigned to accepting it.

For all the bickering and bitching that goes on here, if you have some technical query relating to some abstruse issue at work or elsewhere you can be pretty certain someone here will have some detailed knowledge about the situation.
I wasn’t suggesting you shouldn’t raise it here, gave a few excellents and informatives to the responses so I agree with raising things here and picking through the crap.

I was merely suggesting that to me, if the French or Chinese are asking for this, it rings alarm bells. The Russians wouldn’t ask for it because they are too poor to have UK workers who use computers.

Now if Russia asked Paddy McPikey to report on the latest Potato Crops via a pre paid telegram I might raise a twitch.
 
I wasn’t suggesting you shouldn’t raise it here, gave a few excellents and informatives to the responses so I agree with raising things here and picking through the crap.

I was merely suggesting that to me, if the French or Chinese are asking for this, it rings alarm bells. The Russians wouldn’t ask for it because they are too poor to have UK workers who use computers.
Oh I see, I am currently resident overseas.
 

Sarastro

LE
Kit Reviewer
Book Reviewer
If the VPN tunnels ALL your traffic, including DNS, through it, then your employer can see every website that you visit. If those sites are encrypted (HTTPS) they cannot see the actual traffic UNLESS they have also insisted you install/accept certificates from the VPN server which allow the traffic to be decrypted/re-encrypted.
This is slightly wrong I think - HTTPS sites, correctly configured, also shouldn't show the IP of the site. You can see the protocol used for any packet and local source IP, but not the destination address. Certainly when I've set up various levels of network monitoring (from a Wireshark client sniffing a network, to a network I've set up and given full permissions to Wireshark at the router switch) you only see the destination IP addresses of HTTPS packets if you've deliberately structured the network that way, which requires altering the clients, not just the router or server. This may apply if you set up the VPN server as your primary DNS, but that isn't terribly common in VPN setups these days, because it tends to break a lot of software (because they recognise it's a major security flaw and type of MITM).

But otherwise this point is important. Most browsers and websites default to HTTPS these days. Collecting / analysing network traffic to HTTPS sites - you can do this to yourself if you download and learn how to use Wireshark at a basic level - really doesn't show you much of interest, mostly just your local (internal) network data. In your case this would be the VPN network, so you work network (depending on where you put the Wireshark client). Browsers visiting HTTPS sites should be identified as HTTP/HTTPS (or 80,8080,443) but no addresses.

Allowing the VPN server to provide, run or authenticate certificates breaks all this and is a major security and privacy no-no. Once you've done it, it will usually operate in the background (you may see certain sites or functionality not working, but it won't be clear it is a VPN issue). There is no good reason for any employer to demand this.
 
This is slightly wrong I think - HTTPS sites, correctly configured, also shouldn't show the IP of the site
This is wrong. Secure HTTP simply provides encryption between the browser and web server. Your IP address (and that of the other end) is not obfuscated.
 

giatttt

War Hero
This is slightly wrong I think - HTTPS sites, correctly configured, also shouldn't show the IP of the site. You can see the protocol used for any packet and local source IP, but not the destination address. Certainly when I've set up various levels of network monitoring (from a Wireshark client sniffing a network, to a network I've set up and given full permissions to Wireshark at the router switch) you only see the destination IP addresses of HTTPS packets if you've deliberately structured the network that way, which requires altering the clients, not just the router or server. This may apply if you set up the VPN server as your primary DNS, but that isn't terribly common in VPN setups these days, because it tends to break a lot of software (because they recognise it's a major security flaw and type of MITM).

But otherwise this point is important. Most browsers and websites default to HTTPS these days. Collecting / analysing network traffic to HTTPS sites - you can do this to yourself if you download and learn how to use Wireshark at a basic level - really doesn't show you much of interest, mostly just your local (internal) network data. In your case this would be the VPN network, so you work network (depending on where you put the Wireshark client). Browsers visiting HTTPS sites should be identified as HTTP/HTTPS (or 80,8080,443) but no addresses.

Allowing the VPN server to provide, run or authenticate certificates breaks all this and is a major security and privacy no-no. Once you've done it, it will usually operate in the background (you may see certain sites or functionality not working, but it won't be clear it is a VPN issue). There is no good reason for any employer to demand this.

If they add a root certificate to your machine which your browser presents and then uses to provide the encryption, then they can inspect everything. Normally they would add an exemptions list which should ensure that they are not performing content inspection as you use your browser to access your bank, healthcare, or insurance providers. Palo Alto and others provide the appropriate kit. As others have mentioned it is a potential GPDR nightmare which most responsible suppliers will manage very carefully.

BTW They will do the same for the encryption provided by email, so may be scanning all of your email for things of interest along with suspicious traffic patterns.
 

Sarastro

LE
Kit Reviewer
Book Reviewer
This is wrong. Secure HTTP simply provides encryption between the browser and web server. Your IP address (and that of the other end) is not obfuscated.
I think we're confusing the DNS request and HTTPS. Yes, if the DNS request is insecure, then they can see which sites you are accessing (which is a very good reason not to use non-standard DNS: the Google, OpenDNS etc servers are a good option in this case, don't use a local IP (192.168.x.x, 10.0.x.x and so on), or even your ISP provided DNS if you don't trust them, as a DNS, that is inviting the provider to snoop your traffic). But that isn't about HTTPS, it's about how your connection is set up. This is why ISPs are such potential problems, because they almost all provide their own DNS servers (which are set up to do whatever they want).

Assuming the connection is made securely, once the connection is made with HTTPS, the packets - in practice, to most nodes in the network (i.e. excluding deliberate attacks like MITM or faked certificates) - do encrypt both the domain and IP for the duration of the session. You need quite a high level of access to the client / router / server to start attacking the HTTPS protocol or decrypting the packets at that stage.

DNSsec / using a trusted and correctly configured DNS is as important a security measure as encryption, but it tends to get ignored and used quite loosely.
 

Sarastro

LE
Kit Reviewer
Book Reviewer
If they add a root certificate to your machine which your browser presents and then uses to provide the encryption, then they can inspect everything. Normally they would add an exemptions list which should ensure that they are not performing content inspection as you use your browser to access your bank, healthcare, or insurance providers. Palo Alto and others provide the appropriate kit. As others have mentioned it is a potential GPDR nightmare which most responsible suppliers will manage very carefully.

BTW They will do the same for the encryption provided by email, so may be scanning all of your email for things of interest along with suspicious traffic patterns.
Yes, fair enough, but short of those 7 pages of instructions including: download this cert or approve this automatic download, it's non-trivial to install a root cert on a user's machine without the user approving it.

@Mike Barton - I think the core point here is: don't allow certain functions to be performed by people you don't trust. A VPN provider (just think of it like an ISP) is definitely one of those functions. It sounds like you don't really trust your employer, so don't let them do this on your computer. Everything else quickly gets into levels of advice that even experts will often get wrong in practice, because nobody has perfect understanding of networking, it has too high a level of complexity and too many variables (from differing hardware and software).
 
Likely the VPN won't work. Try this:

"Boss, my laptop died last night, can IT send me a new one which I can use?"
Personally, I would go with:
"Boss, I followed the Instructions to the letter, now my Personal Laptop is a brick, please get IT to sent a laptop for work. I am offline until they do so."
 
I think we're confusing the DNS request and HTTPS. Yes, if the DNS request is insecure, then they can see which sites you are accessing (which is a very good reason not to use non-standard DNS: the Google, OpenDNS etc servers are a good option in this case, don't use a local IP (192.168.x.x, 10.0.x.x and so on), or even your ISP provided DNS if you don't trust them, as a DNS, that is inviting the provider to snoop your traffic). But that isn't about HTTPS, it's about how your connection is set up. This is why ISPs are such potential problems, because they almost all provide their own DNS servers (which are set up to do whatever they want).

Assuming the connection is made securely, once the connection is made with HTTPS, the packets - in practice, to most nodes in the network (i.e. excluding deliberate attacks like MITM or faked certificates) - do encrypt both the domain and IP for the duration of the session. You need quite a high level of access to the client / router / server to start attacking the HTTPS protocol or decrypting the packets at that stage.

DNSsec / using a trusted and correctly configured DNS is as important a security measure as encryption, but it tends to get ignored and used quite loosely.
Sorry, but no. For an IP packet to be routed to it's destination, it contains the destination IP address (along with the source IP, the source port and the destination port) in the header. HTTPS has nothing to do with this.

If the destination IP was encrypted, then the packet could not make it's way to the destination as no intermediate server could know where it was going.
 

Sarastro

LE
Kit Reviewer
Book Reviewer
Sorry, but no. For an IP packet to be routed to it's destination, it contains the destination IP address (along with the source IP, the source port and the destination port) in the header. HTTPS has nothing to do with this.

If the destination IP was encrypted, then the packet could not make it's way to the destination as no intermediate server could know where it was going.
Two extremely highly rated Stacks disagree with you.. I'll just note that my experience doing specifically this on a network I entirely set up to spy on clients browser requests (legit and required as part of an exercise designed to monitor their website usage) supports the Stack version. I had to implement a certificate hack, as you described previously, on each client, essentially setting up the sniffer on the main switch as a MITM.

Without that effort, the WS of HTTPS packets are all stars for both destination/source IPs and URL. The only IPs visible were from gateway to gateway - effectively you only saw the handoff, not the whole relay.

EDIT: I also think we are talking slightly cross purposes here. There is a major practical difference between an encrypted packet routed to a destination IP gateway via HTTPS, which is then being routed to a client on that gateway's network accorting to whatever is in the NAT or packet information. In some cases it is possible to identify websites / domains / URLS from that, but increasingly in many cases today (with massive cloud hosting networks) it is as useful as the IP address locator info an admin of ARRSE could see for me on this post. It's not going to tell them where I live or who I am. However, yes, the destination IP is visible, and in some cases that might match perfectly to a single website / domain address. The question I was answering, however, was the original: can my company see what domains / URLs I am browsing? To that, with HTTPS, the answer is: not likely.

As I said above, with HTTPS, you can see the handoffs at each node, but that doesn't mean you can see the whole relay.
 
Last edited:

OneTenner

LE
Book Reviewer
You could always set up persistent static routes for work & non-work stuff, with two network adapters, even if connected to the same router.
Once the route scopes have been defined, set the metrics on the network adapters to suit.
 
Top