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

Safari will no longer trust certs valid for more than 13 months

theregister.co.uk

Post reply on HN
Print view View original

71–80 of 179 posts

Re: Safari will no longer trust certs valid for more than 13 months

#71

Post by tialaramex »

detaro wrote: post #21
mamon wrote: post #4

Earlier quoted context omitted.

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free The fact th…

CAs are free to come up with more complicated schemes for customers that think they need them, including systems that include humans in the loop if that's what is requested. It's kind of embarrassing that hasn't happened yet, but apparently "just buy long-term certificates instead of bothering to improve things" wins out unless there is external pressure. That said, many CA verification processes are just less-standa…

A customer can (and some high value customers do) proceed as follows:

* Pick a CA you can do business with. Let's say it's Sectigo as an example here

* Arrange a deal with Sectigo whereby they'll use an agreed process such as phoning a specific (confidential) contact number and speaking with Dave your Head of IT Security to confirm it's as expected before each certificate is issued for your names. Maybe this is a minimum volume deal like you'll pay them $2000 for the first up to 100 certificates per year and then $10 for each additional certificate.

* Set the CAA resource in your DNS for your names to require Sectigo as the only authorised CA.

Now when bad guys try to trick Sectigo it doesn't work because Sectigo calls Dave who shuts it down and you're onto them. If they instead try to trick say, Let's Encrypt the CAA resource says only Sectigo is allowed and the attack fails immediately.

The Ten Blessed Methods (of which Let's Encrypt offers three) are obligatory though, you can't make a deal with a CA to just skip it, they must use one of those methods. However if minimum friction is your goal you could find a CA that also operates as a DNS registrar for your names, whereupon one of the methods (3.2.2.4.12) means they only need to confirm this fact internally, no work for you.

Re: Safari will no longer trust certs valid for more than 13 months

#72

Post by e12e »

gruez wrote: post #19
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

> The client should decide whether the certificate is still trustworthy. Great, now you need to constantly go to some site like caniuse.com to see what % of browsers thinks your certificate is valid.

You have to do that anyway to check if the certificate is revoked. Or, we'll, you should. I'm not sure sure if there are any production tls stacks that actually handle revocation well.

Re: Safari will no longer trust certs valid for more than 13 months

#73

Post by z3t4 »

tingletech wrote: post #67
z3t4 wrote: post #45

I don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. Also browser should send their public key to the server! So that we don't have to come up with a new password for every damn site.

> Also browser should send their public key to the server! That would make fingerprinting even easier?

The browser could generate an unique key pair for every website that request a public key. Or there could be a dialog like "news.ycombinator.com want's to know your identify, which profile to use?" (option to generate a new profile), kinda like password managers work today.'

The advantage with reusing "profiles" is that you could use the same profile on many web apps like Facebook and Instagram, then you could allow your Facebook friend to access your Instagram photos. Or your "contact list" could be offline (eg. managed by your browser, and not by web apps) and you manage access rights via your contact list, rather then on each and every app.

Re: Safari will no longer trust certs valid for more than 13 months

#74

Post by tialaramex »

nicolas_t wrote: post #30
iso1210 wrote: post #28

Earlier quoted context omitted.

Without certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?

oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.

CT didn't change this for bad guys. If you're a bad guy (or a neutral researcher with a budget for the data) you can buy what's called "Passive DNS". Several suppliers will give you a list of DNS requests and their answers, the identifying information for who made the requests is elided so it's not PII but it has the same effect of making the fact servername.example.com exists in effect public information.

Even if you are unusual in actually having machines named cy23hdc9.example.com not exchange2016.example.com then the existence of this service means you need to stop assuming nobody knows these names. Anybody who cares knows them.

Re: Safari will no longer trust certs valid for more than 13 months

#75

Post by Mister_Snuggles »

tialaramex wrote: post #63
Mister_Snuggles wrote: post #57

Earlier quoted context omitted.

I'm definitely open to learning how to do things better, and I have no doubt that some of what I'm doing is wrong - after all, this whole thing started as a homelab-turned-homeprod learning experience. I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resu…

> I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct? Yes. The CSR is public information so it's fine to send that somewhere. "Sign it" [the CSR] is a phrase that doesn't entirely reflect what's happening…

Thanks!

I'm going to try the CSR route the next time I have to do this and see how that works out. xca seems to handle CSRs easily, so doing this less-wrong should work out fine.

I'm not too concerned about the QNAP scenario - it's consumer gear, so I expect it to lean more towards doing things easily over doing things correctly. The iOS scenario is much more interesting to me since this is something that's more applicable in the real world.

Re: Safari will no longer trust certs valid for more than 13 months

#76

Post by snowwrestler »

mamon wrote: post #4
reaperhulk wrote: post #3

Earlier quoted context omitted.

The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful. As for the other browsers, Google originally proposed SC22 ( https://cabforum.org/pipermail/servercert-wg/2019-August/000... ) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back chan…

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free The fact th…

Setting aside the question of Let's Encrypt challenges... even for OV or EV certificates, the CA does not verify the organization at the issuance of every certificate.

Instead, there is a verification process up front when you establish your company's account with the CA, and then each employee's account in the CA web application is associated with the verified company identity.

To be more specific, once the initial company verification is done, the CA relies on their authentication scheme to ensure that the person logging in and requesting a new EV certificate is authorized to do so for that company. The importance of authentication is why both MarkMonitor and CSC require 2FA, for example.

I can't think of a reason that such certificate issuance could not be automated. You would just need to have a machine-to-machine authentication scheme that you can trust and monitor. That is easier than Let's Encrypt's challenges because you can manually establish shared secrets in advance (i.e. API keys).

Re: Safari will no longer trust certs valid for more than 13 months

#77

Post by dtech »

stygiansonic wrote: post #5

I understand the reasons behind wanting to shorten certificate validity periods, but CA or root certificates often have expiration periods far into the future. What’s the argument for this? Ease of use? Historical reasons?

Root certificates are special. They are shipped to the device out-of-band, e.g. with OS updates. This makes them much more difficult to replace than other certificates, especially on devices that do not receive updates often like embedded devices and mobile phones.

For this reason root certificates have a very long validity and very stringent requirements in their security parameters, e.g. large key sizes, and how they are used. Usually the certificate sits in a well secured off-network physical device and is only used a few times during its lifetime to sign sub-certificates.

Re: Safari will no longer trust certs valid for more than 13 months

#78

Post by xg15 »

brirec wrote: post #11
mamon wrote: post #4

Earlier quoted context omitted.

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free The fact th…

I think you may not be very familiar with Let’s Encrypt’s challenges. Allow me to briefly explain the gist of them: The two most common challenges are an http challenge, and a DNS challenge. The http challenge gives you a response code to host as a file on the domain during the validation period. This challenge is, for all practical purposes, random, and cannot be guessed. Then, after your script tells Let’s Encrypt…

> DNS challenge is even more secure, in my opinion, as it works the same but the response code is stored in a TXT record for Let’s Encrypt to validate. In order to break this you would need control of the DNS servers.

> Now let’s contrast this with, for instance, getting a multi-year certificate from the likes of Verisign or similar: this (as far as I am aware) requires manual interaction, which can at least theoretically allow for human error, of which there are many chances.

What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar.

Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other.

> Additionally, many more traditional CAs will let an inexperienced user have the CA generate the private key and then transmit it to the user. This opens up a LOT of dangerous possibilities, as now this private key is being saved and moved around, and could easily be missed and left on the workstation used to perform the work. Or a MitM attack could even snatch it in transit.

Again, it's harder for a rogue CA to abuse my certificate - but instead, a rogue registrar could now easily manipulate my DNS record and receive a valid cert of its own.

Re: Safari will no longer trust certs valid for more than 13 months

#79

Post by jhoechtl »

superkuh wrote: post #39

There are two mutually exclusive views of the web. As a set of protocols to allow individual humans to share information about things they love and the web as a set of protocols to make a living. There are real reasons for the for-profit web to want to limited cert lifetimes since revocation doesn't really work in practice. In terms of browser dev the two views are mutually exclusive and the one that funds the coders…

I am telling you there is a conspiracy going on to end the open and free web.

We should fiercefully start to fight back otherwise those who made the internet great (the open source hackers working on LAMP) will loose everything.

Re: Safari will no longer trust certs valid for more than 13 months

#80

Post by Someone »

lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

”The client should decide whether the certificate is still trustworthy”

That’s what is happening now. Except for common sense, nothing stops a browser from trusting a certificate with an expiration date in the past.

The expiration date more is a statement from the issuer “I wouldn’t trust this after this timestamp”.

Having said that, I think Apple should say “our OSes will stop trusting certificates issued over two years ago” instead of ”our OSes will stop trusting certificates that expire in over two years”

If they did that, one could still use certificates with longer expiration periods, allowing other parties to cache them for longer periods.

Now they force everybody to follow them, so that, if this change breaks sites on iOS, it also breaks sites everywhere else.

Post reply on HN