<div dir="ltr">Hey Noel,<div> I understand the security implications, as mentioned here: <a href="https://bluebox.com/technical/questioning-the-chain-of-trust-investigations-into-the-root-certificates-on-mobile-devices/" target="_blank">https://bluebox.com/technical/questioning-the-chain-of-trust-investigations-into-the-root-certificates-on-mobile-devices/</a><div>But I have no other way to get this working for clients without asking them to run through a long installation process.</div><div><br></div><div>I now have it working, but when I disable BYOD (no libtncss, libtncnif, or libimcv) in the Android client, it no longer works.<br></div></div><div>Any ideas? I see the messages:</div><div><div>12-06 15:19:41.844 2184-2308/ I/charon﹕ 06[ENC] proposal number smaller than previous</div><div>12-06 15:19:41.844 2184-2308/ I/charon﹕ 06[ENC] SECURITY_ASSOCIATION payload verification failed</div><div>12-06 15:19:41.844 2184-2308/ I/charon﹕ 06[IKE] message verification failed</div></div><div>on the server</div><div>and on the client, it seems to be stuck generating IKE_SA_INIT instead of IKE_AUTH requests.<br></div><div><br></div><div>Are those libraries required?</div><div><br></div><div>regards,</div><div>imran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 11:44 AM, Noel Kuntze <span dir="ltr"><<a href="mailto:noel@familie-kuntze.de" target="_blank">noel@familie-kuntze.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hello Imran,<br>
<br>
</span>Using a trusted root CA would mean, that you have to trust a third party with access to your gateway.<br>
An attacker could very well be in the network path between the client and the gateway, hence you need<br>
to make sure he can't get a valid certificate. Trust between the client and the gateway is created over ...<br>
1) the CN of the DN of the certificate it presents that matches the name the client tries to connect to<br>
2) any SAN value in the certificate that matches the name the client tries to connect to<br>
3) the signature of a trusted third party on the certificate<br>
<br>
Controlling access to the trusted third party's certficate means controlling which certificates get<br>
issued. By using another company to issue your server certificate, you trust them to keep you safe.<br>
<br>
Sadly, the CA system has proven to be somewhat untrustworthy, as a lot of hacks of CAs showed.<br>
<span class=""><br>
<br>
Mit freundlichen Grüßen/Regards,<br>
Noel Kuntze<br>
<br>
GPG Key ID: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
</span>Am 05.12.2014 um 20:39 schrieb Imran Akbar:<br>
> Hey Noel,<br>
><br>
<span class="">> Do you mean using a trusted root CA certificate on Android will allow a MITM attack if someone tries to impersonate our gateway? But if we restrict clients to only connect to our gateway - and not others signed by the same CA, would that still be an issue?<br>
> The VPN itself doesn't have access to any protected resources - which is why I'm not worried about the lack of a PIN code on devices. It's ease of use that I'm aiming for.<br>
><br>
> yours,<br>
> imran<br>
><br>
</span><span class="">> On Fri, Dec 5, 2014 at 11:15 AM, Noel Kuntze <<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a> <mailto:<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a>>> wrote:<br>
><br>
><br>
> Hello Imran,<br>
><br>
> I strongly recommend NOT doing that, as the clients would then trust any server with a certificate of the CA<br>
> and try to authenticate against them with their credentials, which may expose them to attackers.<br>
> Also, you should really advise your clients to set up pin code authentication to their phone's home screen, as<br>
> an individual getting their hands on on a client's phone would get access to the VPN, if the phone wasn't locked with a code.<br>
><br>
> You might want to use a p12 file then to make this easier. See this website [1] for an example command to create one.<br>
> The clients can get it sent by email and they just need to open it and accept the certificates.<br>
> I'm sorry for the last email. It seems I experienced a bug with enigmail on Thunderbird.<br>
><br>
> [1] <a href="https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)#PKCS12-file" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)#PKCS12-file</a><br>
><br>
> Mit freundlichen Grüßen/Regards,<br>
> Noel Kuntze<br>
><br>
> GPG Key ID: 0x63EC6658<br>
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
><br>
> Am 05.12.2014 um 19:53 schrieb Imran Akbar:<br>
> > Hey Noel,<br>
><br>
> > thanks for your continued help.<br>
> > I generated a self-signed CA on my server and put it into the correct directories.<br>
><br>
> > While I can (and have previously) installed the CA certificate myself on the Android client, I don't want the other users who aren't as tech-savvy to have to do this step. It also requires them to set up a PIN code for their phone's home screen, which not everyone wants to have to do.<br>
><br>
> > If I used a paid, non-self-signed CA certificate that's tied back to one of the root certificates already installed on Android, would that solve this issue?<br>
><br>
> > regards,<br>
> > imran<br>
><br>
><br>
><br>
><br>
><br>
</span><span class="">> > On Fri, Dec 5, 2014 at 10:19 AM, Noel Kuntze <<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a> <mailto:<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a>> <mailto:<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a> <mailto:<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a>>>> wrote:<br>
><br>
><br>
> > Hello Imran,<br>
><br>
> > Do you have a CA? You need to have your CA installed on all devices.<br>
><br>
> > Try adding the DNS name you're connecting to in an additional SAN field by adding --san DNSNAME to<br>
> > the ipsec pki command used to generate the server certificate.<br>
><br>
> > Mit freundlichen Grüßen/Regards,<br>
> > Noel Kuntze<br>
><br>
> > GPG Key ID: 0x63EC6658<br>
> > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
><br>
> > Am 05.12.2014 um 19:16 schrieb Imran Akbar:<br>
> > > I've gotten past that issue by ensuring I was using the IP when generating the certificates, as in:<br>
> > > <a href="http://endlessroad1991.blogspot.com/2014/04/setup-ipsec-vpn-on-ec2.html" target="_blank">http://endlessroad1991.blogspot.com/2014/04/setup-ipsec-vpn-on-ec2.html</a><br>
><br>
> > > but now the client cannot verify the server with the message "verifying gateway authentication failed"<br>
> > > and in the client log:<br>
> > > "no trusted RSA public key found for 'C=CN, O=strongSwan, CN=54.169.64.53'"<br>
><br>
> > > How can I verify the server without installing its public key on every client, or using a PSK (which the Android client doesn't support)?<br>
><br>
> > > thanks,<br>
> > > imran<br>
><br>
</span><div><div class="h5">> > > On Fri, Dec 5, 2014 at 9:04 AM, Imran Akbar <<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>>>>> wrote:<br>
><br>
> > > When I change the ipsec.conf from:<br>
> > > rightauth=psk<br>
> > > righauth2=eap-mschapv2<br>
><br>
> > > to:<br>
> > > rightauth=eap-mschapv2<br>
><br>
> > > the server log now contains:<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[CFG] looking for peer configs matching 172.31.26.153[%any]...172.56.39.247[app]<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[CFG] selected peer config 'android'<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[IKE] initiating EAP_IDENTITY method (id 0x00)<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[IKE] peer supports MOBIKE<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[CFG] no IDr configured, fall back on IP address<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[IKE] authentication of '172.31.26.153' (myself) with pre-shared key<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[ENC] generating IKE_AUTH response 1 [ IDr AUTH EAP/REQ/ID ]<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 14[NET] sending packet: from 172.31.26.153[4500] to 172.56.39.247[63277] (124 bytes)<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 15[NET] received packet: from 172.56.39.247[63277] to 172.31.26.153[4500] (76 bytes)<br>
> > > Dec 5 16:46:34 ip-172-31-26-153 charon: 15[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]<br>
><br>
> > > and I get a different error message in the client log:<br>
> > > no shared key found for 'app'<br>
><br>
> > > As I was never prompted for the PSK in the app, I'm guessing the Android client doesn't support it?<br>
> > > Therefore, the only way to get this working is for the server to authenticate with a certificate, it seems.<br>
> > > Which isn't working, as it's not parsing my private key properly.<br>
><br>
> > > thanks,<br>
> > > imran<br>
><br>
</div></div><div><div class="h5">> > > On Fri, Dec 5, 2014 at 8:41 AM, Imran Akbar <<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a> <mailto:<a href="mailto:skunkwerk@gmail.com">skunkwerk@gmail.com</a>>>>> wrote:<br>
><br>
> > > Hey Thomas,<br>
><br>
> > > Here's my latest attempt to get a setup working without requiring client certificates.<br>
><br>
> > > Client is Strongswan Android, server is running Strongswan 5.2.2 on a fresh Ubuntu 14 server on EC2 with UDP ports 500 and 4500 opened.<br>
> > > Client is connecting via IKEv2 username/password.<br>
><br>
> > > Is PSK the same as the "EAP username/password" option in the Strongswan android client? I have a feeling it's not, ie this config will not work for EAP-MSCHAPv2: <a href="http://www.strongswan.org/uml/testresults/ikev2/rw-psk-ipv4/" target="_blank">http://www.strongswan.org/uml/testresults/ikev2/rw-psk-ipv4/</a><br>
><br>
> > > But there's no documentation on a version of this one without the gateway authenticating via a RSA key:<br>
> > > <a href="http://www.strongswan.org/uml/testresults/ikev2/rw-eap-mschapv2-id-rsa/" target="_blank">http://www.strongswan.org/uml/testresults/ikev2/rw-eap-mschapv2-id-rsa/</a><br>
><br>
> > > I've tried with the gateway authenticating itself using a certificate, and with PSK - both have the same error:<br>
> > > *"peer requested EAP, config inacceptable"*<br>
><br>
> > > In addition, the gateway seems unable to parse my private server key:<br>
> > > *building CRED_PRIVATE_KEY - RSA failed*, tried 5 builders<br>
> > > Dec 5 16:15:13 ip-172-31-26-153 charon: 00[CFG] loading private key from '/etc/ipsec.d/private/serverKey.pem' failed<br>
> > > even though I see openssl, pkcs1, and pem in my plugins - though I'm not sure which ones weren't loaded, as it doesn't say in the log.<br>
><br>
> > > attempt 1 - with gateway using public key:<br>
> > > ipsec.conf: <a href="https://pastee.org/z8234" target="_blank">https://pastee.org/z8234</a><br>
> > > ipsec.secrets: <a href="https://pastee.org/mva6t" target="_blank">https://pastee.org/mva6t</a><br>
> > > server log: <a href="https://pastee.org/t2ahc" target="_blank">https://pastee.org/t2ahc</a><br>
><br>
> > > attempt 2 - with gateway using PSK:<br>
> > > ipsec.conf: <a href="https://pastee.org/f4fbp" target="_blank">https://pastee.org/f4fbp</a><br>
> > > ipsec.secrets: <a href="https://pastee.org/mva6t" target="_blank">https://pastee.org/mva6t</a><br>
> > > server log: <a href="https://pastee.org/6yd8q" target="_blank">https://pastee.org/6yd8q</a><br>
><br>
> > > Can someone please help?<br>
><br>
> > > thanks,<br>
> > > imran<br>
><br>
</div></div><div><div class="h5">> > > On Thu, Dec 4, 2014 at 3:21 AM, Thomas <jk@c.vu <mailto:<a href="mailto:jk@c.vu">jk@c.vu</a> <mailto:<a href="mailto:jk@c.vu">jk@c.vu</a>> <mailto:<a href="mailto:jk@c.vu">jk@c.vu</a> <mailto:<a href="mailto:jk@c.vu">jk@c.vu</a>>>>> wrote:<br>
><br>
> > > Hi,<br>
><br>
> > > ok, so I have to change my EAP-MSCHAPv2 configuration.<br>
> > > I've tested a lot, but don't find any ipsec-configuration where the<br>
> > > client don't need the certificate installed local.<br>
><br>
> > > Do you have any ideas based on my posted ipsec.conf ?<br>
><br>
> > > Best regards<br>
> > > Thomas<br>
><br>
> > > Am 04.12.2014 10:40, schrieb Martin Willi:<br>
> > > > Hi,<br>
> > > ><br>
> > > >> Any idea whats the best authentication method for username/password only<br>
> > > >> on client-side? EAP-MD5?<br>
> > > >> The client should be able to connect via windows ikev2 native clients,<br>
> > > >> the strongswan android-app,<br>
> > > > If you want to use the native Windows IKEv2 Agile VPN client, there is<br>
> > > > no way around EAP-MSCHAPv2 for username/password authentication. You<br>
> > > > could wrap that in PEAP/TTLS, but that most likely makes no sense for<br>
> > > > your setup. The Android App supports EAP-MSCHAPv2 as well. Refer to [1]<br>
> > > > for configuration details.<br>
> > > ><br>
> > > >> and the native clients from osx/ios.<br>
> > > > OS X does not natively support IKEv2. You'd have to stick to IKEv1 with<br>
> > > > XAuth, so you need a separate configuration profile. Please note that<br>
> > > > there are rekeying issues with that client, which usually breaks the<br>
> > > > tunnel after ~45 minutes if you rely on username/passwords. Refer to [2]<br>
> > > > for configuration details.<br>
> > > ><br>
> > > > iOS supports IKEv2 since version 8, older versions support IKEv1 only.<br>
> > > > Refer to [3] for details about deploying configuration profiles.<br>
> > > ><br>
> > > > Regards<br>
> > > > Martin<br>
> > > ><br>
> > > > [1]<a href="https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#C-Authentication-using-EAP-MSCHAP-v2" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#C-Authentication-using-EAP-MSCHAP-v2</a><br>
> > > > [2]<a href="https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/IOS_(Apple)</a><br>
> > > > [3]<a href="https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile" target="_blank">https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile</a><br>
> > > ><br>
> > > ><br>
><br>
> > > _______________________________________________<br>
> > > Users mailing list<br>
</div></div>> > > <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>>> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>>>><br>
<span class="">> > > <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> > > _______________________________________________<br>
> > > Users mailing list<br>
> > > <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>>><br>
> > > <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
> > _______________________________________________<br>
> > Users mailing list<br>
> > <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>>><br>
> > <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
</span><span class="">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQIcBAEBCAAGBQJUggsWAAoJEDg5KY9j7GZY9IAP/2wwgZbTFK9g//cgkGVuZEiZ<br>
0acNBiqV7iUWGxmfvHACB9vOGX2Q5SW50L7xwg1w/AlXFWyOKGsnBXa0Qbqgy7cD<br>
Dej2VJ/Ehe4sDM3U1SFwbNzk2R/guu7j6atHcz7EyNq8/vTjgIebVmvPSwCxbDG1<br>
VFRL/vbItc1bEA+do/cHntfntLUz2BExneYD8HAInHMh+KZxzABYFwuKxfNadnk3<br>
8h9xmJaH7S00QjVYVWQfLrab25yO78pXJ6YfWQlCmljbYqPbNrBYX3VFrOX2dqmi<br>
k3bk5z0GMPHpDA+4cvdee/JOWRUEBHKYz1kMP+7/cJnGUcqiTsJphJRCuPMAnz/j<br>
XtyxVHn4IWvfyx9mLZAIkW3ocS8GDH9yQnOxYwOJuAkG4Uo7VLoE6xpfD0OhvZ0M<br>
ylais6sycb2VYaP/gnP6j6p70D1G2t4YT2tspzjM1yTaxEGmO496uaLx+qVBN1zA<br>
bwnmC1zlLH/+rkiP1hLQpMEpN1Ituv7Fq/rpaTVxgmR79EJnmMsQlV1xn5Mc+v6a<br>
/1zDwbfG8vpZldx3U+VcogwcOOWOk7EpM/aKler3TTfcFgaQ7jpZFZdwvnS8MuOF<br>
I0+XNhF4omLoTqIdZc1/pgGcXidAx8YdzILmJh9Le8Vs74yEj5W3/NrAuSYMu1X+<br>
zxOivwIo/aXCJES63xUT<br>
=0zwR<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
</blockquote></div><br></div>