[strongSwan] New Android update option - how to best exploit?

[Karl Denninger]

On 7/4/2017 03:49, Tobias Brunner wrote:
> Hi Karl,
>
>> What would be the /least /traffic-generating option for its use?  In
>> other words /exactly what either has to be on the client -- or sent from
>> the server -- for that switch to work?/
> The least traffic you get if you import the server certificate into the
> app and configure `leftsendcert=ifasked` (the default, `never` also
> works) on the server and then either disable the new option or
> explicitly select the server certificate as trusted certificate in the
> profile (that already worked in the older versions of the app).  Then no
> certificate request or certificate will be exchanged at all (unless you
> use client certs and the server sent a certificate request).
Except that I can't install the server's certificate into Android's
storage (whether from the base "Security" tab or in the StrongSwan
client); it refuses and says there's no certificate it can import. 
There's no "trusted" certificate option that I can find either in the
VPN setup on the StrongSwan Android client -- just the selection for
which CA cert to use (either automatic selection or you can pick from
the installed and trusted certificates.)

The CA certificate (private CA here) required for this installs ok (and
has been working pretty-much "forever") but there appears to be no way
to prevent the need to send the VPN server's certificate to the Android
phone client, which is where the problem is coming from.  Going to ECDSA
from an RSA certificate cut the fragments to 2 from 3, but I can't get
it to "1", which would remove the fragmentation problem with connection
setup.

The client phone's certificate (as a .p12 with a private key, either as
an RSA or ECDSA certificate) loads just fine.

> If you want to use the CA certificate instead of the server certificate
> on the client (in that case the server certificate has to be
> transmitted) either select that CA certificate in the profile (only one
> certificate request for that particular CA is then sent) or configure
> `leftsendcert=always` on the server and disable the new option in the
> profile then you don't have to select the CA cert (you still can to only
> trust that CA) and no certificate requests will be sent.
>
>>  Scratch that -- I don't know exactly how I got traffic to  route down the VPN in the past from a tethered client, but it's not doing it now..... so unless I can figure that out again the second part of the query is worthless.
> As far as I know tethering on Android does not work with VPNs unless you
> manually (or with an app) change the routing/firewall rules, which only
> works on rooted devices.
>
> Regards,
> Tobias
Yeah, that's a bummer because Windows' internal VPN has a number of
nasty "gotchas" that REALLY play hell with fragmentation issues -- it
wants to authenticate using EAP-TLS and while it works fine if there's
no fragmentation problem when there is it's just flat-out unusable --
which happens to be the case in virtually every tethered Android
circumstance I've run into.  Then of course there's the base Windows VPN
security issues to start with (e.g. the proposals it supports and such
-- or more to the point, the ones it doesn't) which, frankly leave me in
awe that our government appears at first blush to use it for
rather-secure things (or do they?)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170704/fbcc67f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170704/fbcc67f5/attachment.bin>