When you go to google.com, the certificate under "Subject Public Key Algorithm" shows:
Elliptic Curve Public Key
ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
Key size: 256 bits
which apparently is ECDSA. I thought ECDSA is used only for signing/signatures and not
for key exchange. What am I missing?
The key doesn't restrict this. Most elliptic-curve keys (leaving out Bernstein) including this one technically can be used for ECDSA signing, ECDH or ECMQV key agreement, or ECIES encryption. The encoding was established by X9.62 because that was the first issued, but the same curves, key values and encoding are used by the other operations. (Many applications also use the point encoding first created by X9.62, but there is some variation there.)
But the cert does. The cert (also) has the KeyUsage extension set to digitalSignature (and the ExtendedKeyUsage extension set to id-kp-serverAuth). This means when used in TLS it can only be used for ECDSA signing to authenticate the server.
TLS/SSL often uses sign-only certs. Most TLS connections nowadays use 'ephemeral' keys (not in a certificate) for key agreement combined with signing by a cert's key (or more exactly by the privatekey matching a publickey cert) for authentication of the server, and optionally but rarely authentication of the client. This provides (Perfect) Forward Secrecy which means that even if a server privatekey is later compromised, recordings of previous sessions cannot be decrypted so their content remains safe (at least from this attack; SSL/TLS only covers transport and never protects against compromise at either endpoint, during or after the session). In the early days of SSL people often didn't bother with PFS, but after Snowden made lots of people aware of mass surveillance programs -- especially non-techie people like managers and bosses and users and customers -- these options became much more widely required or recommended, and used.
For TLS1.0-1.2 (and SSL3, but you should no longer use that because it is broken) key agreement and signing (server authentication) are linked in the ciphersuite: all ciphersuites that use an ECDSA cert for server auth use ECDHE key agreement, and all ciphersuites that use (integer) DSA* cert for server auth use (integer) DHE key agreement; the E in DHE and last E in ECDHE are for ephemeral. Since RSA supports both signing and encryption, an RSA cert key can be used for key transport (encryption) but this is no longer recommended, or it can be used to sign either kind of ephemeral key agreement. (* For hysterical raisins SSL/TLS standards use DSS to mean DSA.) For TLS 1.3 these algorithms are now selected separately, but use of some ephemeral key agreement is practically required on the public net, and use of some signing cert is required nearly always, so they will probably be used in the same combinations as now except RSA-only key encryption is no longer allowed.
See:
https://security.stackexchange.com/questions/20803/how-does-ssl-work (the Great Ursine Epic)
https://security.stackexchange.com/questions/3638/security-of-pki-certificates-certificate-authorities-forward-secrecy
https://security.stackexchange.com/questions/8343/what-key-exchange-mechanism-should-be-used-in-tls
https://security.stackexchange.com/questions/35471/is-there-any-particular-reason-to-use-diffie-hellman-over-rsa-for-key-exchange
Related
I have an existing server that is using the following setting.
The connection to this site uses TLS 1.2 (a strong protocol), RSA (an
obsolete key exchange), and AES_128_CBC with HMAC-SHA1 (an obsolete cipher).
If I want to change the key exchange and cipher, do I need to get a new certificate?
The cipher is (mostly) unrelated to the certificate. Given that you are using a RSA certificate (since otherwise RSA key exchange would not be possible) you can switch to ECDHE key exchange. And instead of AES-128-CBC you might use AES-128-GCM or AES-256. For useful configurations you might use the Mozilla SSL Configuration Generator.
I'm trying to generate a certificate for my web server with Let's Encrypt. I want to manually generate key and csr with openssl, and then use letsencrypt / certbot to get the certificate. I specifically want the certificate to use sha256withecdsa. In particular I would like to use the curve secp521r1 (a.k.a. P-521).
The key generation and csr generation work fine, however, when I input the command
certbot certonly --apache -d [censored] --csr mycsr.csr --agree-tos
I get the following error:
The request message was malformed :: Invalid key in certificate request :: ECDSA curve P-521 not allowed
Is ECDSA still unsupported, or am I doing anything wrong?
While P-521 is valid for use in X.509 certificates, most browsers dropped support for it as it is not a part of Suite B and isn't very popular. As a result, Certbot doesn't allow certificates to be generated using P-521 since the browsers would reject it anyway. You can still generate certificates using the P-256 and P-384 curves. See the Mozilla and Google bugreports for details.
Besides my comments on #AfroThundr reply, in fact the definitive source of information on this is https://letsencrypt.org/docs/integration-guide/ and it says:
Supported Key Algorithms
Let’s Encrypt accepts RSA keys from 2048 to 4096 bits in length, and P-256 and P-384 ECDSA keys. That’s true for both account keys and certificate keys. You can’t reuse an account key as a certificate key.
Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support.
Can someone explain the contradictions in the BOLD text below from the NIST document.
"The handshake protocol is used to optionally exchange X.509 public key certificates (5) to authenticate the server and the client to each other. In order to comply with these guidelines, the server always presents an X.509 public key certificate that complies.........."
(4). In these guidelines, “change cipher spec” refers to a protocol, and “ChangeCipherSpec” refers to the message used in that protocol.
(5). The use of X.509 public key certificates is fundamental to TLS. For a comprehensive explanation of X.509 public key certificates see [Adams99] or [Housley01]. In these guidelines, the terms “certificate” and “public key certificate” are used interchangeably.
I need information related to ECDSA certificates. As far as I know ECDSA certificate should contain the ECDSA signature but I see that facebook and google server certificates have the ECDSA certificates with RSA signature.
Is it possible to have the ECDSA certificates with RSA signatures?
The signature for a certificate is created by the issuer using the key of the issuer. Thus if the certificate A has an ECC key inside (i.e. ECDSA certificate) but the issuer B has an RSA key then the signature for A will be an RSA signature, because this is what the issuer has for signing.
For example in the case of facebook.com the certificate itself has an ECC key, but the issuers certificate DigiCert SHA2 High Assurance Server CA has an RSA key. Because the signature for the facebook certificate is done by the issuer with the issuers key it must use RSA too.
Steffen's answer is correct for X.509 standard and many browsers
which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.
I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)
2.2. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.
though RFC-5246, TLS1.2, loosened this restriction. (** is mine):
7.4.4. Certificate Request
...
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. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.
So be warned that such a device exists.
I'd like to understand something.
I generate keys with xca, which is a UI to openssl.
I have created a CA, then generate a server certificate for https and use this CA to sign the generated certificate. The newly created certs are subcerts of the CA (as far as I can tell).
I put in the CN for the domain, generate a new private key of 4096bit length, export the crt and key pem including private key. Upload and configure nginx in this case.
Now I'm accessing the site over https. When clicking connection info in Firefox I see:
Connection Encrypted: High-grade Encryption (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys)
In Chromium:
Your connection to domain.tld is encrypted with 128-bit encryption. <...>
The question/s:
My private key is 4096 bits. Why does it use 128 bits?
Which of the 4096 bits are used in those 128 bits?
Why am I generating a 4096 bit key if only 1/32 of its length are used?
I'd like to understand how this process works.
The 4096 bit RSA key and its associated certificate provides authentication during the setup of the connection and key agreement, allowing the client to verify that they are indeed connected to your server, and not a man-in-the-middle claiming to be your server.
However, the RSA algorithm is orders of magnitude slower than symmetric algorithms like AES with similar security properties, as well as being limited in the amount of data it can encrypt. It is therefore not used to protect the actual data transmitted, and instead a session key for a symmetric algorithm is agreed between the client and server.
In this case, the session key is agreed using the ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm, which allows client and server to derive a random, shared key without ever transmitting the key itself. It is this key which is 128bit, and is being used with the symmetric AES encryption algorithm in Galois/Counter Mode (GCM).