[1.0.1f] RSA-PSS signing through EVP interface
Hello, I'm having a hard time figuring out how to use the EVP interface to get a RSA-PSS signature. I can successfully call RSA_padding_add_PKCS1_PSS, but when I try to call the various macros for EVP_PKEY_CTX_ctrl. The thing is, I'm not sure in which order (if any) these functions should be called. Currently, this is what I have: (OSSL_err() calls ERR_print_errors_fp(stderr)) EVP_PKEY_CTX* keygen_ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL); EVP_PKEY* pkey = NULL; if (EVP_PKEY_keygen_init(keygen_ctx)1) OSSL_err(); else printf(keygen init ok\n); if (EVP_PKEY_CTX_set_rsa_keygen_bits(keygen_ctx, 2048)1) OSSL_err(); else printf(set rsa keygen bits ok\n); if (EVP_PKEY_CTX_set_rsa_padding(keygen_ctx, RSA_PKCS1_PSS_PADDING)1) OSSL_err(); if (EVP_PKEY_CTX_set_rsa_pss_saltlen(keygen_ctx, -2)1) OSSL_err(); if (EVP_PKEY_keygen(keygen_ctx, pkey)1) OSSL_err(); else printf(keygen ok\n); When I call the functions in this order, I get everything okay up to set_rsa_padding, which returns 0:error:0408F090:rsa routines:PKEY_RSA_CTRL:illegal or unsupported padding mode:rsa_pmeth.c:403: 0:error:06089093:digital envelope routines:EVP_PKEY_CTX_ctrl:command not supported:pmeth_lib.c:358: If I call set_rsa_pss_salten before set_rsa_padding, I get 0:error:06089094:digital envelope routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:351: EVP_PKEY_keygen works if I call it before those two. I also tried to use EVP_PKEY_CTX_set_signature_md before them, to no avail. Is there anything obvious I'm missing? I tried building the library and enabling debug mode, but I can't get gdb to find the source. Simply browsing the code got me nowhere. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Server ECDSA certificate requirements for 1.0.1f?
I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). The same server can consume RSA and DSA certificates. (In fact, all the public key and certificate routines are generic and only differ by EVP key type, so the same routines produced the RSA, DSA and ECDSA keys and certs). The ECDSA CA and Server certs are built using P-256 (specifically, NID_X9_62_prime256v1) and SHA-256. The server cert verifies as expected: $ openssl verify -CAfile signing-ecdsa-cert.pem server-ecdsa-cert.pem server-ecdsa-cert.pem: OK Server cert signature algorithm is ecdsa-with-SHA256. The cert key usage is Digital Signature, Key Encipherment, Key Agreement. AKI and SKI are present. EKU is *not* present. (Again, these same certs work with RSA and DSA). When loading them into the server, SSL_CTX_use_certificate_chain_file, SSL_CTX_use_PrivateKey_file, and SSL_CTX_check_private_key succeed. I also perform manual verification on the key, the certifcate, and the chain (in addition to OpenSSL's SSL_CTX_check_private_key). Cipher numbers one and two in the server are ECDHE-ECDSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES128-GCM-SHA256 when using ECDSA. Using default ciphers by removing the call to SSL_CTX_set_cipher_list does not help. When testing under RSA, the ECDH callback is successfully inovked. When teting under ECDSA, the ECDH callback is never invoked. When the negotiation fails, the server's SSL object reports 0x1408a0c1 (no shared cipher). Below is what it looks like from the client's perspective. I found one bug report form 2010 or so mentioning to ECSA and 0x1408a0c1, but it does not appear to be related (the source code no longer looks as described in the bug report). Any ideas what's going on here? Thanks in advance. ** $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect localhost:8443 -CAfile ./pki/signing-ecdsa-cert.pem CONNECTED(0003) 140404774033064:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 140404774033064:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: ... Verify return code: 0 (ok) Adding `-cipher` with ECDHE-ECDSA-AES128-GCM-SHA256 and ECDHE-ECDSA-AES256-GCM-SHA384 produce the same results. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
TLS Triple Handshakes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, the attack described in https://secure-resumption.com/ breaks also tls channel binding tls-unique RFC 5929. I would still like to use tls-unique for channel binding as defined in SCRAM (RFC 5802). Can OpenSSL be used for channel binding and protect against this attack if the session caching is disabled? SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF) Is it necessary to disable resumption using a different function? Kind regards, Fedor Brunner -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTFb30XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtHQIP/iF2Zg0pgBGbCpjACOI/Ug2e wWitxzPhAF0CF6ATE69uke+Q5QaSBee6w1y0hlKuLpayl1wZOqEnhLEUokpOkQZR DEOUFgk/EmU6RaMv0xRlUaB3VdT1F2zMvZ/gwK+3FrM6mNfEYG04JIIZhrD4DCtk 4Ce8FWRzTNIC4HG/OqA2PRp9dGPwm/JhEoTqexu282Qz1icGHQuNLq1HMj9gESbe dkuMg0v7W1YtrFJa1LYc2wOCugG3glya+zn+VRsC/8Ki8bejqkGWTYeAtDeg8yUm +9CFPhSoHYqNgOhAZ4SrRGyaKblnBI+NLEjOfCASqgCc7oJT3LNtWNNGJNgXoqiG 5gP9WLot39fKJ0g/gW0+PJQyCGMGYtYqJ9Xc93xcWmPZ7NGvn4p5wr/orBwyEB4S s62Q/HKzYb9xVpLvXhwHnjbHpWZS18wHNwIGquU6RL6Rl6Vzznl73+HC6u097zAG O+h/lfMmxsXIUbjMxpGazYjmNDR9rGCXzZ9xE498rkWIQIZBwTyyWxj2QSMtLv1v sQ6fmvnLP1aGEByrMjthHPQoFQtVruuGqmKoZ74lrIjttF5WgTBn5OdRoxeJUZPd eTZYrRe1zTKC+k6xqcixliQB2HB+zd4PAHt2IZiUaKR+W5Cu4ypJc4c0G4xNEtuN CZt2VD2yTjfTdlcjKSTH =nIoa -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [1.0.1f] RSA-PSS signing through EVP interface
And then there was enlightenment. Sometimes looking at the documentation a
hundred times is not enough ; it's the 101st which pays off.
I got the signature to work. Here's a minimal example:
/* key generation */
EVP_PKEY_CTX* keygen_ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
EVP_PKEY* pkey = NULL;
if (EVP_PKEY_keygen_init(keygen_ctx)1) OSSL_err();
if (EVP_PKEY_CTX_set_rsa_keygen_bits(keygen_ctx, 2048)1) OSSL_err();
if (EVP_PKEY_keygen(keygen_ctx, pkey)1) OSSL_err();
/* signing */
EVP_MD_CTX* md_ctx = EVP_MD_CTX_create();
if (EVP_DigestSignInit(md_ctx, keygen_ctx, EVP_sha256(), NULL, pkey)1)
OSSL_err();
if (EVP_PKEY_CTX_set_rsa_padding(keygen_ctx, RSA_PKCS1_PSS_PADDING)1)
OSSL_err();
if (EVP_PKEY_CTX_set_rsa_pss_saltlen(keygen_ctx, -2)1)
OSSL_err();
char* message = Welcome to die!;
unsigned int message_l = strlen(message);
unsigned int signature_l = EVP_PKEY_size(pkey);
unsigned char signature[signature_l];
if (EVP_DigestSignUpdate(md_ctx, message, message_l)1) OSSL_err();
if (EVP_DigestSignFinal(md_ctx, signature, signature_l)1) OSSL_err();
/* verifying */
EVP_MD_CTX* verif_ctx = EVP_MD_CTX_create();
if (EVP_DigestVerifyInit(verif_ctx, keygen_ctx, EVP_sha256(), NULL, pkey)1)
OSSL_err();
if (EVP_PKEY_CTX_set_rsa_padding(verif_ctx-pctx, RSA_PKCS1_PSS_PADDING)1)
OSSL_err();
if (EVP_PKEY_CTX_set_rsa_pss_saltlen(verif_ctx-pctx, -2)1)
OSSL_err();
if (EVP_DigestVerifyUpdate(verif_ctx, message, message_l)1)
OSSL_err();
int res = EVP_DigestVerifyFinal(verif_ctx, signature, signature_l);
switch(res) {
case 1:printf(sig checks out!\n); break;
case 0:printf(nope nope nope.\n); break;
default: OSSL_err();
}
This also works if I call EVP_Digest*Init with NULL as the second argument, and
then use the EVP_PKEY_CTX_set* functions on md_ctx-pctx before calling
EVP_Digest*Update. But this is, I suppose, not the intended way to do it.
If I understand correctly, my mistake was assuming that a EVP_PKEY_CTX is a
structure used only for key generation, rather than an all-purpose public key
structure used for all operations.
Sorry for spamming the list!
- Original Message -
From: Kevin Le Gouguec kevin.le-goug...@insa-lyon.fr
To: openssl-users@openssl.org
Sent: Tuesday, March 4, 2014 12:16:21 PM
Subject: [1.0.1f] RSA-PSS signing through EVP interface
Hello,
I'm having a hard time figuring out how to use the EVP interface to get a
RSA-PSS signature. I can successfully call RSA_padding_add_PKCS1_PSS, but when
I try to call the various macros for EVP_PKEY_CTX_ctrl.
The thing is, I'm not sure in which order (if any) these functions should be
called. Currently, this is what I have: (OSSL_err() calls
ERR_print_errors_fp(stderr))
EVP_PKEY_CTX* keygen_ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
EVP_PKEY* pkey = NULL;
if (EVP_PKEY_keygen_init(keygen_ctx)1) OSSL_err();
else printf(keygen init ok\n);
if (EVP_PKEY_CTX_set_rsa_keygen_bits(keygen_ctx, 2048)1) OSSL_err();
else printf(set rsa keygen bits ok\n);
if (EVP_PKEY_CTX_set_rsa_padding(keygen_ctx, RSA_PKCS1_PSS_PADDING)1)
OSSL_err();
if (EVP_PKEY_CTX_set_rsa_pss_saltlen(keygen_ctx, -2)1) OSSL_err();
if (EVP_PKEY_keygen(keygen_ctx, pkey)1) OSSL_err(); else printf(keygen
ok\n);
When I call the functions in this order, I get everything okay up to
set_rsa_padding, which returns
0:error:0408F090:rsa routines:PKEY_RSA_CTRL:illegal or unsupported padding
mode:rsa_pmeth.c:403:
0:error:06089093:digital envelope routines:EVP_PKEY_CTX_ctrl:command not
supported:pmeth_lib.c:358:
If I call set_rsa_pss_salten before set_rsa_padding, I get
0:error:06089094:digital envelope routines:EVP_PKEY_CTX_ctrl:invalid
operation:pmeth_lib.c:351:
EVP_PKEY_keygen works if I call it before those two. I also tried to use
EVP_PKEY_CTX_set_signature_md before them, to no avail.
Is there anything obvious I'm missing? I tried building the library and
enabling debug mode, but I can't get gdb to find the source. Simply browsing
the code got me nowhere.
__
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: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Viktor Dukhovni wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. Well the two should act as a filter for ciphersuites the server will accept. If digital signature is set any ciphersuites which uses the certificate for signing is permissible: which is normally the ephemeral ones. Additionally an EC temporary curve needs to be set as you point out. If key agreement is set the less common ciphersuites which use the server certificate for ECDH are permitted too. If key usage is absent then both can be 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: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; When testing under RSA, the ECDH callback is successfully inovked. When testing under ECDSA, the ECDH callback is never invoked. What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. Non of them are critical. Extended Key Usage is not specified. Its not present in the certifcate (as opposed to present but empty). Let me try adding a EKU of serverAuth to see if that helps. Jeff According to RFC 5280: 4.2.1.12. Extended Key Usage This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension... ... If the extension is present, then the certificate MUST only be used for one of the purposes indicated. I avoided EKU because I've seen some Java clients reject a server's cert due to differences between KU and EKU. Since EKU only offers serverAuth, it can cause problems in key transport schemes. But the really odd thing is RSA and DSA are OK. Its odd that ECDSA is the only cert type causing my head aches. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 10:03 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: ... What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. Non of them are critical. Extended Key Usage is not specified. Its not present in the certifcate (as opposed to present but empty). Let me try adding a EKU of serverAuth to see if that helps. The certifcate now includes EKU of TLS Web Server Authentication. But still no joy. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 10:03:54AM -0500, Jeffrey Walton wrote: What is in the (non-extended) keyUsage extension of the certificate? IIRC with EC, if the keyUsage extension is present, the certificate needs to be marked usable for keyAgreement. From ssl/ssl_lib.c: ecdh_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_KEY_AGREEMENT) : 1; and right below that: ecdsa_ok = (x-ex_flags EXFLAG_KUSAGE) ? (x-ex_kusage X509v3_KU_DIGITAL_SIGNATURE) : 1; so you need at least both of digitalSignature and keyAgreement: https://www.openssl.org/docs/apps/x509v3_config.html#Key_Usage_ or don't include the extension at all. The server's Key Usage is Digital Signature, Key Encipherment, Key Agreement. None of them are critical. That should be sufficient. The next couple of lines in ssl_lib.c are: if (!(cpk-valid_flags CERT_PKEY_SIGN)) ecdsa_ok = 0; I am not familiar with the circumstances under which this might be false. Let me try adding a EKU of serverAuth to see if that helps. Does the TLS client actually offer any ECDSA ciphers? It needs to negotiate TLSv1 or higher to send a TLS extensions with a list of supported curves. You should check the content of the client SSL HELLO with wireshark or similar. Does the certificate/private key combination in question work with openssl s_server as the server? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; Silly question time . Viktor asked if you'd set an ECDHE curve and you responded saying yes and a list of ciphersuites which by themselves don't set a curve. So just to double check: you did set a temporary curve parameters using something like SSL_CTX_set_tmp_ecdh? 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: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Can you check to see if ECDH_callback is being called at all? I suspect it
isn't.
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: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 05:46:45PM +0100, Dr. Stephen Henson wrote: NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried returning NID_secp256k1 with the same result. I'm setting up Wireshark now on another machine to get the trace. Can you check to see if ECDH_callback is being called at all? I suspect it isn't. Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Also the callback does not appear to be caching the ECDHE key, possibly leaking a key for every handshake (if it were ever called). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:46 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01], the more common ECDSA cipher-suites use kEECDH key agreement. Yes. The server's preferred cipher list is: static const char PREFERRED_CIPHERS[] = ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-SHA: DHE-RSA-AES128-SHA: EDH-RSA-DES-CBC3-SHA: DH-RSA-DES-CBC3-SHA; Silly question time . Viktor asked if you'd set an ECDHE curve and you responded saying yes and a list of ciphersuites which by themselves don't set a curve. So just to double check: you did set a temporary curve parameters using something like SSL_CTX_set_tmp_ecdh? This is in the server's context setup code: SSL_CTX_set_tmp_dh_callback(ctx, DH_callback); SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback); And: ... Can you check to see if ECDH_callback is being called at all? I suspect it isn't. There's actually a debug logging line in ECDH_callback. Its not being called when using the ECDSA cert. (And it is being called when RSA cert is used). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:51 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 05:46:45PM +0100, Dr. Stephen Henson wrote: NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried returning NID_secp256k1 with the same result. I'm setting up Wireshark now on another machine to get the trace. Can you check to see if ECDH_callback is being called at all? I suspect it isn't. Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Also the callback does not appear to be caching the ECDHE key, possibly leaking a key for every handshake (if it were ever called). OK, I have not gotten that far. Thanks for the heads up. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:46 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org
wrote:
On Tue, Mar 04, 2014, Jeffrey Walton wrote:
On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
On Tue, Mar 04, 2014 at 06:35:13AM -0500, Jeffrey Walton wrote:
I've got a server that can't negotiate a cipher suite with a client
when using ECDSA certificates. When using ECDSA, the server reports
0x1408a0c1 (no shared cipher).
Did you configure an EECDH (aka ECDHE) curve? With OpenSSL 1.0.[01],
the more common ECDSA cipher-suites use kEECDH key agreement.
Yes. The server's preferred cipher list is:
static const char PREFERRED_CIPHERS[] =
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES256-SHA:
DHE-RSA-AES128-SHA:
EDH-RSA-DES-CBC3-SHA:
DH-RSA-DES-CBC3-SHA;
Silly question time . Viktor asked if you'd set an ECDHE curve and you
responded saying yes and a list of ciphersuites which by themselves don't
set a curve.
So just to double check: you did set a temporary curve parameters using
something like SSL_CTX_set_tmp_ecdh?
This is in the server's context setup code:
SSL_CTX_set_tmp_dh_callback(ctx, DH_callback);
SSL_CTX_set_tmp_ecdh_callback(ctx, ECDH_callback);
And:
EC_KEY* ECDH_callback(SSL *ssl, int is_export, int keylength)
{
return ECDH256();
}
Finally:
static EC_KEY* ECDH256()
{
EC_KEY* key = EC_KEY_new_by_curve_name(NistCurveToNidByBits(256));
unsigned long err = ERR_get_error();
...
return key;
}
NistCurveToNidByBits(256) returns NID_X9_62_prime256v1. I also tried
returning NID_secp256k1 with the same result.
I'm setting up Wireshark now on another machine to get the trace.
Can you check to see if ECDH_callback is being called at all? I suspect it
isn't.
Going back to my config notes:
# Open Configure, change '-O3' to '-Os'
# Open Configure, add '-g3' to target linux-x86_64
./config fips shared no-ssl2 no-ec2m enable-ec_nistp_64_gcc_128
no-srp no-psk
openssl-fips-ecp-2.0.5.tar.gz is the underlying fips tar ball.
Do any of the config options set off alarm bells? (I'm getting ready
to try a build using -O3).
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... read from 0x736bc0 [0x73c1a3] (5 bytes = 5 (0x5)) - 15 03 03 00 02. read from 0x736bc0 [0x73c1a8] (2 bytes = 2 (0x2)) - 02 28 .( 139925962778272:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 139925962778272:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None SRP username: None Start Time: 1393954054 Timeout : 7200 (sec) Verify return code: 0 (ok) --- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. If you use OpenSSL 1.0.2 and you configure with enable-ssl-trace you get a -trace option added to s_client/s_server which is *very* useful for debugging. 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: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 11:59:42AM -0500, Jeffrey Walton wrote: Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Usually, after setting a key and a certificate chain, one calls SSL_CTX_check_private_key(ctx) to check that the most recent cert and key loaded are compatible. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014 at 12:34:22PM -0500, Jeffrey Walton wrote: I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... Find a decoder, or post a PCAP file. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 1:28 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 11:59:42AM -0500, Jeffrey Walton wrote: Perhaps the server's EC private key is not being set correctly, so it can't use the certificate. Is there a way to test this? Usually, after setting a key and a certificate chain, one calls SSL_CTX_check_private_key(ctx) to check that the most recent cert and key loaded are compatible. Yes, did that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 12:34 PM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 4, 2014 at 11:19 AM, Dr. Stephen Henson st...@openssl.org wrote: ... I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug Here's the dump from s_server. $ /usr/local/ssl/bin/openssl s_server -accept 8443 -cert server-ecdsa-cert.pem -key server-ecdsa-key-plain.pem -debug Using default temp DH parameters Using default temp ECDH parameters ACCEPT read from 0x13f0550 [0x13f5c40] (11 bytes = 11 (0xB)) - 16 03 01 01 2e 01 00 01-2a 03 03 *.. read from 0x13f0550 [0x13f5c4e] (296 bytes = 296 (0x128)) - 07 de ce 27 aa ae 3e bf-e2 31 73 46 0d 4a 50 cc ...'1sF.JP. 0010 - f2 09 0f 3e a0 1d 59 d8-e7 63 93 ea 39 37 f4 92 .Y..c..97.. 0020 - 00 00 94 c0 30 c0 2c c0-28 c0 24 c0 14 c0 0a 00 0.,.(.$. 0030 - a3 00 9f 00 6b 00 6a 00-39 00 38 00 88 00 87 c0 k.j.9.8. 0040 - 32 c0 2e c0 2a c0 26 c0-0f c0 05 00 9d 00 3d 00 2...*=. 0050 - 35 00 84 c0 12 c0 08 00-16 00 13 c0 0d c0 03 00 5... 0060 - 0a c0 2f c0 2b c0 27 c0-23 c0 13 c0 09 00 a2 00 ../.+.'.#... 0070 - 9e 00 67 00 40 00 33 00-32 00 9a 00 99 00 45 00 ..g.@.3.2.E. 0080 - 44 c0 31 c0 2d c0 29 c0-25 c0 0e c0 04 00 9c 00 D.1.-.).%... 0090 - 3c 00 2f 00 96 00 41 00-07 c0 11 c0 07 c0 0c c0 ./...A. 00a0 - 02 00 05 00 04 00 15 00-12 00 09 00 14 00 11 00 00b0 - 08 00 06 00 03 00 ff 01-00 00 6d 00 0b 00 04 03 ..m. 00c0 - 00 01 02 00 0a 00 34 00-32 00 0e 00 0d 00 19 00 ..4.2... 00d0 - 0b 00 0c 00 18 00 09 00-0a 00 16 00 17 00 08 00 00e0 - 06 00 07 00 14 00 15 00-04 00 05 00 12 00 13 00 00f0 - 01 00 02 00 03 00 0f 00-10 00 11 00 23 00 00 00 #... 0100 - 0d 00 20 00 1e 06 01 06-02 06 03 05 01 05 02 05 .. . 0110 - 03 04 01 04 02 04 03 03-01 03 02 03 03 02 01 02 0120 - 02 02 03 00 0f 00 01 01- write to 0x13f0550 [0x13ff730] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 28 ..( ERROR 140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353: shutting down SSL CONNECTION CLOSED __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 1:33 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, Mar 04, 2014 at 12:34:22PM -0500, Jeffrey Walton wrote: I'm setting up Wireshark now on another machine to get the trace. The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's what I got on two different machines: http://postimg.org/image/wxxfx0exd/. Perhaps I have missed a Wireshark configuration option somewhere (most of the time, its port 443 so everything works as expected). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, March 04, 2014 12:34 The Wireshark trace is useless (to me) because its only displaying TCP traffic (and not breaking out the SSL/TLS protocol). I can't break the bits out in my head. right-click one of your packets in the packet list, DecodeAs..., make sure Transport has your port number (here 8443), pick SSL in the list at the right, OK. Here's -debug from a separate s_client on a different physical machine. $ /usr/local/ssl/bin/openssl s_client -tls1_2 -connect debian-q500:8443 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -debug CONNECTED(0003) write to 0x736bc0 [0x7406f3] (163 bytes = 163 (0xA3)) - 16 03 01 00 9e 01 00 00-9a 03 03 12 a5 1d c3 7e ...~ 0010 - 5e e1 dc 20 c3 9e da dd-cb 66 8f 0b d0 6c 24 13 ^.. .f...l$. 0020 - e0 b5 de ef 54 5f cd 2c-4c 53 37 00 00 04 c0 2b T_.,LS7+ 0030 - 00 ff 01 00 00 6d 00 0b-00 04 03 00 01 02 00 0a .m.. 0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2 0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 20 00 1e ...#. .. bytes at 42 through 75 are (body of) supported_curves and does include 00 17 which is P-256 -- which s_client always does. 0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f 00a0 - 00 01 01 ... read from 0x736bc0 [0x73c1a3] (5 bytes = 5 (0x5)) - 15 03 03 00 02. read from 0x736bc0 [0x73c1a8] (2 bytes = 2 (0x2)) - 02 28 .( 139925962778272:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40 139925962778272:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: snip but that reminds me: does your ECDSA cert have the publickey in named=OID format, NOT explicit (prime + coefficients + point + order etc.)? If your real client, like openssl, only offers named curves not explicit, a cert containing an explicit key cannot be selected, even if the explicit parameters are actually the parameters for a name-able curve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 6:35 AM, Jeffrey Walton noloa...@gmail.com wrote: I've got a server that can't negotiate a cipher suite with a client when using ECDSA certificates. When using ECDSA, the server reports 0x1408a0c1 (no shared cipher). The same server can consume RSA and DSA certificates. (In fact, all the public key and certificate routines are generic and only differ by EVP key type, so the same routines produced the RSA, DSA and ECDSA keys and certs). The ECDSA CA and Server certs are built using P-256 (specifically, NID_X9_62_prime256v1) and SHA-256. Here's a test set of keys and certs: http://wiki.openssl.org/index.php/file:ecdsa-keys-and-certs.tar.gz. The files are PEM-encoded and described below:: * signing-ecdsa-cert.pem - the CA cert * signing-ecdsa-key-plain.pem - the CA key, no password * server-ecdsa-cert.pem - the server cert * server-ecdsa-key-plain.pem - the server key, no password The server has two SANs and one is 'localhost', so it should be testable. Sorry to put it on the OpenSSL wiki. I'm not up on file sharing sites, and I don't know where to go to avoid porn and malware. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 2:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, March 04, 2014 12:34 ... but that reminds me: does your ECDSA cert have the publickey in named=OID format, NOT explicit (prime + coefficients + point + order etc.)? If your real client, like openssl, only offers named curves not explicit, a cert containing an explicit key cannot be selected, even if the explicit parameters are actually the parameters for a name-able curve. If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? Thanks for the help. $ openssl x509 -in server-ecdsa-cert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 2718864780398442230 (0x25bb591cd3f836f6) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, O=Example, LLC, CN=Example, LLC Certification Authority Validity Not Before: Mar 3 00:00:00 2014 GMT Not After : Mar 12 00:00:00 2014 GMT Subject: O=Example, LLC/emailAddress=supp...@example.com, CN=Example, LLC Proxy Certificate Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:0e:2d:72:28:74:9f:0c:88:e4:25:a3:d4:09:1e: e6:7a:d0:97:89:ed:a4:8d:97:a7:56:aa:63:9d:ee: 94:a1:dd:2d:67:91:8a:88:1f:f9:ba:c3:22:1d:11: c6:8a:7e:a6:72:57:37:cf:dd:fc:eb:01:ca:5a:32: 55:5e:99:da:1c Field Type: prime-field Prime: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff A: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:fc B: 5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86: bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2: 60:4b Generator (uncompressed): 04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4: 40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8: 98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a: 7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40: 68:37:bf:51:f5 Order: 00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff: ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc: 63:25:51 Cofactor: 1 (0x1) Seed: c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26: b7:81:9f:7e:90 X509v3 extensions: X509v3 Subject Alternative Name: DNS:debian-q500 X509v3 Subject Alternative Name: DNS:localhost X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment, Key Agreement Netscape Comment: Powered by OpenSSL X509v3 Subject Key Identifier: 6A:12:D9:BD:F1:C1:33:A8:68:C9:9C:F6:51:99:3F:49:1E:5C:BF:DA X509v3 Authority Key Identifier: keyid:BD:84:4D:C6:A7:22:72:E9:91:08:4E:FA:50:5C:12:73:22:3A:02:7E Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:7d:0d:5b:9f:7a:68:c5:a7:4f:37:f1:2b:43:5b: c7:77:bb:c6:6d:cd:2d:cf:78:dc:bd:13:2e:f8:16:72:9e:bc: 02:20:68:d5:71:45:48:b6:01:23:0a:87:e1:96:ff:8d:1d:c9: 5d:d0:62:ce:5d:ba:ce:c2:fa:73:29:d4:0d:c8:f1:1c __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate 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
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: If that's the case, then that's probably it. Below is a sample. I've been using PEM_write_PKCS8PrivateKey and PEM_write_X509. What does one use to write the named curve? It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); 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
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: Server ECDSA certificate requirements for 1.0.1f?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Tuesday, 04 March, 2014 13:43 On Tue, Mar 4, 2014 at 1:33 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: The wireshark gui decodes SSL handshakes everywhere I've tried it, but you have to have the right compile-time options, and ask it to decode as ssl. Here's what I got on two different machines: http://postimg.org/image/wxxfx0exd/. Perhaps I have missed a Wireshark configuration option somewhere (most of the time, its port 443 so everything works as expected). Open the Analyze menu (or right-click on a packet in the upper frame), select Decode as..., and pick SSL from the list. Note that Wireshark is only able to decode encrypted traffic under fairly stringent conditions: it needs an RSA-keyed cipher suite, it has to be built with the appropriate support, it has to be built to use GnuTLS rather than OpenSSL or BSAFE as its SSL/TLS library, and it has to have access to the server's private key. But even without all that it can decode the unencrypted portions of the flows. The Wireshark documentation is decent. See http://wiki.wireshark.org/SSL to start; the wireshark.org search function finds a lot more information about SSL/TLS dissection. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
RE: Certificate chain verification in-memory using X509's?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Sunday, 02 March, 2014 03:14 I'm trying to add some key and certificate validation code to help diagnose potential issues. X509_verify allows me to verify an X509 and EVP_PKEY pair. verify.c has certificate validation code, but it appears to work from the file system (X509_STORE_add_lookup(), X509_LOOKUP_file(), X509_LOOKUP_hash_dir() and friends). Is there anything which allows validation of X509 chains in memory? Don't think I've seen an answer to this yet... The X509_STORE* functions can be used in applications, but they're largely not documented (as the OpenSSL documentation page for SSL_CTX_set_cert_store admits). By trawling through some code, some old libeay docs, and what's in the OpenSSL docs page, I was able to write code for in-memory certificate validation using X509_STORE_new, X509_STORE_add_cert, and X509_STORE_free; it compiles but I haven't gotten around to testing it yet. Then there's the X509_STORE_CTX* family, which may be more appropriate to your requirements. My understanding is that X509_STORE* is typically used to set up the global configuration, and X509_STORE_CTX* for a specific context. Take a look at: http://www.umich.edu/~x509/ssleay/x509_store.html http://www.openssl.org/docs/crypto/X509_STORE_CTX_new.html http://stackoverflow.com/questions/6646841/what-is-the-difference-between-x509-store-and-x509-store-ctx http://www.openssl.org/docs/ssl/SSL_CTX_set_cert_store.html This may also be useful: http://stackoverflow.com/questions/16291809/openssl-programatically-verify-certificate-chain-in-c-in-memory-certs -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: AES CCM in DTLS v1.2
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
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 3:26 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: ... It is stored in the private key when the key is generated. How did you generate it? int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); That was it. Thank you guys very much. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server ECDSA certificate requirements for 1.0.1f?
On Tue, Mar 4, 2014 at 3:26 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 04, 2014, Jeffrey Walton wrote: On Tue, Mar 4, 2014 at 2:25 PM, Dr. Stephen Henson st...@openssl.org wrote: ... int nid = ... EC_KEY* key = EC_KEY_new_by_curve_name(nid); int rc = EC_KEY_generate_key(key); EVP_PKEY * pkey = EVP_PKEY_new(); rc = EVP_PKEY_assign_EC_KEY(pkey, key); Ah, the default is unfortunately to use explicit parameters. You can change that with: EC_KEY_set_asn1_flag(key, OPENSSL_EC_NAMED_CURVE); Would you happen to know if its a problem with the key, the certificate, or both? I ask because I have my own validation routines, and I can add additional checks so the issue can be spotted early in code and logged to the appropriate place. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EC_KEY, EC_KEY_get_flags and OPENSSL_EC_NAMED_CURVE
I'm reading a private key from disk and trying to validate it. The key was saved with OPENSSL_EC_NAMED_CURVE. After reading the key from disk, I perform the following: __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: EC_KEY, EC_KEY_get_flags and OPENSSL_EC_NAMED_CURVE
On Tue, Mar 4, 2014 at 6:46 PM, Jeffrey Walton noloa...@gmail.com wrote:
I'm reading a private key from disk and trying to validate it. The key
was saved with OPENSSL_EC_NAMED_CURVE.
[sorry about that half-post]
Here's what I needed:
int EC_KEY_get_asn1_flag(const EC_KEY* key)
{
ASSERT(key);
if (key)
{
const EC_GROUP* group = EC_KEY_get0_group(key);
ASSERT(group);
if (group)
return EC_GROUP_get_asn1_flag(group);
}
return 0;
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
