31–40 of 91 posts
Can someone explain why letsencrypt certificates have to be 90 days expiry? I know there is automation available, but what is the rationale for 90 days?
it seems like all this infrastructure could be replaced by a DNS TXT record with a public key that browsers could use to check the cert sent from the web server. A web server would load a self-signed cert (or whatever cert they wanted), and put the cert's public key into a DNS record for that hostname. Every visit to a website would need two lookups, one for address and one for key. It puts control back into the hand…
it seems like all this infrastructure could be replaced by a DNS TXT record with a public key that browsers could use to check the cert sent from the web server. A web server would load a self-signed cert (or whatever cert they wanted), and put the cert's public key into a DNS record for that hostname. Every visit to a website would need two lookups, one for address and one for key. It puts control back into the hand…
I'm not sure what that would solve. You would still need some central entity to sign the DNS TXT record, to ensure that the HTTPS client does not use a tampered DNS TXT record.
it seems like all this infrastructure could be replaced by a DNS TXT record with a public key that browsers could use to check the cert sent from the web server. A web server would load a self-signed cert (or whatever cert they wanted), and put the cert's public key into a DNS record for that hostname. Every visit to a website would need two lookups, one for address and one for key. It puts control back into the hand…
Earlier quoted context omitted.
I know that. But presumably, Let's Encrypt could participate in a MITM attack since they can sign another key, so that even the visitor who knows that you use them as a CA can't tell there is a MITM. Checking multiple signatures on the same key could raise the bar for a MITM attack, requiring multiple CA's to participate. I can't be the first person to think of this. I'm not even a web security guy. It might be inter…
This problem was solved in the mid 2010s by Certificate Transparency. Every issued certificate that browsers trust must be logged to a public append-only certificate transparency log. As a result, you can scan the logs to see if any certs were issued for your domain for keys that you don't control (and many tools and companies exist to do this).
And a malicious actor can abuse this fact.
It’s bizarre. There is a photo at the top, no name, no site title. No about page. Extremely untrustworthy.
I’m sorry, who the heck wrote this and why should I trust them? Very poorly written, also. It’s bizarre. There is a photo at the top, no name, no site title. No about page. Extremely untrustworthy.
Scroll down to the footer--> click on "Homepage"
Then you will get to his homepage: https://www.brocas.org/
Let's Encrypt did more for privacy than any other organization. Before Let's Encrypt, we'd usually deploy TLS certificates, but as somewhat of an afterthought, and leaving HTTP accessible. They were a pain to (very manually) rotate once a year, too. It's hard to overstate just how much LE changed things. They made TLS the default, so much that you didn't have to keep unencrypted HTTP around any more. Kudos.
I think it was Snowden who made TLS the default. Let's Encrypt did great work, but basically having the NSA's spying made common knowledge (including revealing some things that were worse than we expected, like stealing the traffic between Google's data centers) created a consensus that unencrypted HTTP had to go, despite the objections of people like Roy Fielding.
Snowden may have been a coincidence, too. We knew encryption was better, it was just too much of a hassle for most sites.
Earlier quoted context omitted.
I'm not sure what that would solve. You would still need some central entity to sign the DNS TXT record, to ensure that the HTTPS client does not use a tampered DNS TXT record.
If someone can tamper with your DNS TXT records now they can get a certificate for your domain.