This is almost certainly an independent discovery/implementation of the same idea, there's really only one sensible way to do it. There are, of course, several non-sensible ways to do it as well, but...
Longest ‘paper’ I’ve read in ages, I’m slightly ashamed to admit.
This is the main reason I hate these notarization. And the worst thing is if you want to work on some software that require network extension, you can't even do it without paying apple $99 a year. There are workaround like turning off SIP, but it isn't recommended.
Obviously, for the commoners, it is definitely not recommended, especially since they usually run random commands from stochastic engines w/o supervision… oh…… engineers do that too now? how in the hell???
I’m out.
To be fair, given the increasingly sneaky cyber attacks these days, the more layers of security between you and root access the better IMHO. Turning off SIP in today's environment is a bit nuts as it is a genuinely sensible security layer.
However, for the benefit of more sensible people, I will point out:
1. I used the terminology "layered security" twice in my post above
2. By definition if you have a blind hatred of Apple SIP, you must also have a hatred of SELinux or AppArmor or dm-verity or kernel lockdown mode on Linux.LetsEncrypt is a surprising success, but it's still a centralized system running as a non-profit — which means that it's always at risk of not being funded and/or to be under influence of big sponsors. It also came too late, app stores were already centralized.
Obviously, enterprises prefer to be the one to gate the access, so with a situation as it was, they jumped on the opportunity.
I don't so much care about the rest of this analysis, but you can't call an unauthenticated TLS session "secure".
What does this mean practically? Getting a VPN profile installed ?
Website looked identical to the real one so they managed to easily get her one-time-codes. “For security purposes please enter the one-time-code we just sent you.”
No DNS injection. Just auto-complete and a reasonable URL and a convincing <title> in the HTML !
I’ve never felt a more relaxed feeling (easy on the eyes) while reading any blog in comparison.
You're implying that they should???
Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.
Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.
It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.
In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.
We really go on a pinky swear across the public CA ecosystem?
By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.
And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.
And the CA certificate is "self-signed"
Meanwhile under this "Web PKI" the www user is by default discouraged and/or blocked from using self-signed certificates she herself creates
Someone else decides who she must trust. It's not optional
For example, for a number of years someone else told her she must trust eMudhra
Of course that argument got heavily undermined by the existence of Let's Encrypt.
Take that number, raise it to the power of e, and take the remainder after division of that number by n.
Not actually all that long ago, people faced down the prospect of $1000+/year E.V. Verisign certs that involved faxing legal documents, phone calls, and other probing. Many jumped for joy when LetsEncrypt was finally mature enough for the mainstream. Kids these days don't know how good they've got it...
See also: https://maurycyz.com/misc/quality/indicators.html#:~:text=Th...
If I remember correctly, Let's Encrypt lets you go up to a hundred domains per certificate, with 256 characters per domain[1]. If you get a short domain like a.bc and start requesting certificates for its subdomains, you can easily get a few kB of user-controlled data embeddable per certificate. Given LE's rate limits, it should, within a few weeks of easily-automated work, be possible to embed child pornography into a CT log, making it illegal to host and destroying it completely.
You could do something more useful (and less destructive) with this idea; like embedding a separate public key, with the corresponding private key stored offline in an HSM, which could then be used to sign the location of your new domain in case the old one was seized. This would, in a weird and perverted way, add a lot more censorship resistance to DNS than what it natively provides.
You could even use a CT log as a blockchain, with the order of log entries being used for consensus.
Also, please don't do this.