Welcome back to the Certificates and Security Series!
In the past articles, we have understood encryption fundamentals, the importance of TLS certificates to keep the web secure, and the need for Certificate Authorities to issue these certificates, and the challenges associated with the same.
But keeping the web secure is an ongoing process — given that bad actors are always finding newer ways to find vulnerabilities. Private companies like Google and non-profit organizations like Mozilla continue to make efforts to secure the Web.
In this edition, we look at a few such key initiatives, and what they’ve changed for web security.
1. Public Key Pinning
Google introduced public key pinning in Chrome in 2011. Also sometimes known as certificate pinning, it is a security mechanism used to ensure the authenticity and integrity of SSL/TLS certificates. It is designed to protect against certain types of attacks, such as man-in-the-middle (MITM) attacks, where an attacker intercepts and modifies the communication between a client and a server.
How it works:
Typically, when a client connects to a server using SSL/TLS, the server presents its digital certificate to the client as proof of its identity. The client then verifies the certificate’s authenticity by checking its validity, the certificate authority (CA) that issued it, and its associated public key. If everything checks out, the client proceeds with secure communication.
However, in a man-in-the-middle attack, an attacker can present a fraudulent certificate to the client, effectively impersonating the legitimate server. Public key pinning counters this threat by allowing a client to associate a specific server or CA’s public key with a particular domain. The client can then check if the presented certificate contains the expected public key, and if not, it goes on to raise an error and terminate the connection.
Public Key Pinning and VoIP
While public key pinning can enhance the security of VoIP systems, it is not as commonly implemented in the VoIP world. VoIP primarily relies on other security measures, such as encryption, authentication protocols, and secure signaling, to protect the confidentiality and integrity of voice communications.
2. False Start
False Start is a feature in the Transport Layer Security (TLS) protocol that allows the client to send application data immediately after completing its portion of the TLS handshake – without waiting for the server to finish its part. This feature is primarily used in web browsers and servers to reduce the latency associated with establishing a secure connection.
Google’s introduction of False Start in ~2010 helped the secured web browsing experience in the following ways:
- Reduced Latency: By allowing the client to send application data before the handshake completes, False Start reduced the latency associated with establishing a secure connection. This improvement in performance was particularly beneficial for web applications, where reduced latency leads to a better user experience.
- Improved Page Load Times: TLS handshake overhead can impact page load times, especially for websites that require multiple round trips between the client and the server. False Start mitigated this issue by allowing the client to send the first application data without waiting for the server to complete its part of the handshake. This resulted in faster page load times, enhancing the overall browsing experience.
- Enhanced TLS Adoption: False Start made TLS more attractive for web application developers by addressing the performance concerns associated with the handshake process. The improved performance and reduced latency made it easier for developers to adopt and deploy TLS in their applications without significant performance penalties.
False Start and VoIP
Importantly, the applicability of False Start extends primarily to web applications and may not be directly applicable or widely implemented in other protocols or systems, including Voice over IP (VoIP).
While it’s technically feasible to apply False Start to the TLS handshake in VoIP systems, its usage and impact on VoIP performance would depend on the specific implementation and context of the VoIP application.
3. Forward secrecy
Forward secrecy was introduced by Mozilla Firefox in 2008 and Google Chrome in 2011. Forward secrecy (FS) is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. For HTTPS, the long-term secret is typically the private key of the server.
Forward secrecy protects past sessions against future compromises of keys or passwords. It is achieved by generating new (ephemeral) session keys for every transaction. These keys are then used to encrypt and decrypt data for that specific transaction.
Even if attackers compromise the long-term secrets used to generate the session keys, they will be unable to decrypt any data that was encrypted using the ephemeral keys.
Forward secrecy is an important security feature for any application that uses encryption. It helps to protect against a variety of attacks, including man-in-the-middle attacks, key compromise attacks, and password attacks.
Forward Secrecy in VoIP Systems
In the context of SIP-based voice systems, forward secrecy ensures that the confidentiality of past communication sessions remains intact even if the private keys of the endpoints are compromised in the future. It achieves this by generating unique session keys for each session and not relying on the long-term private keys for encryption.
4. Disabling TLS fallbacks
TLS fallback is a mechanism that allows a client and server to negotiate and use a less secure TLS version or cipher suite if the preferred, more secure options are not available.
It is a security vulnerability that can occur when a client or server attempts to negotiate a lower security protocol version than what is supported by both parties. This can be exploited by attackers to downgrade the security of a connection, making it easier to eavesdrop on or manipulate traffic.
Several attacks like man-in-the-middle, BEAST, Lucky 13 attacks, etc. can be launched against TLS fallback vulnerabilities.
In 2015, both Firefox and Chrome disabled TLS fallbacks as part of their effort to improve security and promote the use of secure and modern cryptographic protocols. T
Wrapping Up
Though the developments mentioned in this article have done their little bit to make browsing safe, securing the web is – and will be – an ongoing task. Stay tuned to this series to know what else goes into building a more secure web for communications.