{{Header}} {{Title|title= Transport Layer Security (TLS) }} {{#seo: |description=The Broken Certificate Authority System |image=TLS1432.jpg }} [[File:TLS1432.jpg|thumb]] {{intro| 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. https://en.wikipedia.org/wiki/Transport_Layer_Security 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 {{Project_clearnet}}), meaning the connection is private, authenticated and reliable. For a detailed overview of the TLS design, refer to [https://en.wikipedia.org/wiki/Transport_Layer_Security 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 [[Warning#Man-in-the-middle_Attacks|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. https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise Examples of CA security breaches include (ordered roughly by severity of the breech): * [https://arstechnica.com/information-technology/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/ 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".] [https://en.wikipedia.org/wiki/DigiNotar DigiNotar issues rogue HTTPS certificate for Google] , * [https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html Comodo issued rouge HTTPS certificate for Google, Yahoo, Skype, Firefox Add-Ons and live.com] [https://web.archive.org/web/20160604141017/http://www.scmagazine.com/two-more-comodo-resellers-owned-in-ssl-hack/article/199620/ Comodo] , * [https://arstechnica.com/information-technology/2015/09/symantec-employees-fired-for-issuing-rogue-https-certificate-for-google/ Ars Technica: "Symantec employees fired for issuing rogue HTTPS certificate for Google"], * [https://arstechnica.com/information-technology/2017/01/already-on-probation-symantec-issues-more-illegit-https-certificates/ Ars Technica: Symantec again], * [https://www.wired.com/threatlevel/2013/01/google-fraudulent-certificate/ Wired: Turktrust issued rouge HTTPS certificate for Google] * [https://sslmate.com/resources/certificate_authority_failures 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 [https://www.youtube.com/watch?v=09fNjMur1Gs 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, [https://letsencrypt.org Let's Encrypt] is a very popular Quote [https://letsencrypt.org Let's Encrypt] homepage:
A nonprofit Certificate Authority providing TLS certificates to 260 million websites.
 certificate authority that provides free TLS certificates. Let's Encrypt often uses the [https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment 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. https://letsencrypt.org/docs/challenge-types/#http-01-challenge Other TLS certificate authorities also use the ACME protocol. The ACME HTTP-01 challenge is vulnerable to man-in-the-middle attacks. https://security.stackexchange.com/questions/229050/is-the-acme-http-01-challenge-secure-against-mitms 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, [https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning 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 [https://en.wikipedia.org/wiki/Certificate_Transparency Certificate Transparency] and its Expect-CT header.
* https://www.theregister.com/2017/10/30/google_hpkp/ * https://www.zdnet.com/article/google-chrome-is-backing-away-from-public-key-pinning-and-heres-why/ == 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. * https://www.chromium.org/Home/chromium-security/education/tls#TOC-Certificate-Pinning * https://www.imperialviolet.org/2011/05/04/pinning.html * https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html However, this functionality isn't available to most websites. = DANE = [https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=672600 Use DNSSEC/DANE chain stapled *into TLS handshake in certificate chain validation], started working on it but later the ticket [https://bugzilla.mozilla.org/show_bug.cgi?id=672600#c64 was closed as wontfix]. *** There was a [https://web.archive.org/web/20230329214932/https://addons.mozilla.org/en-US/firefox/addon/dnssec-dane-validator/ DNSSEC/DANE Validator Firefox add-on], but the developers [https://www.dnssec-validator.cz/2018-10-16-end-of-support.html 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 [https://www.imperialviolet.org/2011/06/16/dnssecchrome.html removed]. *** [https://chrome.google.com/webstore/detail/dnssec-checker/amebjlfjmmeflkjhcealhbekaljgnekg DNSSEC Checker] chrome(ium) add-on but does it check DANE? * E-mail servers: ** Ironically One would expect web browsers with more users, supposedly more developers and more funding to be able to implement such an important security feature faster. 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 https://github.com/certbot/certbot/pull/5901 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: https://en.wikipedia.org/wiki/Transport_Layer_Security#Attacks_against_TLS/SSL * [https://blog.qualys.com/product-tech/2013/09/10/is-beast-still-a-threat BEAST attack]: violation of same origin policy constraints. * [https://en.wikipedia.org/wiki/OpenSSL#CCS_injection_vulnerability ChangeCipherSpec injection attack]: a specially crafted handshake forces the use of weak keyring material, allowing decryption and modification of traffic in transit. * [https://www.mitls.org/pages/attacks/VHC 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. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#Heartbleed Heartbleed]: private keys are stolen from servers, allowing anyone to read the memory of protected systems. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#POODLE_attack POODLE attack]: padding attacks which reveal the contents of encrypted messages. * [https://en.wikipedia.org/wiki/Downgrade_attack Protocol downgrade]: web servers are tricked into negotiating connections with earlier versions of TLS that are insecure. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attacks RC4 attack]: recovery of plain text relying on the RC4 cipher suite. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#Renegotiation_attack Renegotiation attack]: plaintext injection attacks via the hijacking of the https connection. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#CRIME_attack TLS Compression (CRIME attack)]: session hijacking of web sessions via recovery of secret authentication cookies. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#Truncation_attack Truncation attack]: victim logout requests are blocked so the user remains logged into a web service. * [https://en.wikipedia.org/wiki/Transport_Layer_Security#Unholy_PAC_attack Unholy PAC attack]: URLs are exposed when a user attempts to reach a TLS-enabled web link. * [https://www.robotattack.org/ 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 [https://github.com/SSLMate/certspotter Cert Spotter] ** third-party hosted such as by [https://sslmate.com/certspotter/ sslmate], [https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/ cloudflare], [https://developers.facebook.com/tools/ct/search/ 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/ {{reflist|close=1}} {{Footer}} [[Category:Documentation]] [[Category:Design]]