[strongSwan] New Android update option - how to best exploit?
Karl Denninger
karl at denninger.net
Wed Jul 5 16:02:47 CEST 2017
On 7/5/2017 02:47, Tobias Brunner wrote:
> Hi Karl,
>
>> 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.
> If you tried the import option in the CA certificate view of the app and
> it doesn't show up, the mime-type is probably not set correctly (if it
> is set correctly the strongSwan app should actually show up when trying
> to open that file e.g. in the Downloads app). If it does show up in the
> file browser but the import fails, the file might be corrupt.
It does show up in the StrongSwan import option and in the browser, and
it's the same file that ipsec listcerts says is good on the server end
(and it works).
The issue appears to be that there can be no text in front of the "BEGIN
CERTIFICATE" line. Nasty, but once I removed it I was able to import
the cert.
>> 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.)
> That's the one. After you imported the server cert into the app you can
> select it as a "CA certificate" (you basically set the certificate to
> use as trust anchor during authentication).
Got it.
>> 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.
> Are you talking about IKE or IP fragments? How big is the IKE_AUTH
> response?
~1728 bytes. Just big enough to screw me:
Jul 4 21:35:50 IpGw charon: 11[ENC] generating IKE_AUTH response 1 [
IDr CERT A
UTH CPRP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP)
N(ADD_4
_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Jul 4 21:35:50 IpGw charon: 11[ENC] splitting IKE message with length
of 1728 b
ytes into 2 fragments
Jul 4 21:35:50 IpGw charon: 11[ENC] generating IKE_AUTH response 1 [
EF(1/2) ]
Jul 4 21:35:50 IpGw charon: 11[ENC] generating IKE_AUTH response 1 [
EF(2/2) ]
Jul 4 21:35:50 IpGw charon: 11[NET] sending packet: from
68.1.57.197[4500] to 1
72.58.144.228[22528] (1236 bytes)
Jul 4 21:35:50 IpGw charon: 11[NET] sending packet: from
68.1.57.197[4500] to 1
72.58.144.228[22528] (564 bytes)
With the server cert successfully imported the connection almost comes
up -- however, it fails here now (client log):
Jul 5 08:51:48 00[DMN] Starting IKE charon daemon (strongSwan 5.5.3, Android 6.0.1 - AAL158/2017-05-05, BBA100-1 - blackberry/argonamericas/BlackBerry, Linux 3.18.20, aarch64)
Jul 5 08:51:48 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey chapoly curve25519 pkcs1 pkcs8 pem xcbc hmac socket-default revocation eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
Jul 5 08:51:48 00[JOB] spawning 16 worker threads
Jul 5 08:51:48 06[LIB] signature scheme RSA_EMSA_PKCS1_SHA2_256 not supported in EC
Jul 5 08:51:48 06[CFG] loaded user certificate 'C=US, ST=Florida, O=Cuda Systems LLC, CN=karl.ecdsa at denninger.net' and private key
Jul 5 08:51:48 06[CFG] loaded CA certificate 'C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda Systems LLC CA'
Jul 5 08:51:48 06[IKE] initiating IKE_SA android[2] to 68.1.57.197
Jul 5 08:51:48 06[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 5 08:51:48 06[NET] sending packet: from 192.0.0.5[39710] to 68.1.57.197[500] (746 bytes)
Jul 5 08:51:48 09[NET] received packet: from 68.1.57.197[500] to 192.0.0.5[39710] (38 bytes)
Jul 5 08:51:48 09[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Jul 5 08:51:48 09[IKE] peer didn't accept DH group ECP_256, it requested CURVE_25519
Jul 5 08:51:48 09[IKE] initiating IKE_SA android[2] to 68.1.57.197
Jul 5 08:51:48 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 5 08:51:48 09[NET] sending packet: from 192.0.0.5[39710] to 68.1.57.197[500] (714 bytes)
Jul 5 08:51:48 11[NET] received packet: from 68.1.57.197[500] to 192.0.0.5[39710] (267 bytes)
Jul 5 08:51:48 11[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
Jul 5 08:51:48 11[IKE] local host is behind NAT, sending keep alives
Jul 5 08:51:48 11[LIB] signature scheme RSA_EMSA_PKCS1_SHA2_256 not supported in EC
Jul 5 08:51:48 11[IKE] received cert request for "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda Systems LLC CA"
Jul 5 08:51:48 11[IKE] authentication of 'C=US, ST=Florida, O=Cuda Systems LLC, CN=karl.ecdsa at denninger.net' (myself) with ECDSA_WITH_SHA512_DER successful
Jul 5 08:51:48 11[IKE] sending end entity cert "C=US, ST=Florida, O=Cuda Systems LLC, CN=karl.ecdsa at denninger.net"
Jul 5 08:51:48 11[IKE] establishing CHILD_SA android
Jul 5 08:51:48 11[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) AUTH CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Jul 5 08:51:48 11[ENC] splitting IKE message with length of 2016 bytes into 2 fragments
Jul 5 08:51:48 11[ENC] generating IKE_AUTH request 1 [ EF(1/2) ]
Jul 5 08:51:48 11[ENC] generating IKE_AUTH request 1 [ EF(2/2) ]
Jul 5 08:51:48 11[NET] sending packet: from 192.0.0.5[44975] to 68.1.57.197[4500] (1364 bytes)
Jul 5 08:51:48 11[NET] sending packet: from 192.0.0.5[44975] to 68.1.57.197[4500] (724 bytes)
Jul 5 08:51:49 12[NET] received packet: from 68.1.57.197[4500] to 192.0.0.5[44975] (480 bytes)
Jul 5 08:51:49 12[ENC] parsed IKE_AUTH response 1 [ IDr AUTH CPRP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Jul 5 08:51:49 12[LIB] signature scheme RSA_EMSA_PKCS1_SHA2_256 not supported in EC
Jul 5 08:51:49 12[CFG] using trusted ca certificate "C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda Systems LLC CA"
Jul 5 08:51:49 12[CFG] checking certificate status of "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis-ecdsa.denninger.net"
Jul 5 08:51:49 12[LIB] building CRED_CERTIFICATE - OCSP_REQUEST failed, tried 0 builders
Jul 5 08:51:49 12[CFG] generating ocsp request failed
Jul 5 08:51:49 12[CFG] ocsp check failed, fallback to crl
Jul 5 08:51:49 12[CFG] certificate status is not available
Jul 5 08:51:49 12[CFG] reached self-signed root ca with a path length of 0
Jul 5 08:51:49 12[CFG] using trusted certificate "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis-ecdsa.denninger.net"
Jul 5 08:51:49 12[IKE] authentication of 'C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis-ecdsa.denninger.net' with ECDSA_WITH_SHA384_DER successful
Jul 5 08:51:49 12[CFG] constraint check failed: identity 'genesis.denninger.net' required
Jul 5 08:51:49 12[CFG] selected peer config 'android' inacceptable: constraint checking failed
Jul 5 08:51:49 12[CFG] no alternative config found
Jul 5 08:51:49 12[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Jul 5 08:51:49 12[NET] sending packet: from 192.0.0.5[44975] to 68.1.57.197[4500] (80 bytes)
BTW is the OCSP check failure due to lack of "curl" support in the
Android client?
In any event the failure there appears to be wrong as the "CN" has to be
set differently to the RSA's CN or the cert won't certify by the CA (due
to being a duplicate); the SAN DNS field IS correct (genesis.denninger.net)
X509v3 Subject Alternative Name:
email:postmaster at denninger.net, DNS:genesis.denninger.net
X509v3 Extended Key Usage:
TLS Web Server Authentication
I will try it with the RSA certificate:
Uh, nope. Same problem with the same log entry from the client.
....
Jul 5 09:00:21 12[CFG] checking certificate status of "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net"
Jul 5 09:00:21 12[LIB] building CRED_CERTIFICATE - OCSP_REQUEST failed, tried 0 builders
Jul 5 09:00:21 12[CFG] generating ocsp request failed
Jul 5 09:00:21 12[CFG] ocsp check failed, fallback to crl
Jul 5 09:00:21 12[CFG] certificate status is not available
Jul 5 09:00:21 12[CFG] reached self-signed root ca with a path length of 0
Jul 5 09:00:21 12[CFG] using trusted certificate "C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net"
Jul 5 09:00:21 12[IKE] authentication of 'C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net' with RSA_EMSA_PKCS1_SHA2_256 successful
Jul 5 09:00:21 12[CFG] constraint check failed: identity 'genesis.denninger.net' required
Jul 5 09:00:21 12[CFG] selected peer config 'android' inacceptable: constraint checking failed
Jul 5 09:00:21 12[CFG] no alternative config found
Jul 5 09:00:21 12[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Jul 5 09:00:21 12[NET] sending packet: from 192.0.0.5[40957] to 68.1.57.197[4500] (80 bytes)
>> 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?)
> There is a registry key you can enable so it proposes a slightly better
> DH group [1].
>
> Regards,
> Tobias
>
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#AES-256-CBC-and-MODP2048
Thanks -- will look at that once I get this sorted... if I can get
Windows to *also* cut back the response size through a similar trick
(e.g. importing the gateway's cert into Windows' certificate store) I
might be able to get it to reliably come up.
--
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/20170705/b2660897/attachment-0001.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/20170705/b2660897/attachment-0001.bin>
More information about the Users
mailing list