What does this mean?
February 12, 2023 5:54 AM Subscribe
Support services for my VPN (Deeper Connect Pico) sent me these instructions: Please check whether DNS over HTTPS is turned on in the browser, if DoH is turned on, neither webfilter nor youtube filter will work normally. Therefore, you need to manually turn off the browser's DoH settings. I do not know what this means, how to do it, or what the results (good or bad) would be, and, therefore, if I should do it.
I'm trying to enable the "block all ads including Youtube ads" feature and followed the instructions on their site. When this didn't work, I emailed them, and that was their response.
Is it a good idea to follow those instructions or will that have negative effects on my computer/browser. If they are safe to follow them, how do I do so. I use Chrome and Vivaldi.
I'm on an M1 Macbook Air with the latest OS if that matters.
I'm trying to enable the "block all ads including Youtube ads" feature and followed the instructions on their site. When this didn't work, I emailed them, and that was their response.
Is it a good idea to follow those instructions or will that have negative effects on my computer/browser. If they are safe to follow them, how do I do so. I use Chrome and Vivaldi.
I'm on an M1 Macbook Air with the latest OS if that matters.
Dealing with DoH in Chrome. It's on by default these days, so you may well have done nothing to enable it.
I'm not familiar with Vivaldi, but apparently you get to its DoH setting via typing chrome://settings/security in its URL bar.
posted by humbug at 7:04 AM on February 12, 2023 [2 favorites]
I'm not familiar with Vivaldi, but apparently you get to its DoH setting via typing chrome://settings/security in its URL bar.
posted by humbug at 7:04 AM on February 12, 2023 [2 favorites]
Best answer: In the most oversimplified terms:
DNS is the directory that tells websites where to find things on other sites (mapping their hostnames to IP addresses).
HTTPS is the security that ensures that nothing in between your browser and the origin of the content you’re browsing can spy on the content, because it’s encrypted.
DNS over HTTPS means “also encrypt the lookups of hostnames, so nothing in the middle can even spy on which sites are being looked up.” You can see why this would be a good idea. This is a fairly recent development, and unlike HTTPS itself, it’s not totally standard yet, but it is pretty widely supported by now.
However, in order to do its ad blocking, the VPN evidently needs to know which sites are being looked up, so (I’m assuming) it can intercept any that it knows to be ad-like.
So they’re asking you to disable a semi-standard security feature so that they can provide the ad-blocking service. Since with a VPN all traffic will be going through them anyway, whether or not you want to do this really depends on how much you trust this provider. I’m not familiar with them so won’t venture an opinion, but in the abstract it’s something I’d be willing to do if I were using a reputable service and really wanted ads blocked.
posted by staggernation at 8:01 AM on February 12, 2023 [4 favorites]
DNS is the directory that tells websites where to find things on other sites (mapping their hostnames to IP addresses).
HTTPS is the security that ensures that nothing in between your browser and the origin of the content you’re browsing can spy on the content, because it’s encrypted.
DNS over HTTPS means “also encrypt the lookups of hostnames, so nothing in the middle can even spy on which sites are being looked up.” You can see why this would be a good idea. This is a fairly recent development, and unlike HTTPS itself, it’s not totally standard yet, but it is pretty widely supported by now.
However, in order to do its ad blocking, the VPN evidently needs to know which sites are being looked up, so (I’m assuming) it can intercept any that it knows to be ad-like.
So they’re asking you to disable a semi-standard security feature so that they can provide the ad-blocking service. Since with a VPN all traffic will be going through them anyway, whether or not you want to do this really depends on how much you trust this provider. I’m not familiar with them so won’t venture an opinion, but in the abstract it’s something I’d be willing to do if I were using a reputable service and really wanted ads blocked.
posted by staggernation at 8:01 AM on February 12, 2023 [4 favorites]
Best answer: The instructions you linked don't actually deal with DNS over HTTPS, they deal with installing a root certificate that allows your VPN provider to spoof everybody else's SSL certificates. If you do that, you're giving your VPN provider the ability to see and modify the content of anything you transfer over what would otherwise be an impenetrably secure encrypted connection.
Personally I would not ever do this. There is not a VPN provider on the planet that I would trust to the extent of giving it the technical ability to manipulate my bank accounts.
The reason they want you to do it is not prima facie nefarious, even though almost all of what the capability can be used for absolutely is. They can't filter stuff for you by inspecting the URLs that your browser is using to retrieve it unless they can actually see those URLs and modify those retrievals, and the only way they can do that is if you help them break the encryption that would normally keep all that stuff invisible to everybody but you and the sites you're actually browsing to. If you don't install their spoofing certificate then they can't do that, and the only ad-blocker-relevant information available to any network man-in-the-middle for sites reached over HTTPS is hostnames rather than complete URLs.
My strong recommendation is to uninstall any root certificate signed by your VPN provider and then ignore any ad-blocking functionality that fails as a result.
As for disabling DNS over HTTPS: there exist trustworthy local network-level ad blockers like the Pi-Hole that work by intercepting DNS requests rather than web traffic. These are also restricted to blocking entire network hosts rather than specific URL-specified pages on those hosts, and because they do work by intercepting DNS traffic they can't work if your browser is set up to transport that traffic encrypted over HTTPS.
To give the advertising industry the rude finger it so richly deserves without undermining your network security, just install a reliable, free, browser-based advertising blocker like uBlock Origin. Browser extensions do not require you to hand over your house keys to the delivery driver and will suppress requests for advertising resources (including, as it happens, YouTube ads) before those even hit the network.
posted by flabdablet at 8:41 AM on February 12, 2023 [6 favorites]
Personally I would not ever do this. There is not a VPN provider on the planet that I would trust to the extent of giving it the technical ability to manipulate my bank accounts.
The reason they want you to do it is not prima facie nefarious, even though almost all of what the capability can be used for absolutely is. They can't filter stuff for you by inspecting the URLs that your browser is using to retrieve it unless they can actually see those URLs and modify those retrievals, and the only way they can do that is if you help them break the encryption that would normally keep all that stuff invisible to everybody but you and the sites you're actually browsing to. If you don't install their spoofing certificate then they can't do that, and the only ad-blocker-relevant information available to any network man-in-the-middle for sites reached over HTTPS is hostnames rather than complete URLs.
My strong recommendation is to uninstall any root certificate signed by your VPN provider and then ignore any ad-blocking functionality that fails as a result.
As for disabling DNS over HTTPS: there exist trustworthy local network-level ad blockers like the Pi-Hole that work by intercepting DNS requests rather than web traffic. These are also restricted to blocking entire network hosts rather than specific URL-specified pages on those hosts, and because they do work by intercepting DNS traffic they can't work if your browser is set up to transport that traffic encrypted over HTTPS.
To give the advertising industry the rude finger it so richly deserves without undermining your network security, just install a reliable, free, browser-based advertising blocker like uBlock Origin. Browser extensions do not require you to hand over your house keys to the delivery driver and will suppress requests for advertising resources (including, as it happens, YouTube ads) before those even hit the network.
posted by flabdablet at 8:41 AM on February 12, 2023 [6 favorites]
Response by poster: Thanks for the answers so far, folks.
flabdablet, you said, "Personally I would not ever do this. There is not a VPN provider on the planet that I would trust to the extent of giving it the technical ability to manipulate my bank accounts."
Does it make a difference if the VPN is a hardware device, which this is, as opposed to one of those software / app services you pay, like ExpressVPN and such? I could understand an app having the ability to be nefarious but can the hardware ones be as well?
I will follow your advice and uninstall the root cert and attempt the further steps to see if it blocks the ads and if it doesn't, will check out the other services you mention.
posted by dobbs at 9:39 AM on February 12, 2023
flabdablet, you said, "Personally I would not ever do this. There is not a VPN provider on the planet that I would trust to the extent of giving it the technical ability to manipulate my bank accounts."
Does it make a difference if the VPN is a hardware device, which this is, as opposed to one of those software / app services you pay, like ExpressVPN and such? I could understand an app having the ability to be nefarious but can the hardware ones be as well?
I will follow your advice and uninstall the root cert and attempt the further steps to see if it blocks the ads and if it doesn't, will check out the other services you mention.
posted by dobbs at 9:39 AM on February 12, 2023
Best answer: Small backgrounder on SSL/TLS: many details are glossed over and grossly oversimplified but hopefully you'll get the gist.
When your browser wants to establish a secure connection to another host, it needs to set up an encrypted connection to that host in a way that can't be interfered with with by any other device on the network path in between.
Part of that process involves the browser sending a probe message to the server it thinks it's talking to, encrypted with that server's public key. That message contains a secret generated on the fly by and known only to the browser, as well as the browser's own public key.
The server then uses its private key - the one complementary to its public key, but held as a closely guarded secret by only that server - to decrypt the browser's probe message. The server extracts the browser's on-the-fly secret and public key, uses the browser's public key to re-encrypt the secret, and sends it back.
The browser then decrypts that response using its private key, and checks that the secret it contains is the same one it sent in the first place. The only way that it possibly could be is for the browser's initial probe message to have been successfully decrypted, which can only be done by the server that knows the private key corresponding to its advertised public key.
The secret, now known to both browser and server but nobody else because it was only ever transferred in messages that could only ever be decrypted using private keys, can then be used to encrypt further traffic between browser and server.
And all of this is absolutely ironclad provided that the browser used the correct public key for that server to begin with. Which gives rise to the issue of how the browser finds out what public key it's supposed to use to talk to any given server.
There are too many servers and too many browsers out in the world for every browser to be able to maintain a complete list of all the public keys for all the servers it might possibly ever want to communicate with. So what they do instead is rely on host certificates: small documents that contain an assertion like "the server at DNS name D has public key K", along with a digital signature that the browser can check to make sure that the assertion hasn't been tampered with since it was signed.
Those host certificates are generated and signed by certificate authorities that the server operators pay to do that, and the authenticity of those signatures rests in turn on another certificate, this one essentially asserting only that "any certificate signed by this one contains reliable assertions". And that certificate's signature references yet another certificate saying much the same kind of thing. There will typically be a chain of these "if you trust me then you can also trust this other guy" certs, and at the end of that chain will be one that the browser does already have a copy of because it shipped with it.
That's a root certificate, and browsers typically ship with a few hundred of those baked in. They come from organizations whose entire reason for existence is selling trustworthiness, and if you trust those organizations to do their job and keep all their private keys secret, then it's reasonable to trust the host cert at the far end of any such chain of trust.
If any of those certificate issuing outfits proves not to be trustworthy, browser users can uninstall their root certs. Doing this causes enough trouble for the server operators who pay the certificate issuers to pick a different one instead, so dodgy certificate issuers rapidly go out of business. At least, that's the theory.
VPN providers and other "security as a service" (SAAS) vendors act like very dodgy certificate issuers. The root certs they entice you to install allow the VPN provider itself to generate bogus host certificates on the fly for any secure site your browser tries to visit, and sign it in a way that your browser will then just instantly trust. This lets the SAAS provider set up a "man-in-the-middle" relay or proxy: when your browser tries to connect to your bank, then instead of connecting to the actual bank server it gets told a lie via DNS about what the bank server's IP address is, and then another lie about what the bank server's public key is, and makes a beautifully secure encrypted connection to the proxy controlled by the SAAS provider instead of to the real bank server.
That proxy then makes its own secure connection to the actual bank server, and starts shovelling traffic back and forth between it and your browser. The net effect is that you get to use the real bank server, but the SAAS provider's proxy box gets to see and possibly modify all of that traffic in unencrypted form, in completely arbitrary ways.
It doesn't make much difference whether the proxy is physically located in a little box on your own premises or in some data centre that the SAAS provider controls. Once their dodgy root cert is installed in your browser, they can set up as many decrypting/re-encrypting way stations between you and your bank as they like.
And because the SAAS provider's dodgy root cert needs to be able to assert the trustworthiness of the bogus host certificates that the SAAS provider's proxy might generate for any server in the world, all the usual caveats and limitations that would normally be placed on these things to limit the scope of cascading security failure are just missing. Which means that if your SAAS provider's private key leaks and falls into the hands of black hats, any of those people can then do the same decrypting proxy trick on any of your traffic that they can organize physical access to.
SAAS providers have a rather worse record of maintaining tight control over sensitive data than the respectable certificate vendors do, and the private keys associated with their spoofing-enabling root certs are very attractive targets.
posted by flabdablet at 11:45 AM on February 12, 2023 [2 favorites]
When your browser wants to establish a secure connection to another host, it needs to set up an encrypted connection to that host in a way that can't be interfered with with by any other device on the network path in between.
Part of that process involves the browser sending a probe message to the server it thinks it's talking to, encrypted with that server's public key. That message contains a secret generated on the fly by and known only to the browser, as well as the browser's own public key.
The server then uses its private key - the one complementary to its public key, but held as a closely guarded secret by only that server - to decrypt the browser's probe message. The server extracts the browser's on-the-fly secret and public key, uses the browser's public key to re-encrypt the secret, and sends it back.
The browser then decrypts that response using its private key, and checks that the secret it contains is the same one it sent in the first place. The only way that it possibly could be is for the browser's initial probe message to have been successfully decrypted, which can only be done by the server that knows the private key corresponding to its advertised public key.
The secret, now known to both browser and server but nobody else because it was only ever transferred in messages that could only ever be decrypted using private keys, can then be used to encrypt further traffic between browser and server.
And all of this is absolutely ironclad provided that the browser used the correct public key for that server to begin with. Which gives rise to the issue of how the browser finds out what public key it's supposed to use to talk to any given server.
There are too many servers and too many browsers out in the world for every browser to be able to maintain a complete list of all the public keys for all the servers it might possibly ever want to communicate with. So what they do instead is rely on host certificates: small documents that contain an assertion like "the server at DNS name D has public key K", along with a digital signature that the browser can check to make sure that the assertion hasn't been tampered with since it was signed.
Those host certificates are generated and signed by certificate authorities that the server operators pay to do that, and the authenticity of those signatures rests in turn on another certificate, this one essentially asserting only that "any certificate signed by this one contains reliable assertions". And that certificate's signature references yet another certificate saying much the same kind of thing. There will typically be a chain of these "if you trust me then you can also trust this other guy" certs, and at the end of that chain will be one that the browser does already have a copy of because it shipped with it.
That's a root certificate, and browsers typically ship with a few hundred of those baked in. They come from organizations whose entire reason for existence is selling trustworthiness, and if you trust those organizations to do their job and keep all their private keys secret, then it's reasonable to trust the host cert at the far end of any such chain of trust.
If any of those certificate issuing outfits proves not to be trustworthy, browser users can uninstall their root certs. Doing this causes enough trouble for the server operators who pay the certificate issuers to pick a different one instead, so dodgy certificate issuers rapidly go out of business. At least, that's the theory.
VPN providers and other "security as a service" (SAAS) vendors act like very dodgy certificate issuers. The root certs they entice you to install allow the VPN provider itself to generate bogus host certificates on the fly for any secure site your browser tries to visit, and sign it in a way that your browser will then just instantly trust. This lets the SAAS provider set up a "man-in-the-middle" relay or proxy: when your browser tries to connect to your bank, then instead of connecting to the actual bank server it gets told a lie via DNS about what the bank server's IP address is, and then another lie about what the bank server's public key is, and makes a beautifully secure encrypted connection to the proxy controlled by the SAAS provider instead of to the real bank server.
That proxy then makes its own secure connection to the actual bank server, and starts shovelling traffic back and forth between it and your browser. The net effect is that you get to use the real bank server, but the SAAS provider's proxy box gets to see and possibly modify all of that traffic in unencrypted form, in completely arbitrary ways.
It doesn't make much difference whether the proxy is physically located in a little box on your own premises or in some data centre that the SAAS provider controls. Once their dodgy root cert is installed in your browser, they can set up as many decrypting/re-encrypting way stations between you and your bank as they like.
And because the SAAS provider's dodgy root cert needs to be able to assert the trustworthiness of the bogus host certificates that the SAAS provider's proxy might generate for any server in the world, all the usual caveats and limitations that would normally be placed on these things to limit the scope of cascading security failure are just missing. Which means that if your SAAS provider's private key leaks and falls into the hands of black hats, any of those people can then do the same decrypting proxy trick on any of your traffic that they can organize physical access to.
SAAS providers have a rather worse record of maintaining tight control over sensitive data than the respectable certificate vendors do, and the private keys associated with their spoofing-enabling root certs are very attractive targets.
posted by flabdablet at 11:45 AM on February 12, 2023 [2 favorites]
all i want to add is that apparently this thing is a cryptocurrency miner.
posted by glonous keming at 12:24 PM on February 12, 2023
Deeper Network represents the world's first decentralized blockchain network for building a truly private, secure and fair Internet.Deeper Network Inc. was founded in Silicon Valley in 2018 with the vision of leveraging blockchain technology to empower the everyday users of the internet by building both the WEB 3.0 infrastructure of the future and an accessible gateway for everyone to join the revolution.from https://shop.deeper.network/pages/aboutus
posted by glonous keming at 12:24 PM on February 12, 2023
Response by poster: Again, I appreciate the answers.
all i want to add is that apparently this thing is a cryptocurrency miner.
Yes, there is a dashboard with sections for mining and for sharing. To mine you need to create an account (wallet), which I never did as I have no interest.
For Sharing there are on/off toggles for "sharing" and "bit torrent sharing", both of which I've disabled.
posted by dobbs at 1:37 PM on February 12, 2023
all i want to add is that apparently this thing is a cryptocurrency miner.
Yes, there is a dashboard with sections for mining and for sharing. To mine you need to create an account (wallet), which I never did as I have no interest.
For Sharing there are on/off toggles for "sharing" and "bit torrent sharing", both of which I've disabled.
posted by dobbs at 1:37 PM on February 12, 2023
all i want to add is that apparently this thing is a cryptocurrency miner.
Between that and inducing customers to subvert their own encryption security, that's enough technical smell that I would personally not choose to use anything this outfit has to offer.
posted by flabdablet at 8:28 PM on February 12, 2023 [3 favorites]
Between that and inducing customers to subvert their own encryption security, that's enough technical smell that I would personally not choose to use anything this outfit has to offer.
posted by flabdablet at 8:28 PM on February 12, 2023 [3 favorites]
I use a hardware VPN (for work). As far as my computer is concerned, it's just connecting to the internet. I didn't have to install any certificates or anything else on my computer. (It's managed by my organization, so if they did install a certificate, I couldn't tell.)
posted by Spike Glee at 10:52 AM on February 13, 2023
posted by Spike Glee at 10:52 AM on February 13, 2023
A simple VPN doesn't need SSL spoofing or anything remotely similar.
VPN endpoints look and behave like any other Internet router from the point of view of the other devices that connect to them. It's just that those routers link to each other over private, encrypted connections that are themselves carried on the wider Internet rather than over dedicated cabling.
SSL spoofing certificates are for breaking into encrypted connections, not for implementing them.
That said, SaaS providers like Zscaler offer corporate VPN services that do include SSL content inspection for the purposes of malware detection and enforcement of corporate Internet usage policy which, again, can only work if the user's browser gets Zscaler's spoofing root cert installed.
Zscaler gives the corporate administrator the ability to disable that inspection selectively, and any corporation that used something like it would probably have a pretty extensive whitelist of do-not-inspect sites, but even if you trust that neither your workplace nor its SaaS provider is going to abuse the capability it now has to fuck with your Internet banking and whatnot, the existence of that spoofing root cert in the browser's collection of trusted root certs creates a big increase in its attack surface.
Best practice, then, is to use workplace-provided equipment for work-related purposes, and personal equipment for personal purposes, and don't cross the streams. I rate allowing an employer to forcibly reduce my personal devices' security as a fundamental error that I'm simply not willing to make.
posted by flabdablet at 11:23 AM on February 13, 2023
VPN endpoints look and behave like any other Internet router from the point of view of the other devices that connect to them. It's just that those routers link to each other over private, encrypted connections that are themselves carried on the wider Internet rather than over dedicated cabling.
SSL spoofing certificates are for breaking into encrypted connections, not for implementing them.
That said, SaaS providers like Zscaler offer corporate VPN services that do include SSL content inspection for the purposes of malware detection and enforcement of corporate Internet usage policy which, again, can only work if the user's browser gets Zscaler's spoofing root cert installed.
Zscaler gives the corporate administrator the ability to disable that inspection selectively, and any corporation that used something like it would probably have a pretty extensive whitelist of do-not-inspect sites, but even if you trust that neither your workplace nor its SaaS provider is going to abuse the capability it now has to fuck with your Internet banking and whatnot, the existence of that spoofing root cert in the browser's collection of trusted root certs creates a big increase in its attack surface.
Best practice, then, is to use workplace-provided equipment for work-related purposes, and personal equipment for personal purposes, and don't cross the streams. I rate allowing an employer to forcibly reduce my personal devices' security as a fundamental error that I'm simply not willing to make.
posted by flabdablet at 11:23 AM on February 13, 2023
Response by poster: I use a hardware VPN (for work). As far as my computer is concerned, it's just connecting to the internet. I didn't have to install any certificates or anything else on my computer. (It's managed by my organization, so if they did install a certificate, I couldn't tell.)
The VPN works out of the box without doing any of the stuff I asked about. The stuff I asked about was in the manual for the ad eliminating feature.
Due to this thread, I've given up on the ad stuff and undone all the settings I turned on and the VPN still works fine.
posted by dobbs at 2:06 PM on February 13, 2023
The VPN works out of the box without doing any of the stuff I asked about. The stuff I asked about was in the manual for the ad eliminating feature.
Due to this thread, I've given up on the ad stuff and undone all the settings I turned on and the VPN still works fine.
posted by dobbs at 2:06 PM on February 13, 2023
This thread is closed to new comments.
posted by dobbs at 5:55 AM on February 12, 2023