How Do New Encryption Standards Affect Security?

TL;DR

Stronger encryption standards improve privacy, simplify configuration, remove broken cryptography, and reduce connection latency, but they can also weaken traditional network monitoring. TLS 1.3 hides server certificates and prevents retrospective decryption with static RSA keys, while DNSSEC authenticates DNS responses without encrypting them, forcing enterprises to reconsider inspection, compliance, phishing detection, and defense-in-depth strategies.

Transcript

Thanks, and, uh, thanks for having me here, um, to talk today a little bit about, um, Hacked by Crypto, and what does that mean? So, um, in my slides today, we're gonna be talking a lot about some of the standards development, what those are gonna mean for operational security and for security defense in depth, um, holistically. Um, you'll notice, ... Read More

Key Insights

• TLS 1.3 is an IETF RFC standard released in August 2018 that removes broken cryptographic options and complicated configurations found in TLS 1.2 and earlier versions, with the goal of making secure deployment easier, more efficient, and less prone to configuration errors.
• Perfect forward secrecy is mandatory in TLS 1.3, which means compromising key material or information from one session does not provide the means to compromise future sessions. This restriction also removes the static RSA mechanism that some organizations previously used for retrospective traffic decryption.
• TLS 1.3 improves connection performance by reducing the normal handshake from two round trips to one. It also offers a zero-round-trip option for reestablishing a previous connection, which is particularly relevant to mobile networks where every round trip can add 100–300 milliseconds of latency.
• The TLS 1.3 handshake encrypts the server certificate because the client supplies Diffie-Hellman key material in its initial hello message. Once the server responds, both sides have what they need to form an encrypted tunnel, limiting certificate visibility for network monitoring systems.
• Policy-based inspection becomes more difficult when monitoring systems cannot see the server certificate. The remaining SNI value comes from the client and cannot necessarily be verified against the certificate, while a fronting server could accept that SNI and translate it to another destination behind the server.
• Retrospective decryption is impossible through static RSA in TLS 1.3 because the protocol no longer supports that method. Organizations that archived server private keys for later investigations can no longer use those keys to decrypt previously captured TLS 1.3 sessions in the data center.
• DNSSEC authenticates DNS responses by signing them so a resolver can confirm that returned information is legitimate and current. It does not provide confidentiality, so DNS queries and responses remain visible in plain text and can still be monitored while moving across the network.
• DNSSEC validation follows a chain from the requested domain through its top-level domain and the root to a locally configured trust anchor. The client may receive an authenticated-data bit from its trusted resolver, but the final connection to that client remains unsigned and unencrypted.

Questions & Answers

Q: What security benefits does TLS 1.3 provide?

TLS 1.3 removes broken cryptographic options and the complicated configuration choices associated with TLS 1.2 and earlier versions. It restricts connections to perfect forward secrecy, so information compromised from one session cannot be used to compromise future sessions. It also reduces configuration complexity, which is intended to make deployment more efficient and less prone to security errors.

Q: How does TLS 1.3 improve connection performance?

TLS 1.3 reduces the ordinary handshake from two round trips to one by including the client's Diffie-Hellman key material in the initial hello message. The server can then respond with the information needed to form an encrypted tunnel. A zero-round-trip option can also reestablish a former connection, helping on mobile networks where each round trip may add 100–300 milliseconds of latency.

Q: Why does TLS 1.3 make network inspection harder?

TLS 1.3 encrypts the server certificate once the server responds to the client's initial message. Traditional network monitoring and inspection systems often relied on that visible certificate to identify and categorize destinations. Without it, policy decisions may depend largely on the SNI supplied by the client, and the monitoring system cannot confirm that this value matches the destination's server certificate.

Q: What is the problem with relying on SNI for traffic categorization?

An SNI value is supplied by the client, but TLS 1.3 inspection may not expose the server certificate needed to verify it. A fronting server could accept an inaccurate SNI value and translate it on the back end to another site. As a result, destination categorization and policy-based bypass decisions may rely on information that cannot be independently confirmed.

Q: Why does TLS 1.3 prevent retrospective RSA decryption?

TLS 1.3 no longer supports static RSA. Some banks, healthcare organizations, government environments, industrial control operators, and critical infrastructure organizations previously stored a terminating server's RSA private key in cold storage. During a later investigation, they could use that key to decrypt archived sessions. That offline data-center decryption method is no longer possible for TLS 1.3 traffic.

Q: What is DNSSEC and what protection does it provide?

DNSSEC provides assurance between a trusted caching recursive resolver and the wider DNS system by signing DNS responses. The signature allows the resolver to determine that returned information is legitimate and current. DNSSEC does not hide or encrypt the DNS data, however, so queries and responses remain in plain text and can still be observed through network monitoring.

Q: How does DNSSEC validation work from a domain to the client?

After reaching the requested domain, the resolver obtains the domain's DNS key and verifies it through the top-level domain, then through the root, and finally against a trust anchor configured on the local machine. The response sent to the endpoint carries an authenticated-data bit set to one, which tells the client that validation occurred through the trusted resolver.

Q: What enterprise risks can arise from encrypting more network metadata?

Encrypting more connection information can reduce the evidence available to firewalls, proxies, intrusion detection systems, intrusion prevention systems, data loss prevention systems, and related monitoring controls. It can make phishing, staged malware delivery, destination categorization, policy-based bypass, and data-exfiltration detection more difficult. It also complicates compliance policies that require inspection of some sessions while excluding banking or healthcare traffic.

Summary & Key Takeaways

• TLS 1.3 removes broken ciphers and complicated configuration options while requiring perfect forward secrecy. It also improves performance by reducing the standard handshake from two round trips to one, with an option for zero-round-trip reconnection. These changes make encrypted connections easier to configure, faster to establish, and less vulnerable to key compromise.

• The privacy improvements in TLS 1.3 complicate network defense because the server certificate is encrypted after the initial exchange. Security systems may have only the client-provided SNI value for categorization and bypass decisions, without being able to confirm that it matches the destination certificate. This affects inspection, compliance, phishing detection, and malware analysis.

• DNSSEC provides authenticity and freshness for responses between a trusted caching recursive resolver and the wider DNS system, but it does not encrypt DNS information. The final connection to the client remains unsigned and unencrypted, relying on an authenticated-data bit. Larger DNSSEC messages may also require TCP instead of the usual UDP port 53 traffic.