ivanr
Joined 16 years ago
Karma
1,825
Submissions
325
Member since
Jul 24
Recent submissions
Comment · 1 month ago
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.
Comment · 2 months ago
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...
Comment · 5 months ago
Comment · 5 months ago
Spoiler: They're not identical.
Comment · 7 months ago
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.
Comment · 7 months ago
Ah, sorry, I should have referenced this sibling comment: https://news.ycombinator.com/item?id=47403528
Comment · 7 months ago
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...
Comment · 7 months ago
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.
Comment · 7 months ago
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/
Comment · 8 months ago
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].
Comment · 8 months ago
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.
Comment · 8 months ago
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.
Comment · 9 months ago
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
Comment · 9 months ago
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...
- My book Bulletproof TLS and PKI (https://www.feistyduck.com/books/bulletproof-tls-and-pki/) provides a comprehensive and practical coverage of SSL/TLS and PKI. The second edition was released in January 2022.
- I also maintain the free OpenSSL Cookbook, which focuses on command-line usage: https://www.feistyduck.com/books/openssl-cookbook/
- My startup Hardenize https://www.hardenize.com (now acquired by Red Sift) aims to help everyone deploy modern security standards by providing free assessments to everyone.
Previously, I built SSL Labs. Before that, ModSecurity.
[ my public key: https://keybase.io/ivanr; my proof: https://keybase.io/ivanr/sigs/LiVhyast_FE7MnLvqIDRD7yl-KGXtrEaGfBUX-K_6D0 ]