Transport Layer Security (TLS)

From Kicksecure
(Redirected from TLS)
Jump to navigation Jump to search

The Broken Certificate Authority System

Introduction[edit]

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 kicksecure.com), meaning the connection is private, authenticated and reliable. For a detailed overview of the TLS design, refer to this Wikipedia entryarchive.org.

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):

Untrustworthy Certificate Authorities[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, APNICarchive.org summarizes it well.

Censorship[edit]

https://community.letsencrypt.org/t/dnr-online-ru-certificate-was-revoked/48809archive.org

Domain Verification Insecurity[edit]

Many TLS certificates are during their initial certification verified over an insecure channel. For example, Let's Encryptarchive.org is a very popular [5] certificate authority that provides free TLS certificates. Let's Encrypt often uses the ACMEarchive.org 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.

https://letsencrypt.org/2020/02/19/multi-perspective-validation.htmlarchive.org

HTTP Public Key Pinning[edit]

To fix these issues, HTTP Public Key Pinning (HPKP)archive.org 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 Transparencyarchive.org and its Expect-CT header.

[8]

Certificate Transparency[edit]

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

Key Pinning[edit]

HTTP Public Key Pinning (HPKP) was deprecated but Google is still using key pinning.

Hardcoded Key Pinning[edit]

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

DANE[edit]

DANEarchive.org (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 attackarchive.org: violation of same origin policy constraints.
  • ChangeCipherSpec injection attackarchive.org: a specially crafted handshake forces the use of weak keyring material, allowing decryption and modification of traffic in transit.
  • Cross protocol attacksarchive.org: servers are attacked by exploiting their support of obsolete, insecure SSL protocols to leverage attacks on connections using up-to-date protocols.
  • Heartbleedarchive.org: private keys are stolen from servers, allowing anyone to read the memory of protected systems.
  • POODLE attackarchive.org: padding attacks which reveal the contents of encrypted messages.
  • Protocol downgradearchive.org: web servers are tricked into negotiating connections with earlier versions of TLS that are insecure.
  • RC4 attackarchive.org: recovery of plain text relying on the RC4 cipher suite.
  • Renegotiation attackarchive.org: plaintext injection attacks via the hijacking of the https connection.
  • TLS Compression (CRIME attack)archive.org: session hijacking of web sessions via recovery of secret authentication cookies.
  • Truncation attackarchive.org: victim logout requests are blocked so the user remains logged into a web service.
  • Unholy PAC attackarchive.org: URLs are exposed when a user attempts to reach a TLS-enabled web link.
  • The ROBOT Attackarchive.org is the return of a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server.

Mitigation[edit]

TODO: expand

A non-comprehensive of mitigation techniques to reduce TLS based risks:

Power Abuse[edit]

Footnotes[edit]

https://smallstep.com/blog/everything-pki/#trustworthinessarchive.org

https://hexatomium.github.io/2020/10/17/001.htmlarchive.org

https://scotthelme.co.uk/revocation-checking-is-pointless/archive.org

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!