[strongSwan] What the blankety-blank-blank is Win10 doing? (now Android and ECDSA certs)
Karl Denninger
karl at denninger.net
Sat Jul 1 22:53:29 CEST 2017
On 6/30/2017 12:09, Karl Denninger wrote:
>
>
>
> On 6/26/2017 10:46, Tobias Brunner wrote:
>> Hi Karl,
>>
>>> StrongSwan never gets this packet. I assume the problem here is the
>>> length mismatch, but not certain. What is certain is that StrongSwan
>>> never sees it; no matter how far up I turn the logging I never see any
>>> evidence of it being logged.
>> Sounds like an IP fragmentation issue (message is too large -> gets
>> fragmented -> fragments get dropped on the way to the server -> server
>> never sees the complete message). Unfortunately, you can't do much
>> about that on Windows if you want to use certificates as the built-in
>> client does not support IKEv2 fragmentation, ECDSA certificates (which
>> are significantly smaller than RSA certificates), or omit the client
>> certificate, and the certificate requests can't be controlled either
>> (since a Windows system has more and more CA certificates installed over
>> time that list gets longer and longer the older a system is). The only
>> option to reduce the size of the IKE_AUTH message is to use EAP
>> authentication with username/password.
>>
>> Regards,
>> Tobias
> I've been unable to get an ECDSA certificate to import on my Android
> phone (BlackBerry DTEK60, Android 6.01) -- the same error occasionally
> bites me on the phone too during initial negotiation *some* of the
> time (looks like I got 3 fragments that have to be passed and one of
> them gets dropped often enough that the initial keying fails, which
> has to succeed before Ikev2 frag support helps.)
I got that sorted (don't include the curve parameters in the
certificate!) and now Android will import it.
But now, when that certificate is selected, StrongSwan doesn't seem to
want to *find* the certificate, even though it *does* verify as ok
against the CA that issued it, and it's in the "certs" directory..... I
get this:
Jul 1 15:19:24 NewFS charon: 16[NET] received packet: from
172.56.21.156[19485] to 192.168.10.100[500] (746 bytes)
Jul 1 15:19:24 NewFS charon: 16[ENC] parsed 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 1 15:19:24 NewFS charon: 16[IKE] 172.56.21.156 is initiating an IKE_SA
Jul 1 15:19:24 NewFS charon: 16[IKE] local host is behind NAT, sending
keep alives
Jul 1 15:19:24 NewFS charon: 16[IKE] remote host is behind NAT
Jul 1 15:19:24 NewFS charon: 16[IKE] DH group ECP_256 inacceptable,
requesting CURVE_25519
Jul 1 15:19:24 NewFS charon: 16[ENC] generating IKE_SA_INIT response 0
[ N(INVAL_KE) ]
Jul 1 15:19:24 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] to 172.56.21.156[19485] (38 bytes)
Jul 1 15:19:24 NewFS charon: 16[NET] received packet: from
172.56.21.156[19485] to 192.168.10.100[500] (714 bytes)
Jul 1 15:19:24 NewFS charon: 16[ENC] parsed 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 1 15:19:24 NewFS charon: 16[IKE] 172.56.21.156 is initiating an IKE_SA
Jul 1 15:19:24 NewFS charon: 16[IKE] local host is behind NAT, sending
keep alives
Jul 1 15:19:24 NewFS charon: 16[IKE] remote host is behind NAT
Jul 1 15:19:24 NewFS charon: 16[IKE] sending cert request for "C=US,
ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=Cuda Systems LLC CA"
Jul 1 15:19:24 NewFS charon: 16[ENC] generating 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 1 15:19:24 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] to 172.56.21.156[19485] (267 bytes)
Jul 1 15:19:25 NewFS charon: 16[NET] received packet: from
172.56.21.156[47709] to 192.168.10.100[4500] (1364 bytes)
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [ EF(1/2) ]
Jul 1 15:19:25 NewFS charon: 16[ENC] received fragment #1 of 2, waiting
for complete IKE message
Jul 1 15:19:25 NewFS charon: 16[NET] received packet: from
172.56.21.156[47709] to 192.168.10.100[4500] (756 bytes)
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [ EF(2/2) ]
Jul 1 15:19:25 NewFS charon: 16[ENC] received fragment #2 of 2,
reassembling fragmented IKE message
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [ IDi
CERT N(INIT_CONTACT) CERTREQ 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 1 15:19:25 NewFS charon: 16[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 1 15:19:25 NewFS charon: 16[LIB] building CRED_CERTIFICATE - X509
failed, tried 3 builders
Jul 1 15:19:25 NewFS charon: 16[CFG] looking for peer configs matching
192.168.10.100[%any]...172.56.21.156[C=US, ST=Florida, O=Cuda Systems
LLC, CN=karl.ecdsa at denninger.net]
Jul 1 15:19:25 NewFS charon: 16[CFG] selected peer config 'StrongSwan'
*Jul 1 15:19:25 NewFS charon: 16[IKE] no trusted ECDSA public key found
for 'C=US, ST=Florida, O=Cuda Systems LLC, CN=karl.ecdsa at denninger.net'*
Jul 1 15:19:25 NewFS charon: 16[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jul 1 15:19:25 NewFS charon: 16[IKE] peer supports MOBIKE
Jul 1 15:19:25 NewFS charon: 16[ENC] generating IKE_AUTH response 1 [
N(AUTH_FAILED) ]
Jul 1 15:19:25 NewFS charon: 16[NET] sending packet: from
192.168.10.100[4500] to 172.56.21.156[47709] (80 bytes)
The certificate IS there in the "certs" directory as a trusted
certificate, AND it validates when checked. I can't find a log setting
that will tell me why the scan of the directory where the certificate is
fails to find it (or if it does find it, why it would load and validate it.)
The peer config is also known to be correct and (when I don't get hit
with a frag problem) it works with an RSA certificate:
Jul 1 15:24:32 NewFS charon: 16[NET] received packet: from
172.56.21.156[19562]
to 192.168.10.100[500] (746 bytes)
Jul 1 15:24:32 NewFS charon: 16[ENC] parsed 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 1 15:24:32 NewFS charon: 16[IKE] 172.56.21.156 is initiating an IKE_SA
Jul 1 15:24:32 NewFS charon: 16[IKE] local host is behind NAT, sending
keep ali
ves
Jul 1 15:24:32 NewFS charon: 16[IKE] remote host is behind NAT
Jul 1 15:24:32 NewFS charon: 16[IKE] DH group ECP_256 inacceptable,
requesting
CURVE_25519
Jul 1 15:24:32 NewFS charon: 16[ENC] generating IKE_SA_INIT response 0
[ N(INVA
L_KE) ]
Jul 1 15:24:32 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] t
o 172.56.21.156[19562] (38 bytes)
Jul 1 15:24:32 NewFS charon: 16[NET] received packet: from
172.56.21.156[19562]
to 192.168.10.100[500] (714 bytes)
Jul 1 15:24:32 NewFS charon: 16[ENC] parsed 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 1 15:24:32 NewFS charon: 16[IKE] 172.56.21.156 is initiating an IKE_SA
Jul 1 15:24:32 NewFS charon: 16[IKE] local host is behind NAT, sending
keep ali
ves
Jul 1 15:24:32 NewFS charon: 16[IKE] remote host is behind NAT
Jul 1 15:24:32 NewFS charon: 16[IKE] sending cert request for "C=US,
ST=Florida
, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda
Systems LLC CA
"
Jul 1 15:24:32 NewFS charon: 16[ENC] generating 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 1 15:24:32 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] t
o 172.56.21.156[19562] (267 bytes)
Jul 1 15:24:33 NewFS charon: 16[NET] received packet: from
172.56.21.156[51342]
to 192.168.10.100[4500] (1364 bytes)
Jul 1 15:24:33 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [ EF(1/3) ]
Jul 1 15:24:33 NewFS charon: 16[ENC] received fragment #1 of 3, waiting
for com
plete IKE message
Jul 1 15:24:33 NewFS charon: 16[NET] received packet: from
172.56.21.156[51342]
to 192.168.10.100[4500] (1364 bytes)
Jul 1 15:24:33 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [ EF(2/3) ]
Jul 1 15:24:33 NewFS charon: 16[ENC] received fragment #2 of 3, waiting
for com
plete IKE message
Jul 1 15:24:33 NewFS charon: 13[NET] received packet: from
172.56.21.156[51342]
to 192.168.10.100[4500] (212 bytes)
Jul 1 15:24:33 NewFS charon: 13[ENC] parsed IKE_AUTH request 1 [ EF(3/3) ]
Jul 1 15:24:33 NewFS charon: 13[ENC] received fragment #3 of 3,
reassembling fr
agmented IKE message
Jul 1 15:24:33 NewFS charon: 13[ENC] parsed IKE_AUTH request 1 [ IDi
CERT N(INI
T_CONTACT) CERTREQ 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 1 15:24:33 NewFS charon: 13[IKE] received cert request for "C=US,
ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=Cuda Systems LLC C
A"
Jul 1 15:24:33 NewFS charon: 13[IKE] received end entity cert "C=US,
ST=Florida
, O=Cuda Systems LLC, CN=Karl Denninger (OCSP)"
Jul 1 15:24:33 NewFS charon: 13[CFG] looking for peer configs matching
192.168.
10.100[%any]...172.56.21.156[C=US, ST=Florida, O=Cuda Systems LLC,
CN=Karl Denni
nger (OCSP)]
Jul 1 15:24:33 NewFS charon: 13[CFG] selected peer config 'StrongSwan'
Jul 1 15:24:33 NewFS charon: 13[CFG] using certificate "C=US,
ST=Florida, O=C
uda Systems LLC, CN=Karl Denninger (OCSP)"
Jul 1 15:24:33 NewFS charon: 13[CFG] using trusted ca certificate
"C=US, ST=F
lorida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda
Systems
LLC CA"
Jul 1 15:24:33 NewFS charon: 13[CFG] checking certificate status of
"C=US, ST=F
lorida, O=Cuda Systems LLC, CN=Karl Denninger (OCSP)"
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp response correctly signed
by "C=US,
ST=Florida, O=Cuda Systems LLC, CN=ocsp.cudasystems.net,
E=info at cudasystems.net
"
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp response contains no status
on our
certificate
Jul 1 15:24:33 NewFS charon: 13[CFG] requesting ocsp status from
'http://cuda
systems.net:8888' ...
Jul 1 15:24:33 NewFS charon: 13[LIB] libcurl request failed [52]: Empty
reply f
rom server
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp request to
http://cudasystems.net:888
8 failed
Jul 1 15:24:33 NewFS charon: 13[CFG] requesting ocsp status from
'http://cuda
systems.net:8888' ...
Jul 1 15:24:43 NewFS charon: 13[LIB] libcurl request failed [28]:
Connection ti
med out after 10032 milliseconds
Jul 1 15:24:43 NewFS charon: 13[CFG] ocsp request to
http://cudasystems.net:888
8 failed
Jul 1 15:24:43 NewFS charon: 13[CFG] ocsp check failed, fallback to crl
Jul 1 15:24:43 NewFS charon: 13[CFG] certificate status is not available
Jul 1 15:24:43 NewFS charon: 13[CFG] reached self-signed root ca with
a path
length of 0
Jul 1 15:24:43 NewFS charon: 13[IKE] authentication of 'C=US,
ST=Florida, O=Cud
a Systems LLC, CN=Karl Denninger (OCSP)' with RSA_EMSA_PKCS1_SHA2_384
successful
.... and it comes up (I have to run down why the OCSP responses aren't
always working as the responder appears to be dying after sending the
first response, but that's not what's killing it here)
--
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/20170701/1e36c67c/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/20170701/1e36c67c/attachment-0001.bin>
More information about the Users
mailing list