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.
"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.
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???
> 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.
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!
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.
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.
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.
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.
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.
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.
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".
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 !
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.
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.
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…
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.
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.
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?
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.
"... 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
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
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.
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.
> 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...
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.
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').
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.
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.
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.
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.
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".
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.
Previously, Stupid Certificate Tricks (2014): https://news.ycombinator.com/item?id=9516824
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...
The linked pdf at https://tom7.org/httpv/httpv.pdf is extremely long but a great read if you enjoyed the article.
> 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.
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?
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.
why would tom 7 ask you for your credit card number?
Or if you prefer the paper in video form: https://www.youtube.com/watch?v=M1si1y5lvkk
"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.
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.
> 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.
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.
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!
a virus that disables windows update? Sounds like an actual sellable product to me!
Wait until you find out I use passwordless sudo. Surely you can't really believe that every Linux laptop is horribly compromised.
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:
Does Apple SIP allow you to change the configuration per app? I thought now, which is a big difference with SELinux or Apparmor.
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.
Not every conversation has to be a complaint about AI.
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.
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.
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.
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.
Not surprisingly "isn't recommended" by the ones who want you to pay them.
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.
Previously:
https://news.ycombinator.com/item?id=50425226 Horrible Public Key Tricks (maurycyz.com) 1 day ago
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.
Was done some time ago: https://hosted-files.sched.co/bsidessf2019/88/Catlog_BSidesS...
Also, please don't do this.
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".
> usually by tricking victims into diverting their own traffic
What does this mean practically? Getting a VPN profile installed ?
No, the simplest (but far from the only) example is DNS injection.
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 !
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.
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.
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…
[0] https://en.wikipedia.org/wiki/EncroChat
Tip: select the the ‘tty’ mode prior to digging in.
I’ve never felt a more relaxed feeling (easy on the eyes) while reading any blog in comparison.
Yes! It takes me back to the amber VT-220 terminals at school. I might have the model wrong.
Yes, VT-220. The amber color was so pleasant, and so easy on the eyes.
The AI guestbook is an interesting addition. Does that actually work in weakening crawling LLMs? Which is presumably the idea?
Looks like https://zadzmo.org/code/nepenthes/ / https://github.com/amenyxia/Sarracenia
>Nobody checks your private keys
You're implying that they should???
I suspect private keys should receive a nominal check, that they can't be guessed by smashing the number 4 on a numpad.
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.
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.
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?
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.
You're looking for https://www.ietf.org/archive/id/draft-ietf-lamps-csr-attesta.... It's gotten enough renewed attention in the wake of the eMudhra fiasco that I'm reasonably optimistic about it becoming required for intermediates.
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.
Do you know how many SSL certificates are issued per year? LE issued 10 million per day in 2025. https://letsencrypt.org/2025/12/09/10-years
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.
The check should probably be done for intermediary CAs though? Right?
"... 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
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
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.
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.
Certificates don't tell you whether a site is trustworthy.
> 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...
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.
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').
> And it was already a bad idea to publish anything without encryption at the time, and it still is
Why?
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.
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.
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.
Browsers didn't defame websites for not using HTTPS before Let's Encrypt.
Browsers did devote a ton of chrome space to showing off E.V. certificates though, which had approximately the same effect.
I cant get past the title spelling
Yes. It’s horrible.
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.
See also: https://maurycyz.com/misc/quality/indicators.html#:~:text=Th...
more: chalange, largly, crytosystems
It's a way to show human authorship I guess... But still, misspelling a headline is pretty shit
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".
>the whole system doesn't even work
Yeah, I saw a fire hydrant leaking the other day. Time to tear out all the plumbing, the whole system doesn't even work!
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.
I don't understand the math. What does plaintext^e mod n actually do?
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.
[flagged]
[dead]
[flagged]