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

use ECDSA, e.g., if it's all we have #2237

Open
richsalz opened this Issue Jan 16, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@richsalz
Contributor

richsalz commented Jan 16, 2017

From @vdukhovni in the thread on #1597

we must not fail to use an ECDSA certificate (supposing it is the only one we have) even if we share no curves with the client. That's a more complex fix, since it will likely require a second pass over the shared ciphersuites with a less stringent filter. I'd suggest a separate PR for that. This is also needed for supported signature algorithms (SHA1 cert when client only offers SHA256, ...)

@mattcaswell mattcaswell added this to the 1.1.1 milestone Jan 18, 2018

@richsalz richsalz added after 1.1.1 and removed after 1.1.1 labels May 6, 2018

@richsalz richsalz modified the milestones: 1.1.1, Post 1.1.1 May 6, 2018

@richsalz

This comment has been minimized.

Contributor

richsalz commented May 6, 2018

We will not delay 1.1.1 for this.

@vdukhovni

This comment has been minimized.

vdukhovni commented May 6, 2018

A simple short-term fix is possible. If we have exactly one certificate, then don't check its conformance with client's "supported " extensions. Provided the leaf public key is acceptable, proceed with the handshake. This will cover the vast majority of cases. In most of the other cases we'll have a vanilla RSA cert and an ECDSA cert, and the vanilla RSA cert will be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment