Subject: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-split-dns-14: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Nov 2018 14:29:59 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-ipsecme-split-dns-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I hope I'm just missing something obvious here, but this seems like it may
cause a significant security issue.

Lots of "regular" users use VPNs for access the Internet, either to bypass
censorship / content restrictions, or to improve their privacy. These are not
"corporate" / "enterprise" VPNs, but rather public ones - and sometimes they
are run by people I wouldn't entirely trust.

What is to stop one of these VPN providers setting:
INTERNAL_DNS_DOMAIN(www.paypal.com)
INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)

or, better yet:
INTERNAL_DNS_DOMAIN(com)
INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)

and so being able to spoof DNSSEC for paypal.com / all of .com?
This is especially worrying if something like DANE is ever deployed...

The draft *does* says:
"Other generic or public domains, such as top-level domains, similarly SHOULD
NOT be whitelisted." - this doesn't really answer the above. 1: It is
increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2:
How do I programatically tell if www.foo.net is a "public domain"? What is a
public domain anyway? How is an implementer supposed to address this?

It also says:
"Any updates to this whitelist of domain names MUST happen via explicit human
interaction to prevent invisible installation of trust anchors." Is my auntie
really expected (or competent) to understand what "Your VPN provider, TrustVPN
wants to whitelist com. Do you want to allow this? [Y/N]" means?

I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit
works.

Also, some of the DNS behavior is handwavey - I think that the document really
should be reviewed by DNSOP, but will leave it to Eric to make that call.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  As with any network
   input, the content SHOULD be considered untrusted and handled
   accordingly." feels a bit handwavey. Are there currently any DNSSEC
   validating clients which can easily take a targeted TA for a specific domain
   / set of domains?

I’m also not quite sure how this interacts with delegations. E.g:

example.com   600 IN NS ns01.internal.example
And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local
recursive, does it need to send the query to ns01 though the VPN or not?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 00:22:30 -0500 (EST)

No, you missed something subtle that clearly needs to stand out more :)

> INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...)

This sentence:

    When only a subset of traffic is routed into a private network using
    an IPsec SA, these Configuration Payload options can be used to
    define which private domains are intended to be resolved through the
    IPsec connection without affecting the client's global DNS
    resolution.

I think we had more explicit text in earlier versions that didn't make
the cut on future revisions. I will re-add proper text in Section 4 and
the Security Section.

> This is especially worrying if something like DANE is ever deployed...

There is a whole section on that.

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-14#section-5

Specifically:

    IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
    a whitelist of one or more domains that can be updated out of band.
    IKE clients with an empty whitelist MUST NOT use any
    INTERNAL_DNSSEC_TA attributes received over IKE.  Such clients MAY
    interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
    whitelisted domain as an indication that their local configuration
    may need to be updated out of band.

We basically said this is too dangerous to only authenticate via IKE. So
now, you need to _also_ do a (remote) configuration update, which
presumbly involves some Enterprise management system or humans.

> public domain anyway? How is an implementer supposed to address this?

What we tried to say was that any generic domain open for any registrant
for registration should never be accepted. While if you are Red Hat,
maybe te TLD .redhat would be okay. (brand TLD vs generic TLD). I agree
that it is difficult to determine this. The idea of the whitelist is
that VPN clients will show/confirm/enable the listed DNS domains, so
that if Honest Paul's VPN service includes "gmail.com", the enduser can
freak out properly.

> wants to whitelist com. Do you want to allow this? [Y/N]" means?

Split-DNS is meant for Enterprise use of actual domains. If your auntie
works for Foo Inc., hopefully she can either have Foo's sysadmin
configure and install her VPN, or if the admin gives her some kind of
profile, auntie will be okay seeing "Your VPN provider Foo Inc. wants to
whitelist internal.foo.com" and she would be familiar with using the
internal.foo.com domain from the office.

Note that our text basically meant to say the IKE software should
probably never allow com/net/org/CCtld ever, but that would be difficult
to hardcode because we _still_ haven't fixed the PublicSuffix issue :/

> should be reviewed by DNSOP, but will leave it to Eric to make that call.

What is wavey?

It should not think about "through the VPN or not". We had that text
originally, but Tero pointed out a lot of Enterprise VPN's can come up
on demand. So the initial IKE negotiation could be for 10.1.2.3/32, and
include the DNS configuration for the internal auth servers on
192.168.1.1. It needs to configure the DNS so a packet for 192.1.1:53
triggers another IPsec tunnel to be setup.

So to use an unbound example, you only need to drop in the internal DS
record, and the "unbound-control forward example.com ip1 ip2"
configuration pointing to the internal auth servers for example.com.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Nov 2018 09:59:58 -0500

On Wed, Nov 21, 2018 at 12:22 AM Paul Wouters <[email-masked]> wrote:

> Split-DNS is meant for Enterprise use of actual domains.

If your auntie
> internal.foo.com domain from the office.

Yes, I get that the *intended* audience is Enterprises, and that usage
doesn't really scare me (most enterprise admins already have their fingers
sufficiently deep inside their employees machines that they can do
$whatever anyway).
My concerns is that this will also be used for the "Buy our VPN for secure
browsing of the torrentz - only $2.99 per month. Punch the monkey for a
discount!!!!!!!!!!" type people -- I trust my enterprise admins to not
DNSSEC / DANE poison me, but I don't necessarily trust (to pick  at random)
CyberGhostVPN -
https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2&
(I know nothing about this org!)

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 10:10:48 -0500 (EST)

>>  recursive, does it need to send the query to ns01 though the VPN or not?

I added some text that clarifies dependencies:

     Deployments that configure INTERNAL_DNS_DOMAIN domains should pay
    close attention to their use of indirect reference RRtypes in their
    internal-only domain names.  Examples of such RRtypes are CNAME,
    DNAME, MX or SRV records.  For example, if the MX record for
    "internal.example.com" points to "mx.internal.example.net", then both
    "internal.example.com" and "internal.example.net" should be sent
    using an INTERNAL_DNS_DOMAIN Configuration Payload.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 10:20:45 -0500 (EST)

On Wed, 21 Nov 2018, Warren Kumari wrote:

> Yes, I get that the *intended* audience is Enterprises, and that usage doesn't really scare me (most
> enterprise admins already have their fingers sufficiently deep inside their employees machines that they can
> do $whatever anyway).
> My concerns is that this will also be used for the "Buy our VPN for secure browsing of the torrentz - only
> $2.99 per month. Punch the monkey for a discount!!!!!!!!!!" type people -- I trust my enterprise admins to
> not DNSSEC / DANE poison me, but I don't necessarily trust (to pick  at random) CyberGhostVPN
> - https://offer.cyberghostvpn.com/en_US/trnt/rocket?aff_id=1392&coupon=FlashSale2&aff_sub4=FlashSale2&  (I
> know nothing about this org!)

These VPN services need to take ALL your network traffic. We now more
explicitly state INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA MUST be
ignored when the VPN configuration is not a split tunnel one.

This can still be abused by VPN service providers but it would require
some serious hacking since most remote access profiles will only offer
to set a source/dest IP tunnel for YourTempAssignedIP/32 <-> 0.0.0/0

That is, if you connect to vpn.nohats.ca, it will give you
193.111.157.66 as INTERNAL_IP4_ADDRESS and the IPsec policy will
cover 193.111.157.66/32 <-> 0.0.0.0/0 only. In which case our new
attributes are ignored. They could do something like:

193.111.157.66/32 <-> 0.0.0.0/128 to get their attribute accepted, but
the VPN would not work for half the internet. Of course, if their only
goal is to screw you over and get your gmail.com traffic on 172.217.1.165,
then giving you 172.217.0.0/16 would work and all your other traffic
would simply go out in the clear. And if you accept their provisioning
profile, they could also override TLSA records.

We tried to close all of this as much as possible so that you can still
use enterprise split tunnel with DNS while making it as hard as possible
for VPN services to not abuse this. But in the end, it all depends on
how badly you want your VPN service to see cute kittens.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 11:00:43 -0500

Warren, I see your concern, but I don't think it's much of an in practice.

    > censorship / content restrictions, or to improve their privacy. These are not

Sadly, very few regular users use IPsec/IKEv2 for this kind of access.
So, really, this comment applies to a vanishing few number of people.
(There are a few:  Openswan is run by at least one big one to provide
IPsec/IKEv2 access, but I note that they provide 5 other protocols as well).

In almost all cases the VPN provider is in control of the software that is
installed on the client system, so they can hijack paypal already.
Few support IPv6 or DNSSEC for the VPN either.  Some are effectively HTTPS
proxies only, so ALG gateways, with HTTPS certificate evaluation done by the
VPN provider.  This is not much of a new threat.

In the remote cases where a user uses IPsec/IKEv2, and configures it
themselves (perhaps from instructions), then they could easily omit the:
  trust-ikev2-internal-dns=true
configuration option.  In the case where they don't configure it themselves,
then DNSSEC would get hijacked at configuration time, does not matter what
the protocol does.

****
Where I think there may be issues is when one has a non-technical consultant
who has an Enterprise-VPN to *two* customers, that the two Enterprises could
arrange to do things to each other via the cross-site scripting via the
consultant.

I think the document does a good job of making it clear that there
are issues the client implementer needs to worry about.
****

But, this seems terribly unlikely since just getting two VPNs installed
(and compatible) and running at the same time is such deep VPN-fu, that it's
like only half the IPsec WG members that could ever make this work anyway.

    > wants to whitelist com. Do you want to allow this? [Y/N]" means?

If she managed to install the TrustVPN herself, then I think yes.
Otherwise, she is going to call whomever installed the thing (I guess you),
and ask them.

{I think walled-garden DNS (whether for Enterprise use or IPTV) is security
threatre myself.  IPv6 is here, use it, and stop building coconut networks.}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Nov 2018 11:04:34 -0500

On Wed, Nov 21, 2018 at 10:20 AM Paul Wouters <[email-masked]> wrote:

> doesn't really scare me (most
> > -
> the VPN would not work for half the internet.

So, what my (OpenVPN) client seems to do is send:
193.111.157.66 <-> 0.0.0.0/1
193.111.157.66 <-> 128.0.0.0/1

This "overrides" my default of 0.0.0.0/0, and (depending on how you read
things) could be considered a split tunnel, but with both sides routed
through the tunnel.
You could also do silly things like:
193.111.157.66 <-> 0.0.0.0/1
193.111.157.66 <-> 128.0.0.0/2
193.111.157.66 <-> 192.0.0.0/3
193.111.157.66 <-> 224.0.0.0/4
(I think that this covers basically all space except 240.0.0.0, but I
haven't had any coffee yet).

> Of course, if their only
> for VPN services to not abuse this.

Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to do
this through "normal" enterprise tools methods this would work.
(It started writing that the zone could also be unsigned, but that
obviously doesn't work in the case of non-delegated "TLDs"...)

W

> But in the end, it all depends on

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 23:32:19 +0700

> Sadly, very few regular users use IPsec/IKEv2 for this kind of access.

This is very incorrect.

Almost all VPN providers for apple (OSX and iOS) use IKEv2 with CP. Based on numbers of concurrent users I have seen from some vendors using libreswan, we are talking in the orders of 100’s of thousands of users.

And more and more Windows L2TP/IPsec and XAUTH deployments are moving to IKEv2. 

One of the main reasons: MOBIKE with phones using wifi and 4/5G and network switching.

For Android, the situation is bad. Due to the OS not properly supporting IKEv2, most VPN services bundle openvpn apps for android and very few bundle strongswan with its userland ESP that can do IKEv2.

> installed on the client system, so they can hijack paypal already.

This is also incorrect. All OSX and iOS provisioning happens via .mobileconfig profiles or apps using apple API’s that are equivalent. None of their apps can do weird things like hijacking paypal.com domain other then modifying the DNS stream after IPsec decryption. Any installed root CA as part of the VPN provisioning is limited to that VPN profile only and does not affect HTTPS.

> Few support IPv6 or DNSSEC for the VPN either.

That is correct but with SNAFUs like NAT64 breaking IPsec the telcos have helped greatly in that situation being addressed for IPv6.

> are issues the client implementer needs to worry about.

I have improved the text but I am waiting for my co-author to proofread and agree to my changes. It hopefully addresses Warrens concerns as best we can.

> like only half the IPsec WG members that could ever make this work anyway.

It is currently uncommon indeed but I think and hope we will see more of this, especially when we all want a continuous VPN link up to our home network.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 11:36:18 -0500

> ignored when the VPN configuration is not a split tunnel one.

And, there is no reason for this kind of VPN service to have any
INTERNAL_DNS_DOMAIN, so it would be reasonable for a well configured client
to simply ignore such things.

(It's not like they have .internal or .corp for you...
Some of the services offer virtual corporation services, but that's really
a different kettle of fish)

---

From: "D. Hugh Redelmeier" <[email-masked]>
Date: Wed, 21 Nov 2018 11:40:42 -0500 (EST)

| From: Michael Richardson <[email-masked]>

| In almost all cases the VPN provider is in control of the software that is
| installed on the client system, so they can hijack paypal already.

VPN providers should not provide software to their clients.  That's a
bug and should not be encouraged by the committee.

The point of a standard is that any IPSec implementation should be
able to connect with any other IPsec implementation.  The default
provider of VPN software ought to be the provider of the OS for the
client's machine.  The client should be able to choose any conformant 
implementation.  I admit that we have failed to make interop easy
and normal, but that's where we should be heading.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 23:41:55 +0700

On Nov 21, 2018, at 23:04, Warren Kumari <[email-masked]> wrote:
> 
>> 
> 
> Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to do this through "normal" enterprise tools methods this would work.

That is basically what we did with the mandatory white list, except now the internal zones can still do rollovers without locking out all VPN clients that haven’t recently done some (automatic or manual) provisioning update that isn’t standardized.

And in the end, if a user treats/trusts a generic VPN service provider the same as an enterprise provisioning system, then we cannot define them to be different. That is, whatever you define as out of band, non-ike enterprise provisioning with be equally weak to this attack if provided by the generic VPN provider. Kittens all the way down.

Paul

> (It started writing that the zone could also be unsigned, but that obviously doesn't work in the case of non-delegated "TLDs"...)
> 
> W
> 
>  
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 23:53:20 +0700

> On Nov 21, 2018, at 23:40, D. Hugh Redelmeier <[email-masked]> wrote:
> 

And you can see the security nightmare it causes in the Android Play Store with zillions of (un?)modified openvpn code that no one knows what it exactly does.

Where as with Apple, the VPN apps provide a custom UI to the user but it is all using the systems IKE/IPsec stack and the standard VPN was information tools of the OS can be used to see what the VPN configuration is (currently not for the DNS settings but a bug report has been verbally submitted for this a while ago :) 

> client's machine.

+1

>  The client should be able to choose any conformant 
> implementation.

For opensource based solutions, sure. For proprietary devices I would hope they just ship with only one implementation.

> I admit that we have failed to make interop easy

It is getting much better compared to what we had for IKEv1 (with PFS and rekey issues being the main thing I see going wrong)

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Nov 2018 12:03:44 -0500

So, I'm still fairly uncomfortable - having a VPN provider able to override
my DNSSEC configuration worries me, especially if things like TLSA / DNSSEC
Chain Extension / similar are used.
I was starting to come to terms with this, as I'd assumed that the common
deployment scenario was "Install (as root / admin) this binary package
containing a VPN client.", in which case a malicious VPN provider already
has the ability to do, well, basically anything (and doesn't need this
method to be malicious), but if this isn't the universal case, I'm
concerned again...

A number of other IESG folk were also concerned - as a compromise, I'm
going to ask DNSOP to have a look at the document (it is, after all, quite
DNS related) and get their feedback.
I am sympathetic to the general use case, but really don't want this to
open scary security holes / decrease "trust" in DNSSEC.

W

On Wed, Nov 21, 2018 at 11:42 AM Paul Wouters <[email-masked]> wrote:

> Well, if you removed the DNSSEC_TA bit, and expected enterprise tools to
> do this through "normal" enterprise tools methods this would work.
>
>
> That is basically what we did with the mandatory white list, except now
> the internal zones can still do rollovers without locking out all VPN
> clients that haven’t recently done some (automatic or manual) provisioning
> update that isn’t standardized.
>
> And in the end, if a user treats/trusts a generic VPN service provider the
> same as an enterprise provisioning system, then we cannot define them to be
> different. That is, whatever you define as out of band, non-ike enterprise
> provisioning with be equally weak to this attack if provided by the generic
> VPN provider. Kittens all the way down.
>
> Paul
>
>
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Nov 2018 00:55:34 +0700

On Nov 22, 2018, at 00:03, Warren Kumari <[email-masked]> wrote:
> 
> 
> 
> I am sympathetic to the general use case, but really don't want this to open scary security holes / decrease "trust" in DNSSEC.

By not allowing VPNs to use an enterprise internal dnssec trust anchor, you also erode trust in dnssec, or end up not using dnssec internally at all when connected via VPN.

I suggest you wait for me to push -15 before asking dnsop. It should be out today or tomorrow and contains quite some changes related to this topic.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Nov 2018 12:57:59 -0500

On Wed, Nov 21, 2018 at 12:55 PM Paul Wouters <[email-masked]> wrote:

> By not allowing VPNs to use an enterprise internal dnssec trust anchor,
> you also erode trust in dnssec, or end up not using dnssec internally at
> all when connected via VPN.
>
>
True.

> I suggest you wait for me to push -15 before asking dnsop. It should be
> out today or tomorrow and contains quite some changes related to this topic.
>

Okey dokey, thank you.
Please let me know LOUDLY when you have a new version ready (I don't want
it to get lost in the post IETF103 / US Thanksgiving holiday / similar
shuffle).

W

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 13:18:36 -0500

{sorry to re-interate, and/or beat what might be a dead horse already}

Warren Kumari <[email-masked]> wrote:
    > So, I'm still fairly uncomfortable - having a VPN provider able to
    > override my DNSSEC configuration worries me, especially if things like
    > TLSA / DNSSEC Chain Extension / similar are used.
    > I was starting to come to terms with this, as I'd assumed that the
    > common deployment scenario was "Install (as root / admin) this binary
    > package containing a VPN client.", in which case a malicious VPN
    > provider already has the ability to do, well, basically anything (and
    > doesn't need this method to be malicious), but if this isn't the
    > universal case, I'm concerned again...

It's more of the: "Install (as root / admin) this binary package containing
                  an *IKEv2* VPN client."
and this just does not apply to 90% of the non-Enterprise use cases, because
they aren't using IKEv2 anyway.

The places where you should have a concern are:
  1) iOS, Android phones,   Linux/MacOS desktops,   running the OS-provided
     IKEv2/IPsec client.
  2) installing an opaque (to the end user) configuration blob.
     - configuration blob enables DNSSEC and INTERNAL_DNS configuration support
  3) connecting to a non-Enterprise VPN supplier, or to an Enterprise that
     does not already own (p0wn) the device you are using (i.e. BYOD).

I omit windows desktop VPN (even if it's IPsec), because in practice there is
always a binary install of some kind, despite decades of trying to do otherwise.
(This in itself should make the IESG sad)

Note if (2) is not true, that is, the end user is loading .p12 files, and
setting up policies in some semi-manual fashion (IKEv2 lets us automate a
great deal of the policy), then the dialog ought to have some way for a
knowledgeable user to decline and/or whitelist the DNSSEC overrides.
A non-knowledgeable user is going to be loading a configuration blob.
Potentially, there might be validation on the contents of that, and whatever
DNSSEC whitelisting is going to occur.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 13:25:29 -0500

> Almost all VPN providers for apple (OSX and iOS) use IKEv2 with
    > CP. Based on numbers of concurrent users I have seen from some vendors
    > using libreswan, we are talking in the orders of 100’s of thousands of
    > users.

That's awesome news to learn!!!
I haven't seen this in the wild myself, and it's not the case in Android as
you point out.

    > One of the main reasons: MOBIKE with phones using wifi and 4/5G and

So that's a good really good result.  Kudos.
Sometimes the tortoise does win the race with better technology.

    > For Android, the situation is bad. Due to the OS not properly
    > supporting IKEv2, most VPN services bundle openvpn apps for android and
    > very few bundle strongswan with its userland ESP that can do IKEv2.

I'm aware that they (Android) were thinking about fixing this, but nothing
has happened yet to my knowledge.

    > This is also incorrect. All OSX and iOS provisioning happens via
    > .mobileconfig profiles or apps using apple API’s that are

I'm talking here about people using VPNConnect, OpenConnect, some .MSI that
actually installs OpenVPN on windows, etc.

    > It is currently uncommon indeed but I think and hope we will see more
    > of this, especially when we all want a continuous VPN link up to our
    > home network.

I also want it to be easier.

I see IPv6 for the Enterprise remote-access VPN as instrumental to making
this happen.  Each Enterprise can embed their IPv4 RFC1918 address space into
a unique IPv6 prefix, and can NAT64 to get to actual internal legacy services
if they have to.

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 21 Nov 2018 15:55:28 -0500

> I haven't seen this in the wild myself, and it's not the case in Android as

FWIW, I use Private Interent Access (privateinternetaccess.com), and
while it's "user friendly Linux install is effectively "curl | sudo
/bin/sh" it did have a manual install procedure, and all the manual
install procedure did was install the package
network-manager-openvpn-gnome and then make configuration changes to
Network Manager so it new where to find the PIA servers.

So yes, no VPN software was downloaded, and while you could argue that
if most users are trusting a "curl .... | sudo /bin/sh" install, there
are plenty of ways for a VPN provider to completely take over your
machine (never mind your DNS!), at least a security expert can audit
the script, and someone who is sufficiently paranoid can run the
commands and/or edit the config files by hand.

Cheers,

						- Ted