Transport Layer Security (TLS)

From Kicksecure
Jump to navigation Jump to search



Transport Layer Security (TLS) is a cryptographic protocol that is designed to provide secure communications over a computer network. TLS has replaced the deprecated Secure Sockets Layer (SSL) predecessor and is intended to enforce privacy and data integrity between two or more communicating computer applications. [1] TLS is utilized for a host of online activities, such as web browsing, email, instant messaging and VOIP applications. It ensures the client (like a web browser) is securely communicating with a server (such as, meaning the connection is private, authenticated and reliable. For a detailed overview of the TLS design, refer to this Wikipedia entry.

Use of TLS encryption is only as good as its keys.

Some TLS issues are not directly TLS issues but issues with the certificate authorities which are trusted by default by operating systems, web browsers and other applications.

(Self-signed) SSL certificates using Certificate Pinning are unaffected by issues with certificate authorities.

Compromised Certificate Authorities[edit]

Little trust should be placed in the public TLS certificate authority (CA) system, since it relies on a third-party correctly establishing the authenticity of certificates. The Snowden leaks confirmed that CAs were a weakpoint targeted by the IC, allowing for Man-in-the-middle attacks if the CAs were either compromised or cooperative.

If/once a single CA is subverted, then the security of the entire system is lost, and potentially all entities relying on the trust of the compromised CA are affected. [2]

Examples of CA security breaches include (ordered roughly by severity of the breech):

The Broken Certificate Authority System[edit]

Quote wikipedia:

As of 24 August 2020, 147 root certificates, representing 52 organizations, are trusted in the Mozilla Firefox web browser, 168 root certificates, representing 60 organizations, are trusted by macOS, and 255 root certificates, representing 101 organizations, are trusted by Microsoft Windows.

Rhetoric questions:

  • Why where these organisations given the power to sign certificate for any domain on the internet?
  • How where they vetted?

Research exercise for the reader:

  • Have previously maliciously acting certificate authorities been removed from operating system's and web browser's default list of trusted certificates?

This video Let's Encrypt with Dane by Geoff Huston, APNIC summarizes it well.

Many TLS certificates are during their initial certification verified over an insecure channel. For example, Let's Encrypt is a very popular [5] certificate authority that provides free TLS certificates. Let's Encrypt often uses the ACME protocol HTTP-01 challenge to verify domain owners are really owners of the domain and authorized to request TLS certificates for their domain name. Most websites initially signing up for a free Let's Encrypt TLS certificate are verified by Let's Encrypt connecting to these websites over the insecure, unencrypted HTTP port 80. [6] Other TLS certificate authorities also use the ACME protocol. The ACME HTTP-01 challenge is vulnerable to man-in-the-middle attacks. [7] As a result, the initial root anchor is insecure.

To fix these issues, HTTP Public Key Pinning (HPKP) was invented but unfortunately deprecated later because, quote:

Due to HPKP mechanism complexity and possibility of accidental misuse, browsers deprecated and removed HPKP support in favor of Certificate Transparency and its Expect-CT header.


While Certificate Transparency might allow for faster detection, it does not prevent maliciously issued certificates such as through a malicious or hacked certificate authority.

The browser Chromium and Chrome still pin public key hashes for Google properties. [9] However, this functionality isn't available to most websites.

DANE (DNS-based Authentication of Named Entities) would be a huge improvements because it does not depend on any certificate authorities but only on the website's domain registrar. Unfortunately, no (mainstream) web browser has implemented DANE and it seems unlikely that DANE will be implemented.

  • Web Browsers:
  • E-mail servers:
    • Ironically [10] often have better DANE support (for example postfix .
  • E-mail clients:
    • Unfortunately, the author is not aware of any e-mail clients making use of DANE.
    • Alternative e-mail user to e-mail server encryption: E-mail servers have the ability to implement user to e-mail server encryption through providing an onion service. That is because e-mail fetching protocols (POP, IMAP) as well as mail submission protocols (SMTP) can be tunneled through onion. Web-mail obviously also works great over onion. That is because the e-mail fetching server (such as for example dovecot) or e-mail submission server (for example dovecot "do not care" how connections arrive at their listening ports. Transporting e-mails from users to e-mail servers is one thing and doable with reasonable effort. Sending e-mails to recipient@example.onion format addresses however is a different topic.
  • certbot implemented --reuse-key [11] which helps to simplify the process of which website owners can add DANE to their website or e-mail server.

TLS Attacks[edit]

A significant number of attacks have been demonstrated against the SSL/TLS protocol in the recent past, including: [12]

  • BEAST attack: violation of same origin policy constraints.
  • ChangeCipherSpec injection attack: a specially crafted handshake forces the use of weak keyring material, allowing decryption and modification of traffic in transit.
  • Cross protocol attacks: servers are attacked by exploiting their support of obsolete, insecure SSL protocols to leverage attacks on connections using up-to-date protocols.
  • Heartbleed: private keys are stolen from servers, allowing anyone to read the memory of protected systems.
  • POODLE attack: padding attacks which reveal the contents of encrypted messages.
  • Protocol downgrade: web servers are tricked into negotiating connections with earlier versions of TLS that are insecure.
  • RC4 attack: recovery of plain text relying on the RC4 cipher suite.
  • Renegotiation attack: plaintext injection attacks via the hijacking of the https connection.
  • TLS Compression (CRIME attack): session hijacking of web sessions via recovery of secret authentication cookies.
  • Truncation attack: victim logout requests are blocked so the user remains logged into a web service.
  • Unholy PAC attack: URLs are exposed when a user attempts to reach a TLS-enabled web link.


Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.