An SSL cipher, or an SSL cipher suite, is a set of algorithms or a set
of instructions/steps that helps to establish a secure connection
between two entities — usually the client (a user’s browser) and the web
server they’re connecting to (your website).
Creating a secure, encrypted connection via the SSL/TLS protocol is a fairly complex process that has many layers to it. In technical terms, it’s regarded as an “SSL/TLS handshake.” This includes key exchange, identity verification, data encryption, etc.
To negotiate a secure communication, the client and the server need to come on terms with four crucial elements:
- Key exchange algorithm: RSA (Rivest–Shamir–Adleman), DH (Diffie-Hellman), ECDH (Elliptic-curve Diffie-Hellman), and ECDHE (Elliptic-curve Diffie-Hellman Ephemeral) are some of the most widely used key exchange algorithms.
- Bulk encryption algorithm: Encrypt messages exchanged between clients and servers. Ex. AES.
- Data encryption algorithm
- Hash function: Generate message hashes and signatures to ensure the integrity of a message
A cipher suite is a set of cryptographic algorithms that describes the above four elements.
This is an example of a cipher suite:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS : Protocol
- ECDHE : The first part is the key exchange algorithm.
- RSA: It uses a key signed with an RSA certificate authority which is supported by most internal certificate authorities
- AES_256_GCM: The third section is the type of encryption algorithm used.
- SHA384: The fourth component is the type of hashing algorithm used.
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
Perfect Forward Secrecy for TLS
Perfect Forward Secrecy (PFS) is a concept in Transport Layer Security (TLS) that makes sure that even if attackers manage to gain access to the private key of a certificate, they are not able to decrypt communication from the past (or communication in the future, without using active man in the middle attacks). For example, if the latest key is compromised, it exposes only a small portion of the user's sensitive data.
Example of Perfect Forward Secrecy cipher suites using ephemeral key agreement with elliptic curve Diffie-Hellman key exchange:
TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES256_CBC_SHA384
Enabling perfect forward secrecy on your server: If you check the security details of a site and see that it is using "ECDHE" or "DHE" then the server is already using forward secrecy. Any key exchange that uses ephemeral keys provides forward secrecy.
Downsides of perfect forward secrecy: While they generally don't outweigh the benefits, like anything else, there are drawbacks to this type of security. To begin with, it usually requires greater processing power from a server since every transaction requires the generation of a unique encryption key. Ephemeral Elliptic Curve Diffie-Hellman is believed to be the faster of the two, but even it adds up to 20 percent greater SSL/TLS processing requirements to a server.
If you would like to test your implementation of SSL/TLS, following websites could be used:
https://www.ssllabs.com/ssltest
https://gf.dev/tls-scanner
https://www.digicert.com/help/
https://www.sslshopper.com/ssl-checker.html
0 comments:
Post a Comment