Transport Layer Security (TLS)

Kicksecure ™

Download

Debian morph to Kicksecure (Hardware) Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) USB ISO (coming soon) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Free Plus Premium Contact

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

The Broken Certificate Authority System

Introduction

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. 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 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

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.

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

• Ars Technica: DigiNotar issues rogue HTTPS certificate "for *.*.com and *.*.org, which would allow someone in possession of the certificates to perform man-in-the-middle attacks for almost any site with a .com or .org domain". ,
• Comodo issued rouge HTTPS certificate for Google, Yahoo, Skype, Firefox Add-Ons and live.com ,
• Ars Technica: "Symantec employees fired for issuing rogue HTTPS certificate for Google",
• Ars Technica: Symantec again,
• Wired: Turktrust issued rouge HTTPS certificate for Google
• the list goes on and on

Untrustworthy Certificate Authorities

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.

Censorship

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

Domain Verification Insecurity

Many TLS certificates are during their initial certification verified over an insecure channel. For example, Let's Encrypt is a very popular 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. Other TLS certificate authorities also use the ACME protocol. The ACME HTTP-01 challenge is vulnerable to man-in-the-middle attacks. As a result, the initial root anchor is insecure.

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

HTTP Public Key Pinning

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.

Certificate Transparency

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

Hardcoded Key Pinning

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

DANE

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:
  • Firefox:
    • Mozilla created a Firefox feature for Use DNSSEC/DANE chain stapled *into TLS handshake in certificate chain validation, started working on it but later the ticket was closed as wontfix.
    • There was a DNSSEC/DANE Validator Firefox add-on, but the developers decided to stop development and support after struggling and failing to implement the DNSSEC/TLSA Validator extension for Firefox Quantum (57+). This is worth further research.
  • Chromium based:
    • Chromium and Chrome had DNSSEC support (which is a prerequisite for DANE TLSA), but it was removed.
    • DNSSEC Checker chrome(ium) add-on but does it check DANE?
• E-mail servers:
  • Ironically 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 which helps to simplify the process of which website owners can add DANE to their website or e-mail server.

TLS Attacks

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

• 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.
• The ROBOT Attack 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

TODO: expand

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

• CAA policy
• Certificate Transparency Log Monitor:
  • self hosted such as Cert Spotter
  • third-party hosted such as by sslmate, cloudflare, facebook
• onion: Tor onion services (.onion) which are encrypted Tor to Tor ("end-to-end encryption") can be used as an alternative to TLS. Unfortunately both client and server require to run Tor. See also Non Anonymous Onion Encryption and NAT Traversal.

Power Abuse

• https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/

Footnotes

https://smallstep.com/blog/everything-pki/#trustworthiness

https://hexatomium.github.io/2020/10/17/001.html

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

---

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.

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

FREE  ·  PLUS  ·  PREMIUM Support

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012-2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

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!