Live data from Hacker News

Standing on our own two feet

letsencrypt.org

151–160 of 200 posts

Re: Standing on our own two feet

#151

Earlier quoted context omitted.

IdenTrust's buisness also spans to managing private CAs for companies, which includes managing the HSM and private keys. Also, the companies who hire IdenTrust and similar companies are not that involved in technology. Also, security experts who can manage this safely is a tad harder to find and requests higher wages than your standard IT staff. TLDR: yes, but some companies wants another company to manage their cert…

In those cases IdenTrust bought an insane amount of goodwill from some of the most technical people online by supporting Let’s Encrypt.

They also helped basically make it a requirement by allowing google to flag http pages as insecure and convince the public that it's necessary

Re: Standing on our own two feet

#152
post #7

> Without IdenTrust, Let’s Encrypt may have never happened and we are grateful to them for their partnership. What I have never understood is why IdenTrust accepted to cross-sign Let’s Encrypt's root certificate. With that move, IdenTrust basically broke the CA cartel and helped driving the price of basic certificates to zero. How did they, as a for-profit organization, justify "doing the right thing" when that meant…

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

Re: Standing on our own two feet

#153
post #88

Earlier quoted context omitted.

As a site owner that is somehow not my problem. It's not my fault that you have a shitty ISP. I can understand and support that argument. I do TLS only for my stuff however.

> It's not my fault that you have a shitty ISP. Really don't think you're grasping this and lack an understanding of packet routing. Please type: traceroute apache.org It's not just your ISP that's potentially shitty, it's every single hop on that list. Even worse if the person is using an open wifi connection. Apache will happily serve you an insecure connection, they are the 80th top site on the internet. This type…

That is still not my problem as a site owner.

Re: Standing on our own two feet

#154

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.

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 context, 'green' and 'no-green' is just non-helpful to validate anything. Sadly, 1 person out of 1000? actually care about encryption, or even know what SSL is. Maybe only 1 out of 10000 know about EV.

Sometimes I just become sad, when I think of the lack of general knowledge about fairly important things.

Re: Standing on our own two feet

#155

Earlier quoted context omitted.

I think you might be ignorant with regards to how the rest of the world uses the internet.

But for certain businesses, there is a case to be made for not serving these kinds of customers. Someone using a shitty old Android phone might not even be able/willing to pay for your product, and if they do, might cost more in technical support and/or fraud (due to their device being vulnerable) than what they bring in revenue.

When you are a bank or a crypto exchange, that might make sense. When you are the municipality of a village in rural India or the company that handles all vehicle registrations, it does not.

You cannot gatekeep with such sweeping statements. People have old phones for lots of reasons. Others will have to serve those people for lots of other reasons.

Re: Standing on our own two feet

#156
post #131

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?

> Maybe an app could simplify delivery? I'd be very surprised if an app without root privileges could install a new root certificate. If an app installed a malicious (or even just a poor quality) certificate, that would be a pretty big compromise to the OS. What is strange to me though, is that it seems like the OS should have a mechanism to update the root certs independently of the OS itself. Then again, not updati…

> I'd be very surprised if an app without root privileges could install a new root certificate.

Its not like the OS can actually withstand the app though, looking at a years out-of-date OS with thousands of accumulated known bugs.

Re: Standing on our own two feet

#157
post #150

The answer there would be strong "rights to repair" legislation. In the most affected markets it would be a viable option to go to the phone shop and have a new operating system image installed for 20 Euros/Dollars. But those markets don't have the legal power against Google or Samsung. And markets that would have the legal power, don't care about unnecessary electronic waste ruining the planet. (Sent from Android 4.…

The scenario you describe unfortunately requires more than just right to repair. It requires the SoC vendors to either keep updating their kernels, or to open source their driver blobs. Without these, you can't build a proper new OS image, you're stuck on the latest one provided by the SoC manufacturer.

In practice, updates might be possible, but you'll often see hardware stopping working.

If it is "just" bluetooth, that may be fine. When networking (wifi/GSM) or the screen stops working, it probably is not.

I've done a fair bit of upgrades of ancient android phones to CyanogenMod, LineageOs and even an accidental Ubuntu Touch. Fairly common that things like the camera or bluetooth stop working (partly), but for many owners of old phones, that is certainly a trade to make. "I never use Bluetooth, what could you use it for?", "Oh, but then I'll just use this jack-cable for my sonos").

What I'm trying to say: yes: updates require SoC vendors to help, or at least stay out of the way. But no, that does not mean one cannot ever update at all.

Re: Standing on our own two feet

#158
post #7

> Without IdenTrust, Let’s Encrypt may have never happened and we are grateful to them for their partnership. What I have never understood is why IdenTrust accepted to cross-sign Let’s Encrypt's root certificate. With that move, IdenTrust basically broke the CA cartel and helped driving the price of basic certificates to zero. How did they, as a for-profit organization, justify "doing the right thing" when that meant…

My professor was one of the founders of Let's Encrypt. He said it was basically a game theory problem. Whichever CA defects gets money. The rest get nothing. IdenTrust decided to get that money, because they thought that if they didn't, a different CA would.

Re: Standing on our own two feet

#159
post #144

Earlier quoted context omitted.

Yes and Yes. And both are reasonable and not excluding. Google sells you a pocket computer with a locked down OS, not for your safety but to control the ability to run ads. If they cared about user security, they would provide updates, no matter how "slow" (their excuse) the device gets. If they didn't want full control to show ads (ads are downloaded by the GooglePlayServices, which is pretty much the kernel of all…

Google does provide updates. It's the device manufacturers and/or mobile operators who choose not to push them.

But that model is flawed, and it's been more than a decade to learn that. The interesting thing is: We already have a model that works much better, and it's been around for longer. If you buy a computer with Windows it is completely normal that you still get your updates from Microsoft, even if your computer is built by a company that may no longer exist by the time you install the update. (That's not to say Windows and Microsoft don't have their own security issues - but the idea that "we provide an OS and we add a middle man for OS updates that by all experience doesn't do his job" is a good model is at this point preposterous.)

Re: Standing on our own two feet

#160
post #154

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…

For PKIX (and thus in your web browser) leaf certificates the X.509 Common Name is only permitted to be textually equivalent to one of the SANs (Subject Alternative Names, the Internet's way to write a name for a machine) in the certificate. So that's either a dnsName or an ipAddress. This is grandfathered in because it's how Netscape worked last century before PKIX was standardised and thus before SANs existed to do this properly.

So it would be prohibited to issue leaf certificates with a CN that's a human meaningful name like "Google" or "Hacker News" because that violates PKIX.

It doesn't matter anyway, the only enforcement that really matters for HTTPS is the mechanical enforcement by the user agent, because there are way too many HTTPS transactions for the human to realistically assess the certificate shown for each transaction and decide if it's OK.

Post reply on HN