[openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on Master Branch

Linsell, StevenX stevenx.linsell at intel.com
Fri Mar 20 12:44:24 UTC 2015


On Thu, Mar 19, 2015, Steve Linsell wrote:
> 
> I am trying to use ECDH-RSA-AES256-SHA with ssl3 with s_client and s_server on
> the master branch. (cloned at commit
> f7683aaf36341dc65672ac2ccdbfd4a232e3626d) and then retested  with a more
> recent clone: (commit da27006df06853a33b132133699a7aa9d4277920).

Following further testing I see identical failures in the master branch using the following cipher/protocol combinations:

ECDH-ECDSA-AES128-SHA      ssl3 
ECDH-ECDSA-AES256-SHA      ssl3            
ECDH-ECDSA-DES-CBC3-SHA    ssl3          
ECDH-ECDSA-RC4-SHA         ssl3               
ECDH-RSA-AES128-SHA        ssl3                    
ECDH-RSA-AES256-SHA        ssl3         
ECDH-RSA-DES-CBC3-SHA      ssl3          
ECDH-RSA-RC4-SHA           ssl3                
ECDHE-ECDSA-AES128-SHA     ssl3         
ECDHE-ECDSA-AES256-SHA     ssl3          
ECDHE-ECDSA-DES-CBC3-SHA   ssl3                
ECDHE-ECDSA-RC4-SHA        ssl3             

The issue appears to be anywhere an elliptical curve certificate (whether signed with rsa or ecdsa) is used with ssl3.
The error produced looks very similar to that produced when you generate a certificate without the OPENSSL_EC_NAMED_CURVE flag as described on the OpenSSL wiki, but as you can see from the dump of the certificate below in this case the ASN1 OID: prime256v1 line is present. The certificates also function fine with tls1, tls1.1 and tls1.2.

Is there anyone that can confirm that they see the same behaviour, to rule out my setup and certificate generation?

> Here is a dump of the certificate:
> ./openssl x509 -in prime256v1-rsaTestServer.cert.pem -text -noout
> Certificate:
>     Data:
>         Version: 1 (0x0)
>         Serial Number: 16838786626002069798 (0xe9af63387b73a926)
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc., OU=Sun
> Microsystems Laboratories, CN=Test CA (2048 bit RSA)
>         Validity
>             Not Before: Mar 13 11:38:21 2015 GMT
>             Not After : Apr 21 11:38:21 2019 GMT
>         Subject: C=US, ST=CA, L=Mountain View, O=Sun Microsystems, Inc.,
> OU=Sun Microsystems Laboratories, CN=Test Server (prime256v1 key signed
> with RSA)
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub:
>                     04:0d:a6:16:d8:43:25:dc:83:6d:18:fb:f0:b7:41:
>                     bc:05:88:a2:f2:56:8a:76:7a:d0:2b:7f:de:0a:44:
>                     33:4b:de:5b:30:44:ff:34:0e:17:c6:38:77:d7:53:
>                     b2:c2:fa:9f:7f:d5:e3:a4:b5:de:ce:29:9d:74:e6:
>                     59:76:9f:e6:eb
>                 ASN1 OID: prime256v1
>                 NIST CURVE: P-256
>     Signature Algorithm: sha256WithRSAEncryption
>          d0:1c:97:60:b9:14:cf:5a:c8:ea:8d:65:63:75:50:f2:63:68:
>          82:06:0c:47:f5:52:13:a5:61:4b:cd:99:ab:d0:56:81:a7:92:
>          21:c7:07:e3:12:25:4a:a8:c7:83:7a:bd:57:11:c7:55:88:28:
>          74:f1:37:bb:cd:0b:5b:7b:6f:45:e6:8d:1a:be:1a:fd:e0:d2:
>          5b:e5:ee:39:2e:73:c8:d6:03:5c:f6:f9:37:4a:81:e4:41:5a:
>          87:d5:0d:da:48:67:14:bb:75:3b:ae:68:b9:c4:25:2d:19:a7:
>          05:90:a2:fb:b4:d3:00:4f:40:19:e9:2d:83:75:db:3c:53:fe:
>          08:ae:ca:ba:3d:a5:4d:6e:f6:14:af:ee:7e:6d:dc:45:96:91:
>          92:6d:37:52:b6:b7:ad:70:02:d0:11:0d:84:1b:f1:3b:82:be:
>          66:af:a6:3c:17:33:d0:98:c3:cb:d3:22:39:d1:66:6e:94:ce:
>          7e:70:3c:02:29:6a:b6:87:e9:c4:e9:44:b4:9b:f1:8e:47:82:
>          2d:20:79:0e:f6:91:b1:e9:cf:83:66:8f:ff:e1:4f:2f:a1:ab:
>          ca:2d:81:53:7d:7f:69:b5:11:59:7e:9a:47:1c:6a:c8:83:54:
>          83:0a:7d:46:ec:2e:e9:82:f3:b4:d4:f6:04:57:bc:a5:b2:c5:
>          0c:ed:a6:fa
> 
> Single stepping through the code I can see the failure is occurring in
> tls1_check_ec_key when it is called from tls1_check_cert_param.
> It appears to go around a for loop (j) twice. The first time through it correctly
> matches the curve it is looking for. The second time round the list is empty and 0
> is returned. This failure causes the Elliptical curve cert not to be declared as valid
> and consequently the handshake fails with the no shared cipher message.
> I don't have a good understanding of how the certificate code works so I
> haven't managed to debug any further than that in order to determine why the
> second time round the loop the list is empty.
> 
> --
> Steve Linsell                                     Intel Shannon DCG/CID Software Development
> Team
> Stevenx.Linsell at intel.com
> 
Steve Linsell                                     Intel Shannon DCG/CID Software Development Team
Stevenx.Linsell at intel.com

--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.




More information about the openssl-users mailing list