Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Using

openssl s_client -host myserver.net -port 443

I can see the cipher negotiated is indeed using ECDHE for session key exchange:

SSL handshake has read 5894 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

Both the client and the server use exactly the same OpenSSL version "OpenSSL 1.0.1e 11 Feb 2013" and I can get the list of available, builtin curves using:

openssl ecparam -list_curves

However, how do I find out which elliptic curve is actually being used in the session?

For completeness, here are the TLS handshake messages relevant to curve negotiation from a real-world session (using the openssl command given by Thomas):

ClientHello:

>>> TLS 1.2 Handshake [length 013c], ClientHello
    01 00 01 38 03 03 52 6c 53 04 fb 32 94 d4 f4 91
    53 fe 59 5c d1 58 7f e0 67 e0 22 db da f4 8d ac
    dc 15 68 21 3d ec 00 00 a0 c0 30 c0 2c c0 28 c0
    24 c0 14 c0 0a c0 22 c0 21 00 a3 00 9f 00 6b 00
    6a 00 39 00 38 00 88 00 87 c0 32 c0 2e c0 2a c0
    26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 12 c0
    08 c0 1c c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0
    2f c0 2b c0 27 c0 23 c0 13 c0 09 c0 1f c0 1e 00
    a2 00 9e 00 67 00 40 00 33 00 32 00 9a 00 99 00
    45 00 44 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00
    9c 00 3c 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0
    0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00
    11 00 08 00 06 00 03 00 ff 01 00 00 6f 00 0b 00
    04 03 00 01 02[00 0a 00 34 00 32 00 0e 00 0d 00 [>>  ?
    19 00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00
    08 00 06 00 07 00 14 00 15 00 04 00 05]00 12 00  <<] ?
    13 00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00
    00 00 0d 00 22 00 20 06 01 06 02 06 03 05 01 05
    02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02
    01 02 02 02 03 01 01 00 0f 00 01 01

ServerKeyExchange:

<<< TLS 1.2 Handshake [length 014d], ServerKeyExchange
    0c 00 01 49 03 00 17 41 04 7e 74 d7 ed f4 7b 2f
    ...
share|improve this question

2 Answers 2

up vote 5 down vote accepted

You can make OpenSSL print out the handshake messages with the -msg parameter:

openssl s_client -msg -connect myserver.net:443

Then look for the ServerKeyExchange message. Here is an example:

<<< TLS 1.2 Handshake [length 014d], ServerKeyExchange
    0c 00 01 49 03 00 17 41 04 6b d8 6e 14 1c 9b 12
    4d 58 29 20 e8 e2 1a 24 0d da 8f 38 1a 5d 85 2b
    2b 70 61 97 3b a7 5b fd b6 14 b3 5d f0 dd ea 7b
    68 d9 eb bc b2 59 32 52 9d 8e 9c 97 c0 d4 45 4c
    (...)

This can be analyzed, using RFC 5246 and RFC 4492 as references. In this case:

  • 0c: this is a ServerKeyExchange message (described in section 5.4 of RFC 4492)
  • 00 01 49: of length 0x000149 bytes (329 bytes)
  • 03: the curve type is "named_curve"
  • 00 17: the curve is secp256r1 (curve identifiers are in section 5.1.1, identifier 0x0017 is 23 in decimal).

secp256r1 is also known as P-256, one of the 15 curves standardized by NIST in FIPS 186-4. In fact this is the curve that almost everybody uses.

share|improve this answer
    
Fantastic! And yes, secp256r1 is also what I get: <<< TLS 1.2 Handshake [length 014d], ServerKeyExchange 0c 00 01 49 03 00 17 41 04 7e 74 d7 ed f4 7b 2f –  oberstet Oct 26 '13 at 23:43
    
Would you mind pointing out the relevant bits in the ClientHello (I've updated the question) where the client announces the curves it is willing to use? I am having a hard time wading through the RFCs as I am not at all experienced with TLS wire-level. Thank you very much! –  oberstet Oct 27 '13 at 0:09

For what it's worth, the OpenSSL developers have committed changes that improve this. I assume they will be in OpenSSL 1.0.2, but I don't know for sure. In any case, if you clone the git repo and compile the OpenSSL_1_0_2-stable branch (or master, I suppose), s_client will display the curve name:

$ OPENSSL_CONF=apps/openssl.cnf apps/openssl s_client -CApath /etc/ssl/certs/ -connect mn9.us:443
...
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3876 bytes and written 499 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported  
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
...

The third line quoted gives the colloquial name, "P-256", for everybody's favorite NIST curve.

By the way, there's also a new -brief command line option, which also displays it:

$ OPENSSL_CONF=apps/openssl.cnf apps/openssl s_client -brief -CApath /etc/ssl/certs/ -connect mn9.us:443
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256
Peer certificate: description = 1q3bI66tAjZYi6a1, C = US, CN = dynroute53.mn9.us, emailAddress = mnordhoff@gmail.com
Hash used: SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits
^C
share|improve this answer
    
Awesome, thanks! If I get this right, I can now see the actual curve negotiated in the end, but not the curves announced by the client in the first place? –  oberstet Dec 22 '13 at 9:58
    
That's right, I'm afraid. –  Matt Nordhoff Dec 22 '13 at 23:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.