Mastodawn

The Hacker‘s Choice Feb 2

Kevin Beaumont Apr 15

Samofhearts Apr 10

@hacks4pancakes I want to take a second to publicly thank Lesley for helping me with my resume. On my first series of interviews post changing my resume per her suggestions I ultimately ended up receiving an offer. Unfortunately, I had to turn it down because it was a little under budget, but Lesley helped me so much and if you get a chance in the future you should set up a mentee session with her.

Samofhearts Apr 3

Wendy Nather Apr 2

I do not want your Gemini,
I do not want any AI.
I do not want it in my Chrome,
I do not want it in my home.
Not in my mail,
Even on sale,
Not in my app,
None of this crap.
I do not want it here or there,
I do not want it anywhere!

(with apologies to the estate of Dr. Seuss 🍳🍖)

Samofhearts Mar 28

CatSalad🐈🥗 (D.Burch)

Mar 28

It's Friday. Don't forget to vibe push to PROD on your way out!

Samofhearts Mar 25

HD Moore Mar 25

Jacob Sandum posted a detailed and well-written PoC for the IngressNightmare (CVE-2025-1974 ) vulnerability found in the Kubernetes ingress-nginx Admission Controller by Wiz (Woogle!). If you are looking for a quick way to reproduce the issue or validate detection and mitigation, take a look:
https://github.com/sandumjacob/IngressNightmare-POCs/blob/main/CVE-2025-1974/README.md

IngressNightmare-POCs/CVE-2025-1974/README.md at main · sandumjacob/IngressNightmare-POCs

CVE-2025-1974. Contribute to sandumjacob/IngressNightmare-POCs development by creating an account on GitHub.

GitHub

Samofhearts Mar 6

Daniela Quirke Mar 6

Libraries are bae. Free yourself from corporate, capitalist scams and find new, interesting things that haven't been selected for you by paternalistic algorithms.

Samofhearts Feb 7

Lesley Carhart

Feb 7

Just a reminder that our trans industry colleagues are literally running out the clock. Life and death. If you are wondering if you should offer them a gig even at a low rate outside America, for the love of Pete, do it now. There very well might not be a later for them, even to get a passport to leave. If this is imposter syndrome about their followers, credentials, or reputation, just offer the damn job. SOC analyst. Trainer. Anything.

Samofhearts Feb 3

DRAFT Release: Don't share outside mastodon yet. Please comment and review :>

https://hashnode.com/preview/6704fd37275ab42a417af94a

[Draft] Practical HTTPS Interception

20 years of SSL/TLS Interception - A disclosure

Hashnode

Samofhearts Jan 22

HD Moore Jan 22

runZero Hour Episode 14 (0xE) is happening now, you can find the YouTube live feed here: https://www.youtube.com/watch?v=nvkGd31s46c

runZero Hour: Episode 14

YouTube

Samofhearts Dec 30

SwiftOnSecurity Dec 30

Zoomers: "Hey why these mf so good at command line interfaces"

Millennials: "You wouldn't last an hour in the asylum where they raised me"

The Hacker‘s Choice Feb 2

DRAFT Release: Don't share outside mastodon yet. Please comment and review :>

https://hashnode.com/preview/6704fd37275ab42a417af94a

joernchen

Feb 2

@thc you nailed it with „no surprise here“. ¯_(ツ)_/¯

https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-10#section-10

joernchen

Feb 3

@thc I mean the ACME RFC states it already

An active attacker on the validation channel can subvert the ACME
process, by performing normal ACME transactions and providing a
validation response for his own account key.

Automatic Certificate Management Environment (ACME)

Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).

IETF Datatracker

@joern @thc I came here to say this. There’s a good chunk of truth in your article but I would tone down a bit of the hyperbole and uncertainty. Replace "all CAs" or "Let’s Encrypt" with All CAs doing ACME (e.g., Let’s Encrypt) and link to the spec.

@joern @thc Regarding the proposed changes:
1. CT already has a bandwidth/storage/scalle issue. Convincing someone to include more data is unlikely to succeed.
2. CAA checking in the browser would be an interesting experiment. Many already query DNS HTTPS resource records. But as you say, CAA adoption is very low.
3. Could we make ACME renewal behind HTTPS such that only the first certificate is unencrypted?

@joern @thc I also found a couple of minor typos. Link me to a file and I can send a diff / pull request.

@joern @thc Wait, I am slowly waking up 🥴.. How does CAA actually help though? It's a record to tell the world which certificate authority is allowed to create certs for a domain. But if you already use ACME with a specific CA, then the attack would just be confined to that very same specific CA. That doesn't really limit the attacker in any kind of way, does it?

@freddy @joern uhh. err. yes, you are correct. I made this clear now in the article. Thank you for your feedback. CAA on its own wont help. Instead, the requestor would need to proof that it has access to the current key for the CA to issue a new one (? just a wild idea?).

CAs have to perform one of the methods described in the CA/B Forum Server WG Baseline Requirements under 3.2.2.4. Perhaps with the acceptance of enough CAs and Browsers we can introduce a new method but requiring the previous certificate to get a new one has been a challenge for other protocols based on it like SCEP.

So far we focused on making verification better (you need to compromise all traffic) and results visible (CT). I think ACME challenges are the most (1/2)

@thc @freddy @joern secure of the existing methods. For example people still use phones and fax machines or mail.

Regarding CAA there are options whose support isn’t required (but Let’s Encrypt has it) to limit to specific accounts which would then require the account key to issue. And CAA can be applied per subdomain (per server?).

In practice very few people configured them, however, which makes it a small motivation for further work in this area :(

Frederik Braun �Feb 4

@antonis @thc @joern Right. Good point. Binding certificate requests to a specific ACME-account in CAA would secure all renewals. But it would still leave those that don't use Let's Encrypt/ACME for their certificates unprotected, as an attacker could just sign up as a new user.

@freddy @thc @joern

The CAA account limitation is purposefully not specific to ACME and CAs are using it with account IDs of their own systems for non-ACME issuance too.

A CAA record that only permits Let's Encrypt (which uses this) and ties issuance to one account should never allow anyone to issue without access to this account and have it not be a misissuance. Same with a manually-issued DigiCert certificate and a non-ACME account in the CAA record.

I think if your CA supports it, it's ok

@antonis @freddy @joern I can see the challenge with “new very only if you know old cert/key” but also feel it’s the obvious and easiest next move as a defender: enforce this only if mode=strict is set in the CAA record. If it fails then owner shall only be allowed to download new cert via web-login + 2FA or owner must temporarily remove mode=strict.
Still doesn’t solve the problem that almost nobody uses CAA. It’s a niche for nerds. The CA and (later) the browser manufacture could make “no CAA” far less appetising than CAA…..

Correct, there are 3 things here to note:

1) Downgrade attacks. I don't *have* to use the new super-secure challenge, I can always use HTTP-01 if I am an attacker with MITM access.

2) The CAA record is still required for protection as today all CAs are trusted equally. Without it, any CA with broken processes can fall back to phone / fax / mail / e-mail / ... and since there's a very long tail of quality, it'll work.

3) Most domains by count have DNS + WWW on the same IP

This latter part is a problem as there's also no DNSSEC in this average domain name. It's large shared hosting farms. You can just as easily change CAA / do DNS-01 if you control the traffic to WWW.

@antonis @freddy @joern from an attacker it is harder (often impossible) to intercept the DNS as well. It raises the bar and DNSSEC is not needed to get started. It’s better (much better) than doing nothing :) every little help.

Exactly, and that's the spirit. Try to protect as many properties or users as you can, by default, without necessarily involving operators that may not know about the existence of all these things or have the time to configure them.

This is why I think all these plaintext challenges have been successful. They were not nihilistic and 100%-secure-or-nothing, but worked good enough in reality and beat the alternative.

That's why MPDV reduces risk by moving work to the CA too

@antonis @freddy @joern 100% agree. ACME-HTTP-01 stops Eve but not Malory. And they did well and it was a success. But Malory is on the rise….and admins do not (and should not have to) understand the risk.

@antonis @freddy @joern “most domains have DNS and WWW on the same IP”? I don’t see that in the wild. The NS of any domain is almost always not the IP of the www and mostly “far away” from the WWW and…DNS has it that there are at least 2, sometimes 3 or 4 authoritative servers at different geo locations (not equal www location).

Per bit/sec or req/sec this is true. But for domains, I don't think so. All of the cPanel / Plesk shared hosting instances have 100-5'000 domains in a single Linux box with bind/PowerDNS & nginx/apache and that's it. All of these old school PHP apps, Wordpress, Drupal, etc. that do it for 1-5€ / mo.

By default these panels configure everything in a single machine, including MySQL and e-mail, and by domain count it's the most common case. Full service colocation :(

@freddy @joern thank you for your feedback. Toned down and added "ACME".

Sven Feb 8

@freddy @joern @thc This also isn't something new with/specific to ACME, other CAs Domain Validation processes also often have "present a file at a HTTP URL" as an option? (e.g. docs from Digicert: https://docs.digicert.com/en/certcentral/manage-certificates/organization-and-domain-management/manage-domains/supported-domain-control-validation--dcv--methods-for-domain-prevalidation.html , note that higher up in the doc says that WHOIS-based methods are being removed)

Supported domain control validation (DCV) methods for domain prevalidation

Frederik Braun �Feb 8

@HeNeArXn @joern @thc reminds me I got a cert for a throw-away email provider because they protected access to the mailboxes for webmaster, hostmaster, and ssladmin but not.. certmaster or something?

@joern Thank you for your feedback. I've added your link and made it more clear at the top that "cleartext auth" is a feature of RFC-8555. Not everything in the RFC is secure or clever. It's time to abandon "cleartext auth" for cert-issuance for the same reason that we have given up on RFC-854 (telnet) and so many others....

Code of Amor 💘Feb 2

@thc a well-written article. Definitely needs addressing with the massive use of LetsEncrypt and ZeroSSL-like services. I mean, obviously, we could pay for CA-issued, long-lived TLS certs... but who is going to pay when free exists... it could all be a ploy to pander to our illusion of safety, all while making the digital world at large vulnerable and observable. Doesn't even require prism-level sneakiness.

waldi Feb 3

@codeofamor And how exactly do those providers verify the identity that does not rely on interceptable means?

Code of Amor 💘Feb 3

@waldi Is this a rhetorical question or were you asking for a walkthrough?

waldi Feb 3

@thc Question, just questions.

1. Which hoster in there right mind allows a customer L2 ethernet access shared with others? Fixing that is however easy: Set in DNS a CAA issue record "letsencrypt.org;validationmethods=dns-01" and enable DNSSEC: voila, no longer interceptable.

2. No actual information why the author came to this conclusion.

3. Come to dev-security-policy@mozilla.org.

@waldi I would say, about 50% of all hosts I gain access to. Most big players (AWS, OVH, ..) dont allow it however. Reached almost 100% for self-hosted or on-prem servers.

1. CAA, thank you for your feedback on this. I made it more clear further down why CAA is not the full solution (but needs to be enforced/checked by the browser or so to encourage admins to use CAA. Almost nobody of the S&p500 uses CAA tags....that's alarming.

2. Uhh, which part?

3. I so wish, but time....

Søborg Feb 3

@thc This is solved with ACME-CAA (#RFC8657), not that people use ACME-CAA, but it is actually fairly easy to setup: https://norrebro.space/@n/111355026651084793

Søborg (@n@norrebro.space)

Keep leaving dangling DNS records pointing towards DO/Linode? Worried about potential BGP hijacking? Concerned about running a russian Jabber and the possibility of law enforcement interference? Well, we've got a solution for you! Introducing: ACME-CAA (#RFC8657) 🚀 If you're only using Let's Encrypt as CA and Caddy's automatic cert management, you can easily protect against these scenarios. I've written a small guide here: https://søb.org/ACME-CAA/

Nørrebro.space

@n Thank you for your feedback. Thank you for the RFC-8657 note. I have not read it yet but I assume it has the same problem as RFC-8555 - it shifts the liability to the admin to use it. It's totally voluntary and no end-user can tell (by browser locks or so) that it is being used.

Dr. Christopher Kunz Feb 3

@thc What I don't get: In section 3 you write "No, we wont fix this with CAA tags in the DNS record.", then go on to present two ideas how to fix it with CAA. Am I misreading this?

Also, notable that your idea three is already implemented for Cloudflare customers (even for CF's own cert issuing process) and LE is working on making renewal more invisible by discontinuing renewal reminders. That way, people will know even less when to expect a new LE certificate for their domain to be issued.

@christopherkunz thank you for your feedback. I've now changed this to make it clear that CAA is not the full solution. It still needs to "force" all admins to use it and there should be a visible indication to the end-user (browser lock?) when it is not...and there might even be easier or better solutions to prevent this loophole from being exploited.

Dr. Christopher Kunz Feb 3

@thc I'm not sure that the CA/B is going to condone re-implementing visible indicators for specific certificate types or features. It felt to me that after the whole "EV green bar" thing, they're kinda through with that idea.

It's a delicate balance between security and usability. Although I wholly support your point that ACME HTTP-01 can be MITMed, I'm not sure if additional technical complexity would be beneficial to overall security. Just my two cents...

John-Mark Gurney Feb 3

@thc
Question, why isn't dns-01 mentioned? It's not clear if let's encrypt does DNSSEC validation, but it should and would address the problem mentioned. But this article also implies that all certs are vulnerable, but I have a CAA record which only allows dns-01 and does not allow http challenges.

@encthenet thank you for your comments. I don’t think the article says “all certs” but instead “all CA using acme” …but you are right that I should mention “unless domain has a CAA record that disallows acme-http-01” 🤙

John-Mark Gurney Feb 4

@thc
Yeah, it doesn't say all certs, but there are statements that heavily imply all certs issued by let's encrypt.

> LE’s achilles heel is that it uses a HTTP/cleartext request to the target’s web server (port 80) to authorise the issuance of a new TLS Certificate (ACME).

I would add something like "most users by default use".

Also, dns-01 is part of acme.

It's good for articles like this to also mention mitigations and switching to dns-01 is one (only? Since alpn is also vulnerable) way.

The Hacker‘s Choice Feb 5

@encthenet thanks for the feedback. I’ve changed ACME to ACME-HTTP-01. Further below I mention why CAA did not work for the masses. Adoption rate shows that this is (and likely only ever will) be for security geeks and nerds. The masses need something that is “secure by default” or at least making it harder (more work) for the admins to _not_ use CAA…