Erik van Straten<p>🌘DV-CERT MIS-ISSUANCES & OCSP ENDING🌒<br>🧵#1/3</p><p>On Jul 23, 2024, Josh Aas of Let's Encrypt wrote, while his nose was growing rapidly:</p><p><<< Intent to End OCSP Service<br>[...]<br>We plan to end support for OCSP primarily because it represents a considerable risk to privacy on the Internet.<br>[...]<br>CRLs do not have this issue. >>><br><a href="https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">letsencrypt.org/2024/07/23/rep</span><span class="invisible">lacing-ocsp-with-crls.html</span></a></p><p>🚨 On THAT SAME DAY, Jul 23, 2024, LE (Let's Encrypt) issued at least 34 certs (certificates) for [*.]dydx.exchange to cybercriminals, of which LE revoked 27 mis-issued certs approximately 6.5 hours later.</p><p>Note that falsified DNS records may instruct DNS caching servers to retain entries for a long time; therefore speedy revocation helps reducing the number of victims.</p><p>Apart from this mis-issuance *blunder*, CRL's have HUGE issues that Josh does not mention: they are SSSLLLOOOWWW and files are potentially huge - while OCSP is instantaneous and uses little bandwith.</p><p>🌘NO OCSP INCREASES INTERNET RISKS🌒<br>If LE quits OCSP support, the average risk of using the internet will *increase*.</p><p>🌘LIES🌒<br>Furthermore, the privacy argument is mostly moot, as nearly every website makes people's browsers connect to domains owned by Google (and even let's those browsers execute Javascript from third party servers, allowing nearly unlimited espionage). In addition, IP-addresses are sent in the plain anyway (📎).</p><p>(📎 When using a VPN, source and destination IP-addresses *within the tunnel* are not visible for anyone with access to the *outside* of the tunnel - but they are sent in the plain between the end of the tunnel and the actual server.)</p><p>Worse, the remote endpoint of your E2EE https connection increasingly often is *not* the actual server (that website was moved to sombody else's server in the cloud anyway), but a CDN proxy server which has the ability to monitor everything you do (unencrypting your data: three letter agencies love it, FISA section 702 grants them unlimmited access - without anyone informing you).</p><p>🤷 LE may try to blame others for their mis-issuance blunder, but *THEY* chose to use old, notoriously untrustworthy, internet protocols (BGP and DNS, including database records - that DNSSEC will never protect) as the basis for authentication. By making that choice, LE and other DV cert suppliers were simply ASKING for trouble.</p><p>🔓 In fact, the promise that Let's Encrypt would make the internet safer was misleading from the start: domain names are mostly meaningless to users, 100% fault intolerant, unpredictable and easily forgotten. If your browser is communicating with a malicious server, encryption is pointless.</p><p>Josh, stop lying to us; your motives are purely economical.</p><p>🌘CORRUPT: BIG TECH FACILITATES CRIME🌒<br>DV-certs were heavily promoted by Google (not for phun but for profit) after their researchers "proved" that it was possible to show misleasing identification information in the browser's address bar after certificate mis-issuance (the "Stripe, Inc" incident, <a href="https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">arstechnica.com/information-te</span><span class="invisible">chnology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/</span></a>).</p><p>This message was repeated by many specialists (e.g. <a href="https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">troyhunt.com/paypals-beautiful</span><span class="invisible">-demonstration-of-extended-validation-fud/</span></a>) with stupid arguments: certificates do NOT directly warrant reliable websites.</p><p>OV and EV certificates, and QWAC's, more or less reliably, warrant *WHO OWNS* a domain name. That means that users know *who* they're doing business with, can depend on their reputation and can sue them if they violate laws.</p><p>"Of course" Google recently lost trust in Entrust for mis-issuing certificates (<a href="https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">security.googleblog.com/2024/0</span><span class="invisible">6/sustaining-digital-certificate-security.html</span></a>).</p><p>Meanwhile the internet has become a corrupt and criminal mess; its users get to see misleading identification info in their browser's address bar WAY MORE OFTEN, e.g. https:⁄⁄us–usps–ny.com (for loads of examples see <a href="https://www.virustotal.com/gui/ip-address/188.114.96.0/relations" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">virustotal.com/gui/ip-address/</span><span class="invisible">188.114.96.0/relations</span></a>; tap ••• a couple of times).</p><p>Supporting DN's like "ing–movil.com" and "m–santander.de" *is* facilitating cybercrime, by repeatedly mis-issuing certs for them (see <a href="https://crt.sh/?q=ing-movil.com" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">crt.sh/?q=ing-movil.com</span><span class="invisible"></span></a> and <a href="https://crt.sh/?q=m-santander.de" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">crt.sh/?q=m-santander.de</span><span class="invisible"></span></a>) and by letting them hide behind a CDN (see <a href="https://www.virustotal.com/gui/domain/ing-movil.com/details" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">virustotal.com/gui/domain/ing-</span><span class="invisible">movil.com/details</span></a> and <a href="https://www.virustotal.com/gui/domain/m-santander.de/details" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">virustotal.com/gui/domain/m-sa</span><span class="invisible">ntander.de/details</span></a>).</p><p>In addition, *thousands* of DV-certs have been mis-issued - without *their* issuers getting distrusted by Google, Microsoft, Apple and Mozilla.</p><p>People have their bank accounts drained and companies get slammed with ransomware because of this.</p><p>But no Big Tech company (including the likes of Cloudflare) takes ANY responsibility; they make Big Money by facilitating cybercrime. Not by issuing "free" DV-certs, but by selling domain names, server space and CDN functionality, and by letting browsers no longer distinguish between useful and useless certs. They've deliberately made the internet insecure *FOR PROFIT*.</p><p>🌘CERT MIS-ISSUANCE ROOT CAUSE🌒<br>The mis-issuance of LE certs was caused by the unauthorized modification of customer DNS records managed by SquareSpace; this incident was further described in <a href="https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">bleepingcomputer.com/news/secu</span><span class="invisible">rity/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/</span></a>.</p><p>Note that a similar attack, also affecting SquareSpace customers, occurred on July 11, 2024 (see <a href="https://www.bleepingcomputer.com/news/security/dns-hijacks-target-crypto-platforms-registered-with-squarespace/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">bleepingcomputer.com/news/secu</span><span class="invisible">rity/dns-hijacks-target-crypto-platforms-registered-with-squarespace/</span></a>). Even if it *looks like* that no certs were mis-issued during the July 11 incident, because (AFAIK) none of them have been revoked, this does not warrant that none of them were mis-issued; such certs can still be abused by attackers, albeit on a smaller scale.</p><p>🌘MORE INFO🌒<br>Please find additional information in two followups of this toot:</p><p>🧵#2/3 Extensive details regarding Mis-issued dydx.exchange certs on 2024-07-23;</p><p>🧵#3/3 Links to descriptions of multiple other DV-cert mis-issuance issues.</p><p>🌘DISCLAIMER🌒<br>I am not (and have never been) associated with any certificate supplier. My goal is to obtain a safer internet, in particular for users who are not forensic experts. It is *way* too hard for ordinary internet users to destinguish between 'fake' and 'authentic' on the internet. Something that, IMO, can an must significantly improve ASAP.</p><p>Edited 08:16 UTC to add people:<br><span class="h-card" translate="no"><a href="https://infosec.exchange/@troyhunt" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>troyhunt</span></a></span> <br><span class="h-card" translate="no"><a href="https://infosec.exchange/@dangoodin" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>dangoodin</span></a></span> <br><span class="h-card" translate="no"><a href="https://infosec.exchange/@BleepingComputer" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>BleepingComputer</span></a></span> <br><span class="h-card" translate="no"><a href="https://infosec.exchange/@agl" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>agl</span></a></span> </p><p><a href="https://infosec.exchange/tags/DV" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DV</span></a> <a href="https://infosec.exchange/tags/LE" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>LE</span></a> <a href="https://infosec.exchange/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>LetsEncrypt</span></a> <a href="https://infosec.exchange/tags/Certificates" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Certificates</span></a> <a href="https://infosec.exchange/tags/Certs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Certs</span></a> <a href="https://infosec.exchange/tags/Misissuance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Misissuance</span></a> <a href="https://infosec.exchange/tags/Mis_issuance" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Mis_issuance</span></a> <a href="https://infosec.exchange/tags/Revocation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Revocation</span></a> <a href="https://infosec.exchange/tags/Revoked" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Revoked</span></a> <a href="https://infosec.exchange/tags/Weaknessess" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Weaknessess</span></a> <a href="https://infosec.exchange/tags/WeakCertificates" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WeakCertificates</span></a> <a href="https://infosec.exchange/tags/WeakAuthentication" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>WeakAuthentication</span></a> <a href="https://infosec.exchange/tags/Authentication" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Authentication</span></a> <a href="https://infosec.exchange/tags/Impersonation" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Impersonation</span></a> <a href="https://infosec.exchange/tags/Identification" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Identification</span></a> <a href="https://infosec.exchange/tags/Infosec" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Infosec</span></a> <a href="https://infosec.exchange/tags/DNS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNS</span></a> <a href="https://infosec.exchange/tags/DNSHijacks" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DNSHijacks</span></a> <a href="https://infosec.exchange/tags/SquareSpace" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>SquareSpace</span></a> <a href="https://infosec.exchange/tags/Authorization" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Authorization</span></a> <a href="https://infosec.exchange/tags/UnauthorizedChanges" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UnauthorizedChanges</span></a> <a href="https://infosec.exchange/tags/UnauthorizedModifications" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>UnauthorizedModifications</span></a> <a href="https://infosec.exchange/tags/DeFi" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>DeFi</span></a> <a href="https://infosec.exchange/tags/dydx_exchange" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>dydx_exchange</span></a> <a href="https://infosec.exchange/tags/CryptoCoins" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>CryptoCoins</span></a></p>