0

I'm working on a project with a client based on mbedtls and a server built with vsftpd.

I had basic RSA authentication working but am now upgrading to using the cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. And I am struggling to get it to work:

I see the handshake taking place and server and client agree on the above cipher.I had validate_cert=YES in vsftpd.conf but it then would not be able to validate it and I got certificate verify failed errors in vsftpd.log.

I decided to temporarily turn validation off (validate_cert=NO). I then saw the following error (in vsftpd.log) during the handshake: routines:tls12_check_peer_sigalg:wrong curve

How do I make sure that my vsftpd works with the correct curve?

openssl x509 -text gives me: NIST CURVE: P-384 for the ca-cert

My certificate looks like:

openssl x509 -text -in /path/to/ca-cert -noout                                                                                                                                                 
Certificate:                                                                                                                                                                                                                                
    Data:                                                                                                                                                                                                                                   
        Version: 3 (0x2)                                                                                                                                                                                                                    
        Serial Number:                                                                                                                                                                                                                      
            <Some hash>                                                                                                                                                                     
        Signature Algorithm: ecdsa-with-SHA256                                                                                                                                                                                              
        Issuer: C = CA, ST = BC, L = Town, O = Company, OU = Software, emailAddress = [email protected], CN = va.company.com                                                                                                  
        Validity                                                                                                                                                                                                                            
            Not Before: date/time GMT                                                                                                                                                                                            
            Not After : date/time GMT                                                                                                                                                                                            
        Subject: C = CA, ST = BC, L = Town, O = Company, OU = Software, emailAddress = [email protected], CN = va.company.com                                                                                                 
        Subject Public Key Info:                                                                                                                                                                                                            
            Public Key Algorithm: id-ecPublicKey                                                                                                                                                                                            
                Public-Key: (384 bit)                                                                                                                                                                                                       
                pub:
                    <Some hash1>
                    <Some hash2>
                    <Some hash3>
                    <Some hash4>
                    <Some hash5>
                    <Some hash6>
                    <Some hash7>
            ASN1 OID: secp384r1
            NIST CURVE: P-384
    X509v3 extensions:
        X509v3 Basic Constraints:
            CA:TRUE
        X509v3 Subject Key Identifier:
            <Some hash8>
Signature Algorithm: ecdsa-with-SHA256
     <Some hash9>
     <Some hash10>
     <Some hash11>
     <Some hash12>
     <Some hash13>
     <Some hash14>

The signature algorithms in the Client Hello, are the following:

Extension: signature_algorithms (len=22)
    Type: signature_algorithms (13)
    Length: 22
    Signature Hash Algorithms Length: 20
    Signature Hash Algorithms (10 algorithms)
        Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
        Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
        Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
        Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
        Signature Algorithm: SHA224 ECDSA (0x0303)
        Signature Algorithm: SHA224 RSA (0x0301)
        Signature Algorithm: ecdsa_sha1 (0x0203)
        Signature Algorithm: rsa_pkcs1_sha1 (0x0201)

And these are the ones listed in the Server Hello Done:

Signature Hash Algorithms (23 algorithms)
    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
    Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
    Signature Algorithm: ed25519 (0x0807)
    Signature Algorithm: ed448 (0x0808)
    Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
    Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
    Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
    Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
    Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
    Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
    Signature Algorithm: SHA224 ECDSA (0x0303)
    Signature Algorithm: ecdsa_sha1 (0x0203)
    Signature Algorithm: SHA224 RSA (0x0301)
    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
    Signature Algorithm: SHA224 DSA (0x0302)
    Signature Algorithm: SHA1 DSA (0x0202)
    Signature Algorithm: SHA256 DSA (0x0402)
    Signature Algorithm: SHA384 DSA (0x0502)
    Signature Algorithm: SHA512 DSA (0x0602)

I found the following: https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.4.1

3
  • 1
    FYI the publickey value and signature value are not hashes; they are effectively random binary data, but not hashes. Similarly, compressed data, image data, audio data, video data, and executable files all look like arbitrary (not human readable) data, but are not hashes. SKI is (at least normally) a hash, and serial is determined by the CA or other creator so it might be anything. More substantively, try to get a network capture showing the ClientHello being sent and see what is in its signature_algorithms (aka sigalg[s]) extension. Commented Sep 12, 2021 at 3:50
  • @dave_thompson_085 Thank you, I have added the signature algorithms above
    – stdcerr
    Commented Sep 12, 2021 at 15:17
  • ServerHelloDone does not contain any signature/hash values (or any data at all). Could you be looking at CertificateRequest? If so how did you get that far in the protocol when the server is reporting an error that should have aborted the handshake? Can you outline all the messages you have in your handshake? And per below can you also add supported_groups (new name) or supported_curves (old name) from ClientHello? Commented Sep 13, 2021 at 1:34

1 Answer 1

2

The P-384 curve is a red herring. Certificate verification is almost certainly failing in your case because you've got an RSA certificate installed on the vsftpd server, but you're telling your client to only support the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite, which requires an ECDSA certificate.

What you probably want here is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which uses ECDHE for the key exchange and RSA certificates for server authentication. Alternatively, you could install an ECDSA certificate on the vsftpd server, if it supports it.


The new information you supplied clarifies the situation somewhat. The TLS 1.2 specification has the following to say about the signature_algorithms extension:

If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same.

Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension.

Your certificate uses secp384r1 (aka P-384), and its signature algorithm is ecdsa-with-SHA256. But if you look at the supported signature algorithms in the ClientHello, the only entry supporting secp384r1 is ecdsa_secp384r1_sha384, which requires SHA384.

The ECDSA curves are paired with appropriately sized hash functions, so there isn't an option for ecdsa_secp384r1_sha256, because that would result in mismatched security levels from a cryptographic perspective. So you either need a secp384r1 (P-384) certificate that uses SHA384, or a secp256r1 (P-256) certificate that uses SHA256.

5
  • Added certificate on top. The cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is required and I do have a ECDSA certificate: Signature Algorithm: ecdsa-with-SHA256, right?
    – stdcerr
    Commented Sep 11, 2021 at 19:01
  • 1
    @stdcerr: sort of. In general it is the public-key type (id-ecPublicKey) that matters, not the signature algorithm; however your cert is self-signed, and for a self-signed cert the public-key type and signature algorithm always match. Commented Sep 12, 2021 at 3:49
  • 1
    @stdcerr I've updated my answer given your new info. TL;DR you mismatched the hash size and curve when generating the cert.
    – Polynomial
    Commented Sep 12, 2021 at 15:45
  • 1
    P: except the curve-matched-to-hash sigalg (renamed SignatureScheme) codes are the meaning in TLS1.3 only, and the ciphersuite used here implies it must be 1.2; in 1.2 (even with 8422) 0403 is sha256+ecdsa with any curve allowed by supported_curves/groups -- which I forgot to also ask OP for (see Q). Commented Sep 13, 2021 at 1:33
  • 1
    Hey guys, I actually found that vsftpd.conf has the option ec_curve_name which can be set to ec_curve_name=P-384 with which I can at least make a "test download" using curl happen (with the existing certificate)
    – stdcerr
    Commented Sep 13, 2021 at 19:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .