Article Summary
Embracing TLS versions 1.3 and 1.2 is essential for ensuring the highest level of online security and performance. These updated versions offer faster and more secure connections, safeguarding user data from potential threats. By transitioning to these protocols, we're not only enhancing the speed of our online interactions but also fortifying our digital defenses, making our online experiences both swift and safe.
Understanding the Shift: TLS 1.3 vs. TLS 1.2
In the ever-evolving landscape of cybersecurity, staying ahead of potential threats is paramount. As part of our commitment to ensuring the utmost security and optimal user experience for our clients, IHRDC is excited to announce that we are transitioning to exclusively support TLS 1.3 and TLS 1.2.
TLS (Transport Layer Security) is the modern successor to SSL and is used by HTTPS and other network protocols for encryption. The latest version, TLS 1.3, was introduced by the Internet Engineering Task Force (IETF) in August 2018, succeeding TLS 1.2 which had been standardized a decade earlier in 2008.
The primary distinctions between the two versions lie in their speed and security. TLS 1.3 has dropped support for older, less secure cryptographic features, making it inherently more secure. Additionally, it has introduced faster TLS handshakes, which now require just one round trip instead of two. This enhancement not only reduces latency but also significantly improves the overall user experience.
Why the Move to TLS 1.3 is Crucial
-
Enhanced Speed and Performance: One of the standout features of TLS 1.3 is its ability to complete TLS handshakes in a single round trip, as opposed to the two required by TLS 1.2. This results in faster HTTPS connections, reducing latency and offering a smoother user experience.
-
Bolstered Security: TLS 1.2, despite its widespread use, had vulnerabilities stemming from its support for older cryptographic algorithms. TLS 1.3 has eliminated these vulnerabilities by dropping support for these outdated algorithms, making it less susceptible to cyberattacks.
-
Adapting to the Times: Software development is an ever-evolving field. As systems become more complex, they inevitably require updates and improvements. By transitioning to TLS 1.3, we are ensuring that our systems are equipped with the latest and most secure protocols, safeguarding our clients' data and trust.
The Role of Ciphers in Secure Communication
Ciphers play a crucial role in the encryption process. They are algorithms that transform data into a format that can only be read if decrypted. When a user attempts to establish a secure connection to a server, both the user's browser and the server possess a list of ciphers that they support. The security of the connection largely depends on which cipher is chosen for the communication.
IHRDC uses these ciphers (as of September 2023) on all servers and applications
| Layer | preferred order | Cipher Suite | Alternate Name | Encryption |
| TLS 1.3 | 1 | TLS_AES_128_GCM_SHA256 | ECDH x25519 (eq. 3072 bits RSA) FS | 128 |
| TLS 1.3 | 2 | TLS_AES_256_GCM_SHA384 | ECDH x25519 (eq. 3072 bits RSA) FS | 256 |
| TLS 1.3 | 3 | TLS_CHACHA20_POLY1305_SHA256 | ECDH x25519 (eq. 3072 bits RSA) | 256 |
| TLS 1.2 | 4 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDH x25519 (eq. 3072 bits RSA) | 128 |
| TLS 1.2 | 5 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ECDH x25519 (eq. 3072 bits RSA) FS | 256 |
Negotiating the Best Cipher
The process of selecting a cipher is known as cipher suite negotiation. Here's how it works:
- Initiation: When a browser connects to a server, it sends a list of ciphers it supports in the order of preference.
- Server Selection: The server, upon receiving the list, picks the highest-preference cipher that it also supports.
- Establishment of Connection: Once both parties agree on a cipher, they use it to secure their communication.
It's worth noting that with the introduction of TLS 1.3, the list of supported ciphers has been streamlined to include only the most secure options. This ensures that even if an older, potentially less secure cipher is preferred by a browser, the server will default to a more secure option, enhancing the overall security of the connection. Based upon our setup the following browser would negotiate the below ciphers.
| Browser | Encryption Level | TLS version | Cipher Scheme |
| Android 4.4.2 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Android 5.0.0 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Android 6.0 | RSA 2048 (SHA256) | TLS 1.2 > http/1.1 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Android 7.0 | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Android 8.0 | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Android 8.1 | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Android 9.0 | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| BingPreview Jan 2015 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Chrome 49 / XP SP3 | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Chrome 69 / Win 7 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Chrome 70 / Win 10 | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Chrome 80 / Win 10 R | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Firefox 31.3.0 ESR / Win 7 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Firefox 47 / Win 7 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Firefox 49 / XP SP3 | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Firefox 62 / Win 7 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Firefox 73 / Win 10 R | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Googlebot Feb 2018 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| IE 11 / Win 7 R | Protocol or cipher suite mismatch | ||
| IE 11 / Win 8.1 R | Protocol or cipher suite mismatch | ||
| IE 11 / Win Phone 8.1 R | Protocol or cipher suite mismatch | ||
| IE 11 / Win Phone 8.1 Update R | Protocol or cipher suite mismatch | ||
| IE 11 / Win 10 R | Protocol or cipher suite mismatch | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Edge 15 / Win 10 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Edge 16 / Win 10 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Edge 18 / Win 10 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| Edge 13 / Win Phone 10 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Java 8u161 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Java 11.0.3 | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Java 12.0.1 | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| OpenSSL 1.0.1l R | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| OpenSSL 1.0.2s R | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| OpenSSL 1.1.0k R | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH x25519 FS |
| OpenSSL 1.1.1c R | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Safari 6 / iOS 6.0.1 | Protocol or cipher suite mismatch | ||
| Safari 7 / iOS 7.1 R | Protocol or cipher suite mismatch | ||
| Safari 7 / OS X 10.9 R | Protocol or cipher suite mismatch | ||
| Safari 8 / iOS 8.4 R | Protocol or cipher suite mismatch | ||
| Safari 8 / OS X 10.10 R | Protocol or cipher suite mismatch | ||
| Safari 9 / iOS 9 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Safari 9 / OS X 10.11 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Safari 10 / iOS 10 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Safari 10 / OS X 10.12 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Safari 12.1.2 / MacOS 10.14.6 Beta R | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Safari 12.1.1 / iOS 12.3.1 R | - | TLS 1.3 | TLS_AES_128_GCM_SHA256 ECDH x25519 FS |
| Apple ATS 9 / iOS 9 R | RSA 2048 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| Yahoo Slurp Jan 2015 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
| YandexBot Jan 2015 | RSA 2048 (SHA256) | TLS 1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS |
Why Cipher Negotiation Matters
The negotiation process is vital for a few reasons:
- Optimal Security: By allowing both parties to select the most secure cipher they mutually support, the data remains as secure as possible.
- Compatibility: Some older browsers or servers might not support the latest ciphers. The negotiation ensures that they can still establish a secure connection using the best available option.
- Performance: Different ciphers have varying computational requirements. The negotiation process ensures a balance between security and performance.
By understanding the intricacies of ciphers and their negotiation, we can appreciate the robustness of the security protocols in place. As we transition to TLS 1.3 and TLS 1.2 exclusively, our commitment to leveraging the best in encryption technology remains unwavering.
Conclusion
Our decision to move exclusively to TLS 1.3 and TLS 1.2 is a testament to our dedication to providing the best services to our clients. By embracing the latest advancements in cybersecurity, we aim to offer a seamless and secure digital experience for all our users.
Comments