Server ECDSA certificate requirements for 1.0.1f?

[Jeffrey Walton]

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(00000003)
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 : 0000
...
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 List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Viktor Dukhovni]

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.

[Dr. Stephen Henson]

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

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
<openss...@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.

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 10:03 AM, Jeffrey Walton <nolo...@gmail.com> wrote:
> On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
> <openss...@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

[Viktor Dukhovni]

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.

[Dr. Stephen Henson]

On Tue, Mar 04, 2014, Jeffrey Walton wrote:

> On Tue, Mar 4, 2014 at 9:02 AM, Viktor Dukhovni
> <openss...@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

[Jeffrey Walton]

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

[Dr. Stephen Henson]

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

[Viktor Dukhovni]

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.

[Jeffrey Walton]

>> ...

>
> 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

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 11:51 AM, Viktor Dukhovni
<openss...@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.

[Jeffrey Walton]

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:

>> 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).

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton <nolo...@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(00000003)
write to 0x736bc0 [0x7406f3] (163 bytes => 163 (0xA3))
0000 - 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))
0000 - 15 03 03 00 02 .....
read from 0x736bc0 [0x73c1a8] (2 bytes => 2 (0x2))
0000 - 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 : 0000

Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
SRP username: None
Start Time: 1393954054
Timeout : 7200 (sec)

Verify return code: 0 (ok)

---

[Dr. Stephen Henson]

On Tue, Mar 04, 2014, Jeffrey Walton wrote:

> On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton <nolo...@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

[Viktor Dukhovni]

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.

[Viktor Dukhovni]

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(00000003)
> write to 0x736bc0 [0x7406f3] (163 bytes => 163 (0xA3))
> 0000 - 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.

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 1:28 PM, Viktor Dukhovni
<openss...@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.

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 12:34 PM, Jeffrey Walton <nolo...@gmail.com> wrote:
> On Tue, Mar 4, 2014 at 11:41 AM, Jeffrey Walton <nolo...@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))
0000 - 16 03 01 01 2e 01 00 01-2a 03 03 ........*..
read from 0x13f0550 [0x13f5c4e] (296 bytes => 296 (0x128))
0000 - 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))
0000 - 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

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 1:33 PM, Viktor Dukhovni
<openss...@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

[Dave Thompson]

> From: owner-ope...@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(00000003)
> write to 0x736bc0 [0x7406f3] (163 bytes => 163 (0xA3))
> 0000 - 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))
> 0000 - 15 03 03 00 02 .....
> read from 0x736bc0 [0x73c1a8] (2 bytes => 2 (0x2))
> 0000 - 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.

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 6:35 AM, Jeffrey Walton <nolo...@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

[Jeffrey Walton]

On Tue, Mar 4, 2014 at 2:00 PM, Dave Thompson <dtho...@prinpay.com> wrote:
>> From: owner-ope...@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=sup...@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

[Dr. Stephen Henson]

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

[Jeffrey Walton]

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

[Dr. Stephen Henson]

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

[Michael Wojcik]

> From: owner-ope...@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
> <openss...@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

[Jeffrey Walton]

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.

[Jeffrey Walton]

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.