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

[Karl Denninger]

There is now a new "Send certificate requests" toggle available in the
Android client which defaults on and gives the old behavior.  The
switch's note is that it will only work if the server always sends
whatever cert(s) it needs, and that's true -- if it's off then it
doesn't work (at all) without changes on the server side.

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?/

A second (derivative) question is whether the StrongSwan android client
authors have considered the possibility of fixing the DNS issues that
arise if you tether behind an Android phone with StrongSwan up. 
Interestingly enough it appears you /can /ping and such, but DNS
resolution fails.

If that could be resolved then the (relatively common) Windows 10 issue
with IKE not being able to handle fragmentation (in the Windows client)
could be alleviated since the user could tether off their phone and have
StrongSwan run on the phone.  If you can then get the negotiation down
to where it doesn't have to fragment we now have killed two birds with
one stone!

This looks like a very interesting path forward that might require only
a modest amount of work on the StrongSwan Android client end.... but I'm
not sure whether you can actually pull off the DNS redirection from a
tethered device at that level.

Thoughts?

-- 
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/20170703/74e783d4/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/20170703/74e783d4/attachment.bin>