231–240 of 391 posts
> $ sqlite3 whois-log-copy.db "select source from queries"|sort|uniq|wc -l Oh cool they saved the logs in a database ! Wait... |sort|uniq|wc -l ?? But why ?
-- COUNT ( DISTINCT ... ) ~= uniq | wc -l ;; sort without -u is this busybox? ORDER BY col ASC
-- wait this doesn't need sort and uniq if it's just being counted...
SELECT COUNT( DISTINCT source ) FROM queries
The article puts the blame on > Never Update, Auto-Updates And Change Are Bad as the source of the problem a couple of times. This is pretty common take from security professionals, and I wish they'd also call out the other side of the equation: organizations bundling their "feature" (i.e. enshittification) updates and security updates together. "Always keep your programs updated" is just not feasible advice anymore…
I actually think it's viable to fix, I am simply not sure if anyone would pay for it — basically, old LTS model from Linux distributions where a set of packages gets 5 or 10 years of guaranteed security updates (backported, maintaining backwards compatibility otherwise).
If one was to start a business of "give me a list of your FLOSS dependencies and I'll backport security fixes for you for X", what's X for you?
This is a fantastic exploit and I am appalled that CAs are still trying to use whois for this kind of thing. I expected the rise of the whois privacy services and privacy legislation would have made whois mostly useless for CAs years ago. > This is the approach taken by whois on Debian. Years ago I did some hacking on FreeBSD’s whois client, and its approach is to have as little built-in hardcoded knowledge as possib…
[[ Edited to add: I remembered last time I mentioned these some people got confused. The requirement is a CA must use at least one of the blessed methods, there used to be "Any other method" basically they could do whatever they wanted and that "method" was of course abused beyond belief which is why it's gone. They can do whatever they like in addition, and there are also some (largely not relevant) checks which are always mandatory, but these "blessed methods" are the core of what prevents you from getting a certificate for say the New York Times websites ]]
https://cabforum.org/working-groups/server/baseline-requirem...
The Ten Blessed Methods are listed in section 3.2.2.4 of the Baseline Requirements, there are currently twenty sub-sections corresponding to what the Forum considers distinct methods, the newer ones unsurprisingly are later in the list, although many are retired (no longer permitted for use)
3.2.2.4.2 "Email, Fax, SMS, or Postal Mail to Domain Contact" specifically says to check whois as does 3.2.2.4.15 "Phone Contact with Domain Contact".
For the commercial CAs this is all bad for their bottom line, because a willing customer can't buy their product due to some bureaucratic problem. They want to give you $50, but they can't because some IT bloke needs to update a field in some software. When they ask the IT guy "Hey, can you update this field so I can buy a $50 certificate" the IT guy is going to say "Oh, just use Let's Encrypt" and you don't get $50. So you want to make it as easy as possible to give you $50. Bad for the Internet's Security? Who cares.
ISRG (the Let's Encrypt CA) of course doesn't care about $$$ because the certificates do not cost money, only the provisioning infrastructure costs money, so they only implement 3.2.2.4.7, 3.2.2.4.19 and 3.2.2.4.20 IIRC because those make sense to automate and have reasonable security assuming no bugs.
Why are tools using hardcoded lists of WHOIS servers? Seems there is a standard (?) way of registering this in DNS, but just from a quick test, a lot of TLDs are missing a record. Working example: dig _nicname._tcp.fr SRV +noall +answer _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr. Edit: There's an expired Internet Draft for this: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...
Obviously there are a lot of errors by a lot of people that led to this, but here's one that would've prevented this specific exploit: > As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023. Never ever ever ever let a domain expire.…
This is the most obvious reason why Verisign is a monopolist and should be regulated like a utility. They make false claims about choice and not being locked in. You buy a domain, you use it, you're locked in forever. And they know it. That's why they fight tooth and nail to protect their monopoly.
Earlier quoted context omitted.
Our industry needs to finish what it starts. Between IPv6, DNSSEC, SMTP TLS, SCTP/QUIC, etc all of these bedrock technologies feel like they're permanently stuck in a half completed implementation/migration. Like someone at your work had all these great ideas, started implementing them, then quit when they realized it would be too difficult to complete.
In my 25+ years in this industry, there's one thing I've learned: starting something isn't all that difficult, however, shutting something down is nearly impossible. For example, brilliant people put a lot of time end effort into IPv6. But that time and effort is nothing compared to what it's gonna take to completely shut down IPv4. And I've dealt with this throughout my entire career: "We can't shut down that Apache…
I have the feeling that any day now I’m gonna wake up in the morning and I’ll find out that there just isn’t internet anymore because somebody did something from a hotel room in the middle of nowhere with a raspberry pi connected to a wifi hotspot of a nearby coffee shop.
Why are tools using hardcoded lists of WHOIS servers? Seems there is a standard (?) way of registering this in DNS, but just from a quick test, a lot of TLDs are missing a record. Working example: dig _nicname._tcp.fr SRV +noall +answer _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr. Edit: There's an expired Internet Draft for this: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...
I have a feeling whois is way older than the concept of SRV records even
Earlier quoted context omitted.
None of these relate to TLS/SSL - that's the wrong level of abstraction: they relate to fragility of the roots of trust on which the registration authorities for Internet PKI depend.
As long as TLS/SSL depends on Internet PKI as it is, it is flawed. I guess there's always Private PKI, but that's if you're not interested in the internet (^:
Now, the application using TLS probably cares, and most Internet applications want an X.509 certificate, conforming more or less with PKIX and typically from the Web PKI. But TLS doesn't care about those details.