Posts by brotherelf 199 posts • joined 16 Jun 2014
As if "there'll be collateral damage" ever stopped a browser vendor. Basic auth in iframes, not showing www/m prefix even if what's shown has no A/AAAA record, the default changing from rel="opener" to rel="noopener", abandoning the CA/B forum, the list goes on and on. We are rapidly heading back towards "best viewed in X/Y/Z because Y/Z/X is broken".
Where's the SecureBoot flaw in there? It hands over control to a boot loader with a valid digital signature, which is the only notion of "trusted" at that point, and the fix on SB's side is a revocation list that invalidates that particular signature.
The flaw, if any, is that buggy software got signed, but putting that at SecureBoot's door is like saying CAs should miraculously not issue and revoke certificates for sites running old Wordpress versions.
I would be entirely unsurprised if there are boot loaders which have gone through formal verification, i.e. are mathematically proven to work correctly (on an abstracted machine model, i.e. still vulnerable to compiler and CPU microcode bugs)
I'm not worried about the 8% that report 5+ incidents. "Prof sends a mail to students and uses CC instead of BCC" is a data breach that technically needs to be reported. Frankly, "prof has former student's mail still in address book" is probably an incident in and of itself because the reason for processing is gone.
I'm worried about the 92%, because I fear 91% don't look or don't report, and only 1% is running a proper shop.
(And we all know that all it takes to make a university stop dead is a handful of current or former students requesting the full extent of information GDPR entitles them to. Yes, that includes paper files.)
From my experience (in Edumacation), it is exactly the "very important people" who would insist that a single helpdesk person should of course be able to imMEdiately set a new password, without callback or other further identification, after all they already have the cheek of not giving out the original value of the password.
Point one: I've seen people who've done setups like that, by accident of incompetence. (I.e. they threw everything they had into the certificate bundle, including now-expired intermediate and root certs.) Not all browsers handle this. I don't recall if it was Firefox who'd pick an arbitrary certificate chain and fail if that one wasn't valid. Could've been Chrome, too.
Point two: I've not checked in detail, but I wouldn't be surprised if certificate transparency logs reject requests to log a certificate for the far-future. (And I don't think trusted CAs issue un-logged certs anymore.)
This – though, since both the GoDaddy hack and this one have rumors about infected sshd binaries, I'm not entirely convinced it's not the forwarding aspect of the protocol that is part of the issue. (I.e., if you connect into an infected host, it uses forwarding to log "you" into other nodes. That still doesn't explain the privilege escalation to modify sshd in the first place, though.)
> They would have to steal your hopfully protected private key...
Well yes. The certificate is public anyway, the common parlance of "compromised certificate" can be a bit misleading there. (And no, a new certificate does not mean it must be a new private key.)
The extent to which you can protect the private key can be limited on servers you want to restart without human interaction.
>> Apple clearly wants to avoid an ecosystem that cannot quickly respond to major certificate-related threats
> Not that clear - if there's a major certificate-based threat then 1 year is absurdly long.
They have a point, in a very roundabout way – remember the joke about the clock flashing on your microwave because you just can't be arsed to read up how to set it and you forgot from the last time around and you think it's really not that important? That's what certificate hygiene is. Wait till it fails, tell the customer to click ok, find out the guy who did it the last time retired, and then find out how to do it yourself, and forget until next time. Until it's frequent enough for you to actually learn (or automate away).
How is it a pain? Don't ask me, ask the people running dnssec-tools.org or mozilla add-on update servers, those being two examples that come to my mind of sites that ran around with expired LE certs for quite a while.
It's a fun sport if you're so inclined: compare the certificates in use with the public ledger of issued certificates. If the auto-renew doesn't work, who knows what else doesn't work on those servers.
Well, there is nothing that stops browsers from implementing relaxed rules for certain TLDs, for example the ones reserved for documentation and internal purposes, in particular when they resolve to RFC1918 IPs. (Chrome has a flag for that for localhost, IIRC.) Then you'd just need the use the domains you're supposed to use for this kind of thing, and you'd be set.
Wow would I be "happy" to pay 80€ every five years for a new passport. I think the fastest way through the checks is still to go to the machine, fail the test, and then go to the counter which does not handle the normal queues but only the express lane and the rejects from the automatic machine.
OTOH, the machine at ABZ let me in, even if it took long enough to verify the picture that I'm pretty sure that's farmed out to those companies that otherwise farm money in online games and solve captchas for spammers.
"which you then ignore as part of your daily checks"
FTFY. Because yup, I get that kind of mail, and 80% of the entries are stuck on "error" and I'm in no position to fix them and even when I tell the person responsible to fix it, I don't know how long it will take until it actually is fixed. Red tape at its flypapery best.
Well, the corporate attitude to the law is easy: the question is not whether it's legal or not. The question is whether the expected (in the stochastical sense) fine is larger or smaller than the extra revenue it generated.
(Do we have court decisions already on whether breach of GDPR falls under unfair business practices? Because which end user is going to go and bring the charges against GitLab?)
Which is why there'll be a flag for "culturally appropriating", most likely. And AIs to train for that, probably. Because surely the reason we've not solved the social problem of people being rude assholes by technical means is that we've just not tried hard enough.
Sorry, if it doesn't have an adjustable iteration count, it's not a modern password hash algorithm.
(And no, I don't make the individual UX/load/security tradeoff for every individual machine either, even though for local auth on a desktop, where the password is checked only on login/unsuspend/screenunlock, I could easily set the iteration count to the equivalent of half a second without any serious effect.)
> Nobody I ever met believes that Fermat really had a proof.
I'm not much of a believer in afterlife, but I get a chuckle out of the idea that Fermat's corner of hell, for whatever reasons, is everybody recognizing him, looking at his proof in the margin, and going "you forgot a minus at the beginning there, mate".
I hate to tell you, but there's protocols that are actually somewhat underspecified in terms of what encoding the password should be in, effectively reducing you to 7bit ASCII as common denominator. (HTTP Auth, I'm looking at you.)
And your hash-in-the browser scheme is somewhat flawed: whatever you give the service to recognize you by, that's de facto the password. The server can't tell if you use 2000 rounds of bcrypt every time to derive it from your first pet's maiden name or if it's just wgo4387gwheo34 by chance and you send that directly. Yes, you can build something like "Server tells the client to run X iterations, server runs N-X iterations and only has the N-iteration hash on file", which is basically challenge-response, but frankly, the answer to "the service has something like my password" is public key crypto, and that's even baked into TLS (client auth), and HTML5 had extra support for that by way of the keygen element, but browsers are actively removing those capabilities, and the UI was always pretty horrible, and server-side, it was always a bit of a dark art.
Possibly. "This endpoint allows you to retrieve a live feed of absolutely all uploaded files to VirusTotal, and download them for further scrutiny, along with their full reports."
It's not part of the free public API, but I've not investigated what amount of background checks they do for access to the for-pay private API.
I'll grant them this: CAA is a time-of-issue check done by good-faith actors (with working software – not everybody's is). Once the certificate has been issued by whoever, CAA doesn't mean anything.
And CT is along the same lines: a public time-of-issue message published by good-faith actors. Yes, doing that might be a pre-requisite for getting into root certificate stores. Do we have technical certitude that $bigCA does not have mechanisms to bypass CT, if a three-letter agency with signed warrants compels them? No. (It would be in their own interest, though, to make it technically impossible.)
The thing you are looking for is the now-defunct (Chrome dropped support, Edge did not get support so far) HPKP HTTP public key pinning, which did not take off, because it actually forces you to think about what you're doing for two minutes, or otherwise your website will be unreachable for long timeframes if you are unprepared for a key change. (Also, technically it had a TOFU risk.) The hordes of "I click deploy on cloud" have overrun the greybeards.
I'm sure it's handled as "anonymized quality control" in para 437 of the privacy statement that "you" had to agree on after you've already bought and paid for the device. (Whatever happened to the shrinkwrap EULA cases of the 90s?)
The other pertinent question, of course, is: does that imply consent by anybody in earshot? I see a future of "to opt out, please have a Genuine Google Android device with Bluetooth enabled on you at all times. This is necessary to transmit your opt-out decision to the device. Your location data may be stored and processed for privacy and quality control purposes."
I am fairly certain we can get "using voice-activated assistants in public spaces violates GDPR" quite easily, but that hammer might fall on the owner of the device, not the company that makes it, unless somebody pulls quite stunning tricks around how you've only licensed rights to use the software and don't own it.
I remember my compsci teacher looking over my shoulder, seeing me reading a nethack newsgroup, and telling me "I don't mind, but others might, be a bit less flagrant about it". But new posters who didn't bother to read first made that mistake, too, including the one guy whose lawyer father received a printout of the post by mail. (At that time, the provider would use the phone number as part of the message id, or something like that, and reverse phone search already existed.)
And the capital-S Shun you got in de.* if you dared post with an obvious pseudonym.
And the scary devil monastery.
Memories. My beard feels grey now.
Why, that already happened, when it got turned off-by-default in Windows long ago.
FWIW, I'm surprised that "we'll ship a different default config" warrants an article. Reading the leader, I expected it to be "this is now a compile-time switch that defaults to off", and frankly, I'd be not surprised at all if all major distros already ship a stronger default config.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020
