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.
Related
I am using mbedtls on my TLS application. I've a question about the cipher suites.
When I debug my process, I get below lines from server side:
selected ciphersuite: TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
What is the reason for selecting this CHACHA20-POLY1305 cipher ? Key? or certificate? or something else?
How can I change my chipher suite to TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256?
What is the reason for selecting this CHACHA20-POLY1305 cipher
The ciphers supported by the server and by the client, including their preferences. Thus it depends on client and server configurations and on their TLS stacks.
How can I change my chipher suite to TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256?
The RSA in the currently chosen cipher suite means that an RSA certificate was used for authentication. The ECDSA in the cipher you want means that the server needs to use a ECDSA certificate instead, i.e. you cannot achieve this with an RSA certificate.
Some servers can use both a RSA and ECDSA certificate in which case the choice of certificate depends again on client and server configuration regarding supported ciphers, preference etc.
I have traffic between clients (which send XML over HTTPS) to my IIS.
I tried to decrypt the traffic using Wireshark and the following settings:
Adding the private key:
But even after setting this, I can't see the decrypted data:
Should I change any other settings to see the original data?
There is strong possibility that a Diffie-Hellman (DH) key exchange is being used here. In that case Wireshark cannot decipher SSL/TLs with a private key. You can check for this in the handshake packet.
From the Docs:
The RSA private key file can only be used in the following
circumstances:
The cipher suite selected by the server is not using (EC)DHE.
The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.
The private key matches the server certificate. It does not work with the client certificate, nor the Certificate Authority (CA)
certificate.
The session has not been resumed. The handshake must include the ClientKeyExchange handshake message.
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
I'm trying to check a specific IIS configuration, which should reject weak SSL certificates.
How would I go about creating an SSL certificate with either RC4 or DES encryption?
I've tried using openssl with the -des flag, but it seems to still create a sha256 cert.
The choice of the symmetric cipher used in TLS (i.e. RC4, DES, AES...) does not depend on the certificate. This means that any certificate you'll create can be used together with RC4, DES, ... . Instead of trying to enforce a strong cipher using the certificate you have to do this in the server configuration. See Mozilla: Security/Server Side TLS for examples on how to configure common web servers with strong ciphers.
My server may be attached to a RSA or ECDSA certificate.
In my code I set the prtocol method as
sslmethod = SSLv23_server_method();
and setting the cipher using the SSL_CTX_set_cipher_list() API.
The problem is when the server is attached to ECDSA certificate and if I pass "RSA" cipher SSL_CTX_set_cipher_list() does not return any error though "RSA" cipher is not compatible with ECDSA certificates.
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
Is there any openssl API which I can use to find out if the cipher we are going to set is compatible with the certificate or with protocol or not?
If you author the app and own the server, then YES, you do know what to expect. But the general case is NO, you don't know in advance and you can't query for it. You try to setup a channel and if it fails, then you try something else.
Generally speaking, there's no way to know in advance what cipher suites a server supports; or what type of public key is bound in the server's certificate. In fact, there's no way to know what protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, etc) a server supports. Its the reason for RFC 7405, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks.
In 2016/2017, about the best you can do is assume:
No SSLv2, SSLv3; only TLS 1.0 and above
Cipher suites from the collection "HIGH:!aNULL:!kRSA:!RC4:!MD5"
"!kRSA" is "no RSA key transport", and it means you can only use ephemeral key exchanges. If a server has a RSA key, then it will only be used for authentication. That is, the key will be used to sign the server's ephemeral values during key exchange so the client knows they are authentic.