[HN Gopher] Safari will no longer trust certs valid for more tha...
___________________________________________________________________
Safari will no longer trust certs valid for more than 13 months
Author : nimbius
Score : 143 points
Date : 2020-02-23 17:19 UTC (5 hours ago)
(HTM) web link (www.theregister.co.uk)
(TXT) w3m dump (www.theregister.co.uk)
| gsich wrote:
| Safari market share ... so who cares.
|
| I am not talking about mobile usage.
| Mister_Snuggles wrote:
| I have my own mini-CA for internal stuff, built using the xca[0]
| tool with certificates and private keys distributed manually. I
| usually make the keys valid for two years so that I don't have to
| renew and redistribute very often. Most of this started as a way
| to learn how this stuff works, but it's now turned into a
| "production" thing as I've started using this to issue user
| certificates for VPN authentication.
|
| Is there any tool that I can use to help automate this in a
| reasonable manner?
|
| Ideally, I'd love to see a web version of xca that supports ACME
| with some controls on how ACME certificates get issued. Bonus
| points for supporting OCSP as distribution of CRLs is another
| upcoming pain point.
|
| [0] https://hohnstaedt.de/xca/
| tialaramex wrote:
| If you're moving Private Keys you are Doing It Wrong. This is
| very common in VPN setups (and S/MIME) but still a terrible
| idea and worth taking the time to figure out how you'll make
| sure you don't do this.
| lmilcin wrote:
| Well, you are mostly correct.
|
| There are ways to distribute keys safely. You can use key
| derivation or you can set up transport key (yet another key,
| just to transport session keys). Both methods are allowed by
| PCI if done correctly.
|
| Unfortunately that's not what typically happens. Setting up
| infrastructure to transport keys safely is such a pain in the
| ass that, for SSL/TLS, I always recommend to just generate
| the key at the site of its intended use.
| Mister_Snuggles wrote:
| 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 resulting signed cert on the
| server. Is this correct?
|
| What I'm finding in some cases is that there are cases where
| this just won't work. For example, my QNAP NAS allows me to
| either create a self-signed certificate (I don't want this, I
| want it signed by my CA), get one from Let's Encrypt (same
| issue), or upload certificate, private key, and optional
| intermediate CA certificate files (and we're back to moving
| private keys). This is a limitation of QNAP's GUI for sure,
| but it's not unique to QNAP.
|
| Similarly, I'm not sure how I'd generate the certificate plus
| private key on an iOS device and submit it for signing (the
| VPN scenario). This one particularly bothers me because the
| .mobileconfig file ends up being the key to the castle.
| Ideally I'd like the client to be authenticated with both a
| user-specific certificate and EAP, but I don't think iOS
| supports this. I haven't quite gone very far down this rabbit
| hole, so it's possible that I'm missing something.
|
| When I finally secure my internal web server (which acts as a
| reverse proxy for all of my internal services), I'll try the
| CSR approach for the learning experience. This approach
| should also work fine on my VPN server.
| tialaramex wrote:
| > 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 with the
| relationship between a CSR and Certificate, experts know
| it's technically wrong but they say it anyway, so don't
| sweat it but it's probably misleading.
|
| I will try to circle back to see if I have any suggestions
| for your specific scenarios later.
| Mister_Snuggles wrote:
| 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.
| nimbius wrote:
| check out Cloudflares CFSSL https://github.com/cloudflare/cfssl
| to manage the CA side, its API, and its OCSP
|
| then check out Netflix Lemur for issuing and tracking certs
| automatically. https://github.com/Netflix/lemur
| dcow wrote:
| CFSSL was developed with cloudflare-specific use cases in
| mind. If you're looking for a general purpose personal CA,
| checkout smallstep/certificates:
| https://github.com/smallstep/certificates. Full disclosure, I
| work for smallstep, but we're not exactly competitors.
| Regardless, here's an external analysis of the two:
| https://jite.eu/2020/2/17/step-ca/
| Mister_Snuggles wrote:
| This looks very nice too! I'll have to look at this one
| closely, it seems to give me most of what I'm looking for.
| Thanks!
| Mister_Snuggles wrote:
| These both look really good! I'll have to check them out in
| more detail.
| PureParadigm wrote:
| Use a web browser that respects your choices. Your software
| should work for you, not the other way around.
| Wowfunhappy wrote:
| Users _can_ choose to manually trust expired certs in macOS
| /iOS, I don't believe that's what is at issue here.
| z3t4 wrote:
| 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.
| jaywalk wrote:
| >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.
|
| The vast majority of users will not understand this. Also let's
| say you go to a site one day, and you get a prompt that their
| certificate has changed. Is this legit? How can you know?
|
| >browser should send their public key to the server!
|
| This already exists (HTTPS Client Certificates) but it's a huge
| pain in the ass so it's barely ever used. When it is used, it's
| generally within a controlled corporate environment.
| z3t4 wrote:
| There could still be a trust chain. But most websites don't
| need it, just like most websites only use the basic level of
| certification today, all they really want is encryption. (or
| the green padlock :P)
|
| Client certificates has kinda been deprecated by browsers.
| Which is why it's such a PITA. Also handling signing
| certificates by itself is a PITA. But most website's wouldn't
| need signing, just encryption.
|
| Automatic SSL certificate signing is not that secure, if an
| attacker would be able to mess with DNS, or access the HTTP
| server, they could also create a fake certificate via
| Letsencrypt. Or if the attacker has access to the client,
| they could sneak in a root certificate. Most nation states
| and ISP (those who would like to spy on it's citizen) already
| have root certificates. All that SSL certificates do is to
| create extra work for site maintainers. We can have
| encryption without certificates. If you would for example
| side-load a list of public keys for the main sites you visit,
| that would be much more secure then SSL certificates are
| today.
| tingletech wrote:
| > Also browser should send their public key to the server!
|
| That would make fingerprinting even easier?
| z3t4 wrote:
| 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.
| Santosh83 wrote:
| No joint announcement with other industry 'leaders' like Google
| and Microsoft? What is their stance on this? Will they be making
| similar changes to Chrome/Edge? And Mozilla? And maybe I am wrong
| but compromised certs are game over very soon aren't they?
| Reducing their lifetime to 'just' a year is still plenty of time
| to do enough damage seemingly, so what exactly does this high-
| handed change bring to the table? Another reason stated that it
| will keep the cert management folks busy and alert also sounds
| like grasping at straws to prop up the decision. I wonder what
| the entire reasons are...
| reaperhulk wrote:
| 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 channels that several major CAs actually wanted
| the ballot to pass but for political reasons could not publicly
| support it.
|
| So while Apple is acting "unilaterally" here, there is
| universal support among browser makers and tepid support from
| CAs. You should expect Google and Mozilla to follow suit in the
| next 6-12 months.
| mamon wrote:
| 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 that it's automated results in less human
| intervention along the way, which on one hand lowers costs,
| on the other hand makes it detecting scams harder (unless
| they deploy some really Machine Learning that detects
| frauds).
|
| The fact that it's free means that there's no credit card
| number or other info that would help identify actual person
| that requested certificate issuance.
|
| Together those things make things less secure, not more.
|
| EDIT 2: Both types of Let's Encrypt challenges look like
| pushing down the responsibility to either web server owner or
| DNS service. Maybe that's a good thing, since at least
| there's one fewer party that can screw things up.
| iso1210 wrote:
| How does doing it manually verify that certificate is
| issued to the legal owner of the web site and not a hacker?
| brirec wrote:
| It doesn't. It actually opens up more opportunities for
| error, intentional or otherwise, that can possibly be
| exploited by a malicious actor.
| jchw wrote:
| Humans are actually _detrimental_ to preventing abuse.
| snowwrestler wrote:
| 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).
| brirec wrote:
| In regards to your edits, let me also mention that Let's
| Encrypt does not offer (and indeed can not offer) "Extended
| Validation" certificates, due to things related to the two
| "bad things" you mention. However, extended validation
| certificates don't in fact prevent fraud the way they are
| intended to -- indeed, a security researcher managed to get
| ahold of a certificate for Stripe, Inc. simply by legally
| registering a corporation under that entity name elsewhere
| and purchasing a certificate for that legal company.[1]
| This issue with EV certificates -- the fact that they are
| issued to a company as opposed to just a domain name --
| cause them to potentially pose a greater risk to web users.
|
| [1] https://arstechnica.com/information-
| technology/2017/12/nope-...
| brirec wrote:
| 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 that the response to its challenge is
| available and up-to-date, Let's Encrypt performs an http
| GET request to retrieve that response, and checks to ensure
| it is exactly what the script provided. Only then does it
| proceed with signing your CSR and giving you a valid
| certificate.
|
| This requires (at least temporarily) a web server running
| on port 80 at the domain in question, and in order to break
| it you would need to be able to effectively either hijack
| the A record for the domain as read by Let's Encrypt, or to
| break into the web server to properly issue a certificate
| that one then steals. Impossible? Probably not.
| Impractical? Very.
|
| 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.
|
| So, to put it rather simply, >Are the challenges used by
| Let's Encrypt secure? Yes, so long as you trust your DNS
| and web servers not to be compromised. And if they are,
| it's frankly game over anyway.
|
| 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.
|
| 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.
|
| Honestly, I don't think there is much (if any) point in
| still using manual verification. The human aspect of it
| also opens up chances for forgery, and so on.
|
| Let's Encrypt's challenges are specifically designed to be
| difficult or impossible to hijack, and so far as I
| understand it the private key should never leave the server
| it will remain on.
|
| So again, to answer your question succinctly and to the
| best of my knowledge: yes, the challenges used by Let's
| Encrypt are most certainly secure.
| tialaramex wrote:
| > Additionally, many more traditional CAs will let an
| inexperienced user have the CA generate the private key
|
| This should not be true for any CA in the Web PKI. If you
| have evidence that a CA trusted by Mozilla offers this
| service you should give that evidence to m.d.s.policy (or
| me and I'll see it gets passed on with attribution)
|
| There have been resellers who offer this. These are
| independent businesses from the CAs, and it's even
| crazier to let them (basically middlemen with no
| oversight) pick your private keys or know what they are.
| But as separate businesses it's hard for us to
| effectively stop them.
| xg15 wrote:
| _> 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.
| tialaramex wrote:
| This is correct. But perhaps even more correct would be
| to say it _consolidates_ the risk at your DNS registrar,
| since of course bad guys who seize control of your DNS
| records could anyway deny all service and capture
| anything unencrypted.
|
| You should definitely not use an untrustworthy DNS
| registrar or registry for important things, but that was
| true regardless and it hasn't stopped the .com TLD (which
| is run very badly indeed) making a tremendous amount of
| money.
| Reelin wrote:
| I think there's an underlying assumption that your
| server, your DNS registrar, and all the CAs present in
| your root store are trustworthy. It may not be a
| particularly safe assumption, but it's presumably better
| than unverified TLS or trust on first use (for the
| majority of present day usecases).
|
| If anything, I would expect universal adoption of
| automated verification methods to improve security.
| Instead of only needing to trick a _single_ CA out of an
| entire root store into issuing a certificate, you would
| instead need to hijack the DNS listing without being
| noticed by _anyone_ (and hopefully all CAs, as well as
| everyone else, would be on the lookout for this).
| gruez wrote:
| >The fact that it's automated results in less human
| intervention along the way, which on one hand lowers costs,
| on the other hand makes it detecting scams harder (unless
| they deploy some really Machine Learning that detects
| frauds).
|
| You think that other CAs manually issues their DV
| certificates?
|
| >The fact that it's free means that there's no credit card
| number or other info that would help identify actual person
| that requested certificate issuance.
|
| How do you feel about CAs that accept cryptocurrency, or
| accept prepaid credit cards?
| detaro wrote:
| 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-
| standardized variants of the things LE does. If you can get
| LE to give you a fraudulent cert, you will also find
| another CA you can fool.
| tialaramex wrote:
| 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.
| duskwuff wrote:
| > The fact that it's automated results in less human
| intervention along the way...
|
| Let's Encrypt is far from unique in being heavily
| automated. If anything, its verifications are more
| stringent than those used by other major CAs.
|
| > The fact that it's free means that there's no credit card
| number or other info that would help identify actual person
| that requested certificate issuance
|
| Payment details are basically useless in terms of tracking
| abuse. Attackers have no lack of access to untraceable or
| fraudulent payment methods.
| simias wrote:
| The challenges used to verify ownership and whether the
| task is automated or not are mostly orthogonal issues. I
| don't see how automating the renewal makes it less safe, if
| anything it removes human error from these tedious tasks.
| michaelbuckbee wrote:
| Google and Mozilla are both major backers of LetsEncrypt which
| is tackling this problem from the other side (issuing short-
| lived certificates and putting in a system to automatically
| update them).
| moneromoney wrote:
| Apple's browser is already called "the New Internet Explorer":
|
| https://fabiofranchino.com/blog/css-height-parent-flex-safar...
|
| https://dev.to/nektro/safari-is-the-new-internet-explorer-1d...
|
| https://arstechnica.com/information-technology/2015/06/op-ed...
|
| ... and millions similar articles
|
| I developed widgets for web developers and I had to change it to
| stop using the 'fixed' positioning anywhere, because iOS is the
| only browser that interpret it differently on all touch enabled
| devices. They have many other issues as well. I have to spend
| half of my time to fix their buggy browser!!!!!!!!! Not even the
| old internet explorer causes that many issues as safari.
|
| They torpedoed progressive web apps and many important web
| standards. Why? Just because they want you to use their apple
| store, where they can take 30% from every transaction without
| doing anything.
|
| I hope Apple will go bankrupt and stop hurting the web community
| as they successfully did in the past years.
| nicolas_t wrote:
| While I agree that it is better from a security perspective not
| to issue long lived certificate and that automation would be
| best, I dislike the fact that the subdomain of any certificate I
| issue becomes public due to Google's certificate transparency
| project.
|
| By making every subdomain public, it makes the job easier for any
| attacker wanting to try and find smaller servers to target. It's
| not that I believe in security through obscurity but besides
| making sure all servers are as secure as they can be, I do
| believe in not making the job easier for adversaries.
|
| So, instead I use wildcard certificates, and for this automation
| gets much more annoying, you need to use DNS to validate it
| (route 53 or similar does provide an api that can be used) and
| then I'm not sure if I'm confortable having each server generate
| their own wildcard certificate, leading to 100s of wildcard
| certificates...
|
| This is why I currently use old style 1 year wildcard certificate
| which gets updated through chef but I'm really not sure if this
| is the best solution or not.
| iso1210 wrote:
| 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?
| nicolas_t wrote:
| 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.
| tialaramex wrote:
| 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.
| TeMPOraL wrote:
| I never heard about Passive DNS before. Thanks.
|
| That said, shouldn't that be illegal? Where does this
| data come from anyway? I'm guessing spyware - on the
| phone, in browsers, and spyware browsers like Chrome.
| xg15 wrote:
| Yes, which is why you used to be able to have fully
| internal domains that are served by an internal DNS
| server and are never seen on the public internet.
| njsubedi wrote:
| Wouldn't it be a better idea to use alternate domains
| instead of subdomains? You could use something like [any
| subdomain].atdie8e73bhdbdie93ruhe.[any tld] for
| obfuscation?
| saagarjha wrote:
| Those cost money.
| X-Istence wrote:
| You could automate the generation of the wildcard certificate
| and push it out with chef to all your servers. Instead of
| replacing it once a year, you replace it every 90 days.
| lisper wrote:
| 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.
| hannob wrote:
| That is... a very absurd idea.
|
| You really don't want a situation where webpages may work or
| not work based on some completely unclear criteria.
| User23 wrote:
| This is exactly what Safari deciding to arbitrarily not trust
| valid certs is.
|
| The de facto standard will be that you will need to
| accommodate the least tolerant user agent if you want your
| certs to work for all browsers.
| Wowfunhappy wrote:
| But Safari has laid out clear criteria as to under what
| conditions the certs will be invalid.
|
| If I'm understanding correctly, the GP is saying browsers
| should be making decisions based on a much wider variety of
| criteria (for example, who issued the cert, how popular is
| the website using the cert, etc), which would be much more
| difficult to troubleshoot.
| tialaramex wrote:
| The likely result is that two year certs will just cease to
| be available, even if other clients don't decide to make an
| equivalent rule.
|
| And yes, the de facto standard is that for the general
| purpose web you can't sell certificates based just on, for
| example, getting an OK from Microsoft (whose trust stores
| includes a tonne of governments and government agencies
| whose inclusion a cynic might assume is not coincidental to
| those governments agreeing to purchase Microsoft's
| products...) because those certificates don't work on an
| iPhone or in Firefox or...
|
| The relationship that is symbolised by the CA/Browser Forum
| has always been asymmetrical like this, it was this way
| before the CA/B Forum was created, and if the two groups
| aren't able to reach common ground the CA/B will just
| gradually go away.
| diroussel wrote:
| Yes but what we have now is also absurd. One day I can visit
| a site just fine and the very next I can't and the browser
| won't even let me override the "invalid" certificate.
| pickdenis wrote:
| How about grading the validity of the certificate on a
| continuous scale? P(site loads) = 1 - R*(days since issue)
| where browsers can choose R as they wish. This gets rid of
| this discontinuity.
| wool_gather wrote:
| It's basically what has been announced here, though, no?
| There's no technical impediment to a CA continuing to hand
| out 2+ year certs. The only reason they would not do so is
| that webpages will start breaking if they're accessed from
| Safari.
| tambre wrote:
| The criteria are very clear:
|
| - Safari
|
| - max 398 days
| luckylion wrote:
| > The criteria are very clear:
|
| _today_. Tomorrow they may change to be 397 days, or
| 39.8 days, or "until the next iPhone is released".
| chrisandchris wrote:
| Isn't that a bit like arguing about the 825 days? The
| CA/B could change that aby day they want and there's
| nothing you can do. Others will follow Apple and the CA/B
| will follow too, like they should have in 2017, IMHO.
|
| The 398 days isn't something they came up right before
| they presented it. It's already 3 years old...
| Someone wrote:
| _"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.
| thefounder wrote:
| And how are the CAs supposed to squeeze you of money?
| gruez wrote:
| > 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.
| e12e wrote:
| 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.
| derefr wrote:
| I mean, in a world with more than an oligopoly of browser
| makers, that'd already be true given that browsers each ship
| with their own trusted CA store.
|
| In the original conception of X.509, it was supposed to be an
| enterprise's system administrator (e.g. a university's IT
| department) that would define the set of root CAs that the
| enterprise's computers would trust. So there'd be literally
| no way to know whether a given user device would trust your
| certificate. That was supposed to be a choice that is _up to
| them_ , not something you can pre-guarantee by making deals
| with third parties.
| abdullahkhalids wrote:
| Can someone chime in with the original intended purpose of the
| expiration date?
|
| The one that I can imagine (without research) is that the
| issuer knows the quality of their own security practices, and
| if they says that a certificate will expire by X date, they are
| saying that they can't guarantee that they will still be the
| only person with the secret key after that point.
|
| Any other explanation?
| FireBeyond wrote:
| 1. As an analogue for password expiration (with all the
| commentary that entails).
|
| 2. Recurring revenue models for CAs.
| wool_gather wrote:
| > the issuer [...] are saying that they can't guarantee that
| they will still be the only person with the secret key after
| that point.
|
| It's not quite clear what you mean here.
|
| The issuer should _never_ have the private key for the end-
| entity cert (the one representing the domain or whatever).
| Only the owner should have the private key.
|
| EDIT: Hmm, according to another comment here, some CAs will
| offer to generate both halves of the keypair for the end
| user. Yikes.
|
| If you are talking about the CA's own private key...if that
| _ever_ leaks, then _no_ certificates signed by it should ever
| be trusted again; expiration date has no relevance here.
| tgv wrote:
| The latter did already happen: Diginotar, in 2011. The
| Dutch government tried to restrain browser makers from
| revoking Diginotar's certificates, since many of their
| websites and services used them. It's a good thing
| certificates don't have an eternal life span.
| tialaramex wrote:
| > EDIT: Hmm, according to another comment here, some CAs
| will offer to generate both halves of the keypair for the
| end user. Yikes.
|
| I wasn't able to find this comment, but perhaps I didn't
| look hard enough? EDIT: Wait, I think I found it. I will
| reply there.
|
| In the Web PKI this is prohibited _but_ there are or at
| least were resellers who 'd offer this service to their
| customers. You should not use this service of course, and
| some CAs have pledged to tell their resellers not to offer
| it.
|
| In S/MIME it's more common because often the end user is
| both technically unsophisticated and not given real control
| over their client in order to mint their own keys anyway.
| But S/MIME is... probably not important, certainly it isn't
| what Apple's change is about.
| zaat wrote:
| One effect of expiration dates is shorter revocation lists -
| if a revoked certificate was originally valid forever, the
| revocation list should list it since it was revoked to the
| end of times. Short lived certificates results in shorter
| CRLs.
|
| Lengthy CRLs have performance cost, they need to be
| downloaded and processed by clients.
|
| There is also a growing risk correlated to certificates
| validity length. If CRLs are unavailable to a client, the CRL
| server might be offline or unreachable or the client's access
| is maliciously blocked. The client have no knowledge of the
| reason and need to decide whether to trust the certificate
| without CRL check or not. If clients would be configured not
| to trust in such cases, the path to DOS is clear - block
| access to the CRL server and you effectively block traffic to
| all services of that CA. If clients are configured to trust
| certificates when CRLs are unavailable, which I beleive is
| the default on all OSs currently, blocking access to CRLs
| allows attacker to fool clients to trust revoked CRLs. With
| short living certificates, the opportunity window for such
| attacks is smaller.
| simias wrote:
| Without an expiration date the only way to retire a
| certificate would be to explicitly revoke it. That'd be a bit
| heavy handed IMO.
|
| Forcing certificates to expire means that domain ownership
| gets re-validated every time. Nobody would risk buying 2nd-
| hand domains for anything sensitive if the previous owners
| could have a permanently valid certificate stashed somewhere.
| Or you'd have to contact all the CAs that could've issued a
| certificate for that domain and ask them to revoke it if they
| did.
| Reelin wrote:
| Is there not already a standard procedure for certificate
| revocation on domain ownership transfer? It seems like
| there really should be - even a 13 month expiry is hardly
| enough to prevent intentional abuse.
| tialaramex wrote:
| The issuer shouldn't know the private (not secret) key
| corresponding to the public key in the certificate anyway. In
| the Web PKI they're explicitly forbidden from knowing this
| key and good ones will react to being shown a private key by
| revoking any associated certificates -- that's what happened
| in the Trustico incident.
|
| They do know a private key for their entire CA certificate
| which they're using to sign things, but that's not what the
| expiry date in the leaf certificates they issue you is about.
|
| Nor is it intended that the lifetime of a certificate
| reflects the expected time to break the private key the user
| knows, otherwise Apple would let you have say a two year
| certificate if you went to P-384 certificates because they're
| harder to break in theory. There is obviously a threat over
| time that your keys leak ("Oops, the backup tapes I put in
| the trash have our current keys") but that's hard to assign a
| specific time interval to, it just means you should
| definitely change keys sometimes.
|
| The main thing that we're always worried about on a specific
| timescale is the name information. The same people control
| google.com today as two years ago, and likewise for
| my.lovely.horse but how about bobs-exhausts.example ?
|
| But the main impetus for desiring shorter lived certificates
| is that the certificate lifetime in practice constrains our
| ability to make technical changes like the SHA-1 deprecation.
| We'd like to make changes faster, and if you've just bought
| an 825 day certificate realistically our changes can't be
| effective in less than 825 days unless we're willing to be so
| disruptive your apparently valid cert ceases to work in
| popular browsers, which will be a hard thing to sell for
| merely precautionary changes.
| Reelin wrote:
| I agree with your overall point and appreciate the clear
| explanation. However, I'd like to suggest that perhaps what
| you describe as "merely precautionary changes" should never
| occur on anything less than a ~2 year timescale anyhow. If
| it's urgent, go right ahead and break things. But the
| internet is _big_, and modifications can be _expensive_, so
| precautionary changes should probably occur quite slowly at
| this point.
| tmpz22 wrote:
| Millions of dollars in IT consultation work. Target in 2014,
| 2019 (it was a 5 year certificate), Microsoft Teams 2020,
| etc.
| marcosdumay wrote:
| Well, it's the one that works in practice. The issuer is the
| one that known when he will renew the certificate. If every
| client decided for himself, half of the internet would be
| broken at each time.
| JoshTriplett wrote:
| If a certificate never expires, revocation lists have to grow
| without bound forever.
|
| If a certificate expires, revocation lists only have to hold
| revoked certificates that haven't expired.
| enigmabridge wrote:
| Apple Drops SSL/HTTPS Bomb - Forget Long Certificates
|
| https://keychest.net/stories/apple-drops-sslhttps-bomb-forge...
| j1elo wrote:
| Anybody knows why Safari on iOS will reject using self-signed
| certificates for WebSocket connections? (doesn't happen on
| desktop)
|
| This is a major annoyance since it is the _only_ browser that
| does this and won 't work with "wss://" URIs even after accepting
| the mandatory certificate exception. Accessing the page
| rightfully shows a warning on all browsers, to which the user can
| click on "Continue" or similar, to ignore this and start the
| demo, except if they try with iOS (this is for simple one-off
| tutorials or demos [1], so maintaining good certs _or_ requesting
| users to install a custom root CA in their devices is out of the
| question).
|
| I know, this seems like a StackOverflow question... but the only
| 100% relevant one I found [2] didn't get much love, so I thought
| maybe someone at HN knows more about this
|
| [1]: https://github.com/Kurento/kurento-demos-
| js/tree/master/play...
|
| [2]: https://stackoverflow.com/questions/36741972/using-a-self-
| si...
| X-Istence wrote:
| I posted about this a couple of days ago:
| https://news.ycombinator.com/item?id=22373673 didn't get much
| traction then :-(
| dboreham wrote:
| Is this an early April fool article?
| tambre wrote:
| What do you find strange about this?
| stygiansonic wrote:
| 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?
| dtech wrote:
| 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.
| gruez wrote:
| Because those certificates are much well guarded (HSMs), rather
| than an unencrypted .pem file sitting on a server or someone's
| computer.
| jcranmer wrote:
| The two big reasons for short certificate validity periods are
| to manage revocation issues (expiry is the one guaranteed way
| to revoke a certificate), and to reduce the risk of forgetting
| to renew certificates (by having to rotate them more
| frequently, your IT is more likely to have better processes in
| place). There's a secondary concern of reducing the ability of
| CAs to backdate certificates (which happened when SHA-1 was
| prohibited).
|
| Neither of those really apply to the root certificate store.
| Updating the root certificate (to add or remove CAs) requires
| an OS/browser update instead of relying on CRL or OCSP queries
| which are flakier--and browsers have a variety of mechanisms to
| punish misbehaving CAs that aren't "drop you from the root
| store effective immediately."
|
| Meanwhile, the process for updating root stores is entirely
| different than regular certificates, and it takes months to
| years to add a new root certificate--and I believe you don't
| get a pass to merely update your new root certificate for an
| existing CA.
|
| The other risks with overly long validity times are ameliorated
| in large degree by the fact that CAs are regularly audited and
| have much greater scrutiny placed on their issuance.
| jakub_g wrote:
| It's not easy to (at least this was the case until a few years
| ago) to ship updates to an old device (think Android 4.x or
| Windows XP; even worse for embedded systems). Hence to avoid
| the devices become useless bricks even if otherwise fully
| functional, root certs need to have more than a decade cert
| validity at minimum. (That's my personal theory, I'm not in the
| industry).
| userbinator wrote:
| I think the industry is very much trying to push for the
| exact opposite of that, with things like planned obolescence
| to ensure you keep consuming their latest products.
| superkuh wrote:
| 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 gets it's way. Especially with the
| W3C marginalized and a mix of corporations and corporate-centric
| standards groups running things now. Expect to eventually be
| unable to host a visitable or indexable website without relying
| on at least one third party service in the near future.
| derefr wrote:
| CAs have always been third-party services, though. Their APIs
| just used to involve humans talking to humans, rather than
| machines talking to machines. But that's no less of an
| operational dependency.
|
| In a systems engineering plan (e.g. a NASA long-term project),
| both kinds of dependencies are considered liabilities that must
| be engineered for long-term reliability, fault-tolerance, etc.
| superkuh wrote:
| In the past browsers did not scaremonger so much about self-
| signed certs and search engines would index sites that were
| just http and this didn't effect their ranking.
| threeseed wrote:
| I can't tell if you are serious here.
|
| You want self signed certs to be trusted and the web to
| move back to the days of HTTP where anybody could just
| intercept your traffic ?
| gsich wrote:
| That's not what he said.
| gruez wrote:
| >In the past browsers did not scaremonger so much about
| self-signed certs
|
| That's necessary because people tend to be fixated on
| whatever task they're doing, and that causes them to click
| pass any warnings regardless of risk or comprehension.
| benibela wrote:
| Search engines have stopped listing http sites? Since when?
| I do not have https for my site (unclear if sourcefoge
| allows https for custom domains)
| luckylion wrote:
| It's different if you can "buy" a cert and be "safe" for a
| few years vs needing to renew it every 90 days. If they
| choose not to renew your cert, you're out after what ever
| time is left on your cert.
|
| Let's lower that to 60 ... 45 ... 15 .. ah, let's just renew
| all certs every day, that's the only way to keep control
| centralized.
| greglindahl wrote:
| What about people who want to share information about things
| they love with privacy and security? This change seems likely
| to enhance my privacy and security.
| jhoechtl wrote:
| 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.
| Reelin wrote:
| I'll agree that modern mainstream browsers (and devices!)
| have an increasingly centralized security model that isn't at
| all conducive to an open web. But given the current state of
| the FOSS ecosystem, I'm not terribly concerned in the long
| term so long as the network layer remains open to all.
|
| (Consider: QtWebEngine, PinePhone, SiFive, OpenTitan, IPFS,
| DAT, Solid, ...)
| diminish wrote:
| Does apple try to kill the web? Does Google try to take it
| over?
|
| Why doesn't Apple kill a million sh.tty apps just trying to
| grab attention doing nothing useful?
|
| It's time to get rid of Apple/Google browsers really
| bad_user wrote:
| With Let's Encrypt it's cheaper than ever to host a personal
| website over HTTPS with a certificate that updates itself.
|
| Due to Let's Encrypt, free hosting services like Netlify or
| GitHub Pages are now providing HTTPS certificates and
| installing it on your own server is pretty painless, if you're
| into managing your own server. And if your hosting provider
| doesn't support Let's Encrypt, you can always put Cloudflare in
| front of it.
|
| So I don't really understand what you're talking about, when
| the price and ongoing maintenance of HTTPS certificates has
| gone significantly down for hobbyists.
| superkuh wrote:
| >So I don't really understand what you're talking about,
|
| That's because you didn't finish reading my post.
|
| >Expect to eventually be unable to host a visitable or
| indexable website without relying on at least one third party
| service in the near future.
| threeseed wrote:
| You mean like how it has been for decades ?
|
| You have always needed at minimum hosting, SSL and domain
| service providers.
| jchw wrote:
| > Expect to eventually be unable to host a visitable or
| indexable website without relying on at least one third party
| service in the near future.
|
| I mean... How do you expect to have a valid, trusted TLS
| certificate without a third party? Nobody says it has to be
| Lets Encrypt or Cloudflare or Amazon load balancers or ... so
| forth. Some certificate authorities even already have APIs....
| snek wrote:
| You already have to rely on a third party to get a domain (and
| to get an IP address)
| TeMPOraL wrote:
| Every additional third party is an extra problem. It's an
| extra relationship to track.
| OrgNet wrote:
| Google doesnt trust my password for a gmail account that I last
| used 6 months ago (I had to also provide one my previous password
| to be able to login). It is getting ridiculous...
|
| Now I gotta keep an history of passwords, just for Google...
| [deleted]
| mooibos wrote:
| I develop for Apple platforms, and it's absolutely mind-boggling
| how frequently and regularly they break your code for no tangible
| benefit.
|
| Hopefully their influence doesn't spread to the web too.
| threeseed wrote:
| There is a tangible benefit. For users.
|
| 64-bit only, Project Catalyst, BitCode, HTTPS only connections
| etc are examples of initiatives which definitely has caused
| pain to developers but has immensely benefited users as a
| whole. And if you don't passionately care about users then
| frankly find another platform to develop on.
| gsich wrote:
| >64-bit only
|
| how has that benefitted the user? Directly and measureably,
| no "it's 0.3% faster now" excuses.
| kevingadd wrote:
| How does it benefit the user for half their software to
| break, or for them to have to pay a vendor (rightfully) for a
| massive update/overhaul just so the software keeps working?
|
| 64-bit Only benefits Apple because they don't have to
| maintain the 32-bit stack anymore. Any perf-sensitive
| software that needed to be 64-bit transitioned a long time
| ago.
| ericd wrote:
| 64-bit only certainly doesn't benefit me as a user on the
| balance. There's a lot of software that's useful that has
| zero need for yearly updates.
___________________________________________________________________
(page generated 2020-02-23 23:00 UTC)