TLS

Full Title or Meme

Transport Layer Security (TLS) creates a tunnel between two parties using TCP/IP, typically also using HTTP.

Note what when TLS is in force the transport protocol is changed from http to https (ie http with security).

Context

The more recent versions of SSL - secure sockets layer code. Renamed due to Microsoft's distaste for code created by competitors.

Identifiers

TLS is designed to create a secure tunnel between two parties at the transport layer and hence identification is of the transport end-points. Channel Binding (qv.) is a method to bind the application end-point, or even the actual Entity at each end-point to the security created from those two transport layer Identifiers.

Sequence

Client	Server	Notes	Misc
TCP Syn		to port 80	Synchronize sequence nos
	SynAck		Synchronize-Acknowledgment
Ack			acknowledges SYN-ACK
http get		to port 80	client can skip directly to https
	html 301	moved permanently	Redirects client to port 443
TCP Syn		to port 443	Synchronize sequence nos
	SynAck		Synchronize-Acknowledgment
Ack			acknowledges SYN-ACK
client hello			supported versions & ciphers
	server hello		selected version (1.3) ciphers & rand no
	server cert		to prove its identity
client secret			encrypted with the public key of server
client finish		https complete	session key = rand no + client secret

TLS 1.3 is faster and more secure that 1.2. It is even faster on reconnection if the client remembers a server random number from before and thus skips the hello exchange.

HSTS

(HTTP Strict Transport Security)

Implementing HSTS is crucial for long-term security. It instructs browsers to remember to only use TLS when connecting to your site in the future. Note that even if connections to port 80 are insecure, HSTS will automatically redirect clients from port 80 to port 443 without attempting to connect over port 80. M-15-13 calls for “all publicly accessible Federal websites and web services” to only provide service through a secure connection (HTTPS), and to use HTTP Strict Transport Security (HSTS) to ensure this.

Crypto Suites for 1.3

TLS 1.3 supports a limited set of cipher suites, each specifying a combination of cryptographic algorithms. The following cipher suites are defined:

TLS_AES_256_GCM_SHA384: AES-256 in Galois/Counter Mode (GCM) with SHA-384 for integrity.
TLS_CHACHA20_POLY1305_SHA256: ChaCha20-Poly1305 with SHA-256 for integrity.
TLS_AES_128_GCM_SHA256: AES-128 in GCM mode with SHA-256 for integrity.
TLS_AES_128_CCM_8_SHA256: AES-128 in Counter with CBC-MAC (CCM) mode (8-byte tag) with SHA-256 for integrity.
TLS_AES_128_CCM_SHA256: AES-128 in CCM mode (12-byte tag) with SHA-256 for integrity3.

Symmetric Encryption:

TLS 1.3 uses symmetric-key algorithms for encryption.
The keys for symmetric encryption are generated uniquely for each connection based on a shared secret negotiated during the handshake4.

Cryptographic Issues

• WebAppSec WG - 2024-03-20 reported on implementation of EC 35529 an issue with rejecting small order points. Mozilla requested, didn't get push-back on the spec, but my understanding is that Chromium prefers to ship their implementation of x25519 as it is. Technically also not conformant to the RFC. But wider issue applying also to TLS. Discussion needs to happen in CFRG about the behavior. W3C might not be the right place to have those conversations.
• The Crypto Forum Research Group (CFRG) has also been exploring the adoption of new elliptic curves. Curve25519 has been proposed, but it’s essential to consider its suitability beyond just TLS (including SSH, IKE, etc.) The CFRG aims to achieve re-usability across various protocols.
• A brief discussion on selecting new elliptic curves is a report from Microsoft research. " This position paper summarizes our perspectives on the selection of next-generation elliptic curves for standardization. It also contains generation algorithms intended as a foundation for choosing elliptic curves for cryptography in a simple, consistent and rigid way"

When TLS 1.3 was designed starting in 2013, there were a number of objectives:

1. Clean up: Remove unused or unsafe features
2. Improve privacy: Encrypt more of the handshake
3. Improve latency: Target: 1-RTT handshake for naıve clients; 0-RTT handshake for repeat connections
4. Continuity: Maintain existing important use cases
5. Security Assurance: which later evolved into perfect forward security

In order to address objectives (2) and (3) TLS 1.3 adopted a new handshake skeleton which reverses the order of the DH key shares, as shown below:

Post Quantum Solutions

Buckle your seat-belts, it's going to get rough, The IETF has decided not to add support for post-quantum (PQ) encryption algorithms to TLS 1.2. In fact, the TLS WG is taking a rather stronger position, namely that it's going to stop enhancing TLS 1.2 more or less entirely, including support for PQ algorithms:

Also see the wikipage Quantum_Computing_Threat#Post_Quantum_Cryptography.

Certificate Authority Issues

There are approximately 85 organizations authorized to issue TLS certificates for the web today. And seven of them issue 99% of all certificates currently in use. The presence of the others is largely intended to accommodate web openness and national sovereignty—an admirable goal, albeit one that introduces a significant attack surface for every web user.

But were you aware that the recent EIDAS 2.0 legislation, that was just signed, will obligate browsers to trust all QWAC-approved CAs listed on the EU Trust List (https://esignature.ec.europa.eu/efda/tl-browser)? To illustrate, Spain has 13 CAs approved to issue these certificates and there are 27 member states in the EU. Additionally, did you know the legislation will not permit browsers to remove of CA with a history of repeated incompetence without government approval?

The most famous of all CA distrust events was an EU CA known as DigiNotar, and those in the PKI space might say that 12 years ago and today, the Conformity Assessment Bodies would have caught that and dealt with it proactively. But is that true? Check out the history of Camerfirma (https://wiki.mozilla.org/CA/Camerfirma_Issues) and wonder why an organization with such poor operational practices that the internet isn't dependent on is still trusted by anyone? Then ask why the associated CAB still lets it be approved as a CA for issuance.

For those who say that the web doesn't need Browsers for such actions, consider this recent incident involving a Turkish CA (https://bugzilla.mozilla.org/show_bug.cgi?id=1801345). And for those who doubt governments would use CAs to gain visibility into web traffic, take a look at this case where a French CA was doing just that: https://arstechnica.com/information-technology/2013/12/french-agency-caught-minting-ssl-certificates-impersonating-google/.

Supposedly the final text has a recital that was added to the language to suggest that the scope of these requirements is to be limited to trusting these CAs for identity information and not the domain but the document is still private so we don't know for sure. Even if true recitals are not binding and the bill has other issues, for example, it requires browsers to reinstate user interface that has been proven to be harmful and misleading to users. https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/.

It also prevents the Browsers from establishing additional requirements for the CAs above and beyond what is included in the associated EU legislation, for example, they won't be subject to http://certificate.transparency.dev which has helped catch many many issues. All this means calcifying the web making it impossible to move forward without legislative change and leaving the web less secure at the same time. Change will now be governed by regulators, lobbyists, and standards boffins that either benefit from this weakening of the web or have no accountability for its consequences.

There are 195 sovereign nations in this world. each would love to be in a position to observe everything their citizens and everyone who interacts with them does. When the world's most liberal and democratic governments put into place the tools to enable mass surveillance and weaken internet security in this fashion what makes us think the rest won't as well.

Originally from a post by Ryan Hurst.

Protocol Issues

Application-Layer Protocol Negotiation (ALPN) is a TLS extension that allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application-layer protocols. It is used to establish HTTP/2 connections without additional round trips (client and server can communicate over to ports previously assigned to HTTPS with HTTP/1.1 and upgrade to use HTTP/2 or continue with HTTP/1.1 without closing the initial connection).

References

Other Material

• See wiki page for OpenSSL for open source code implementations of TLS.