Seems Let's Encrypt also have control of https://letsdecrypt.org . It takes you to https://www.nsa.gov rather than Let's Encrypt. Not sure what to make of that!
letsdecrypt.org doesn't load for me.
10 Years of Let's Encrypt
311–320 of 361 posts
Re: 10 Years of Let's Encrypt
#312Earlier quoted context omitted.
It was a red herring the entire time. At Shopify we made experiment regarding conversion between regular certs and EV before they stop being displayed and there was no significant difference. The users don't notice the absence of the fancier green lock.
I think the rebuttal to the CEO today is really very simple. a) How many of the sites you visit everyday have DV and how many have EV certificates? b) Name any site at all, that you have visited, where your behavior or opinion has changed because of the certificate? In truth the green-bar thing disappeared on mobile long before desktop (and in some cases it was never present.) In truth if you polled all the company s…
it used to be that EV certs had higher insurance if there was a leak of the intermediate private keys and lost data.
Since nobody ever actually leaked an intermediate private key for a CA, people don't recognise the value.
If we had lost payment card information through MITM, we would have been liable for a lot more money.
That was the business justification for EV back when I was doing major ecommerce stuff.
Re: 10 Years of Let's Encrypt
#313Earlier quoted context omitted.
Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).
You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.
It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.
Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.
Re: 10 Years of Let's Encrypt
#314Earlier quoted context omitted.
Random anecdote: I have a device in which the http client can't handle https. Runs out of memory and crashes. Wasn't able to find a free host with a public http to host a proxy.
What is the device, if I may ask?
Yes, ESP8266. FWIW, https worked when bluetooth was disabled.
Re: 10 Years of Let's Encrypt
#315Earlier quoted context omitted.
The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)
I sign my zones :) The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain. Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right. The original stapled DNSSEC experiment was suff…
Huh? What did CAs have to do with stapling?
Re: 10 Years of Let's Encrypt
#316Seems Let's Encrypt also have control of https://letsdecrypt.org . It takes you to https://www.nsa.gov rather than Let's Encrypt. Not sure what to make of that!
letsdecrypt.org doesn't load for me.
Here's a curl from my connection:
$ curl -v letsdecrypt.org
* Host letsdecrypt.org:80 was resolved.
* IPv6: (none)
* IPv4: 62.116.130.8
* Trying 62.116.130.8:80...
* Connected to letsdecrypt.org (62.116.130.8) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: letsdecrypt.org
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
Edit: Ah, over HTTPS protocol it doesn't respond.
$ curl -v https://letsdecrypt.org
* Host letsdecrypt.org:443 was resolved.
* IPv6: (none)
* IPv4: 62.116.130.8
* Trying 62.116.130.8:443...
Re: 10 Years of Let's Encrypt
#317I love Let's Encrypt
A small VPS + LetsEncrypt + Dokku is a fantastic way to run personal side projects/hustles at minimal cost.
Re: 10 Years of Let's Encrypt
#318Would be interesting to hear what database they are using and how they are doing replication? Is it simple master / slave or multi-master?
Let’s Encrypt currently has a single primary with a handful of replicas, split across a primary and backup DC. We’re in progress of adopting Vitess to shard into a handful of smaller instances, as our single big database is getting unwieldy.
Let’s Encrypt is an incredible project and the internet is better off for it. If you ever have questions about vitess or need help please let me know.
Re: 10 Years of Let's Encrypt
#319Earlier quoted context omitted.
My experience was: get 3-year certificate for free, install it and forget about it. With LetsEncrypt, it's always pain, expired websites everywhere. Too bad that american IT mafia put these good CA out of business.
Literally all you have to do is configure a cronjob to renew the cert? I've got a website I build for a friend running that I haven't touched in 5 years TLS-wise, never had any issues.
For public websites most probably don't even need to touch cron as Apache/Caddy/NGINX/Traefik have built-in options these days. The only time I run something like a cron task is for certain internal IoT type certs.
Re: 10 Years of Let's Encrypt
#320I remember buying certs from Godaddy then Namecheap then using Let's Encrypt feels like when GitHub offered free private repos