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...
> I can tell you for certain that when I was connecting to my own website, there was no attacker trying to "steal my credit card."
Of course, no one can actually be certain of this, because any MITM could have injected anything they wanted into the website, including something asking for your credit card (which they would then steal). Plain http is commonly MITM'd to inject tracking and ads, even on an ISP you pay for with money, and has been for decades at this point.
Just because you own the website does not mean you get to choose the threat model your visitors have to operate under.
quibono 9 hours ago [-]
Does this threat model include knowing where to put credit card numbers and when to refrain from doing so?
If you posted your credit card number to someone's blog over HTTPS, is that any more secure?
capitol_ 7 hours ago [-]
Yes, since the set of people who can mitm/steal it is strictly smaller.
Blog operator Vs blog operator + network operator.
It's still not 100% secure.
quibono 6 hours ago [-]
My point was that if it's a website that doesn't take payments or any personal info then it doesn't really matter if it's HTTPS or not; not that TLS or HTTPS has no use case in absolute.
I guess a better way to rephrase would be, if you go to a random GitHub issue and post your credit card number + details publicly, would it matter if you posted them over HTTP or HTTPS?
stymaar 6 hours ago [-]
Payement is only one of the reason why encryption is important: most people don't want their ISP to know what kind of porn they watch, for instance.
andrewflnr 6 hours ago [-]
It's not just about the information you supply. You can find accounts of hotel wifi services injecting ads into pages loaded over insecure connections. A MitM lets you inject content including arbitrary malicious JS. With ad networks being what they are, that might already have happened with those injected ads.
stoltzmann 11 hours ago [-]
why would tom 7 ask you for your credit card number?
(Ironically?) I can't access it in Firefox, which reports SSL_ERROR_UNSAFE_NEGOTIATION.
cute_boi 19 hours ago [-]
"the way, to sign a piece of software, you
need to pay an extortive $100/year fee to Apple"
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.
frizlab 17 hours ago [-]
Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
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.
traceroute66 15 hours ago [-]
> Deactivating SIP is not that dangerous if you know what you’re doing. All it does it give back write access to root to some parts of the system.
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.
account42 11 hours ago [-]
On a desktop/laptop, root doesn't have anything even remotely as interesting as your own user. What you are arguing for is pure security theater.
icedchai 10 hours ago [-]
It’s much easier to insert persistent malware when you can modify the operating system. I remember Windows viruses that would disable windows update. Very annoying!
vrighter 8 hours ago [-]
a virus that disables windows update? Sounds like an actual sellable product to me!
Spivak 15 hours ago [-]
Wait until you find out I use passwordless sudo. Surely you can't really believe that every Linux laptop is horribly compromised.
traceroute66 14 hours ago [-]
If you're going to insist on being one of those hardcore "I must be root" people then there's nothing I can say that will satisfy your urge. The same if you are one of those permanent Apple bashers.
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.
graemep 12 hours ago [-]
Does Apple SIP allow you to change the configuration per app? I thought now, which is a big difference with SELinux or Apparmor.
frizlab 9 hours ago [-]
AFAIK, no. SIP is for the whole system, period.
I think we could say AppArmor is more akin to TCC on macOS, though AppArmor would be much more flexible.
Spivak 5 hours ago [-]
I'm a huge proponent of SELinux, you as the user are totally in control of it. The thing I disagree with philosophically is putting barriers between or outright locking the user out of root. Software running on the system is fine to be locked in various jails but the user shouldn't be.
JimDabell 13 hours ago [-]
Not every conversation has to be a complaint about AI.
necovek 14 hours ago [-]
Community approach basically failed in building a "web of trust" with all the PGP/GPG signing parties: both tools were tricky to use, integrating PGP/GPG signing into common tools (like email, word processors, web, but also version control systems like CVS, SVN, bzr, git...) was always lackluster.
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.
LoganDark 19 hours ago [-]
Apple won't even let you pay the fee in some cases. I've been fighting with them trying to figure out why they won't accept my ID verification since March. They keep saying my devices are linked to another Apple Account, but I purchased them all directly from the Apple Store and none of them have ever touched another account, so what the fuck.
RobotToaster 12 hours ago [-]
You could try returning them, if apple say they were tampered with before you got them then apple will either have to accept the return or say apple are lying.
LoganDark 12 hours ago [-]
Apple says that some device linked to my Apple Account is associated with some other Apple Account already in the Apple Developer Program. They give generic advice like "try removing linked devices and linked phone numbers that are not yours" and "try asking the owner of any other Apple Accounts to unlink your devices". Because of the lawyerish nature of their wording, there is no way to prove they are actually talking about my particular devices or my particular phone numbers, or which ones they are talking about, or what other Apple Accounts they may be talking about, or what types of association they may be talking about. So there is no way to call them out on anything because they haven't actually said anything.
There aren't any devices or phone numbers on my Apple Account that aren't mine, and I have literally no fucking clue who could possibly have my devices or phone numbers linked to their account, given that the devices are my own devices, each purchased in-person at an Apple Store, that I've never even let anybody else hold, let alone link to a different Apple Account, and the phone number is one I've owned for probably close to a decade at this point. I'm at a complete loss.
zackmorris 1 hours ago [-]
I almost wonder if tech support failures could be posted on prediction markets like Polymarket or Kalshi, so maybe you could bet $10 against them resolving the issue by such and such date. That way a lot of people could make money on their inadequacy to bring embarrassment to companies having incomplete disputes, and it's worth losing your $10 to get the matter resolved.
userbinator 17 hours ago [-]
Not surprisingly "isn't recommended" by the ones who want you to pay them.
jrmg 18 hours ago [-]
I came here to say the same thing! I’m not sure I have the author’s vehemence, but I enjoyed the read.
Longest ‘paper’ I’ve read in ages, I’m slightly ashamed to admit.
tptacek 21 hours ago [-]
All serious attackers are man-in-the-middle attackers (usually by tricking victims into diverting their own traffic, not literally by inserting themselves into the network path). Passive-only attackers went extinct along with the backbone-connected Sun servers that were used to launch those attacks.
I don't so much care about the rest of this analysis, but you can't call an unauthenticated TLS session "secure".
stingraycharles 21 hours ago [-]
> usually by tricking victims into diverting their own traffic
What does this mean practically? Getting a VPN profile installed ?
tptacek 21 hours ago [-]
No, the simplest (but far from the only) example is DNS injection.
juliusdavies 17 hours ago [-]
My friend ended up having the URL to a fraudulent version of her online banking start getting auto-completed by her phone’s browser because they’d gotten her to click on some random SMS links a few times.
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 !
Xirdus 17 hours ago [-]
For some reason, getting rid of autocomplete suggestions is harder than getting rid of all other browser data combined. I really don't know why. I've been wishing to clear autocomplete orders of magnitude more often than to clear history or cookies.
JoeBOFH 2 hours ago [-]
Not just in the browser. I somehow have my work account’s UPN somehow in my Google account history somewhere. So randomly Android will try to auto complete as that instead of the email address I used daily on forms, etc.
kakacik 6 hours ago [-]
Well, doing ebanking on phone browser sounds like a bad idea to start with. (artificial) limitations of those browsers are only some of the reasons.
tptacek 6 hours ago [-]
You're far safer doing banking stuff on your phone than on a computer.
embedding-shape 21 hours ago [-]
Make the web unusable unless you're protected by your "DDOS" protection, offer a free service to solve the problem. Or provide a free service with as little friction to start replacing private/internal networking with, ideally with wide platform support. Or provide some sort of alternative "private" altnet, promising anonymity and access to clearnet via some sort of gateways, specifically for murky stuff.
alwa 20 hours ago [-]
Or, of course, go high-touch: sell hyper-e2e-encrypted, hardware+software mobile devices directly to crime syndicates, explicitly to keep their traffic safe from prying governmental men-in-the-middle…
On that note: I was always wondering whether you could do stupid CT log tricks.
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.
I suspect private keys should receive a nominal check, that they can't be guessed by smashing the number 4 on a numpad.
arcfour 20 hours ago [-]
So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?
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.
hxtk 19 hours ago [-]
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
alwa 20 hours ago [-]
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…
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?
hxtk 19 hours ago [-]
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.
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.
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
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.
jethro_tell 7 hours ago [-]
The check should probably be done for intermediary CAs though? Right?
arcfour 6 hours ago [-]
Yes, that is what I meant by "this thinking doesn't apply to CAs themselves" and "CAs themselves are separate beasts"
It's a separate point from the one the OP/OC were making so I saw no reason to go into much depth there.
1vuio0pswjnm7 18 hours ago [-]
"... and the whole system doesn't even work because certificates are issued over plaintext connections, and trusted certificate aurthorities[sic] use very secure keys like "4""
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
1vuio0pswjnm7 9 hours ago [-]
Yes, one can remove certificates from a "trust store" in a folder (in practice, usually a "bundle" maintained by a browser vendor, or something derived therefrom)
But how does the www user remove a certificate that's compiled into a popular browser
The popular browsers, maintained by companies invested in internet surveillance advertising, is so large and complex that in practice few will edit and compile it themselves. Not only is certificate removal impractical but user-signed certificates outside the browser will usually trigger multiple warnings, even requiring users to type shibboleths to be detected by keyloggers
This "Web PKI" system presumes no www user can _ever_ trust themselves to make trust decisions. It's presumed that this is _never_ an option for _any_ user, in any situation
Spivak 15 hours ago [-]
I mean some people can and do remove entries in their trust store. I imagine there's a very near future where someone inclined could have a perfectly serviceable internet experience with nearly all of them removed.
Xirdus 17 hours ago [-]
Unfortunately, smart internet users are outnumbered by not so smart users thousands to one. And the not so smart users aren't smart enough to know every time when a website is or isn't trustworthy. So while far from ideal, the world is a much better place since we gave control of the entire internet to a few aristocrats.
Of course that argument got heavily undermined by the existence of Let's Encrypt.
Geezus_42 14 hours ago [-]
Certificates don't tell you whether a site is trustworthy.
Xirdus 6 hours ago [-]
They kinda sorta do if the only way to obtain a trusted cert is to be vetted by a quasi-government entity with physical paper trail of who you are. But like I said, it's not how things work anymore thanks to Let's Encrypt.
kaslai 20 hours ago [-]
> So, I've always been somewhat annoyed at SSL/TLS. It requires everyone to go through a complex "ACME" dance just to put up a public website. Worse, certificates expire every few months, so it's not a one and done thing: even with automation, maintaining a certificate requires care to ensure the ACME client always has access to DNS records or the web server.
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...
jrmg 18 hours ago [-]
Yes, but back then SSL/TLS wasn’t a requirement to publish anything on the web. You just needed a domain, and IP and a web server. The minimum bureaucracy you have to do now is much greater.
maeln 12 hours ago [-]
It's still not a requirement. Most modern browser will pester you about it, but it can be circumvented. And it was already a bad idea to publish anything without encryption at the time, and it still is. The issue with SSL/TLS and in general with most encryption scheme (even e2e) is bootstrapping trust, and to my knowledge, there is no perfect way to deal with that. The CA system as its pros and cons and LE at least fixed the biggest flaw for the web (good luck if you need a certificate that can't use an ACME challenge, like most thing non-web tho').
nurumaik 12 hours ago [-]
> And it was already a bad idea to publish anything without encryption at the time, and it still is
Why?
kaslai 8 hours ago [-]
Famously, sites like Facebook didn't use or enforce SSL/TLS for a long time, and people were constantly getting session hijacked when using public WiFi. Even if all you publish is static content, encryption still makes your site robust against malicious content injection from e.g. ISPs or malicious access points.
smw 8 hours ago [-]
Because anyone who controls any system on the network path between -- or your DNS -- can read, or more importantly ALTER the content. This includes javascript malware, redirecting links to phishing sites, etc. It's honestly disrespectful to your site visitors not to provide TLS.
jrmg 8 hours ago [-]
It's still not a requirement
It de-facto is. All major browsers will yell at the user saying in more or fewer words that the site is dangerous to view if it’s not connecting over https.
account42 11 hours ago [-]
Browsers didn't defame websites for not using HTTPS before Let's Encrypt.
kaslai 8 hours ago [-]
Browsers did devote a ton of chrome space to showing off E.V. certificates though, which had approximately the same effect.
lacoolj 20 hours ago [-]
I cant get past the title spelling
jansenmac 19 hours ago [-]
Yes. It’s horrible.
Curiositry 18 hours ago [-]
I suspect there might be something intentional about this. There is a strangely high seeming-typo count in that post (yeild, pivate, relevent, etc). There are typos in the author's other work, but not quite at this density.
It's a way to show human authorship I guess... But still, misspelling a headline is pretty shit
userbinator 17 hours ago [-]
You can ask an AI to randomly misspell words too, omit all punctuation or lowercase everything. I don't like the default AI dialect of English either, but at least it's readable while this IMHO just makes you look lazy and stupid. As the old saying goes, "cut off your nose to spite your face".
18 hours ago [-]
teddyh 6 hours ago [-]
See also “Everything you Never Wanted to Know about PKI but were Forced to Find Out” by Peter Gutmann:
Yeah, I saw a fire hydrant leaking the other day. Time to tear out all the plumbing, the whole system doesn't even work!
YoshiRulz 8 hours ago [-]
False equivalence. The leaking fire hydrant doesn't enable you to poison the water supply of a town on the other side of the planet.
18 hours ago [-]
geekgod382 18 hours ago [-]
I don't understand the math. What does plaintext^e mod n actually do?
pred_ 15 hours ago [-]
Convert the plaintext to a number using some reversible encoding scheme. For instance, if the plaintext is an ASCII string, then take the ASCII index for each character to get fixed length binary strings, combine those strings.
Take that number, raise it to the power of e, and take the remainder after division of that number by n.
minfazhai 19 hours ago [-]
[flagged]
fleroviumna 15 hours ago [-]
[dead]
aronaxe 17 hours ago [-]
[flagged]
Rendered at 22:13:10 GMT+0000 (Coordinated Universal Time) with Vercel.
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...
Of course, no one can actually be certain of this, because any MITM could have injected anything they wanted into the website, including something asking for your credit card (which they would then steal). Plain http is commonly MITM'd to inject tracking and ads, even on an ISP you pay for with money, and has been for decades at this point.
Just because you own the website does not mean you get to choose the threat model your visitors have to operate under.
If you posted your credit card number to someone's blog over HTTPS, is that any more secure?
Blog operator Vs blog operator + network operator.
It's still not 100% secure.
I guess a better way to rephrase would be, if you go to a random GitHub issue and post your credit card number + details publicly, would it matter if you posted them over HTTP or HTTPS?
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:
I think we could say AppArmor is more akin to TCC on macOS, though AppArmor would be much more flexible.
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.
There aren't any devices or phone numbers on my Apple Account that aren't mine, and I have literally no fucking clue who could possibly have my devices or phone numbers linked to their account, given that the devices are my own devices, each purchased in-person at an Apple Store, that I've never even let anybody else hold, let alone link to a different Apple Account, and the phone number is one I've owned for probably close to a decade at this point. I'm at a complete loss.
Longest ‘paper’ I’ve read in ages, I’m slightly ashamed to admit.
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 !
[0] https://en.wikipedia.org/wiki/EncroChat
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.
I’ve never felt a more relaxed feeling (easy on the eyes) while reading any blog in comparison.
https://news.ycombinator.com/item?id=50425226 Horrible Public Key Tricks (maurycyz.com) 1 day ago
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.
It's a separate point from the one the OP/OC were making so I saw no reason to go into much depth there.
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
But how does the www user remove a certificate that's compiled into a popular browser
The popular browsers, maintained by companies invested in internet surveillance advertising, is so large and complex that in practice few will edit and compile it themselves. Not only is certificate removal impractical but user-signed certificates outside the browser will usually trigger multiple warnings, even requiring users to type shibboleths to be detected by keyloggers
This "Web PKI" system presumes no www user can _ever_ trust themselves to make trust decisions. It's presumed that this is _never_ an option for _any_ user, in any situation
Of course that argument got heavily undermined by the existence of Let's Encrypt.
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...
Why?
It de-facto is. All major browsers will yell at the user saying in more or fewer words that the site is dangerous to view if it’s not connecting over https.
See also: https://maurycyz.com/misc/quality/indicators.html#:~:text=Th...
<http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf>
Yeah, I saw a fire hydrant leaking the other day. Time to tear out all the plumbing, the whole system doesn't even work!
Take that number, raise it to the power of e, and take the remainder after division of that number by n.