Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Network

Novel Attack Against Virtually All VPN Apps Neuters Their Entire Purpose (arstechnica.com) 114

Posted by BeauHD from the PSA dept.
Researchers have discovered a new attack that can force VPN applications to route traffic outside the encrypted tunnel, thereby exposing the user's traffic to potential snooping or manipulation. This vulnerability, named TunnelVision, is found in almost all VPNs on non-Linux and non-Android systems. It's believe that the vulnerability "may have been possible since 2002 and may already have been discovered and used in the wild since then," reports Ars Technica. From the report: The effect of TunnelVision is "the victim's traffic is now decloaked and being routed through the attacker directly," a video demonstration explained. "The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the Internet." The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network. A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself. [...]

The attack can most effectively be carried out by a person who has administrative control over the network the target is connecting to. In that scenario, the attacker configures the DHCP server to use option 121. It's also possible for people who can connect to the network as an unprivileged user to perform the attack by setting up their own rogue DHCP server. The attack allows some or all traffic to be routed through the unencrypted tunnel. In either case, the VPN application will report that all data is being sent through the protected connection. Any traffic that's diverted away from this tunnel will not be encrypted by the VPN and the Internet IP address viewable by the remote user will belong to the network the VPN user is connected to, rather than one designated by the VPN app.

Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn't implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there's a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation. The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn't in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. You can learn more about the research here.

Novel Attack Against Virtually All VPN Apps Neuters Their Entire Purpose More | Reply

Novel Attack Against Virtually All VPN Apps Neuters Their Entire Purpose

Comments Filter:

  • Um... (Score:5, Insightful)

    by Baron_Yam ( 643147 ) on Monday May 06, 2024 @09:46PM (#64452858)

    If you can already set up a rogue DHCP server on my network that can hand out an address to a VPN client before my own, my network is already lost.

    • Re:Um... (Score:5, Insightful)

      by Anonymous Coward on Monday May 06, 2024 @09:53PM (#64452866)

      If you can already set up a rogue DHCP server on my network that can hand out an address to a VPN client before my own, my network is already lost.

      This is true, but I suspect many folks who normally would VPN in public spaces like coffee shops or hotels will now be thinking twice and/or causing additional headaches for their IT department.

      • Re: (Score:2)

        by mysidia ( 191772 )

        but I suspect many folks who normally would VPN in public spaces like coffee shops or hotels will now be thinking twice

        What I say is plug a hardware mini-router GL-MT300N-V2 in to your laptops instead of connecting the laptop directly to the Public WiFi.

        The mini-router serves the DHCP to your laptop, and you choose which WiFi network to connect to.

        Basically, a Mini-router acts as a Condom shielding the laptop from the rest of the Local network, which a VPN alone does not entirely do.

        Thus at no point can se

    • Re: (Score:2)

      by ls671 ( 1122017 )

      Maybe route -n; route del ? I usually do route -n after connecting to the vpn. Also get ip from dhcp, then configure static ip with the given ip after that etc.

    • Say that with a network of 1000 people searching for copulation footage.

    • Re:Um... (Score:5, Interesting)

      by Amouth ( 879122 ) on Monday May 06, 2024 @10:29PM (#64452916)

      don't need to be rogue and act as an actual DHCP - you just need to send DHCP messages....

      not hard to craft a DHCP FORCERENEW message with modified routes that looks authentic.... hop on a network, start updating clients, watch traffic and then drop off

    • Re:Um... (Score:5, Interesting)

      by codebase7 ( 9682010 ) on Tuesday May 07, 2024 @03:01AM (#64453184)
      Also, doesn't affect anything that uses static addressing.

      Many of today's "vulnerabilities" are just generation derp discovering how things are supposed to work without understanding any of it and cooking up a media hype in hopes of being awarded the contract to "fix" the "problem" by a bunch of other idiots. (The C-Level kind.)

      Hold on to your old equipment folks, you'll need it again when the hysteria finally ends. After they've managed to break everything else.....

    • Consider public WiFi (Score:5, Informative)

      by _merlin ( 160982 ) on Tuesday May 07, 2024 @03:54AM (#64453266) Homepage Journal

      People often recommend using VPNs to protect traffic when using public WiFi networks, etc. The hypothetical attack would be a malicious public WiFi network using a DHCP server that sets static routes for the IP addresses of servers they want to intercept traffic to. The static routes described in DHCP take precedence over the default route for the VPN.

      For example, suppose I want to intercept traffic to Slashdot:

      • I set up the DHCP server on my public WiFi network to announce static routes for 104.18.5.215 and 104.18.5.215 leading to my malicious router.
      • You connect to my WiFi network, and connect to your VPN in the hope that it will protect your traffic from malicious parties on the untrusted public WiFi network.
      • Your VPN creates a default route leading to its virtual interface to send all IP traffic across the tunnel, but the static routes configured via DHCP take precedence for 104.18.5.215 and 104.18.5.215.
      • Your Slashdot browsing traffic is routed via my malicious router while the rest of your traffic goes across your VPN.

      • Re:Consider public WiFi (Score:5, Informative)

        by mysidia ( 191772 ) on Tuesday May 07, 2024 @10:56AM (#64453888)

        Your VPN creates a default route leading to its virtual interface to send all IP traffic across the tunnel, but the static routes configured via DHCP take precedence

        This is one possibility, but your VPN app does not Have to work this way. You can also write the VPN app to periodically scan the routing tables and Suspend the network connection with an Alert Popup displayed if a New route is detected that was not present when the VPN connection started.

        You can have the VPN app so that when it first connects, It will install a more-specific route for every IP address covered by a route entry the DHCP client installed.

        A /32 entry in the table with a metric of 1 can't be overridden by the DHCP client. If you are scanning the table every 5 seconds, then your adversary can't pull a whole browser session off the VPN, And the user will be notified about the local attack.

        On linux you can create IP RULE entries that indicate which routing table to use, then create rules that say Every destination IP address except for your Router IP, and your VPN Endpoint IP use a different routing table ID, which you leave empty except for the one default route pointing to your VPN's virtual interface.

    • I think you misunderstand. The main reason to use a VPN is precisely because you do not trust the local network. Public WiFi in an airport, for example. Log into a VPN, and your traffic should be completely protected from the local network. If the local network can force your traffic to be visible, then they can filter it - even if it is encrypted - because they can see which sites you are communicating with. There are also still cases where you might have unencrypted traffic, and you definitely don't wan

    • Re: (Score:2)

      by Bert64 ( 520050 )

      But that's the point, people use a VPN when connecting to a network they already don't trust (eg public wifi).

      • But that's the point, people use a VPN when connecting to a network they already don't trust (eg public wifi).

        I'm not connecting to the public wifi. I only use it to deliver the message. This attack seems to disable VPN by breaking into the site that I'm connecting to. Not the public wifi near to me, but the final receiver.

    • Re: (Score:2)

      by phlawed ( 29334 )

      And with this, whatever the poor user is connecting to can also be lost.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      One of the most common uses of VPNs is with other people's networks that you have no control over. Hotels/café WiFi, and of course the cellular network.

      Not needing to trust the network is one of the main benefits.

  • ... on non-Linux and non-Android ...

    Is someone tip-toeing around the words "Microsoft Windows": To be fair, this defect can be enabled on Linux too.

    ... diverts the data to the DHCP server ...

    This has some value has a 'Reset Config' command but who decided a reset command didn't require a password?

  • if you are running wireguard and someone reroutes packets, they won't have the key so the data would remain gibberish, so privacy is maintained. This isn't really about VPNs at all, but about routing at the next/os layer. There is limited value in sniffing encrypted packets. I supposed the attacker would be able to read the addressing information, and know where the VPN server IP and port. Still not much use without the key. Also would be defeated by pre-shared keys, even if attacker could determine key from inital handshake.

    Publish or perish. We're seeing a lot of ado about nothing for the sake of writers and publishers filling empty space. This feels like a new type of bait and switch to have something to sell advertisers.

    • Re: doesn't seem to add up to anything real (Score:5, Informative)

      by Baloroth ( 2370816 ) on Tuesday May 07, 2024 @12:12AM (#64453028)
      I don't think you quite get the problem. It isn't routing the encrypted VPN data, it routes the unencrypted packets at the OS level without ever touching the VPN at all. So traffic to, say, www.wikipedia.org you expect to be tunneled through the encrypted VPN instead gets routed through normal unencrypted routes (well normal except for the attacker-controlled gateway). That's why it's so prevelant: it has nothing at all really to do with the VPN itself, it's an issue with DHCP and TCP/IP at the protocol level. On the flip side, since it can't mimic the VPN, traffic that needs to be tunneled (such as a VPN-accessible server) can't be snooped, since data isn't routed through the VPN so the server simply can't be communicated with. The issue mainly affects people who use VPNs as a privacy tool against their ISP or nation state, or possible snoopers on a public WiFi, since it breeches that privacy.
      • A proper VPN wouldn't be affected by this. Why? Because a proper VPN validates the server identity, and has pre-shared secrets on both ends of the connection. The actual data being sent is still encrypted even if it passes through an attacker's host on the way there. The best a DHCP mitm attack does against these kinds of VPNs is cause a connection failure or allow them to record encrypted packets. Just like anyone else between you and the server on the internet would be able to do.

        The kinds of attacks th

        • Re: doesn't seem to add up to anything real (Score:4, Informative)

          by thegarbz ( 1787294 ) on Tuesday May 07, 2024 @03:55AM (#64453268)

          A proper VPN wouldn't be affected by this. Why? Because a proper VPN validates the server identity, and has pre-shared secrets on both ends of the connection.

          You don't seem to understand the problem either. This VPN isn't connecting to a remote server. This is literally a network level attack on routes that your VPN explicitly says it will *not* encrypt. If I run a VPN tunnel I still want to be able to access my local printer, for that I need non-encrypted routes. Nearly all VPN apps offer this, regardless of how "proper" they may be. It's a fundamental network option for managing encrypted tunnels. Worse still when it's done on a port / application level with split tunnels.

          The "proper" VPN app has nothing to validate here.

          • As an example, traffic to "office printer" which is the printer in my office shouldn't go through VPN. It should stay within my local network all the time.

            Now if the guys at Wikipedia don't watch out, someone with access to the wikipedia network could tell my computer and every other computer "www.wikipedia.org is on your local network", just like "office printer". So traffic to this site goes directly and not through the VPN. If I'm sitting at Starbucks with a totally unsecured network, doesn't matter.

            • Re: (Score:2)

              by Budenny ( 888916 )

              You are describing the situation with Mullvad, except that Mullvad takes the opposite approach: your address is the one which its server has, and consequently you will not be able to access anything on the LAN as long as you are connected to Mullvad.

              Unless you explicitly give a specified application the ability to connect from the base system. Which, for the sake of security, though at the cost of a little convenience, you should not do.

              This is why Mullvad, when it considered this exploit back in last Aug

            • Re: (Score:2)

              by maorb ( 2578043 )

              Except it's not the guys at Wikipedia that can cause this redirect, it's the guy running a rogue DHCP server on the local network, possibly even a hostile network admin, that gets to say "The next hop for the IP address of Wikipedia is still [default gateway]. Ignore the VPN." This would result in wikipedia traffic staying outside the VPN tunnel and just being routed like normal. They also could have said the next-hop is [transparent-proxy] which would allow them to see all the traffic with one less layer o

          • Re: (Score:2)

            by Budenny ( 888916 )

            Mullvad as a for instance will block printing to a LAN printer when connected to the LAN.

            There is an option to specify particular apps which will be allowed to bypass the VPN.

            • Yes blocking some of the fundamental functionality of a VPN will do it. I'm calling out the OP for claiming that "proper VPNs" are safe. There's nothing "proper" about a VPN that disables some functionality that is standard as part of VPNs, such as the ability to route non encrypted traffic to a local network. It's a no true Scotsman fallacy, except that they aren't saying the true Scotsman wears a kilt and plays bagpipes, but rather that *THAT* isn't the true Scotsman and the true Scotsman is the one dress

      • How does that break the TLS at wikipedia?

        • How does that break the TLS at wikipedia?

          That's what you call "defense in depth". https and VPN are completely independent. If you wanted to use https over VPN, you get https without VPN instead and the hacker still has a huge problem. If you wanted to use http over VPN, you get http without VPN, and everything is in the clear.

          You could even send encrypted data (data that you encrypted yourself) over http through VPN, so you get encrypted data, sent in the clear. The hacker still needs to decrypt your data.

          If there is other encryption that

        • It does not: TLS happens at a higher layer that isn't affected by routing or tunneling. The attacker can't break that with this attack, but they will be able to capture the TLS encrypted data (which they wouldn't, or would be harder, with a VPN), and any more importantly any unencrypted data (including, notably, most DNS requests). And if they *do* have a TLS-breaking attack (like a stolen certificate), they will then be able to MITM it, which they wouldn't if the VPN was working properly (not without also

    • By this logic you wouldn't have VPN at all. You are using VPN as an increased security layer when dealing with an untrusted network. And this largely eliminates the VPN as a security measure. What you are really discussing is whether VPN is really needed with everything now being encrypted not whether this attack defeats it.

  • But even on those I boot to Linux if I need to do something shady over a VPN.

  • Is it possible for a VPN client on Windows to detect that this has happened and warn the user?

    • Re: (Score:2)

      by vbdasc ( 146051 )

      Probably yes, if they use packet capture. If not, then the detection could be done with a separate utility. Such an utility will require administrator access on your computer, of course.

      • Re: (Score:2)

        by Entrope ( 68843 )

        The VPN client doesn't need to capture any packets, it just needs to look for a dodgy routing table. In the threat case, the VPN client is already injecting a default route, so it must have access to the routing table already.

        • Re: (Score:2)

          by vbdasc ( 146051 )

          It's not certain that the Windows APIs used for examining the routing table will be able to detect the DHCP injection. It might well be transparent. At first glance, MS documentation is not clear about that, so probably an experiment is needed.

          OTOH, a sniffer looking for the specific malicious DHCP option in the incoming traffic is a surefire way to detect the problem.

          • Re: (Score:2)

            by Entrope ( 68843 )

            What's not clear about GetIpForwardTable2() putting MIB_IPPROTO_NETMGMT into the source Protocol field of the MIB row, or NlroDHCP in the Origin field?

        • I was going to say something similar. And most VPN clients do clear the routing table upon connection. It looks like they will have to also periodically examine it in the short-term. In the medium-term there will be an OS option to not accept these DHCP packets.
  • Most connections are via HTTPS and so encrypted. If it isn't work related why should I give a rat's ass about VPN? I don't anyway.
    • Because https only works for websites? Are you saying all you do for your work is go to websites?

    • Re: (Score:2)

      by Bert64 ( 520050 )

      HTTPS still leaks the site name unless you're using ESNI which is not widely used yet.

    • Re: (Score:2)

      by quetwo ( 1203948 )

      Paired with a poisoned DNS server and a shady SSL cert, you can MIM sites with still having the client think things are good.

  • So. I have a VPN client on my computer. It encrypts the data and sends it to the VPN Host. This attack supposedly sends the unencrypted data to a new route, meaning software would have to be on the machine and change the routing table. At that point, if the software has admin access to change the routing table, your security is already lost. If this is supposed to be some kind of man in the middle attack, all they would get is encrypted data from the VPN client... Also, if there's not an encryption ha
    • Essentially, you cannot set up a secure connection on an already compromised computer.

    • Re:Trying to process this logically.... (Score:4)

      by TheNameOfNick ( 7286618 ) on Tuesday May 07, 2024 @02:33AM (#64453166)

      The software which is on your machine and changes the routing table is called a DHCP client and you installed it. It adds routes when it receives them from a DHCP server in an option 121. Note that I wrote "a DHCP server", not "the DHCP server".

      • Weird things tend to happen when you have multiple DHCP servers. Like traffic being randomly split between them.
        I tried to use my own DHCP server to make up for Comcast's passport implementation. It didn't work. I put the thing in bridge mode, and built a pfSense router. It's too bad, because the XB8 had a very decent WiFi AP. But that gets disabled in bridge mode obviously.

        The obvious solution is to use TLS for DHCP. /s

    • No that's not what is happening at all. The routing table can be changed by the DHCP server that issued your IP address. That's a DHCP feature that's been around forever.
      • You're misunderstanding. Doesn't matter what the routing table says, the VPN software is only going to send encrypted data. You can't tell the routing table "only send unencrypted data". If my VPN client blocks all communication that's not on the VPN, the routing table is changed to a different subnet, my VPN client is still going to try to authenticate and encrypt the data. If it can still reach it's intended Host, everything will be encrypted no matter the route. If it can't reach the VPN Host, the VP
        • You are not understanding how VPN clients work. The VPN client works as a virtual network adapter. Connect your VPN client and run ipconfig. You will see it. And then all traffic is routed through the virtual adapter which encrypts it. Then the encrypted traffic is sent via the physical adapter to the VPN endpoint which forwards it along to the destination. When packets come back, essentially the reverse happens. You can't disable the physical adapter because that's what the VPN uses to transport packe
          • DHCP can change my routing table, my gateway, my IP and my DNS servers (if any of those are not hard set), they can NOT tell my VPN client to not encrypt data, not handshake with the connecting Host, not authenticate with my username and password and not hold a connection if any of those fail. The software would have to be ON the Device that is setting up the VPN for any of that to happen. I'm a certified network engineer that has focused on security for over 20 years (since Lantastic and novel networks w
            • All of the things you say are true, but you're still not understanding how VPN works or how this exploit works. Connect your vpn and run ipconfig like I suggested and I think you will understand. Your machine will have *two* connections to the internet. One of them will be the normal, unencrypted non-vpn connection. The other will be the VPN connection. The way that this exploit works is that it tricks your machine into sending traffic over the non-vpn adapter rather than the VPN adapter.

              I am not a c

        • Re: (Score:2)

          by unrtst ( 777550 )

          Doesn't matter what the routing table says, the VPN software is only going to send encrypted data. You can't tell the routing table "only send unencrypted data".

          That's not right.

          Here's a vendor support feature from Cisco that results in encrypted VPN traffic for some subnet destinations and clear text traffic going over your normal connection for other subnets:
          https://www.google.com/search?... [google.com]

          Split tunnel support on *nix just used native /sbin/route commands to achieve that.

          I manually do this myself on nearly all my VPN connections. I limit them so that only the destinations I want go over the VPN. Even if the VPN sets up a default route to push all traffic over th

  • The researchers assume that the VPN is used to hide which sites are accessed on the internet. For this purpose the attack will work.

    It will not work if you are using the VPN to access hosts that are not accessible from the internet since the attacker has no way to inject the rerouted traffic into the VPN. E.g., if you use VPN to access your IMAP server at home, the attacker can try to pose as that IMAP server and might learn you password, but it won't be able to present your inbox.

    • Hopefully you would be using IMAPS in this case and the credentials would not be snoopable.

      If you were using plaintext on the internet, you were already compromised.

      What the security hole allows for is privacy violations, such as a TLA learning which web sites you visit. Or foreign government tracking political opponents. And so on.

    • It will not work if you are using the VPN to access hosts that are not accessible from the internet since the attacker has no way to inject the rerouted traffic into the VPN.

      Absolutely true. If your company has its own VPN server and allows you get on their network through VPN, that means you can get on their network through _their_ VPN server. This attack makes your computer try to get to your company's network without using the company's VPN server, and that will just not work.

      So what will happen that you and your hundred colleagues working from home can't get on the company network and call IT to figure out what's wrong, and hopefully they can find out what happens and fi

      • Re: (Score:2)

        by maorb ( 2578043 )

        I would point out that it also compromises some network topology information like which internal IPs are hosting services based on what specific host IPs your computer is trying to send traffic to. That traffic will get sent to an untrusted device which can still record the destination IP and ports from the packet.

    • Exactly. This doesn't appear to be an attack against corporate VPN users but rather against ones who are using VPN to hide political activity.
  • So if I use VPN to connect to www.amazon.com, the software on my computer will find out whether www.amazon.com is on my own network and should be contacted without VPN. Of course it isn't. So someone would have to get in front of www.amazon.com's servers, then when my computer asks "hey amazon, are you there", it replies "no, I'm on your local network", and there is no VPN.

    So that allows an attacker to watch my traffic with www.amazon.com if they manage to get into amazon's server. Or my traffic with www
    • Forgot: But then if they are capable of disabling use of VPN for everybody connecting to www.sensitivecompany.com, then surely they can break in completely and get my messages when VPN on that site decrypts my message.

    • Re: (Score:2)

      by maorb ( 2578043 )

      They don't need to get into amazon's servers though. They just need to have a rogue DHCP server on your local network that manages to respond first (or to control the actual DHCP server on a malicious network). With that they can redirect your Amazon traffic so it never goes through your VPN tunnel at all, and instead gets sent straight to a transparent-proxy to packet capture it for later offline attack. This attack both bypasses the VPN and guarantees a compromised device gets to be between you and the si

    • *decent* VPN setups have a VPN kill switch that if the VPN is not connected, nothing is sent.

  • It's a good point and most people would be happier with a DHCP client that only pulls address, mask, and gateway.

    It might make a secure default but would break some valid configs out there.

    Interestingly most of my stuff is static again in the devops era and with security in mind so DHCP is mostly for guest and IoT here at this point. We need to be able to cold-up without dependencies like DHCP. The guest network is the only wifi without a 63-bit PSK so it's also useful for new device onboarding.

  • "Novel Attack Against Virtually All VPN Apps Neuters Their Entire Purpose"

    VPNs aren't just used for anonymity, they're also used for gaining access to privileged content and/or devices, such as accessing work stuff when you're offsite (I believe this was the original use case for a VPN). Much/Most of that traffic should still not be in cleartext, even if it gets forced outside the VPN.

    • That stuff is usually not reachable outside of VPN and corporate users aren't the target here.

      • Right, but as I said - the title makes a rather ludicrous claim. But that's what bloggers do.

        • It's not just bloggers. Its the security researchers who find this stuff. After all, they're basically trying to make a name for themselves by finding previously-undiscovered defects to convince somebody to pay for their services. And, in fairness, even though the implications of this are small for corporate users, it's pretty impressive that they found it. And the impact is high for political dissidents and those engaged in espionage.

  • Long assumed VPN clients had the good sense to prefer their own routes over OS installed ones. Still a bit skeptical as I've been on networks with overlapping networks and the VPN nets always seem to take precedence. 'll have to experiment.

    Regardless DHCP is insane as it also enables systems to be totally owned even when turned off thanks to baked in management malware.

    • Some VPN clients clear the routing table upon connection and insert only their own routes. The ones used by the potential targets of this attack most certainly do it as the users who are affected here would be those engaging in unlawful political activity who don't want it to be known that they are visiting certain sites (such as maybe looking at Wikipedia in China or Russia). Some corporate VPN clients don't do this in order to allow access to local resources and some corporate VPN clients only change ro

  • Don't some VPN softwares block all non-VPN traffic to the non-VPN interface while they are active? I swear I've used one like this before.

    • Re: (Score:2)

      by Budenny ( 888916 )

      Yes, Mullvad does (among others).

    • Some of them do that. But they do it via various mechanism that may or may not be effective. The most common way to "block" such traffic is just to clear the routing table. But if the malicious DHCP server were to send the static routes post-connection, they would get put back. Maybe some privacy-oriented (as opposed to corporate confidentiality-oriented) VPN clients are more aggressive.

      • It seems like you could do it with any decent firewall easily enough. Certainly on any of the popular Unixlikes it would be reasonably trivial.

        • Yes, you could block all outbound traffic at the firewall except to the VPN end point. However, that's a real PITA and not super-easy to do on your own. If you want to use VPN on an untrusted WiFi network, most of them have captive portals for registration, so you have to disable the firewall rule long enough to authenticate to the captive portal and then reenable it and setup the VPN connection. The zScaler client does this when it detects a captive portal. For a user to set it up would be a manual err
      • How is a rogue DHCP server going to send a routing table over a connected VPN connection "post-connection"??? For it to be connected, it has to authenticate to the end point with a username and password and then is encrypted when then uses the encrypted tunnel to send the IP, gateway, routing table, DNS, etc?????
        • It's not sending it over the VPN connection. There is a lot of misinformation in this thread on how VPN works. Your machine has a physical ethernet or WiFi adapter that is unimpacted by setting up VPN. The machine is always capable of using this. And it has to sue the non-encrypted VPN connection to communicate to the local DHCP server. The way VPN works is to setup an *additional* network adapter which first encrypts the data and then sends encapsulated packets to the remove VPN endpoint via the physi

  • The degree of security is inversely proportional to an exponential function of complexity.

  • Well, that probably means Windows and maybe OS-X. Anybody trusting especially Windows to keep them safe is already a fool, VPN or not. Hence this story is not very relevant.

  • Because it isn't standard compliant. Now that's a good excuse to ignore standards.

Slashdot Top Deals

The next person to mention spaghetti stacks to me is going to have his head knocked off. -- Bill Conrad

Close