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.ec...@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.ec...@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=i...@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 k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature