Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

5.4K
active users

techhub.social: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.6

#acme

1 post1 participant0 posts today
Public
opendev | scs

Manchmal wünsche ich mir doch schon die Zeit zurück, in der man einfach mal in einen IRC-Channel sprang und dort mit einer qualifizierten Fehlerbeschreibung auch eine qualifizierte und hilfreiche Antwort bekam.
Damals haben Applikationen aber auch noch qualifizierte Fehlermeldungen ausgegeben. #rage #caddy #ReverseProxy #acme

Public
Aral Balkan

So after listening to your feedback, I agree: let’s spend that money in the EU to create a publicly-owned, free and open ACME-compatible certificate authority.

See post quoted below, with links to Tom’s work as he’s already been thinking/working on this.

#EU #ACME #TLS #security #LetsEncrypt #technologyCommons #SmallTech mamot.fr/@tdelmas/114224564125

Mamot - Le Mastodon de La Quadrature du Net Tom (@tdelmas@mamot.fr)@aral@mastodon.ar.al Or let's use the protocol they created - ACME - to create more independent CA, EU-based ! https://github.com/tdelmas/Let-s-Clone
Replied to @BjornW@mastodon.social
Public
Erik van Straten

@BjornW :

I've stopped doing that after a lot of people called me an idiot and a liar if I kindly notified them. I stopped, I'll get scolded anyway.

Big tech and most admins want everyone to believe that "Let's Encrypt" is the only goal. Nearly 100% of tech people believe that.

And admins WANT to believe that, because reliable authentication of website owners is a PITA. They just love ACME and tell their website visitors to GFY.

People like you tooting nonsense get a lot of boosts. It's called fake news or big tech propaganda. If you know better, why don't you WRITE BETTER?

It has ruined the internet. Not for phun but purely for profit. And it is what ruins people's lives and lets employees open the vdoor for ransomware and data-theft.

See also infosec.exchange/@ErikvanStrat (and, in Dutch, security.nl/posting/881296).

@troyhunt @letsencrypt

Infosec ExchangeErik van Straten (@ErikvanStraten@infosec.exchange)🌘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 #DV #LE #LetsEncrypt #Certificates #Certs #Misissuance #Mis_issuance #Revocation #Revoked #Weaknessess #WeakCertificates #WeakAuthentication #Authentication #Impersonation #Identification #Infosec #DNS #DNSHijacks #SquareSpace #Authorization #UnauthorizedChanges #UnauthorizedModifications #DeFi #dydx_exchange #CryptoCoins
#DV#Impersonation#AnonymousCertificates
Public
@BjornW@mastodon.social

FYI laatste dag om bijdrage te leveren aan @forumstandaardisatie internet consultatie over Automatic Certificate Management Environment (ACME)

Zie:
forumstandaardisatie.nl/nieuws

Geen idee wat ACME is?

Dan val je waarschijnlijk buiten de doelgroep 😉

Nieuwsgierig? Dan kun je je kennis wel vergroten met deze link:

en.wikipedia.org/wiki/Automati

www.forumstandaardisatie.nlACME in de aandacht? Geef uw mening! | Forum Standaardisatie
#ACME#Tech#Internet
Public *
Vereniging NLUUG

@forumstandaardisatie roept experts op om een bijdrage te leveren aan een consultatie over het gebruik van ACME (Automatic Certificate Management Environment) binnen de overheid.

Heb jij kennis van dit onderwerp? Neem dan deel aan de consultatie. Zie de oproep:

forumstandaardisatie.nl/nieuws

nluug.nl/nieuws/forum-standaar

www.forumstandaardisatie.nlACME in de aandacht? Geef uw mening! | Forum Standaardisatie
#acme#internetconsultatie#forumstandaardisatie
Public
SPdevALK 🐘️ ☑️

Ok, #Pihole version 6 update needed me to undertake 3 manual interventions:
- #dnsmasq
is disabled now (by default), so I transferred the config in /etc/dnsmasq.d (conditional/reverse resolvers) to Pihole itself
- #ACME #certbot needed to produce a single combined certificate file for pihole web UI which needed a script configured as a ‘deploy-hook’ to facilitate this
-lastly the purging of php and lighttpd was a manual thing as well

That was three hours well spent 😅

Public
Elias Probst

@jpmens what are other #ACME providers except of @letsencrypt and where are they located?

@european_alternatives lists only one (#BuypassGoSSL) so far:
european-alternatives.eu/categ

#ZeroSSL itself seems to be Austria-based, but is a subsidiary of HID Global (Texas, US) which again is a subsidiary of ASSA Abloy (Sweden), so it being independent from US-shenanigans is not quite clear.

We should probably start shipping a "ca-certififcates-eu" package in distributions...

European AlternativesEuropean ACME SSL certificate providers | European AlternativesAn SSL certificate is a digital certificate that is used to establish an encrypted connection to a web server (HTTPS).
Public
Erik van Straten

Fsck de overheid: "Het automatiseren van certificaatbeheer door de overheid op basis van ACME zorgt voor het efficiënter en betrouwbaarder verkrijgen, vernieuwen en intrekken van TLS-certificaten. Dit maakt de digitale overheid betrouwbaarder, wendbaarder en minder leveranciersafhankelijk", aldus de experts. "Daarnaast vermindert het gebruik van ACME de beheerlast voor het beheer van TLS-certificaten."
security.nl/posting/876900/ACM.

In een tijd waarin burgers, online, met steeds hogere betrouwbaarheid moeten authenticeren (o.a. voor online leeftijdsverificatie en binnenkort met eID's zoals EDIW/EUDIW), en de anonieme nepwebsites als paddenstoelen uit de grond schieten (*), is dit een *KRANKZINNIG* plan.

(*) Daarbij geen strobreed in de weggelegd door BigTech - integendeel: medeplichtigheid aan cybercrime is hun verdienmodel geworden.

Het grote risico hier zijn AitM- (Attacker in the Middle) aanvallen: nietsvermoedende mensen worden via een bericht of een Google zoekresultaat naar een nepwebsite gestuurd, die hen vraagt om bijv. een scan van hun paspoort te uploaden en een selfie-filmpje te maken.

Beide stuurt de nepwebsite echter dóór naar een echte website, zoals van een bank, bijv. om een lening af te sluiten. De AitM neemt dat geld op, waarna het slachtoffer opdraait voor de schuld.

Een ESSENTIËLE voorwaarde voor betrouwbare authenticatie is dat je de VERIFIEERDER kunt vertrouwen.

Of dat zo is, weet je nooit zeker (ook offline niet). Het beste alternatief is dat je weet *WIE* de verifieerder is, en hoe betrouwbaar diens identiteit is vaatgesteld. Dat is, zonder meer, vervelend en prijzig voor eigenaren van websites waar klanten, burgers of patiënten risicovolle transacties doen en/of er vertrouwelijke gegevens mee uitwisselen - maar enorm in het belang van bezoekers van dergelijke websites.

Betrouwbare authenticatie van (de juridisch aansprakelijke) eigenaar van een website m.b.v. een website-certificaat vormt *technisch* geen enkel probleem (dit *hadden* we al, maar is met een smoes gesloopt door Google).

In gratis certificaten, bijvoorbeeld van Let's Encrypt (zoals gebruikt door de nepwebsites in onderstaand plaatje) staat uitsluitend een volstrekt anonieme domeinnaam; je hebt dus geen idee wie verantwoordelijk is voor de website.

Juist bij overheidswebsites is het essentieel dat je weet dat het écht om een overheidswebsite gaat - iets dat bij de in het plaatje getoonde domeinnamen (ik heb de punt door + vervangen), zoals:

• afhandelen-belasting+com
• aflossen-belastingdienst+com

beslist *niet* het geval is.

En in de echte ggn.nl/contact/phishing/ kunt u voorbeelden zien van domeinnamen van nepwebsites, zoals ook te zien in onderstaand plaatje.

Kennelijk lukt het niemand om dergelijke criminele websites uit de lucht te halen, terwijl de misdadigers er probleemloos Let's Encrypt certificaten voor *blijven* verkrijgen - naast dat de naar phishing stinkende domeinnamen zonder blikken of blozen worden verhuurd en nooit worden ingetrokken. Dit is simpelweg de SNELSTE en GOEDKOOPSTE oplossing voor eigenaren van websites; de *BEZOEKERS* van die websites draaien op voor alle risico's.

Het onderstaande plaatje is van een Russische server, maar dit soort phishing websites vind je ook bij de vleet op door criminelen gehuurde servers van Google, Amazon, Microsoft, Digital Ocean, Cloudflare en kleinere westerse hostingbedrijven.

Ben ik nou ÉCHT DE ÉNIGE die vindt dat deze gecriminaliseerde puinhoop keihard moet worden aangepakt?

Zie mijn uitgebreide reactie in security.nl/posting/876914 (beginnend met eenvoudige uitleg wat een website-certificaat is).

Nb. naast certificaatuitgevers moeten ook browsers en het CA/B-forum op de schop. Doen we dit allemaal niet, dan wordt verder digitaliseren een gigantische puinhoop met steeds meer slachtoffers van identiteitsfraude.

Screenshot van een deel van de webpagina https://www.virustotal.com/gui/ip-address/193.143.1.14/relations Te zien zijn een reeks domeinnamen die vandaag (in alle gevallen is links de datum 2025-02-19 te zien) via DNS resolvden naar IP-adres 193.143.1.14 (een server in Rusland). Te zien zijn domeinnamen en het aantal virusscanners dat erop aanslaat (die laatste vooraan en, om onbedoeld openen te voorkómen, heb ik de punt vervangen door een plusje), waaronder: 15/94 aanmaning-aflossen+com 10/94 aanmaning-omleiding24+com [...] ik laat een stel Engelstalige weg 12/84 afbetalen-ggn+com 6/94 afhandelen-belasting+com 13/94 aflossen-belastingdienst+com 6/94 aflossen-nl+com 14/94 afronden-ggn+com Die laatste valt half buiten het plaatje (een bonusje voor Alt-lezers). GGN.nl is een bekend incassobureau en deurwaarderskantoor.
#DVcerts#ACME#LetsEncrypt
Public
Alex

Oh, that’s a shame, but understandable, I guess..
"Let's Encrypt: Ending OCSP Support in 2025"
letsencrypt.org/2024/12/05/end
#web #acme #ssl

letsencrypt.orgEnding OCSP Support in 2025Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services: January 30, 2025 OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension May 7, 2025 Prior to this date we will have added CRL URLs to certificates On this date we will drop OCSP URLs from certificates On this date all requests including the OCSP Must Staple extension will fail August 6, 2025 On this date we will turn off our OCSP responders Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension.
Replied in thread
Public
DigitalInfinity

@UmWerker

Hey ;) Wollt mal fragen, wie mittlerweile an der Stelle die Lage ist.
Schon die Segel ins Korn geworfen und die Flinte angestrichen?

Hab mal auf der HP von #webmin geschaut das Ding ist ja echt noch aktiv. Und #usermin auch noch. Echt cool.
Für #letsencrypt bin ich auf #acme.sh umgestiegen. Weiß nicht, ob's da ne Integration für webmin gibt.
Im Nachgang an unseren Thread hab ich im LAN auch noch mal #ispconfig neu installiert aber es hilft dir ja jetzt auch nicht wirklich weiter, wenn ich dir schreibe, dass das einwandfrei funktioniert hat. Werd aber auch webmin mal installieren und mir das anschauen.

Bei Bedarf könnt ma auch mal ne Session machen und schauen, ob ich dir helfen kann. Je mehr Menschen ihre Daten selbst in die Hand nehmen können und wollen desto besser.

Public *
mephisto

#pfsense service toot:

Using #ACME certificates on your #freeradius for wifi authentication and things stop working after 60 days when the cert renews?

in the acme configuration add the follwing php-command to the actions list:

require_once('/usr/local/pkg/freeradius.inc'); freeradius_eapconf_resync(true);

(Long time lingering bug in pfsense, #netgate is not willing to fix)

Public
DrScriptt

I started a discussion with fellow #sysadmin about updating #BIND / #named config to migrate from the overly permissive allow-update {…} stanzas to the more restricted update-policy {…} stanzas using targeted grant statements.

The idea being to allow the #acme client to only be able to update (add / delete) _acme-challenge TXT instead of any record in the zone.

Old:

allow-update {
TSIG_KEY_NAME;
};

New:

update-policy {
grant TSIG_KEY_NAME name _acme-challenge.example.net TXT;
};

#acmesh#certbot
ExploreLive feeds
About