ivanr

Feisty Duck's Cryptography & Security News: https://www.feistyduck.com/news/

It's a news aggregator focused on furthering our understanding of how cryptography is evolving. We're aiming to monitor the people on the ground who are doing the actual work, and amplify them.

The front page is a curated low-volume stream, but there's an all-news feed as well.

After producing Feisty Duck's Newsletter [1] for 12+ years, I built this for myself to make my life [following events] easier, but decided that it might be useful to others as well.

[1] https://www.feistyduck.com/newsletter/

You could argue that it was designed by one guy (Kipp Hickman) in three months:

https://www.feistyduck.com/newsletter/issue_131_the_legend_o...

More context: https://www.recall.ai/blog/postgres-listen-notify-does-not-s...

Spoiler: They're not identical.

No, DNSSEC can enforce strong cryptographic validation _today_. Here's how:

1. Configure a CAA record that restricts issuance to two CAs that support locking down issuance to specific customer accounts. For example, Let's Encrypt supports RFC 8657; DigiCert has a proprietary mechanism. After this, you can only issue certificates when you properly authenticate against your selected CAs.

2. Use only ACME validation methods that rely on DNS. Avoiding HTTP-01, for example, ensures that a MITM can't intercept that unencrypted network traffic and approve certificates with key material under their control.

3. Deploy DNSSEC. Your DNS is now cryptographically validated, meaning your CAA records can't be spoofed and the validation methods from step 2 can't be spoofed either.

Ah, sorry, I should have been more clear; I should have referenced this sibling comment: https://news.ycombinator.com/item?id=47403528

EKR is https://educatedguesswork.org/about/

I'll share a couple of thoughts, but do read EKR's blog first:

- Web PKI is inherently insecure and can't be fixed on its own. The root problem is that the CAs we "trust" can issue certificates without technical controls. The best we can do is ask them to be nice and force them provide a degree of (certificate) transparency to enable monitoring. This is still being worked on. Further, certificates are issued without strong owner authentication, which can be subverted (and is subverted). [3]

- The (very, very) big advantage of Web PKI is that it operates online and supports handshake negotiation. As a result, iteration can happen quickly if people are motivated. A few large players can get together and effect a big change (e.g., X25519MLKEM768). DNSSEC was designed for offline operation and lacks negotiation, which means that everyone has to agree before changes can happen. Example: Kipp Hickman created SSL and Web PKI in 3 months, by himself [1]. DNSSEC took years and years.

- DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.

- A few big corporations control this space, and they chose Web PKI.

- A humongous amount of resources has been spent on iterating and improving Web PKI in the last 30 years. So many people configuring certificates, breaking stuff, certificates expiring... we've wasted so much of our collective lives. There is a parallel universe in which encryption keys sit in DNS and, in it, no one has to care about certificate rotation.

- DNSSEC can't ever work end-to-end because of DNS ossification. End-user software (e.g., browsers) can't reliably obtain any new DNS resource records, be it DANE or SVCB/HTTPS.

- The one remaining realistic use for DNSSEC is to bootstrap Web PKI and, possibly, secure server-to-server communication. This is happening, now that CAs are required to validate DNSSEC. This one changes finally makes it possible to configure strong cryptographic validation before certificate issuance. [2]

[1] https://www.feistyduck.com/newsletter/issue_131_the_legend_o...

[2] https://www.feistyduck.com/newsletter/issue_126_internet_pki...

[3] https://redsift.com/guides/a-guide-to-high-assurance-certifi...

Maybe you're onto something, but in what way do you think that TLS is not serving other protocols?

Personally, I think we have a bigger problem on the PKI side, where Web PKI is very strong, but Internet PKI has been neglected. The recent move to remove client authentication is a good example.

If you like this sort of thing, perhaps you'll enjoy my SSL/TLS and PKI history where I track a variety of ecosystem events starting with the creation of SSL in 1994: https://www.feistyduck.com/ssl-tls-and-pki-history/

Yes, there is! After I left SSL Labs, I built Hardenize, which was an attempt to go wider and handle more of network configuration, not just TLS and PKI. It covers a range of standards, from DNS, over email, TLS and PKI, and application security.

Although Hardenize was a commercial product (it was acquired in 2022 by another company, Red Sift), it has a public report that's always been free. For example:

https://www.hardenize.com/report/feistyduck.com

The CSP inspection in Hardenize could use a refresh, but the TLS and PKI aspects are well maintained [at the time of writing].

Thanks! Sadly, SSL Labs doesn't appear to be actively maintained. I've noticed increasing gaps in its coverage and inspection quality. I left quite a while ago (2016) and can't influence its grading any more, sadly.

I wrote about ECH a couple of months ago, when the specs were still in draft but already approved for publication. It's a short read, if you're not already familiar with ECH and its history: https://www.feistyduck.com/newsletter/issue_127_encrypted_cl...

In addition to the main RFC 9849, there is also RFC 9848 - "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings": https://datatracker.ietf.org/doc/rfc9848/

There's an example of how it's used in the article.

As already noted on this thread, you can't use certbot today to get an IP address certificate. You can use lego [1], but figuring out the exact command line took me some effort yesterday. Here's what worked for me:

    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

[1] https://go-acme.github.io/lego/

I wrote about OpenSSL's performance regressions in the December issue of Feisty Duck's cryptography newsletter [1]. In addition to Alex's and Paul's talk on Python cryptography, at the recent OpenSSL conference there have been several other talks worth watching:

- William Bellingrath, from Juniper Networks, benchmarked versions from 1.1.1 to 3.4.x https://www.youtube.com/watch?v=b01y5FDx-ao

- Tomáš Mráz wrote about how to get better performance, which, in turn, explains why it's bad by default: https://www.youtube.com/watch?v=Cv-43gJJFIs

- Martin Schmatz from IBM presented about their _very detailed_ study of post-quantum cipher suite performance https://www.youtube.com/watch?v=69gUVhOEaVM

Note: be careful with these recorded talks as they have a piercing violin sound at the beginning that's much louder than the rest. I've had to resort to muting the first couple of seconds of every talk.

[1] https://www.feistyduck.com/newsletter/issue_132_openssl_perf...

Because "everybody uses RC4" (the sibling comment from dchest is correct). There was a lot of bad cryptography in that period and not a lot of desire to improve. The cleanup only really started in 2010 or thereabouts. For RC4 specifically, its was this research paper: https://www.usenix.org/system/files/conference/usenixsecurit... released in 2013.

> > transactional enqueueing > But it is safe as long as it's done inside a DBOS workflow.

Yes, but I was talking about the point at which a new workflow is created. If my transaction completes but DBOS disappears before the necessary workflows are created, I'll have a problem.

Taking my trial example, the onboarding workflow won't have been created and then perhaps the account will continue to run indefinitely, free of charge to the user.

> versioning

Here's an example of a common long-running workflow: SaaS trials. Upon trial start, create a workflow to send the customer onboarding messages, possibly inspecting the account state to influence what is send, and finally close the account that hasn't converted. This will usually take 14-30 days, but could go for months if manually extended (as many organisations are very flow in their evaluation).

I think an "escape hatch" would be useful here. On version mismatch, invoke a special function that is given access to the workflow state and let it update the state to work with the most recent version.

> transactional enqueuing

A workflow that goes "database transaction" -> "enqueue child workflow" is not safe if the connection with DBOS is lost before the second step completes safely. This would make DBOS unreliable. Doing it the other way round can work provided each workflow checks that the "object" to which it's connected exists. In my example above, if my "onboarding" workflow starts but the account ID cannot be located, the work is terminated early.

If both the app and DBOS work off the same database connection, you can offer exactly-once guarantees. Otherwise, the guarantees will depend on who commits first.

Personally, I would prefer all work to be done from the same connection so that I can have the benefit of transactions. To me, that's the main draw of DBOS :)

Hello Peter. Thank you for your work. I really like this approach. I too have been following Temporal and I like it, but I don't think it's a good match for simpler systems.

I've been reading the DBOS Java documentation and have some questions, if you don't mind:

- Versioning; from the looks of it, it's either automatically derived from the source code (presumably bytecode?), or explicitly set for the entire application? This would be too coarse. I don't see auto-configuration working, as a small bug fix would invalidate the version. (Could be less of a problem if you're looking only at method signatures... perhaps add to the documentation?) Similarly, for the explicit setting, a change to the version number would invalidate all existing workflows, which would be cumbersome.

Have you considered relying on serialVersionUID? Or at least allowing explicit configuration on a per workflow basis? Or a fallback method to be invoked if the class signatures change in a backward incompatible way?

Overall, it looks like DBOS is fairly easy to pick up, but having a good story for workflow evolution is going to be essential for adoption. For example, if I have long-running workflows... do I have to keep the old code running until all old instances complete? Is that the idea?

- Transactional use; would it be possible to create a new workflow instance transactionally? If I am using the same database for DBOS and my application, I'd expect my app to do some work and create some jobs for later, reusing my transaction. Similarly, maybe when the jobs are running, I'd perhaps want to use the same transaction? As in, the work is done and then DBOS commits?

I know using the same transaction for both purposes could be tricky. I have, in fact, in the past, used two for job handling. Some guidance in the documentation would be very useful to have.

Thank you.

+1 Absolutely. (Source: Original author of ModSecurity.)

I have a bunch of useful resources, most of which are free:

- If you're looking for a concise (yet complete) guide: https://www.feistyduck.com/library/bulletproof-tls-guide/

- OpenSSL Cookbook is a free ebook: https://www.feistyduck.com/library/openssl-cookbook/

- SSL/TLS and PKI history: https://www.feistyduck.com/ssl-tls-and-pki-history/

- Newsletter: https://www.feistyduck.com/newsletter/

- If you're looking for something comprehensive and longer, try my book Bulletproof TLS and PKI: https://www.feistyduck.com/books/bulletproof-tls-and-pki/

In what way does DoH provide end-to-end security? It doesn't, unless you adopt a different definition of "end-to-end" where the "server end" is an entity that's different from the domain name owner, but you're somehow trusting it to serve the correct/unaltered DNS entries. And even then, they can be tricked/coerced/whatever into serving unauthentic information.

For true end-to-end DNS security (as in authentication of domain owners), our only option is DNSSEC.

At best, you can argue that DoH solves a bigger problem.

Those two don't really compete. DNSSEC provides authenticity/integrity without privacy and DoH does exactly the opposite. If anything, you need both in order to secure DNS.

Your comment doesn't match what's written on the very page you quote: https://upcloud.com/fair-transfer-policy

> Even if you exceed your monthly share, don’t worry, there are no excess fees. We will simply notify you of reaching the fair transfer policy and may reduce the bandwidth of your Cloud Servers to 100 Mbps for the rest of the month.

EDIT For completeness, there is also:

> If you believe to require more transfer per month than the Fair Transfer Policy provides, you may opt in to a paid transfer model at €0.01/GB. This affords you completely unlimited egress with no restrictions.

> "Although the chance of a collision is extremely low because the random value has at least 150 bits of entropy, there is still a chance."

I am... speechless. I mean... Um.

The last time I checked, no one was able to break 128 bits of security for anything, let alone 150 bits, or for a domain validation of some domain name no one cares about.

This is the same attitude that has everyone deploying in-kernel code and arbitrary updates written by companies who can't get the basic QA right. The auditors and lawyers get to decide what "security" looks like.

It's "best to be safe".

Try NATS @ https://nats.io

It's a single binary and can operate as a message bus, persistent queue, KV store, object store, provide services, and so on.

Sounds like you're in the UK? Any chance you could send me the details of your doctor(s) to [email protected]? I've been struggling to find a doctor willing to diagnose me properly. Much appreciated.

You're not alone. Hang in there.

Yes. ModSecurity is best used as a tool for virtual patching, meaning something you can use to create a temporary defence for a problem you know you have. That buys you some time until the problem is fixed.

When you're writing a virtual patch you know exactly what data you're dealing with and you can allow through only what's known to be good. Any other approaches (e.g., generic rules) deal with text in bulk and are prone to false positives.

Even with this narrower focus, it's still a difficult problem. Here's a paper I wrote on this subject a while ago: https://blog.qualys.com/wp-content/uploads/2012/07/Protocol-...

Source: I am the original author of ModSecurity (but not of any of the rules packages).