Re: TLS 1.2 with Suite B
Hi Steve! I remade the certs as below, but I still get the same error, i.e. 1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher. Anything else I can try? Warm regards, Fredrik openssl x509 -noout -text -in ca-cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 10878001055568957254 (0x96f66c536f830f46) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 08:11:52 2014 GMT Not After : Nov 14 08:11:52 2024 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:45:e8:b4:d4:3f:89:75:e5:02:0a:65:bf:52:ed: 3b:90:62:df:01:a6:9d:b9:71:28:71:a9:86:5a:1a: 23:7d:95:d8:58:23:44:ab:81:85:48:6a:4b:36:e4: ff:33:a4:14:59:fc:21:11:86:ac:d5:83:2d:52:69: d5:17:50:90:6f:4c:85:a7:4f:79:da:87:01:50:e3: 99:56:2c:a3:c8:df:fa:92:56:4b:3c:22:28:a5:97: 2c:81:5c:aa:15:eb:3c ASN1 OID: secp384r1 X509v3 extensions: X509v3 Subject Key Identifier: 79:22:2D:48:2F:87:81:39:C3:15:AE:F2:6F:EA:DE:11:35:CD:A3:E4 X509v3 Authority Key Identifier: keyid:79:22:2D:48:2F:87:81:39:C3:15:AE:F2:6F:EA:DE:11:35:CD:A3:E4 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: ecdsa-with-SHA384 30:64:02:30:01:4c:6e:fb:9f:00:0c:cd:f8:43:0b:b5:af:e9: 0c:d0:fe:df:81:e4:bc:75:7a:82:0a:c7:5d:45:0d:66:ad:01: 42:98:ed:8f:bb:8c:e0:42:32:d0:d7:00:2f:07:31:b6:02:30: 02:01:72:f4:c6:bc:2c:22:f9:a9:db:78:46:f1:08:75:63:4d: 45:9c:ea:68:fd:40:5b:ac:0f:1c:be:e1:c4:e5:81:a2:ea:97: 48:6c:5b:2f:7b:63:4b:8a:78:c8:6a:af openssl x509 -noout -text -in server-cert.pem Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 08:15:27 2014 GMT Not After : Nov 16 08:15:27 2019 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=server.test.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:b2:1b:ed:7a:70:18:3a:6b:5c:84:d7:2f:1b:f8: 89:c8:8f:72:5a:80:bd:f2:7e:50:a4:80:37:b6:34: d0:54:88:24:dc:a4:a3:58:76:a8:0b:af:ce:cb:1e: bf:cf:33:aa:d0:50:7e:87:f9:77:f3:b9:0e:03:5f: 83:64:e9:b9:8e:d4:4d:08:76:e5:57:77:a2:8d:d1: 01:0c:53:fa:25:d7:bc:2e:a3:0e:6a:4c:2c:2f:0b: 85:ef:d3:2a:ab:e6:de ASN1 OID: secp384r1 Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:3b:8d:a0:82:21:35:59:2d:38:7f:d0:77:58:d0: e9:8c:2a:f6:11:c0:f9:44:b9:64:36:8a:b5:f5:84:db:40:0a: ab:95:51:c5:11:8b:c6:d4:89:fd:ae:77:2a:ba:a2:95:02:31: 00:ba:f5:9c:4f:f6:4a:37:77:ba:91:4b:34:4f:94:92:b1:a3: da:5f:43:13:61:d0:02:bc:27:65:47:ac:ba:4e:79:13:84:cd: eb:c6:5e:a3:94:e9:fa:48:48:e9:78:f9:d3 On Fri, Nov 14, 2014 at 11:32 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 14, 2014, Fredrik Jansson wrote: Hi Steve, thanks for helping out! The server cert is P-256 and the CA is P-384, please see below. Is that ok? That is but this isn't: Signature Algorithm: ecdsa-with-SHA1 The signing digest needs to match the curve. So if you sign with P-384 you need SHA384 and for P-256 SHA256. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
Some more info, SSL_get_ciphers on the server and client: Info2014-Nov-17 10:48:26.961112 All.TLSVerbose ECDHE-ECDSA-AES128-GCM-SHA256 Info2014-Nov-17 10:48:26.961114 All.TLSVerbose ECDHE-ECDSA-AES256-GCM-SHA384 When I do the same on the client, both of the ciphers above are listed (among with several others). Fredrik On Mon, Nov 17, 2014 at 9:54 AM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: Hi Steve! I remade the certs as below, but I still get the same error, i.e. 1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher. Anything else I can try? Warm regards, Fredrik openssl x509 -noout -text -in ca-cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 10878001055568957254 (0x96f66c536f830f46) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 08:11:52 2014 GMT Not After : Nov 14 08:11:52 2024 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:45:e8:b4:d4:3f:89:75:e5:02:0a:65:bf:52:ed: 3b:90:62:df:01:a6:9d:b9:71:28:71:a9:86:5a:1a: 23:7d:95:d8:58:23:44:ab:81:85:48:6a:4b:36:e4: ff:33:a4:14:59:fc:21:11:86:ac:d5:83:2d:52:69: d5:17:50:90:6f:4c:85:a7:4f:79:da:87:01:50:e3: 99:56:2c:a3:c8:df:fa:92:56:4b:3c:22:28:a5:97: 2c:81:5c:aa:15:eb:3c ASN1 OID: secp384r1 X509v3 extensions: X509v3 Subject Key Identifier: 79:22:2D:48:2F:87:81:39:C3:15:AE:F2:6F:EA:DE:11:35:CD:A3:E4 X509v3 Authority Key Identifier: keyid:79:22:2D:48:2F:87:81:39:C3:15:AE:F2:6F:EA:DE:11:35:CD:A3:E4 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: ecdsa-with-SHA384 30:64:02:30:01:4c:6e:fb:9f:00:0c:cd:f8:43:0b:b5:af:e9: 0c:d0:fe:df:81:e4:bc:75:7a:82:0a:c7:5d:45:0d:66:ad:01: 42:98:ed:8f:bb:8c:e0:42:32:d0:d7:00:2f:07:31:b6:02:30: 02:01:72:f4:c6:bc:2c:22:f9:a9:db:78:46:f1:08:75:63:4d: 45:9c:ea:68:fd:40:5b:ac:0f:1c:be:e1:c4:e5:81:a2:ea:97: 48:6c:5b:2f:7b:63:4b:8a:78:c8:6a:af openssl x509 -noout -text -in server-cert.pem Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 08:15:27 2014 GMT Not After : Nov 16 08:15:27 2019 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=server.test.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:b2:1b:ed:7a:70:18:3a:6b:5c:84:d7:2f:1b:f8: 89:c8:8f:72:5a:80:bd:f2:7e:50:a4:80:37:b6:34: d0:54:88:24:dc:a4:a3:58:76:a8:0b:af:ce:cb:1e: bf:cf:33:aa:d0:50:7e:87:f9:77:f3:b9:0e:03:5f: 83:64:e9:b9:8e:d4:4d:08:76:e5:57:77:a2:8d:d1: 01:0c:53:fa:25:d7:bc:2e:a3:0e:6a:4c:2c:2f:0b: 85:ef:d3:2a:ab:e6:de ASN1 OID: secp384r1 Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:3b:8d:a0:82:21:35:59:2d:38:7f:d0:77:58:d0: e9:8c:2a:f6:11:c0:f9:44:b9:64:36:8a:b5:f5:84:db:40:0a: ab:95:51:c5:11:8b:c6:d4:89:fd:ae:77:2a:ba:a2:95:02:31: 00:ba:f5:9c:4f:f6:4a:37:77:ba:91:4b:34:4f:94:92:b1:a3: da:5f:43:13:61:d0:02:bc:27:65:47:ac:ba:4e:79:13:84:cd: eb:c6:5e:a3:94:e9:fa:48:48:e9:78:f9:d3 On Fri, Nov 14, 2014 at 11:32 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 14, 2014, Fredrik Jansson wrote: Hi Steve, thanks for helping out! The server cert is P-256 and the CA is P-384, please see below. Is that ok? That is but this isn't: Signature Algorithm: ecdsa-with-SHA1 The signing digest needs to match the curve. So if you sign with P-384 you need SHA384 and for P-256 SHA256. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users
Re: TLS 1.2 with Suite B
Hi! I have tried with s_client, and I get the same error. Is there any kind of logging callback I can add to my server code that might shed some light on this (I have set SSL_CTX_set_info_callback)? Fredrik On Mon, Nov 17, 2014 at 1:01 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Nov 17, 2014, Fredrik Jansson wrote: Some more info, SSL_get_ciphers on the server and client: Info2014-Nov-17 10:48:26.961112 All.TLSVerbose ECDHE-ECDSA-AES128-GCM-SHA256 Info2014-Nov-17 10:48:26.961114 All.TLSVerbose ECDHE-ECDSA-AES256-GCM-SHA384 When I do the same on the client, both of the ciphers above are listed (among with several others). I'd suggest you try suite B with s_server/s_client and see if you still get an error. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
More tests as you suggested: openssl s_client -tls1_2 -connect XXX:9103 openssl s_server -state -tls1_2 -cipher SUITEB128 -accept 9103 Using default temp DH parameters ACCEPT SSL_accept:before/accept initialization SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client hello C ERROR 139990990374592:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1398: shutting down SSL CONNECTION CLOSED Warm regards, Fredrik On Mon, Nov 17, 2014 at 1:09 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: Hi! I have tried with s_client, and I get the same error. Is there any kind of logging callback I can add to my server code that might shed some light on this (I have set SSL_CTX_set_info_callback)? Fredrik On Mon, Nov 17, 2014 at 1:01 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Nov 17, 2014, Fredrik Jansson wrote: Some more info, SSL_get_ciphers on the server and client: Info2014-Nov-17 10:48:26.961112 All.TLSVerbose ECDHE-ECDSA-AES128-GCM-SHA256 Info2014-Nov-17 10:48:26.961114 All.TLSVerbose ECDHE-ECDSA-AES256-GCM-SHA384 When I do the same on the client, both of the ciphers above are listed (among with several others). I'd suggest you try suite B with s_server/s_client and see if you still get an error. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
I actually got a bit further with a secp256r1 server certificate, I also changed the server certificate version from 1 to 3. Now I get: Info2014-Nov-17 15:03:18.625733 All.TLSVerbose ssl_info_cb: write:fatal:certificate unknown Info2014-Nov-17 15:03:18.625759 All.TLSVerbose ssl_info_cb: SSL_accept: error in SSLv3 read client certificate B (8577) Info2014-Nov-17 15:03:18.625763 All.TLS Accept failed with verification error: Suite B: invalid signature algorithm Error 2014-Nov-17 15:03:18.625777 All.TLS Accept failed with error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed The signature of the client cert is ecdsa-with-SHA256 and the curve for its key is prime256v1. All the best, Fredrik openssl x509 -noout -text -in frja-cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 13:59:13 2014 GMT Not After : Nov 16 13:59:13 2019 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=fredrik.jans...@foo.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:08:64:d1:f6:4e:65:11:6e:81:6e:f6:ab:3b:80: bd:75:74:fc:5b:d5:31:3a:3a:33:32:f9:67:7f:1b: 05:55:fc:3b:bf:27:00:20:b7:1c:59:46:33:2a:b1: 20:52:68:2a:f6:40:66:16:5d:e1:e3:f1:cf:d3:e5: 31:c5:e5:1f:d3 ASN1 OID: prime256v1 Signature Algorithm: ecdsa-with-SHA256 30:65:02:31:00:e1:0a:7f:e9:e0:02:e2:28:1b:01:8b:ae:62: f8:e3:07:46:a9:66:0a:08:c8:e9:9c:00:87:e1:48:66:ce:5d: c1:bc:62:a0:63:00:14:8b:51:13:e7:f6:1d:25:d1:78:47:02: 30:68:90:11:17:f1:a2:42:dc:f4:48:44:90:a6:de:62:f7:f6: f5:a4:4d:e8:8d:d0:54:d8:6f:65:1b:b5:7e:4e:80:7b:f2:70: b5:53:a8:17:f2:fa:e7:bf:62:05:0e:b5:cd On Mon, Nov 17, 2014 at 1:19 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: More tests as you suggested: openssl s_client -tls1_2 -connect XXX:9103 openssl s_server -state -tls1_2 -cipher SUITEB128 -accept 9103 Using default temp DH parameters ACCEPT SSL_accept:before/accept initialization SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client hello C ERROR 139990990374592:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1398: shutting down SSL CONNECTION CLOSED Warm regards, Fredrik On Mon, Nov 17, 2014 at 1:09 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: Hi! I have tried with s_client, and I get the same error. Is there any kind of logging callback I can add to my server code that might shed some light on this (I have set SSL_CTX_set_info_callback)? Fredrik On Mon, Nov 17, 2014 at 1:01 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Nov 17, 2014, Fredrik Jansson wrote: Some more info, SSL_get_ciphers on the server and client: Info2014-Nov-17 10:48:26.961112 All.TLSVerbose ECDHE-ECDSA-AES128-GCM-SHA256 Info2014-Nov-17 10:48:26.961114 All.TLSVerbose ECDHE-ECDSA-AES256-GCM-SHA384 When I do the same on the client, both of the ciphers above are listed (among with several others). I'd suggest you try suite B with s_server/s_client and see if you still get an error. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
Now it works, recreating the client cert with extensions as below made it work. openssl x509 -noout -text -in frja-cert.pem Fredrik Certificate: Data: Version: 3 (0x2) Serial Number: 4 (0x4) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 14:11:55 2014 GMT Not After : Nov 16 14:11:55 2019 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=fredrik.jans...@foo.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:08:64:d1:f6:4e:65:11:6e:81:6e:f6:ab:3b:80: bd:75:74:fc:5b:d5:31:3a:3a:33:32:f9:67:7f:1b: 05:55:fc:3b:bf:27:00:20:b7:1c:59:46:33:2a:b1: 20:52:68:2a:f6:40:66:16:5d:e1:e3:f1:cf:d3:e5: 31:c5:e5:1f:d3 ASN1 OID: prime256v1 X509v3 extensions: X509v3 Authority Key Identifier: keyid:79:22:2D:48:2F:87:81:39:C3:15:AE:F2:6F:EA:DE:11:35:CD:A3:E4 X509v3 Basic Constraints: CA:FALSE Signature Algorithm: ecdsa-with-SHA256 30:64:02:30:7f:4d:07:9e:9b:91:f6:4c:37:78:19:1b:4a:63: eb:a9:80:b0:8c:ab:44:3d:14:4b:44:1d:57:37:9a:6c:b7:db: cb:85:91:ae:23:46:d4:c5:1e:57:08:71:29:e9:6c:41:02:30: 79:d0:80:0a:86:cf:3f:18:cf:66:c6:84:07:73:cd:17:6b:15: 5d:25:45:59:86:22:f6:de:06:db:0c:60:8e:30:32:45:d6:c6: 01:16:a3:94:9d:cb:4e:fd:a6:6b:a1:73 On Mon, Nov 17, 2014 at 3:06 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: I actually got a bit further with a secp256r1 server certificate, I also changed the server certificate version from 1 to 3. Now I get: Info2014-Nov-17 15:03:18.625733 All.TLSVerbose ssl_info_cb: write:fatal:certificate unknown Info2014-Nov-17 15:03:18.625759 All.TLSVerbose ssl_info_cb: SSL_accept: error in SSLv3 read client certificate B (8577) Info2014-Nov-17 15:03:18.625763 All.TLS Accept failed with verification error: Suite B: invalid signature algorithm Error 2014-Nov-17 15:03:18.625777 All.TLS Accept failed with error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed The signature of the client cert is ecdsa-with-SHA256 and the curve for its key is prime256v1. All the best, Fredrik openssl x509 -noout -text -in frja-cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=SE, ST=Stockholm, O=AB, CN=ECDSA CA Validity Not Before: Nov 17 13:59:13 2014 GMT Not After : Nov 16 13:59:13 2019 GMT Subject: C=SE, ST=Stockholm, O=AB, CN=fredrik.jans...@foo.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:08:64:d1:f6:4e:65:11:6e:81:6e:f6:ab:3b:80: bd:75:74:fc:5b:d5:31:3a:3a:33:32:f9:67:7f:1b: 05:55:fc:3b:bf:27:00:20:b7:1c:59:46:33:2a:b1: 20:52:68:2a:f6:40:66:16:5d:e1:e3:f1:cf:d3:e5: 31:c5:e5:1f:d3 ASN1 OID: prime256v1 Signature Algorithm: ecdsa-with-SHA256 30:65:02:31:00:e1:0a:7f:e9:e0:02:e2:28:1b:01:8b:ae:62: f8:e3:07:46:a9:66:0a:08:c8:e9:9c:00:87:e1:48:66:ce:5d: c1:bc:62:a0:63:00:14:8b:51:13:e7:f6:1d:25:d1:78:47:02: 30:68:90:11:17:f1:a2:42:dc:f4:48:44:90:a6:de:62:f7:f6: f5:a4:4d:e8:8d:d0:54:d8:6f:65:1b:b5:7e:4e:80:7b:f2:70: b5:53:a8:17:f2:fa:e7:bf:62:05:0e:b5:cd On Mon, Nov 17, 2014 at 1:19 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: More tests as you suggested: openssl s_client -tls1_2 -connect XXX:9103 openssl s_server -state -tls1_2 -cipher SUITEB128 -accept 9103 Using default temp DH parameters ACCEPT SSL_accept:before/accept initialization SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client hello C ERROR 139990990374592:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1398: shutting down SSL CONNECTION CLOSED Warm regards, Fredrik On Mon, Nov 17, 2014 at 1:09 PM, Fredrik Jansson fredrik.jansson...@gmail.com wrote: Hi! I have tried with s_client, and I get the same error. Is there any kind of logging callback I can add to my server code that might shed some light on this (I have set SSL_CTX_set_info_callback)? Fredrik On Mon, Nov 17, 2014 at 1:01 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Nov 17, 2014, Fredrik Jansson wrote: Some more info, SSL_get_ciphers on the server and client: Info2014-Nov-17 10:48:26.961112 All.TLSVerbose ECDHE-ECDSA-AES128-GCM-SHA256 Info2014-Nov-17
TLS 1.2 with Suite B
Hi! I am trying to force my TLS 1.2 connection into Suite B mode, but at handshake I get an error no shared cipher. The server code is basically: SSL_CTX_new(TLSv1_2_server_method()); //ECDSA cert is added to the ctx SSL_CTX_use_certificate(ctx_, serverCert.cert.get()) SSL_CTX_use_PrivateKey(ctx_, serverCert.privateKey.get()) SSL_CTX_set_cipher_list(ctx, SUITEB128); SSL_CTX_set_options(ctx_, SSL_OP_NO_TICKET); SSL_CTX_set_session_cache_mode(ctx_, SSL_SESS_CACHE_BOTH); The client code is very similar. If I comment out the SSL_CTX_set_cipher_list call, it works and the session is established with ECDH-ECDSA-AES256-GCM-SHA384. I suspect I need to provide the server with ephemeral ECDH keys, but I cannot figure out how to do that. Does anyone have a working example to share? Thanks! Fredrik __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
Hi!
Thanks!
I am using 1.0.2b3 on both server and client, and I have the call to
SSL_CTX_set_ecdh_auto, but still no luck.
The exact code is as follows:
358 void initialize(TLSSettings const settings) {
359 ctx_ = SSL_CTX_new(TLSv1_2_server_method());
360 if (!ctx_) {
361 throw std::runtime_error(OpenSSLSup::currentError());
362 }
363
364 static const unsigned char context[] = WVPN-TLS;
365
366 if (!SSL_CTX_set_session_id_context(ctx_, context,
sizeof(context))) {
367 debug.LogE(Debug::System, Failed to set session ID
context, session resume will fail);
368 }
369
370 auto serverCert =
OpenSSLSup::loadPKCS12(settings.certificate(),
settings.certPassword());
371
372 debug.Log(Debug::System, Server certificate '%s' (%s),
373 OpenSSLSup::commonName(serverCert.cert.get()).c_str(),
374 settings.certificate().c_str());
375
376 SSL_CTX_set_info_callback(ctx_, ssl_info_cb);
377
378 if (!SSL_CTX_use_certificate(ctx_, serverCert.cert.get())) {
379 debug.LogE(Debug::System, Failed to set server
certificate: %s,
380 OpenSSLSup::currentError().c_str());
381 throw std::runtime_error(Failed to create context);
382 }
383
384 if (!SSL_CTX_use_PrivateKey(ctx_, serverCert.privateKey.get())) {
385 debug.LogE(Debug::System, Failed to set server
private key: %s,
386 OpenSSLSup::currentError().c_str());
387 throw std::runtime_error(Failed to create context);
388 }
389
390 auto vfy = SSL_VERIFY_CLIENT_ONCE | SSL_VERIFY_PEER;
391 if(settings.requireClientCert()) {
392 vfy |= SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
393 }
394
395 SSL_CTX_set_verify(ctx_, vfy, nullptr);
396 SSL_CTX_set_ecdh_auto(ctx_, 1);
397
398 std::string ciphers;
399
400 ciphers = SUITEB128;
401
402 if (!ciphers.empty()) {
403 if (SSL_CTX_set_cipher_list(ctx_, ciphers.c_str())) {
404 debug.Log(Debug::System, Successfully set ciphers
%s, ciphers.c_str());
405 }
406 else {
407 debug.LogE(Debug::System, Failed to set ciphers %s, %s,
408 ciphers.c_str(),
409 OpenSSLSup::currentError().c_str());
410 throw std::runtime_error(Failed to create context);
411 }
412 }
413
414 SSL_CTX_set_options(ctx_, SSL_OP_NO_TICKET);
415 SSL_CTX_set_session_cache_mode(ctx_, SSL_SESS_CACHE_BOTH);
416 SSL_CTX_sess_set_remove_cb(ctx_, ssl_remove_session_cb);
417 CertStore::setStoreInCTX(ctx_);
418 }
Warm regards,
Fredrik
On Fri, Nov 14, 2014 at 3:36 PM, Dr. Stephen Henson st...@openssl.org wrote:
On Fri, Nov 14, 2014, Fredrik Jansson wrote:
Hi!
I am trying to force my TLS 1.2 connection into Suite B mode, but at
handshake I get an error no shared cipher.
The server code is basically:
SSL_CTX_new(TLSv1_2_server_method());
//ECDSA cert is added to the ctx
SSL_CTX_use_certificate(ctx_, serverCert.cert.get())
SSL_CTX_use_PrivateKey(ctx_, serverCert.privateKey.get())
SSL_CTX_set_cipher_list(ctx, SUITEB128);
SSL_CTX_set_options(ctx_, SSL_OP_NO_TICKET);
SSL_CTX_set_session_cache_mode(ctx_, SSL_SESS_CACHE_BOTH);
The client code is very similar.
If I comment out the SSL_CTX_set_cipher_list call, it works and the
session is established with ECDH-ECDSA-AES256-GCM-SHA384.
I suspect I need to provide the server with ephemeral ECDH keys, but I
cannot figure out how to do that.
Does anyone have a working example to share?
Firstly you have to use OpenSSL 1.0.2 or this wont work.
With 1.0.2 you just need to set the server to use automatic ECDH parameters
with:
SSL_CTX_set_ecdh_auto(ctx, 1);
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: TLS 1.2 with Suite B
Hi Steve, thanks for helping out!
The server cert is P-256 and the CA is P-384, please see below. Is that ok?
Fredrik
openssl x509 -noout -text -in server-secp256r1-cert.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 3 (0x3)
Signature Algorithm: ecdsa-with-SHA1
Issuer: C=SE, ST=Stockholm, O=Foo, CN=Bar CA
Validity
Not Before: Oct 7 06:59:47 2014 GMT
Not After : Oct 6 06:59:47 2019 GMT
Subject: C=SE, ST=Stockholm, O=Foo, CN=Bar
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:b1:40:a9:b9:d0:01:c7:ed:b0:79:11:54:95:85:
a4:88:3a:4a:79:a6:dc:6f:5f:34:d1:b4:e7:bb:5b:
c9:9c:ab:22:d3:99:31:51:33:4e:c7:43:4e:7e:9c:
dc:59:4c:dd:0a:70:48:e5:5e:0d:36:08:50:78:7b:
07:0f:83:ed:7a
ASN1 OID: prime256v1
Signature Algorithm: ecdsa-with-SHA1
30:66:02:31:00:81:85:94:a8:e5:f7:3a:55:07:21:ca:72:8b:
e3:80:a9:e0:aa:97:e8:0f:22:53:fb:2f:7f:1e:7e:6d:ea:d5:
70:c8:9e:ba:95:25:f4:ef:91:ec:67:35:51:69:73:53:6f:02:
31:00:91:6e:cc:b5:ac:5e:94:fe:19:1a:29:c6:ca:cd:ac:74:
8c:3b:50:8f:18:d5:ed:94:aa:44:2e:7a:17:d7:e7:ab:c9:8e:
03:da:06:2d:be:be:52:34:0c:d7:7d:07:52:77
openssl x509 -noout -text -in ca-cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15490594899219511094 (0xd6f9a5fcf774f736)
Signature Algorithm: ecdsa-with-SHA1
Issuer: C=SE, ST=Stockholm, O=Foo, CN=Bar CA
Validity
Not Before: Oct 7 06:55:12 2014 GMT
Not After : Oct 4 06:55:12 2024 GMT
Subject: C=SE, ST=Stockholm, O=Foo, CN=Bar CA
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:7a:36:38:33:5c:21:36:04:cb:6c:28:1a:1c:d4:
f6:72:e9:54:3e:08:ed:80:3f:cc:b1:f2:e0:07:b8:
bb:9d:77:a9:d3:08:a0:d6:fb:27:bf:d5:53:a0:eb:
24:79:10:21:34:3b:02:22:b9:6d:d2:af:8c:e1:ea:
a8:03:e5:d6:ec:f5:a7:da:64:66:fd:ab:46:cc:ae:
e6:49:ec:b2:0a:56:50:83:12:e2:97:65:b4:04:8c:
a3:a5:a1:6e:57:1e:72
ASN1 OID: secp384r1
X509v3 extensions:
X509v3 Subject Key Identifier:
7A:51:2F:7F:35:6A:A5:C7:08:7B:17:89:45:01:0F:72:B3:F5:81:24
X509v3 Authority Key Identifier:
keyid:7A:51:2F:7F:35:6A:A5:C7:08:7B:17:89:45:01:0F:72:B3:F5:81:24
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA1
30:64:02:30:54:43:52:92:54:74:b6:42:d8:3e:d4:d2:41:96:
b5:86:98:07:46:67:44:21:19:09:31:d5:f2:56:c0:9f:2b:fb:
cc:cb:33:a2:e7:46:2b:c6:89:e7:49:77:9b:2c:ee:f2:02:30:
1a:33:46:5a:26:89:d4:b2:b8:66:13:a4:0e:47:09:2e:2c:3e:
ba:dc:89:02:a4:1a:0e:57:e1:de:ba:62:b7:20:84:d3:cd:4e:
22:66:94:2f:fd:88:4b:28:80:df:e6:ef
On Fri, Nov 14, 2014 at 7:35 PM, Dr. Stephen Henson st...@openssl.org wrote:
On Fri, Nov 14, 2014, Fredrik Jansson wrote:
Hi!
Thanks!
I am using 1.0.2b3 on both server and client, and I have the call to
SSL_CTX_set_ecdh_auto, but still no luck.
The exact code is as follows:
358 void initialize(TLSSettings const settings) {
359 ctx_ = SSL_CTX_new(TLSv1_2_server_method());
360 if (!ctx_) {
361 throw std::runtime_error(OpenSSLSup::currentError());
362 }
363
364 static const unsigned char context[] = WVPN-TLS;
365
366 if (!SSL_CTX_set_session_id_context(ctx_, context,
sizeof(context))) {
367 debug.LogE(Debug::System, Failed to set session ID
context, session resume will fail);
368 }
369
370 auto serverCert =
OpenSSLSup::loadPKCS12(settings.certificate(),
settings.certPassword());
371
372 debug.Log(Debug::System, Server certificate '%s' (%s),
373 OpenSSLSup::commonName(serverCert.cert.get()).c_str(),
374 settings.certificate().c_str());
375
376 SSL_CTX_set_info_callback(ctx_, ssl_info_cb);
377
378 if (!SSL_CTX_use_certificate(ctx_, serverCert.cert.get())) {
379 debug.LogE(Debug::System, Failed to set server
certificate: %s,
380 OpenSSLSup::currentError().c_str());
381 throw std::runtime_error(Failed to create context);
382 }
383
384 if (!SSL_CTX_use_PrivateKey(ctx_, serverCert.privateKey.get())) {
385 debug.LogE(Debug::System, Failed to set server
private key: %s,
386 OpenSSLSup::currentError().c_str());
387 throw std::runtime_error(Failed to create context
Re: External client certificate signature function
Hi Steve! I will try to take that path, thank you! //Fredrik On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Oct 13, 2014, Fredrik Jansson wrote: Hi! I have a device where I cannot access the client certificate's private key directly, but have access to verification and signature functions. The certificate, in DER format, is accessible. I need to use client certificates in my TLS connection and found the SSL_CTX_set_client_cert_cb function. I can convert the encoded cert to a X509 structure and return that, but I cannot provide it with a EVP_PKEY object. Is there any way I can instruct any of the SSL_CTX, SSL or EVP_PKEY objects to call a signature function (that I provide) during the handshake? An EVP_PKEY structure doesn't have to contain the private key components it can contain just the public components. Private key operations can be redirected to a function which performs the necessary operation. How you do that depends on the signing function you have available. Typically you'll write a *_METHOD for the key type and an ENGINE to contain it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: External client certificate signature function
I just realised I can create a RSA_METHOD object and set that in my engine. But what about ECDSA_ENGINE? There is no struct definition available in the public headers, and no public functions to change the members of the struct, e.g. set a new signing function. Is this not possible with ECDSA? Warm regards, Fredrik On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Oct 13, 2014, Fredrik Jansson wrote: Hi! I have a device where I cannot access the client certificate's private key directly, but have access to verification and signature functions. The certificate, in DER format, is accessible. I need to use client certificates in my TLS connection and found the SSL_CTX_set_client_cert_cb function. I can convert the encoded cert to a X509 structure and return that, but I cannot provide it with a EVP_PKEY object. Is there any way I can instruct any of the SSL_CTX, SSL or EVP_PKEY objects to call a signature function (that I provide) during the handshake? An EVP_PKEY structure doesn't have to contain the private key components it can contain just the public components. Private key operations can be redirected to a function which performs the necessary operation. How you do that depends on the signing function you have available. Typically you'll write a *_METHOD for the key type and an ENGINE to contain it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
External client certificate signature function
Hi! I have a device where I cannot access the client certificate's private key directly, but have access to verification and signature functions. The certificate, in DER format, is accessible. I need to use client certificates in my TLS connection and found the SSL_CTX_set_client_cert_cb function. I can convert the encoded cert to a X509 structure and return that, but I cannot provide it with a EVP_PKEY object. Is there any way I can instruct any of the SSL_CTX, SSL or EVP_PKEY objects to call a signature function (that I provide) during the handshake? Best regards, Fredrik Jansson __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X509_STORE_add_crl with updated CRL
I have two CRL, one empty and one with a revoked certificate. I create a X509_STORE and use X509_STORE_add_crl to add the empty CRL. When verifying the certificate using the store, it verifies alright. Then I add the CRL with the revoked cert to the same store, again using X509_STORE_add_crl. When verifying the cert it still verifies (!!), I expected it to be rejected since it is revoked in the updated CRL. If I instead create a new store and add the CRL with the revoked cert, the certificate is rejected, as expected. Am I doing something wrong? Best regards, Fredrik __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Flushing encrypted data to file
Hi!
Some example code to extract a cert from a P12 file:
BIO* certFile = BIO_new_file(cert path, r);
PKCS12* p12 = nullptr;
X509* cert = nullptr;
if (!certFile) {
goto done;
}
p12 = d2i_PKCS12_bio(certFile, nullptr);
if (!p12) {
goto done;
}
if (!PKCS12_parse(p12, P12 password, g_pk, cert, nullptr)) {
goto done;
}
done:
X509_free(cert);
PKCS12_free(p12);
BIO_free(certFile);
On Mon, Mar 10, 2014 at 1:09 PM, Marcio Campos de Lima
marcio.lim...@gmail.com wrote:
Hi
How can I get the Public Key from a PKCS12 keystone?
Do I need to parse the certificate ? Is there a way to store the public key
into the PKCS12 keystone?
Thanks
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: AES CCM in DTLS v1.2
Thanks, guess I will have to wait for 1.0.2. My aim is still the same though, get rid of the padding required by SHA. As I understand it GCM/GMAC would be a good fit too (?). Will I be able to key it using PSK? Br Fredrik On Tue, Mar 4, 2014 at 10:05 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Fredrik Jansson wrote: I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL 1.0.1f I was hoping to be able to use AES CCM mode. We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA. Is it possible to stick with PSK and migrate to AES CCM? DTLS 1.2 is supported in OpenSSL 1.0.2 only not 1.0.1f. Also it only supports AES GCM and not AES CCM. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AES CCM in DTLS v1.2
I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL 1.0.1f I was hoping to be able to use AES CCM mode. We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA. Is it possible to stick with PSK and migrate to AES CCM? Best regards, Fredrik
Re: DTLS handshake messages
Hi Sravanthi, I have implemented this as follows: One thread per listen socket, calling DTLSv1_listen. This thread spawns one thread per client and those treads call SSL_accept. The listening threads share a single SSL_CTX, and each call to SSL_new is protected by a mutex. Each SSL object has an associated mutex for SSL calls. Best regards, Fredrik On Wed, Dec 11, 2013 at 9:27 AM, Sravanthi shravanti.re...@gmail.comwrote: I'm planning to implement an application that has multiple threads. This application uses DTLS protocol. Can each DTLS handshake message go to different thread or is it must that all the DTLS handshake messages should be handled by single thread. Please let me know if anyone has done something similar to this. Thanks, Sravanthi
Re: DTLS PSK in FIPS mode
Steve, thanks for getting back! Since I could not reproduce this using s_client and s_server I set out to take the code I am using into a sample project. Doing so I believe I have found the issue, SSL_CTX_set_cipher(ctx, SSL_TXT_PSK) returns an error (SSL routines:SSL_CTX_set_cipher_list:no cipher match) if I have called FIPS_mode_set(1) first. My original code did not check the return value of SSL_CTX_set_cipher so that may very well be the cause of the subsequent crash. Now my question becomes why I cannot select SSL_TXT_PSK when in FIPS mode? Best regards, Fredrik On Sun, Nov 3, 2013 at 4:15 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Fri, Oct 25, 2013, Fredrik Jansson wrote: I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)). Can you reproduce this using s_client and s_server? If so can you give details of the command lines you used? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS PSK in FIPS mode
Thanks, that did it! To try to understand the implications of this, if I add SSL_FIPS to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA, am I violating the security policy? AES 128/256 CBC and SHA are approved algorithms(?). Best regards, Fredrik On Mon, Nov 4, 2013 at 2:31 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Mon, Nov 04, 2013, Fredrik Jansson wrote: Steve, thanks for getting back! Since I could not reproduce this using s_client and s_server I set out to take the code I am using into a sample project. Doing so I believe I have found the issue, SSL_CTX_set_cipher(ctx, SSL_TXT_PSK) returns an error (SSL routines:SSL_CTX_set_cipher_list:no cipher match) if I have called FIPS_mode_set(1) first. My original code did not check the return value of SSL_CTX_set_cipher so that may very well be the cause of the subsequent crash. Now my question becomes why I cannot select SSL_TXT_PSK when in FIPS mode? The ciphersuites supported in FIPS mode are restricted to those which use approved algorithms. PSK at present is not listed though there isn't really any reason why it can't be included in future. To test this add the flag SSL_FIPS to the relevant ciphersuits in s3_lib.c Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS PSK in FIPS mode
Awesome, thank you! Can you please help me close bug 3152? I will put in a change request to have TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA enabled in FIPS mode. Best regards, Fredrik On Mon, Nov 4, 2013 at 3:37 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Mon, Nov 04, 2013, Fredrik Jansson wrote: Thanks, that did it! To try to understand the implications of this, if I add SSL_FIPS to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA, am I violating the security policy? AES 128/256 CBC and SHA are approved algorithms(?). The security policy means you cannot modify any code in the validated module source, it does not apply to the FIPS capable OpenSSL which is effectively an application of the FIPS module. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DTLS PSK in FIPS mode
Hi! I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)). If I do, I get crashes as below where p =0; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffddffb700 (LWP 15278)] 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680 680*p == SSL3_MT_CLIENT_HELLO) (gdb) bt #0 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680 #1 0x7752ef7f in dtls1_read_bytes (s=0x7fffc8000c00, type=22, buf=0x7fffddffa990 \300\251\377\335\377\177, len=12, peek=0) at d1_pkt.c:838 #2 0x775327cd in dtls1_get_message_fragment (s=0x7fffc8000c00, st1=8465, stn=8466, max=16384, ok=0x7fffddffaa44) at d1_both.c:788 #3 0x77531699 in dtls1_get_message (s=0x7fffc8000c00, st1=8465, stn=8466, mt=1, max=16384, ok=0x7fffddffaa44) at d1_both.c:436 #4 0x77503a53 in ssl3_get_client_hello (s=0x7fffc8000c00) at s3_srvr.c:941 #5 0x7752712c in dtls1_accept (s=0x7fffc8000c00) at d1_srvr.c:298 #6 0x77536e85 in SSL_accept (s=0x7fffc8000c00) at ssl_lib.c:940 #7 0x7752dd38 in dtls1_listen (s=0x7fffc8000c00, client=0x7fffddffacf0) at d1_lib.c:477 #8 0x7752d715 in dtls1_ctrl (s=0x7fffc8000c00, cmd=75, larg=0, parg=0x7fffddffacf0) at d1_lib.c:263 #9 0x77537422 in SSL_ctrl (s=0x7fffc8000c00, cmd=75, larg=0, parg=0x7fffddffacf0) at ssl_lib.c:1106 #10 0x009b64a9 in (anonymous namespace)::listenThread (serverAddr=...) at /home/frja/srv_trunk/src/product/service/dtls/unix/dtlsserver.cpp:586 This is only a problem when combining PSK and FIPS, if I do either FIPS or PSK it works. Can anyone please help me out? Fredrik
Re: DTLS PSK in FIPS mode
Hi again,
in d1_pkt.c:574
(s-rstate != SSL_ST_READ_BODY) || (s-packet_length
DTLS1_RT_HEADER_LENGTH)) seems to be false at times. When the program
reaches *p == SSL3_MT_CLIENT_HELLO further down it fails (since p is
initialized to NULL).
if I add
if (NULL == p) {
p = s-packet;
}
before *p == SSL3_MT_CLIENT_HELLO, it works.
Should I report a bug?
Fredrik
On Fri, Oct 25, 2013 at 2:03 PM, Fredrik Jansson
fredrik.jansson...@gmail.com wrote:
Hi!
I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
If I do, I get crashes as below where p =0;
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddffb700 (LWP 15278)]
0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at d1_pkt.c:680
680*p == SSL3_MT_CLIENT_HELLO)
(gdb) bt
#0 0x7752ebe0 in dtls1_get_record (s=0x7fffc8000c00) at
d1_pkt.c:680
#1 0x7752ef7f in dtls1_read_bytes (s=0x7fffc8000c00, type=22,
buf=0x7fffddffa990 \300\251\377\335\377\177, len=12, peek=0) at
d1_pkt.c:838
#2 0x775327cd in dtls1_get_message_fragment (s=0x7fffc8000c00,
st1=8465, stn=8466, max=16384, ok=0x7fffddffaa44) at d1_both.c:788
#3 0x77531699 in dtls1_get_message (s=0x7fffc8000c00, st1=8465,
stn=8466, mt=1, max=16384, ok=0x7fffddffaa44) at d1_both.c:436
#4 0x77503a53 in ssl3_get_client_hello (s=0x7fffc8000c00) at
s3_srvr.c:941
#5 0x7752712c in dtls1_accept (s=0x7fffc8000c00) at d1_srvr.c:298
#6 0x77536e85 in SSL_accept (s=0x7fffc8000c00) at ssl_lib.c:940
#7 0x7752dd38 in dtls1_listen (s=0x7fffc8000c00,
client=0x7fffddffacf0) at d1_lib.c:477
#8 0x7752d715 in dtls1_ctrl (s=0x7fffc8000c00, cmd=75, larg=0,
parg=0x7fffddffacf0) at d1_lib.c:263
#9 0x77537422 in SSL_ctrl (s=0x7fffc8000c00, cmd=75, larg=0,
parg=0x7fffddffacf0) at ssl_lib.c:1106
#10 0x009b64a9 in (anonymous namespace)::listenThread
(serverAddr=...) at
/home/frja/srv_trunk/src/product/service/dtls/unix/dtlsserver.cpp:586
This is only a problem when combining PSK and FIPS, if I do either FIPS or
PSK it works.
Can anyone please help me out?
Fredrik
Deadlock in FIPS mode
Hi! I have managed to deadlock OpenSSL while running in FIPS mode. The locking functions are setup according to mttest.c and th-lock.c using pthread_mutex_. Please note I have NOT explicitly set a thread id function. Then env is: openssl-1.0.1e openssl-fips-2.0.5 RHEL 6 - 32 bit. Please let me know if there is any other information I can provide. Best regards, Fredrik My callstacks look like: Thread 17 (Thread 0xad841b70 (LWP 13059)): #0 0x00147424 in __kernel_vsyscall () #1 0x00a24059 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00a1f400 in _L_lock_698 () from /lib/libpthread.so.0 #3 0x00a1f2d1 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0024b395 in CRYPTO_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #5 0x002499ba in FIPS_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #6 0x002456ba in fips_drbg_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #7 0x002d51c0 in RAND_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 Thread 11 (Thread 0xa98ffb70 (LWP 13066)): #0 0x00147424 in __kernel_vsyscall () #1 0x00a24059 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00a1f400 in _L_lock_698 () from /lib/libpthread.so.0 #3 0x00a1f2d1 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0024b395 in CRYPTO_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #5 0x002d3ed0 in ssleay_rand_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #6 0x002d4f46 in drbg_get_entropy () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #7 0x0023f217 in fips_get_entropy () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #8 0x0023f3cb in drbg_reseed () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #9 0x0023fc14 in FIPS_drbg_generate () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #10 0x00245733 in fips_drbg_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #11 0x002d51c0 in RAND_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #12 0x00c9f3df in dtls1_enc () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #13 0x00c9b341 in do_dtls1_write () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #14 0x00c9b615 in dtls1_write_bytes () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #15 0x00c9b68a in dtls1_write_app_data_bytes () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #16 0x00c85b2a in ssl3_write () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #17 0x00ca0df9 in SSL_write () from /opt/ct_mvpn/lib/libssl.so.1.0.0 Thread 9 (Thread 0xa751db70 (LWP 13095)): #0 0x00147424 in __kernel_vsyscall () #1 0x00a24059 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00a1f400 in _L_lock_698 () from /lib/libpthread.so.0 #3 0x00a1f2d1 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0024b395 in CRYPTO_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #5 0x002499ba in FIPS_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #6 0x002456ba in fips_drbg_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #7 0x00245817 in fips_drbg_pseudo () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #8 0x002d5200 in RAND_pseudo_bytes () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #9 0x00c78b5f in ssl3_get_client_hello () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #10 0x00c97189 in dtls1_accept () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #11 0x00ca445a in SSL_accept () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #12 0x00c9a129 in dtls1_listen () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #13 0x00c9a1d8 in dtls1_ctrl () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #14 0x00ca3673 in SSL_ctrl () from /opt/ct_mvpn/lib/libssl.so.1.0.0 Thread 8 (Thread 0xa6b1cb70 (LWP 13096)): #0 0x00147424 in __kernel_vsyscall () #1 0x00a24059 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0x00a1f400 in _L_lock_698 () from /lib/libpthread.so.0 #3 0x00a1f2d1 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x0024b395 in CRYPTO_lock () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #5 0x002d3989 in ssleay_rand_add () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #6 0x002d4e06 in drbg_rand_add () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #7 0x00245561 in fips_drbg_add () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #8 0x002d5180 in RAND_add () from /opt/ct_mvpn/lib/libcrypto.so.1.0.0 #9 0x00c96720 in dtls1_accept () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #10 0x00ca445a in SSL_accept () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #11 0x00c9a129 in dtls1_listen () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #12 0x00c9a1d8 in dtls1_ctrl () from /opt/ct_mvpn/lib/libssl.so.1.0.0 #13 0x00ca3673 in SSL_ctrl () from /opt/ct_mvpn/lib/libssl.so.1.0.0
DTLS - cannot make client detect restarted server
Hi all, I am having some trouble with DTLS. I can easily get into a situation where my server is restarted (or the client's SSL object is removed for other reasons) and the client may not know. Now when the client sends data to the server, a new SSL object is created but the server is stuck in: Info Tue Jan 3 09:55:59 2012 All.DTLS ssl_info_cb: SSL_accept: error in SSLv3 read client hello B Info Tue Jan 3 09:55:59 2012 All.DTLS SSL_read: rc: -1, err: 2 i.e. it returns SSL_WANT_READ and of course expects a handshake, but no alert or similar is sent to the client to indicate the client needs to take some measure. The client happily keeps sending data. Any help on how to resolve this would be greatly appreciated. Best regards, Fredrik Jansson
