There's our own local #nextcloud stack running featuring #collabora online and family's impressed so far. #stepca issues the #certs. The #cookbook #app is also nice btw! Next stop trying #AI with #NextcloudAssistant and test other nice things. Since my i3 is operating on it's limits right now, I've purchased an #refurbished #lenovo #thinkcenter core i7 with 16GB RAM being our third #docker host. 
#selfhosting #homelab #opensource
Recent searches
Search options
#certs
0 posts0 participants0 posts today
In https://www.security.nl/posting/852814/DV+certs%3A+de+maat+is+vol schreef ik (in het Nederlands) waarom het internet één grote criminele bende is geworden, refererend naar een eerdere serie (van 3) Engelstalige toots van mijn hand (https://infosec.exchange/@ErikvanStraten/112914047006977222).
In de tweede helft van https://security.nl/posting/852741 beschrijf ik een oplossing voor een deel van het probleem: dat websites, omwille van winstbejag van Big Tech, tot *eenheidsworst* zijn gemaakt.
Als bezoeker kunt u namelijk *nergens* meer uit opmaken of een website authentiek is, of dat er sprake is van inpersonatie van de echte website - door cybercriminelen.
Dat wordt veroorzaakt door browsermakers en certificaatuitgevers die alle mogelijke moeite hebben gedaan om u de informatie te onthouden *WIE* VERANTWOORDELIJK is voor een website (de domeinnaam daarvan om precies te zijn, die u ziet in de adresbalk van uw browser).
De *suggestie* van Big Tech dat het voor *u* goed genoeg is als u weet wat de domeinnaam is van een website, is absurd.
Dat is, in de praktijk, totale onzin omdat mensen uiterst slecht zijn in het exact (noodzakelijkerwijs 100% foutloos) kunnen herkennen van *volledige* domeinnamen - en eenvoudig gefopt kunnen worden (zelfs als zij begrijpen waar zij op moeten letten en hoe domeinnamen zijn opgebouwd).
Bij voor mensen nieuwe websites (zoals van een gegooglde loodgieter of een sandalenwebshop) zegt een domeinnaam meestal ofwel niets *betrouwbaars* over wie de eigenaar is, of is pure misleiding - terwijl elke pagina van de website zelf hartstikke nep kan zijn.
Kom in opstand tegen de geldwolven op internet!
www.security.nlDV certs: de maat is vol - Security.NL
Continued thread
DV-CERT MIS-ISSUANCE INCIDENTS
#3/3
Note: this list (in reverse chronological order) is probably incomplete; please respond if you know of additional incidents!
2024-07-31 "Sitting Ducks" attacks/DNS hijacks: mis-issued certificates for possibly more than 35.000 domains by Let’s Encrypt and DigiCert: https://blogs.infoblox.com/threat-intelligence/who-knew-domain-hijacking-is-so-easy/ (src: https://www.bleepingcomputer.com/news/security/sitting-ducks-dns-attacks-let-hackers-hijack-over-35-000-domains/)
2024-07-23 Let's Encrypt mis-issued 34 certificates,revokes 27 for dydx.exchange: see #2/3 in this series of toots
2023-11-03 jabber.ru MitMed/AitMed in German hosting center https://notes.valdikss.org.ru/jabber.ru
2023-11-01 KlaySwap en Celer Bridge BGP-hijacks described https://www.certik.com/resources/blog/1NHvPnvZ8EUjVVs4KZ4L8h-bgp-hijacking-how-hackers-circumvent-internet-routing-security-to-tear-the
2023-09-01 Biggest BGP Incidents/BGP-hijacks/BGP hijacks https://blog.lacnic.net/en/routing/a-brief-history-of-the-internets-biggest-bgp-incidents
2022-09-22 BGP-hijack mis-issued GoGetSSL DV certificate https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/
2022-09-09 Celer Bridge incident analysis https://www.coinbase.com/en-nl/blog/celer-bridge-incident-analysis
2022-02-16 Crypto Exchange KLAYswap Loses $1.9M After BGP Hijack https://www.bankinfosecurity.com/crypto-exchange-klayswap-loses-19m-after-bgp-hijack-a-18518
BACKGROUND INFO
2024-08-01 "Cloudflare once again comes under pressure for enabling abusive sites
(Dan Goodin - Aug 1, 2024) https://arstechnica.com/security/2024/07/cloudflare-once-again-comes-under-pressure-for-enabling-abusive-sites/
2018-08-15 Usenix-18: "Bamboozling Certificate Authorities with BGP" https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
Infoblox Blog · Who Knew? Domain Hijacking is So Easy | InfobloxLearn about the insidious DNS attack vector that threat actors are using to hijack domains from major brands, government institutions, and other organizations, large and small. Find out how to determine whether your domain name is at risk.
Continued thread
DYDX.EXCHANGE DV-CERT MIS-ISSUANCES#2/3
Below you can find a listing of 34 LE (Let's Encrypt) leaf certs (certificates) that were all issued on 2024-07-23 for [*.]dydx.exchange (i.e. literally dydx.exchange and *.dydx.exchange , where '*' represents exactly one subdomain level).
Most -if not all- of those certs were mis-issued to cybercriminals who used impersonating websites after modifying DNS records without authorization. Of those certs, only 27 were revoked (as of 2024-08-05).
More about the associated DNS attack can be read in https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/.
REMARKABLE / NOTES
Out of caution, all certs issued to [*.]dydx.exchange on 2024-07-23 should have been revoked.
I see no reason to assume that the 7 of the 34 certificates issued during the same small timeframe (14:26:21 GMT through 19:31:11 GMT, with the last non-revoked cert issued at 15:47:29 GMT, i.e. within 2 hours of the first cert) were not mis-issued.
Note: criminals can still abuse them by attacking individuals by forging DNS responses to them.
In one case, no reason whatsoever was specified for the revocation. In all other cases "cessationOfOperation" was specified.
IMO both are wrong and misleading. The reason should have been the one used for mis-issuance:
<<< privilegeWithdrawn (RFC 5280 CRLReason #9) >>>
See, for example, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons and https://blog.mozilla.org/security/2022/05/16/revocation-reason-codes-for-tls-server-certificates/.
In addition to the previous point: maybe I overlooked it, but I found no mention of this security incident on https://letsencrypt.org. Does LE *not* want you to know about this? What happened to "certificate transparency"?
For part of their subdomain names (such as links.dydx.exchange) dydx.exchange seems to have reused an asymmetric keypair *that* many times that tapping on "Subject Public Key Info" in i.e. https://crt.sh/?spkisha256=a49e1f32dc76b0fb9522eb4557b80ce522eab725ac8bfe67b510856e7de0ab8e causes crt.sh to time out (or to crash).
I don't know why there's always a one hour difference between the "invalid before" timestamp and the timestamp of the countersignature. Perhaps there's a mandatory 1 hour delay (please let us know if you know what the reason is).
IMPROVING READABILITY
I've removed all dates that were July 23, 2024 from the list below.
In addition, *each* certificate was actually issued for both:
<subDN>.dydx.exchangeNot mentioned in the following list: www.<subDN>.dydx.exchange
(this also applies to dydx.exchange and www.dydx.exchange).
Records in the list below are sorted in chronological order of issuance of the precertificate.
LEGENDA
r#nn: revoked, #nr (2 digits)
v#nn: valid (not revoked), #nr
f: valid From time (not valid before)
c: counter-signature timestamp
r: revocation timestamp + "(reason)"
s: source
---- BEGIN OF LIST ----
r#01: api.dydx.exchange
f: 14:26:21 GMT
c: 15:26:21.595 GMT
r: 20:59:14 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897807683&opt=ocsp
r#02: dydx.exchange
f: 14:26:23 GMT
c: 15:26:23.451 GMT
r: 21:00:08 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897808125&opt=ocsp
r#03: ios-beta.dydx.exchange
f: 14:26:47 GMT
c: 15:26:47.554 GMT
r: 20:59:36 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897811047&opt=ocsp
r#04: docs.dydx.exchange
f: 14:27:56 GMT
c: 15:27:56.096 GMT
r: 21:00:16 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897811225&opt=ocsp
r#05: links.dydx.exchange
f: 14:28:19 GMT
c: 15:28:19.601 GMT
r: 20:59:47 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897811650&opt=ocsp
r#06: integral.dydx.exchange
f: 14:28:22 GMT
c: 15:28:22.915 GMT
r: 21:00:22 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897821925&opt=ocsp
v#01: status.dydx.exchange
f: 14:28:37 GMT
c: 15:28:37.649 GMT
r: 
NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897817710&opt=ocsp
r#07: media.dydx.exchange
f: 14:29:06 GMT
c: 15:29:06.874 GMT
r: 20:59:56 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897812660&opt=ocsp
r#08: help.dydx.exchange
f: 14:29:18 GMT
c: 15:29:18.337 GMT
r: 21:00:31 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897814167&opt=ocsp
r#09: indexerv4staging.dydx.exchange
f: 14:29:19 GMT
c: 15:29:19.843 GMT
r: 21:12:13 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897819527&opt=ocsp
r#10: forward.dydx.exchange
f: 14:29:26 GMT
c: 15:29:27.028 GMT
r: 21:12:34 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897820336&opt=ocsp
v#02: metabase.dydx.exchange
f: 14:29:26 GMT
c: 15:29:27.210 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897815842&opt=ocsp
r#11: indexerv4dev.dydx.exchange
f: 14:29:51 GMT
c: 15:29:52.070 GMT
r: 21:12:52 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897821570&opt=ocsp
r#12: analytics.dydx.exchange
f: 14:30:21 GMT
c: 15:30:21.562 GMT
r: 21:12:21 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897822133&opt=ocsp
r#13: legacy-docs.dydx.exchange
f: 14:30:22 GMT
c: 15:30:22.997 GMT
r: 21:12:40 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897821933&opt=ocsp
r#14: margintokens.dydx.exchange
f: 14:30:38 GMT
c: 15:30:38.606 GMT
r: 21:13:01 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897821784&opt=ocsp
r#15: parity.dydx.exchange
f: 14:31:13 GMT
c: 15:31:13.749 GMT
r: 21:12:45 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897830727&opt=ocsp
r#16: skhelp.dydx.exchange
f: 14:31:14 GMT
c: 15:31:14.982 GMT
r: 21:12:27 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897829203&opt=ocsp
r#17: pm-bounces.dydx.exchange
f: 14:31:38 GMT
c: 15:31:38.388 GMT
r: 21:13:09 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897833728&opt=ocsp
r#18: trade.dydx.exchange
f: 14:32:28 GMT
c: 15:32:28.689 GMT
r: 21:18:56 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897833284&opt=ocsp
r#19: v#03: margin.dydx.exchange
f: 14:32:36 GMT
c: 15:32:37.015 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897844502&opt=ocsp
r#20: stage.dydx.exchange
f: 14:32:41 GMT
c: 15:32:41.083 GMT
r: 21:18:29 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897834807&opt=ocsp
v#04: whitepaper.dydx.exchange
f: 14:33:17 GMT
c: 15:33:18.231 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897844858&opt=ocsp
r#21: testing.dydx.exchange
f: 14:33:35 GMT
c: 15:33:35.409 GMT
r: 21:18:36 UTC (cessationOfOperation)
s: https://crt.sh/?id=13852529152&opt=ocsp
v#05: url5082.dydx.exchange
f: 14:33:47 GMT
c: 15:33:47.838 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897842992&opt=ocsp
r#22: plhelp.dydx.exchange
f: 15:35:53 GMT
c: 16:35:53.580 GMT
r: 21:30:36 UTC
s: https://crt.sh/?id=13898344519&opt=ocsp
r#23: alpha.dydx.exchange
f: 14:36:47 GMT
c: 15:36:47.886 GMT
r: 21:19:04 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897856627&opt=ocsp
r#24: indexerv4testnet.dydx.exchange
f: 14:37:43 GMT
c: 15:37:44.056 GMT
r: 21:29:58 UTC (cessationOfOperation)
s: https://crt.sh/?id=13897859052&opt=ocsp
r#25: hihelp.dydx.exchange
f: 14:41:50 GMT
c: 15:41:50.408 GMT
r: 21:30:27 UTC
s: https://crt.sh/?id=13897870799&opt=ocsp
v#06: em5800.dydx.exchange
f: 14:44:19 GMT
c: 15:44:19.193 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13897878923&opt=ocsp
r#26: v4dev.dydx.exchange
f: 14:45:36 GMT
c: 15:45:36.560 GMT
r: 21:30:04 UTC
s: https://crt.sh/?id=13897883063&opt=ocsp
1 hour later, not revoked:
v#07: slack.dydx.exchange
f: 15:47:29 GMT
c: 16:47:29.547 GMT
r: NOT REVOKED (as of 2024-08-05)
s: https://crt.sh/?id=13898502795&opt=ocsp
hours later, revoked:
r#27: metrics.dydx.exchange
f: 19:31:11 GMT
c: 20:31:12.076 GMT
r: 20:43:16 UTC (NO REASON PROVIDED)
s: https://crt.sh/?id=13900209357&opt=ocsp
---- END OF LIST ----
DV-CERT MIS-ISSUANCES & OCSP ENDING#1/3
On Jul 23, 2024, Josh Aas of Let's Encrypt wrote, while his nose was growing rapidly:
<<< Intent to End OCSP Service
[...]
We plan to end support for OCSP primarily because it represents a considerable risk to privacy on the Internet.
[...]
CRLs do not have this issue. >>>
https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html
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.
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.
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.
NO OCSP INCREASES INTERNET RISKS
If LE quits OCSP support, the average risk of using the internet will *increase*.
LIES
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 (
).
( 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.)
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).
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.
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.
Josh, stop lying to us; your motives are purely economical.
CORRUPT: BIG TECH FACILITATES CRIME
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, https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/).
This message was repeated by many specialists (e.g. https://www.troyhunt.com/paypals-beautiful-demonstration-of-extended-validation-fud/) with stupid arguments: certificates do NOT directly warrant reliable websites.
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.
"Of course" Google recently lost trust in Entrust for mis-issuing certificates (https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html).
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 https://www.virustotal.com/gui/ip-address/188.114.96.0/relations; tap ••• a couple of times).
Supporting DN's like "ing–movil.com" and "m–santander.de" *is* facilitating cybercrime, by repeatedly mis-issuing certs for them (see https://crt.sh/?q=ing-movil.com and https://crt.sh/?q=m-santander.de) and by letting them hide behind a CDN (see https://www.virustotal.com/gui/domain/ing-movil.com/details and https://www.virustotal.com/gui/domain/m-santander.de/details).
In addition, *thousands* of DV-certs have been mis-issued - without *their* issuers getting distrusted by Google, Microsoft, Apple and Mozilla.
People have their bank accounts drained and companies get slammed with ransomware because of this.
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*.
CERT MIS-ISSUANCE ROOT CAUSE
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 https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/.
Note that a similar attack, also affecting SquareSpace customers, occurred on July 11, 2024 (see https://www.bleepingcomputer.com/news/security/dns-hijacks-target-crypto-platforms-registered-with-squarespace/). 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.
MORE INFO
Please find additional information in two followups of this toot:
#2/3 Extensive details regarding Mis-issued dydx.exchange certs on 2024-07-23;
#3/3 Links to descriptions of multiple other DV-cert mis-issuance issues.
DISCLAIMER
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.
Edited 08:16 UTC to add people:
@troyhunt
@dangoodin
@BleepingComputer
@agl
letsencrypt.org
Intent to End OCSP Service - Let's Encrypt
Today we are announcing our intent to end Online Certificate Status Protocol (OCSP) support in favor of Certificate Revocation Lists (CRLs) as soon as possible. OCSP and CRLs are both mechanisms by which CAs can communicate certificate revocation information, but CRLs have significant advantages over OCSP. Let’s Encrypt has been providing an OCSP responder since our launch nearly ten years ago. We added support for CRLs in 2022.
Websites and people who visit them will not be affected by this change, but some non-browser software might be.