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

Standing on our own two feet

letsencrypt.org

Post reply on HN
Print view View original

161–170 of 200 posts

Re: Standing on our own two feet

#161

Post by tialaramex »

kelnos wrote: post #134

Does IdenTrust have another root cert that has a later expiration date, that is also included in the trust store of OSes farther back than 2016? If so, why can't LetsEncrypt ask them to start cross-signing with a different root cert? (Obviously IdenTrust is under no obligation to do so, but since they've done this much, it's not a stretch to hope they'd do more, even if they want to charge for it.)

IdenTrust owns two newer roots which are widely trusted today, IdenTrust Commercial Root CA 1 and IdenTrust Public Sector Root CA 1 but they were only created in 2014.

Perhaps somebody has a list of what's in the trust store for various historical Android builds, I do not.

But I think you can assume that the team at Let's Encrypt have considered any options that might work and decided that either they wouldn't make enough difference to be worthwhile or have asked and been told it isn't possible or would be too expensive to make sense.

Re: Standing on our own two feet

#162

Post by tialaramex »

CGamesPlay wrote: post #105
kickscondor wrote: post #46

Earlier quoted context omitted.

Ok - next question then: why do browsers block self-signed certs? If Lets Encrypt now allows any domain to get a cert, what's the harm in a self-signed cert? Seems like a step up from plain HTTP.

I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self…

As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case.

If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist.

The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.

Re: Standing on our own two feet

#163

Post by nsgi »

juliend2 wrote: post #20
dubcanada wrote: post #17

Earlier quoted context omitted.

IdenTrust doesn't care about random websites, they care about HIPPA, enterprise, government, securing documents and emails, etc.

Exactly, but the funny thing is that Chrome and Firefox (Desktop at least) are no longer showing the differentiating green lock for those high-end (EV & OV) certs, but the same neutral-looking lock as those Domain-Validated (DV) certs that Let's Encrypt is issuing. I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.

Doesn't really matter if inertia is keeping them using Identrust. They're not going to go to the trouble of switching providers just to save a few bucks. If that was their concern there were much cheaper options available even before Let's Encrypt

Re: Standing on our own two feet

#164

Post by nsgi »

closeparen wrote: post #51
dubcanada wrote: post #17

Earlier quoted context omitted.

IdenTrust doesn't care about random websites, they care about HIPPA, enterprise, government, securing documents and emails, etc.

Does anyone in enterprise actually need publicly trusted certificates for documents and email? Seems like it's an inside-the-firewall Exchange server for internal traffic, and a white-label "secure messaging center" portal for external traffic.

Using a public CA is far better for security than a custom private one. It's a pain having to install the certificate on every client, server, piece of software, etc. and in my experience this inevitably leads to people disabling certificate checking as part of troubleshooting and this being left on. Also, sometimes people need to access documents and emails from home computers and the company may use some devices on which it isn't possible to install the CA

Re: Standing on our own two feet

#165

Post by lxgr »

b112 wrote: post #154
juliend2 wrote: post #20

Earlier quoted context omitted.

Exactly, but the funny thing is that Chrome and Firefox (Desktop at least) are no longer showing the differentiating green lock for those high-end (EV & OV) certs, but the same neutral-looking lock as those Domain-Validated (DV) certs that Let's Encrypt is issuing. I'm very grateful for IdenTrust for having made that move. I just hope it won't hurt their business too much because of that.

I've never understood why browsers didn't show the SSL Common Name or other agreed upon identifier, in place of a little lock. Why do I have to click 4 times in Firefox Linux Desktop, just to see info on the cert? So this is perhaps why there is no EV or OV differentiation. Who cares? Of what use is an EV cert, if no one even checks the name. Or further, knows if the bank (for example) uses that CA? I think in such a…

How would you propose verifying that agreed upon identifier?

Validating human-readable names, be that of individuals or corporations, would be opening a can of worms. Domain validation is already decidedly non-trivial.

Re: Standing on our own two feet

#166

Post by lxgr »

epse wrote: post #152
alanfranz wrote: post #57

Earlier quoted context omitted.

Maybe IdenTrust will now offer an ACME compatible endpoint and offer signed, paid certs with their CA. Or another CA will. I wonder whether IdenTrust imagined that a five year cross signed root ca would be too little a timespan to get wide adoption. Btw... Wouldn't it be possible to just add a new root ca to android? Maybe an app could simplify delivery?

Android has always had an "install certificate from SD card" option, so it's absolutely possible, just very annoying

Starting with (I think) Android 6, this will be accompanied with a non-discardable "Somebody might be tracking you!!!" scare warning in the menu bar. I'm not a fan of the idea of educating users to ignore something like that.

Re: Standing on our own two feet

#167

Post by nsgi »

mrweasel wrote: post #149
gpff wrote: post #2

Let’s Encrypt cross-signature with IdenTrust "DST Root X3" is ending on September 1, 2021 but 33.8% of Android devices are running versions under 7.1 which don't trust Let’s Encrypt new root certificate "ISRG Root X1"

The most impressive thing it that Let’s Encrypt are the ones who are trying to fix a problem that should be fixed by phone manufactures and telcos. I can see why, but I would also have like the phones to “break” so the owners would avoid those brands in the future, and pick one who care enough to push out update. Still, I can blame Let’s Encrypt, they just want to be the good guys, and the do it so beautifully and tr…

It probably wouldn't encourage many people to upgrade their phones, though. They would probably just see the website as broken and either click through the warning or abandon it completely

Re: Standing on our own two feet

#168

Post by Aachen »

CameronNemo wrote: post #121
vhiremath4 wrote: post #103

The company I work at is in a high-growth phase and we are going to be expanding our global audience this coming year through various channels (SEO, performance marketing, sales, etc.). A 1-5% hit in potential customer traffic is not going to fly. Is my only option here to get off LetsEncrypt? A bit of a vent, but I would 100% had paid for a version of LetsEncrypt that supported their costs for the x-signature with I…

Is there any way you can measure how many of your users are on an unsupported Android version?

I think most phones include it in their user agent string.

Re: Standing on our own two feet

#169

Post by Aachen »

fuzxi wrote: post #78
lixtra wrote: post #23

They propose to install Firefox to work around the root certificate problem on old android devices. But can’t you just manually install their root certificate on most phones?

I'm not sure if it's the same on older versions, but on recent Android versions, that requires a rooted device.

I see you've guessed why I'm on Android 7! The updater refuses to work if you have su.apk in your system directory. Can't simply ignore that file now, can we?

Re: Standing on our own two feet

#170

Post by momentoftop »

CGamesPlay wrote: post #105
kickscondor wrote: post #46

Earlier quoted context omitted.

Ok - next question then: why do browsers block self-signed certs? If Lets Encrypt now allows any domain to get a cert, what's the harm in a self-signed cert? Seems like a step up from plain HTTP.

I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self…

An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.
Post reply on HN