Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSSL 1.1.0 s_server doesn't work with secp384r1 and secp521r1 #2033

Closed
mildas opened this issue Dec 6, 2016 · 16 comments

Comments

Projects
None yet
@mildas
Copy link

commented Dec 6, 2016

As the title says, 1.1.0 s_server is not working with secp384r1 and secp521r1, but at 1.0.2a it is ok.
I tried OpenSSL 1.1.0 and OpenSSL 1.0.2a with curves from ecparam -list_curves and these 2 curves differs.

OpenSSL 1.0.2a s_client and s_server - both curves are ok

OpenSSL 1.1.0 s_server:

error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared
cipher:ssl/statem/statem_srvr.c:1422

then OpenSSL 1.1.0 s_client:

error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:ssl/record/rec_layer_s3.c:1382:SSL alert number 40

Keys and certs generated by:

openssl ecparam -genkey -name prime256v1 -out ca.key
openssl req -x509 -batch -new -key ca.key -out ca.cert -subj '/CN=ca'

for t in server client; do
          openssl ecparam -genkey -name prime256v1 -out $t.key
          openssl req -batch -new -key $t.key -out $t.csr -subj "/CN=$t"
          openssl x509 -req -CAkey ca.key -CA ca.cert -CAcreateserial
-in $t.csr -out $t.cert
          rm -f $t.csr
done

s_server command:

openssl s_server -key server.key -cert server.cert -CAfile ca.cert
-sigalgs ECDSA+SHA384:ECDSA+SHA256 -Verify 1 -named_curve secp384r1

s_client command:

openssl s_client -connect localhost:4433 -cert client.cert -key
client.key -CAfile ca.cert -tls1_2 -sigalgs ECDSA+SHA384:ECDSA+SHA256
@mattcaswell

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

Yes, @vdukhovni independently discovered this same issue recently. The problem is that in 1.1.0 the supported curves affect both ECDHE and ECDSA. They should really be independent of each other. This means you can't use a different curve in your ECDSA certificate to the curve used for ECDHE.

Ping @vdukhovni and @snhenson, how do we progress this?

@vdukhovni

This comment has been minimized.

Copy link

commented Jan 8, 2017

The correct approach is outlined in the TLS 1.3 draft. We need to choose a certificate that matches a client supported signature algorithm if possible, but otherwise go with some default certificate.

What this means for OpenSSL is that the server's ECDHE curve list SHOULD NOT be used to constrain the server's certificate. While we must choose the ECDHE curve based on the intersection of the server and client supported curves list, the server certificate need only appear on the client curve list, and the server curve list should be ignored in this context. In addition if the only EC certificate uses a curve that is not on the client's supported curves list, and we have no alternative (RSA or DSA) certificate to choose from, we just go with the certificate we have, and leave its ultimate suitability up to the client.

@snhenson

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2017

Actually the supported curves list affects ECDH and ECDSA in both 1.1.0 and 1.0.2. The difference is that the -named_curve option works by changing the list of server supported curves in 1.1.0: it didn't in 1.0.2.

@vdukhovni

This comment has been minimized.

Copy link

commented Jan 8, 2017

Sure, so we may also need to fine-tune 1.0.2 at some point, with the 1.1.0 situation being a bit more "urgent" as it is not backwards-compatible. Are you willing to take this on, or will it have to wait for me to find the time?

@theilgaard

This comment has been minimized.

Copy link

commented Mar 15, 2017

I would like to use ECDHE with the secp384r1 curve to adhere to NSA's suite B, is there a workaround at the moment?

@mke208

This comment has been minimized.

Copy link

commented Dec 1, 2017

@mattcaswell mattcaswell modified the milestones: 1.1.0, 1.1.1 Jan 18, 2018

@darix

This comment has been minimized.

Copy link

commented Mar 12, 2018

Did you come up with a plan how to fix this issue? haproxy is a nice tool to trigger this issue.

@denji

This comment has been minimized.

Copy link

commented Mar 12, 2018

@darix LibreSSL?

@vdukhovni

This comment has been minimized.

Copy link

commented Mar 12, 2018

My focus area is chain verification, which is rather separate from SSL protocol cipher selection, ... I hope that @mattcaswell will take a look at this, and decouple the certificate from supported curves...

mattcaswell added a commit to mattcaswell/openssl that referenced this issue Mar 12, 2018

Tolerate a Certificate using a non-supported group on server side
If a server has been configured to use an ECDSA certificate, we should
allow it regardless of whether the server's own supported groups list
includes the certificate's group.

Fixes openssl#2033

mattcaswell added a commit to mattcaswell/openssl that referenced this issue Mar 12, 2018

Tolerate a Certificate using a non-supported group on server side
If a server has been configured to use an ECDSA certificate, we should
allow it regardless of whether the server's own supported groups list
includes the certificate's group.

Fixes openssl#2033
@mattcaswell

This comment has been minimized.

Copy link
Member

commented Mar 12, 2018

My focus area is chain verification, which is rather separate from SSL protocol cipher selection, ... I hope that @mattcaswell will take a look at this, and decouple the certificate from supported curves...

Such as PR #5601?

That only fixes master though. A different fix would probably be needed for 1.1.0. Do we want that?

@darix

This comment has been minimized.

Copy link

commented Mar 13, 2018

@AdamMajer

This comment has been minimized.

Copy link

commented Mar 13, 2018

I think official fix would be very welcome for distributions and other users that will remain on 1.1.0 branch for a while. Some cannot immediately move to 1.1.1

mattcaswell added a commit to mattcaswell/openssl that referenced this issue Mar 13, 2018

If a server has been configured to use an ECDSA certificate, we should
allow it regardless of whether the server's own supported groups list
includes the certificate's group.

Fixes openssl#2033

mattcaswell added a commit to mattcaswell/openssl that referenced this issue Mar 13, 2018

Tolerate a Certificate using a non-supported group on server side
If a server has been configured to use an ECDSA certificate, we should
allow it regardless of whether the server's own supported groups list
includes the certificate's group.

Fixes openssl#2033

@levitte levitte closed this in dcf8b01 Mar 28, 2018

levitte pushed a commit that referenced this issue Mar 28, 2018

Tolerate a Certificate using a non-supported group on server side
If a server has been configured to use an ECDSA certificate, we should
allow it regardless of whether the server's own supported groups list
includes the certificate's group.

Fixes #2033

Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from #5607)
@eccgecko

This comment has been minimized.

Copy link

commented May 23, 2018

I still seem to be suffering from this issue when using a TLS openvpn server that uses ECDSA certs signed using the brainpoolP384r1 curve. The server, using openssl 1.1.0h, starts ok, but when a client, also using 1.1.0h, tries to connect the connection fails. A client using 1.0.2o connects fine. Using certs signed using secp384r1 means the client using 1.1.0h can then connect.

@mattcaswell

This comment has been minimized.

Copy link
Member

commented May 23, 2018

I still seem to be suffering from this issue when using a TLS openvpn server that uses ECDSA certs signed using the brainpoolP384r1 curve. The server, using openssl 1.1.0h, starts ok, but when a client, also using 1.1.0h, tries to connect the connection fails. A client using 1.0.2o connects fine. Using certs signed using secp384r1 means the client using 1.1.0h can then connect.

Sounds like a different issue. An OpenSSL client in 1.1.0 does not send the brainpool curves in its default supported groups list. It used to in OpenSSL 1.0.2. That's a deliberate policy change. You can customise that using SSL_CTX_set1_curves_list() or SSL_set1_curves_list() on the client side.

@eccgecko

This comment has been minimized.

Copy link

commented May 23, 2018

Oh ok, apologies if this is the wrong place. I was just following the chain of github issues with openvpn that seemed to lead here.

I did actually add SSL_CTX_set1_curves_list(ctx->ctx, "brainpoolP384r1"); to src/openvpn/ssl_openssl.c before compiling, as I had read that that would fix this issue, but that was on the server side. I'll try adding to client and see if that helps. Thanks

@tomato42

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

@eccgecko what you're experiencing sounds like #2237

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.