Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt root certificate trusted by Mozilla

bugzilla.mozilla.org

Post reply on HN
Print view View original

161–166 of 166 posts

Re: Let's Encrypt root certificate trusted by Mozilla

#161

Post by gnyman »

patates wrote: post #151
tracker1 wrote: post #125

Earlier quoted context omitted.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

I'm ready to pay a reasonable amount for a wildcard cert to use with some hobby projects. Is there a trustworthy cheap wildcard cert provider which is not Comodo?

Have you checked StartSSL? They've worked fine for me.

Re: Let's Encrypt root certificate trusted by Mozilla

#162

Post by collinmanderson »

kentonv wrote: post #99
icebraining wrote: post #65

Earlier quoted context omitted.

> publish Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

It's even finer-grained than that. Each session gets a hostname -- if you open the same document twice, it's at a different hostname each time. This also implies that different users get different hostnames, so you can't discover the host another user sees even if you have access to the same document.

Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)

Re: Let's Encrypt root certificate trusted by Mozilla

#163

Post by icebraining »

collinmanderson wrote: post #162
kentonv wrote: post #99

Earlier quoted context omitted.

It's even finer-grained than that. Each session gets a hostname -- if you open the same document twice, it's at a different hostname each time. This also implies that different users get different hostnames, so you can't discover the host another user sees even if you have access to the same document.

Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)

The hostnames aren't authentication, just another layer of defense, mostly against JavaScript attacks (e.g. from hacked applications): https://docs.sandstorm.io/en/latest/administering/wildcard/#...

Re: Let's Encrypt root certificate trusted by Mozilla

#164

Post by kentonv »

icebraining wrote: post #163
collinmanderson wrote: post #162

Earlier quoted context omitted.

Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)

The hostnames aren't authentication, just another layer of defense, mostly against JavaScript attacks (e.g. from hacked applications): https://docs.sandstorm.io/en/latest/administering/wildcard/#...

Right, this is about mitigating the damage when apps have a bug -- risk management. Instead of being exploitable from anywhere on the internet, the bug becomes exploitable only by attackers who have a passive network MITM, which, while possible, is a very high barrier.

Re: Let's Encrypt root certificate trusted by Mozilla

#165

Post by tracker1 »

icebraining wrote: post #155
tracker1 wrote: post #125

Earlier quoted context omitted.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

What's the problem with dynamic dns provider domains?

I mean domains on no-ip, freedns, dyndns and the like.. that are subdomains are more likely to hit the default limits with Let's Encrypt... I'd like to see some auto-whitelisting for some of the more popular ones.

Re: Let's Encrypt root certificate trusted by Mozilla

#166

Post by AndyMcConachie »

grahamedgecombe wrote: post #150
AndyMcConachie wrote: post #147

Earlier quoted context omitted.

Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control? I'm not OK with that. I understand that other CA's provide wildcard certs, but frankly I see them as a giant problem. It's bad enough that I only have to have something listening on port 80 to prove that I control a domain. Let's not make it more attractive for people to start fooling Let's En…

CAs are forbidden from issuing a cert for * .co.uk. The Baseline Requirements say: > The CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "* .com", "* .co.uk", see RFC 6454 Section 8.2 for further explanation). This basically means that the CA should check the Public Su…

So pick a different DNS zone that isn't in the PSL but that is not an administrative boundary. They exist.

The Public Suffix list is an imperfect maintained list. You're relying on Mozilla to maintain it. You also never know if someone is selling names below their own zone. What if Mozilla decides to no longer maintain it? What if the volunteers stop maintaining it?

Maybe the PSL is a good start, but I would rather not rely on it. It's a convenience vs. security balance issue, and I'm leaning towards security.

Post reply on HN