Apple Strong-Arms Entire CA Industry Into One-Year Certificate Lifespans (zdnet.com) 159
A decision that Apple unilaterally took in February 2020 has reverberated across the browser landscape and has effectively strong-armed the Certificate Authority industry into bitterly accepting a new default lifespan of 398 days for TLS certificates. From a report: Following Apple's initial announcement, Mozilla and Google have stated similar intentions to implement the same rule in their browsers. Starting with September 1, 2020, browsers and devices from Apple, Google, and Mozilla will show errors for new TLS certificates that have a lifespan greater than 398 days. The move is an important one because it not only changes how a core part of the internet works -- TLS certificates -- but also because it breaks away from normal industry practices and the cooperation between browsers and CAs. Known as the CA/B Forum, this is an informal group made up of Certificate Authorities (CAs), the companies that issue TLS certificates used to support HTTPS traffic, and browser makers. Since 2005, this group has been making the rules on how TLS certificates should be issued and how browsers are supposed to manage and validate them.
Bitterly my ass (Score:5, Funny)
I'm sure the CAs are thrilled that they get to sell people certificates more often than before.
Oh no, Apple is forcing us to make more money, woe is us!
Re:Bitterly my ass (Score:4, Informative)
"only 35% of CAs voted to approve a one-year TLS certificate lifespan"
Apple went ahead and said "F U" to the CAs, and then Microsoft and Google followed Apple's lead, forcing the CAs to follow regardless of the outcome of the vote.
Re:Bitterly my ass (Score:5, Insightful)
Re:Bitterly my ass (Score:5, Insightful)
Frankly, it's the security implications of automating renewals that has me worried about this move. The mechanisms to do that will inevitably be ad-hoc and sloppily implemented, totally ignoring any standards. (And in some cases ignoring the standards will be justified because the standards aren't always friendly to every possible scenario)
Anyway, most of the equipment I work on will require manual intervention to renew certificates for the forseeable future. That's job security... I guess... as if I didn't have enough to do already.
Re: (Score:2)
Aye, PKI is a massive shit show right now and many vendors have very cumbersome methods for configure Certs on their devices. Many even require restarts forcing a service outage.
But you are right... it is job security! It's the one thing that is great from all the big players... guaranteed to fail!
Re:Bitterly my ass (Score:5, Insightful)
The pressure here is on cert prices, which has been steadily downward for years, accelerating with the advent of Let's Encrypt!
20 years ago, certificates were priced like information assets, with expected enterprise lifetime duty-cycles.
In fact, they are not assets, but merely technology artifacts. As the relevant infrastructure for validating a certificate became more horizontal with pure infrastructure uses, and the explosion of mobile handsets, the large cert authorities watched revenue drop, and became absorbed into companies like Symantec and Gemalto.
The entire system can be automated better, including renewals of expiration, etc. The existing cert management lifecyle is TERRIBLE! Anyone doing infosec recon can bring you lists of thousands of expired certs, self-signed certs that offer no real validation, and all of these with obsolete, weakened cypher suites.
Crappy ISO protocols and ASN.1 notation prevent these from changing as rapidly as they should have - as these are brittle, unforgiving technologies compared to IETF, etc. But the real issue is BUSINESS, not technology, and certificates should have a cost lower than domain names - a tiny fraction of this, really.
Then they should be renewed quarterly, or better, squashing the existing threat models.
Re: (Score:3)
AWS and Azure and Google automate manage SSL certificates, at no cost, securely. So this change creates no new work or cost for their customers. Setting up cert management isn't much more work than manually installing a cert, and you never have to do it again, which is what every company I've been at for many years has done.
It's a minor hassle for companies that run dedicated servers that for some reason manage cert's manually, and don't use any of the certificate management tools to automate renewals. But,
Re: (Score:3)
Re: (Score:2)
Let's Encrypt gives free certs to anyone and all the LE tools are built around automation.
Re: (Score:2)
Re: (Score:3)
why not automate?
A) because your 3rd party devices do not support it
and
B) because you have not had time to analyze the automation system's security guarantees and do not trust it.
Re:Bitterly my ass (Score:4)
Just because something is automated doesn't mean its more secure. It just changes the attack surfaces.
Without a sea change in the way the internet trust model is designed, we're just rearranging deck chairs. But hey, it keeps people busy, so there's that.
Re:Bitterly my ass (Score:5, Insightful)
Those of us who have experienced almost nonstop problems caused by automation of certificates should also have a vote. The entire notion that sites are somehow more secure because some ostensibly trusted authority has performed an entirely superfluous automated check within the last year is silly and nonsensical. None of this adds security. It just adds fragility.
The theory behind it is that somehow a major site will get its cert and private key stolen, and people will be able to impersonate it. The problem is, even at a year, the risk is still huge. Heck, even if you lower the maximum expiration period to a month, the risk is still huge. Trying to solve the problem of stolen keys through reissuing certificates is exactly like trying to solve the problem of stolen passwords through password expiry — a practice that security researchers almost universally agree is a bad idea.
And it isn't even necessary. The problem that they are trying to solve is precisely what CRLs are designed to solve. If browsers aren't checking to see if certificates are revoked before accepting them, that's the fault of the browser. And if browsers are blocked from checking the revocation status because of a network configuration issue, the network should be considered suspect, and every single site should show a certificate warning.
The only real effects of constantly changing certs are:
It costs webmasters time, money, and lost hair, and does not improve security meaningfully at all.
Making it even more ironic is the fact that the web server configuration in Apple's own Server software is the worst offender. I have fought harder to make certificate updates work reliably with Server.app than I have with all of the configuration issues in all of the other server software I've used in my entire life put together. Don't get me started on that mess. Storing the keys in the keychain seems like a good idea until you actually realize that the keychain is massively asynchronous, and storing things doesn't always "take" immediately. It goes downhill from there.
Re: (Score:2)
None of this is the case for customers of AWS, Azure or Google. It might be true for people still running their own data centers.
Re:Bitterly my ass (Score:5, Insightful)
So what you're saying is that only big companies with large budgets should be on the internet. Glad we cleared that up.
Re: (Score:2)
The problem that they are trying to solve is precisely what CRLs are designed to solve.
Expiration is necessary to trim the CRL, instead of having it grow forever.
A longer duration would probably be better - perhaps 5 or 10 years - but it has to be balanced against the rate that revocations are done.
Re: (Score:2)
Each CA cert potentially has its own CRL URL, so the CRL size can be limited just as easily by using a deeper chain of signing certs, so that each CA cert is used to sign fewer certificates.
Re: (Score:3, Informative)
Automating certificate renewals kind of defeats the entire point of having a verified chain of trust.
How that isn't obvious to anyone with a functional cerebral cortex is quite frankly beyond me.
Re: (Score:2)
The automation opens up a backdoor. The auto scripts for lets encrypt download a shell script that is assumed not to backdoor your server but how many millions of servers don't check what was downloaded and just run it as root?
I wonder how Apple is planning on rolling in cert renewal to their walled garden to take a 30% cut on random numbers.
Re:Bitterly my ass (Score:5, Insightful)
Right do you want to explain to me how to automate the updating of web certificates on a few thousand lights out management controllers on my HPC system? Noting that none of the vendors provide a good method for doing this and there may be more than one vendors equipment in my cluster.
The old way was to have a private CA, issue a certificate that took you to end of the support contract plus say six months to allow of decommissioning, install the certificate on the nodes and forget about it. Other than adding your root certificate to the list of CA's on any machine accessing the lights out management controllers.
Now thanks to the shits at Apple I have a fucking nightmare every 12 months. Bunch of entitled assholes that never seem to have had to deal with anything other than looking after their own personal workstation so have no fucking clue.
I would note the same goes for systemd developers. For example at one point Pottering proposed having all your processes being killed if you logged out, include those running under screen/tmux or simply nohup. Then there is the fact when I start a service with systemctl I then have to run another command to see if it actually started, where as both Debian and RHEL scripts would fecking tell me right there and then.
The whole lot of them need a dam good thrashing with a clue stick.
Re: (Score:3)
Now thanks to the shits at Apple I have a fucking nightmare every 12 months. Bunch of entitled assholes that never seem to have had to deal with anything other than looking after their own personal workstation so have no fucking clue.
My understanding is this only applied to public certificate systems, private PKI infrastructures were exempted. I know that my current mac (and idevices) aren't bitching about 2+ year certificates issued by my internal CA.
Re: (Score:2)
The Apple system is still broken since if you add a exemption for a cert, it is forever, not just the current session. For a company that can't even get simple TLS right, I wonder how valid any of their security claims are.
Re: (Score:2)
Conversely, I would say that the exemption should be forever or until it changes. I have a bunch of old gear that has self-signed certificates. I just want to know if that certificate were to suddenly change.
Re: (Score:2, Informative)
Last I checked, this 398d restriction only applied to the commercial CAs. The ones they supply with the browser. Your own, internal CAs were exempt.
Re:Probably best ... (Score:2)
I worked for a large tech company that routinely lost track of their multi-year certs and suffered embarrassing consequences. You would think people would learn but dysfunctional corporate culture and uncommunicative organization has an inertia that inevitably leads to problems. On the other hand, most things that could be coded into annual operational budgets in SAP got handled routinely and without issue.
Also good to check in at least annually so knowledge of the cert still exists and hasn't disappea
Re: (Score:2)
Well, let's just note that You and I, the people actually affected by the security implications of this, don't get a vote at all. Also Apple's reasoning, that this will be more secure and encourage automation, seems pretty reasonable.
Is there any evidence at all in the public domain to support the more secure premise? Were any surveys or studies conducted? Is there a single peer reviewed paper written on the subject in existence?
Re: (Score:3)
CAs were making money doing nothing by selling longer-term CAs. Now they actually have to do something to make money.
Re: (Score:2)
And what exactly are they doing? Signing more CSRs with less time on the expiration? If they haven't figured out how to scale a web frontend yet, they have no business being a trusted CA.
Re: (Score:2)
Three years is bad, because people have forgotten, and it's still enough in use to cause real damage.
Re: (Score:3)
Uh no. It means there will be more competition every year. They will have to charge less and then win business every year -- people know what the cost is. Makes it harder for them in front of investors too.
Re: (Score:3)
The various MSPs and web hosting/design/consultancy/general fixer operations are the ones that are presumably going to either be praising or cursing this depending on how well they are able to charge a call-out fee for servic
Re: (Score:3)
Yeah, if I have to go through dealing with a CA's bullshit every year, it turns out it's less of a waste of my time to automate certificate renewal and delivery to all my servers using LetsEncrypt and our configuration management system.
Fuck em.
Re: (Score:3)
That's kind of the point. If you are going to age-limit a cert, you might as well do it with a value that will force automation and require vendors to provide a simple, restart-free mechanism for automating cert updates. Set it to 72 hours and 100% of servers will come with some kind of certificate replacement automation script. 1 year accomplishes nothing. Lazy admins will still do it manually, just more frequently, and it will continue to be a PITA.
Ok, so dumb question (Score:5, Interesting)
Are shorter certificate expirations better or worse? Is a year and a quarter something like a sweet spot?
Re:Ok, so dumb question (Score:4)
Sometimes certificates get revoked. Browsers have a revocation list of such certificates, so they won't accept them.
As can be found in the article, certificate revocation lists are not that nice to handle, and the revocation process isn't ideal either
Shorter certificate lifespans means shorter certificate revocation lists (all certificates that already expired anyway can be dropped from the list of revoced ones.
From the browser perspective the ideal is certificates that expire so quickly that no revocation list would be needed anymore. That probably would mean certificates that only last for a few hours.
Re: (Score:3)
Re: (Score:3)
It also means your sites will be down constantly for reloading their configuration because the certs changed. Every rekey can mean a minute of downtime.
Re: (Score:2)
Re: (Score:2)
Great. Glad you've found a solution to the problem. Please explain how to change Apache's cert in a way that doesn't involve reloading its configuration so that the rest of us will benefit, too.
Re: (Score:2)
Why? Doesn't everyone terminate SSL in their load balancer? And rotating certs shouldn't require you to reboot anything or have any user outage...
Re: (Score:2)
Re: (Score:2)
Not everybody HAS a load balancer. For enterprise-scale sites, sure, but those sorts of sites don't care at all this anyway, because they have a team of people responsible for making sure everything stays up and running. For the startup running its web server on a Linux box in a broom closet, not so much.
Re: (Score:2)
Why? Doesn't everyone terminate SSL in their load balancer?
HELL NO. This only increases the attack surface of the system for no reason.
Re: (Score:2)
Sometimes certificates get revoked. Browsers have a revocation list of such certificates, so they won't accept them.
No they don't. They have a list of high profile blunders. The rest (vast majority entirely administrative **non-security** related) are communicated via online query schemes.
As can be found in the article, certificate revocation lists are not that nice to handle, and the revocation process isn't ideal either
Maybe people should spend their time fixing the actual problem instead of creating Band-Aids with ridiculous security properties. Hey sorry bud you can only exploit this certificate for a whole year because revocation doesn't work and nobody feels like fixing it.
Does this make any sense?
Shorter certificate lifespans means shorter certificate revocation lists (all certificates that already expired anyway can be dropped from the list of revoced ones.
Who cares? Why does it matter how long a list
Re: (Score:2)
Better. Almost all certificate renewals from a modern CA can be automated, old certificates get cycled out, new ones get cycled in. Apple's not actually the bad guy in this fight, in my opinion.
Also from my point of view, there's lower impact to the overall chain if an intermediate or root certificate is invalidated or worse, compromised, because while the number of issued certificates are higher, the process is more frequent.
I'd guess (but don't know) much of the pushback is from the older CAs that have no
Re: Ok, so dumb question (Score:2)
The only thing Let's Encrypt certs prove is that the same person in control of the website and the DNS. Those EV and other more vetted certs also prove WHO is in control.
Re: (Score:3, Informative)
No they don't. There is zero proof of who is in control. Sure EV certs (Extended Validation) require a few extra hoops to get but they are just a faulty as any other poorly managed PKI.
Until you know for a fact that a Public/Commercial CA has solid practices in place for monitoring their Certificates in the wild no one know that one is compromised until it is found out that hard way!
Consider the following stories.
https://www.techrepublic.com/b... [techrepublic.com]
We know of lots of compromises... just imaging how many ther
Re: (Score:3)
I'm just waiting for the first compromise that leverages an insecure auto-renewal process.
The industry might then realize that nothing really needs to be done to the rest of the system, and that verified key exchange is the hardest part of crypto... always has been, and always will be.
What? No, I kid. They'll just pile more floors on the house of cards.
Re: (Score:3)
Nice to read another informed post on the subject. Yea, working out "secure" auto-renewals is a big deal... which is why its mostly not done.
Yea, and this article is just one example of what you say about that house of cards.
A 1-year cert is every bit as safe and secure as a 50-year cert. They are secure until they are compromised. Validity periods are only for making Revocation easier to manage and nothing else!
Re: (Score:2)
Yea, working out "secure" auto-renewals is a big deal... which is why its mostly not done.
I wonder how many of these auto-renewal schemes actually rotate the privkey on the supplicant. Used to be
that the certificate would be set to expire when you estimated they privkey had been used to sign enough
material that it had increased its risk of being discovered. If they are renewing without demanding a new key be
generated, then we could have a lot of very stale privkeys left lying around as a result of this automation. Not to
say that pubic CAs demand new keys unless the acceptable key size or algo
Re: (Score:2)
Yes, they are the bad guy in this fight. There is no "Technically Valid" reason to force a time limit this short.
People may give you some tripe about CRL, but lets be honest.... if you have so many certs being revoked from your organization due to compromise that you need a long CRL then your Root needs revocation and at that point you don't need a fucking massive CRL you just put the root on the CRL and all of it's children die. But as Comodo has proven... the industry will leave consumers compromised an
Re: (Score:2)
Apple's not actually the bad guy in this fight, in my opinion.
HERETIC!! BURN HIM!!!
Re: (Score:2)
I remember when this was the response to anything that didn't toe the party line that M$ was evil.
Apple is the new M$ ... HERETIC!!!!
Re:Ok, so dumb question (Score:4, Insightful)
Certificate Validity dates are very much dependent on the situation. And there is nothing inherently wrong with "short" or "long" validity dates. If anyone tells you otherwise you are talking to a moron. It really depends on the situation.
That said, It generally is a good idea to avoid lengthy certificate validity dates for public websites due to how Validity and Certificate Revocation works. However there are more uses for certificates than just web based encryption. There are numerous types of certificates along with certificates that can be custom designed to do things that are not common.,
https://en.wikipedia.org/wiki/... [wikipedia.org]
Certificate validity dates are usually kept short as a "security" mechanism but it is more "theater" than actual security. Without getting too technical, managing PKI is not an easy feat. Often times it is a burdensome process and many people resort to longer validity dates to save themselves some grief.
Which brings us to this current theme. If the systems handling PKI where better and easier to manager and of course not currently a racket then shorter time frames would be less troublesome to implement.
Right now... like everything else it is more politics and "MONEY" than anything else.
Today's PKI infrastructure is mostly a crowd funded racket where you work out a deal with Microsoft, Google, & Apple to get your root certs onto their devices so the certificates that you create are "trusted" and you get to force people to "buy" your trust.
A lot of people do not know it, but businesses can wind up paying a lot of money and occasionally $1,000 or more for some certificates. There is no certificate that should ever be worth a freaking grand but you gotta pay to play which is what makes it a scam, despite certs not being that bad of an idea themselves. Sure the cost of Certs have changed a lot, especially after lets encrypt but they are very much in use in other areas for Rent-Seeking by many companies.
Just take Microsoft Code Singning certs... where they can force you to buy a cert for your application or their Malware system will flag your application as a virus. This is not just for MS, its for console and other plaforms.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Just imagine having to constantly buy certs from everyone for their various devices so that you can avoid having an application you produced being false positive ID'd as malware.
For not this is mainly against Websites, but there will always be more to come.
Re: (Score:2)
It's more a year + 1 month.
I think so. The longer a cert lasts, the longer that an undetected compromise can cause issues.
On the other hand, with longer cert terms, people tend to forget - even for major sites. Having a specific date for all certs to be replaced, roughly a month before it expires, on an annual basis, is actually less likely to be forgotten.
The extra month(and a bit of change) gives time in case a problem crops up.
Re:Ok, so dumb question (Score:4, Insightful)
"The longer a cert lasts, the longer that an undetected compromise can cause issues."
Immaterial, That is still an entire year when a compromise can be completed anywhere from days to minutes. So unless you are going for certs that last less than 1 hour, this entire argument is a pointless one.
"On the other hand, with longer cert terms, people tend to forget - even for major sites. Having a specific date for all certs to be replaced, roughly a month before it expires, on an annual basis, is actually less likely to be forgotten."
A problem for them to solve as a business not for Apple or you.
"The extra month(and a bit of change) gives time in case a problem crops up."
See my first point... time frames this big are pointless in the context of security... there just is no security argument for it at all... not a single IOTA.
SSL Certs are MOST important for 1 thing... "encryption" and that can happen effectively whether the certificate is expired or if it is trusted or not. It will still do it's job... and as long as it has not been compromised it's fucking secure!
Re: (Score:2)
I think so. The longer a cert lasts, the longer that an undetected compromise can cause issues.
Absolutely not. Private keys never expire. If a cert lasts shorter and the compromise is undetected there is no reason to believe that it would not persist with the new key in place.
On the other hand, with longer cert terms, people tend to forget - even for major sites. Having a specific date for all certs to be replaced, roughly a month before it expires, on an annual basis, is actually less likely to be forgotten.
It's a waste of time and money. If you give a fuck about "security" advocate for better revocation mechanisms.
Re: (Score:3)
Depends on if you have dependable automation for deploying those certificates everywhere they need to be or not.
If you don't, a shorter expiration is a massive pain in the ass. If you do, then it's a once-a-year annoyance that takes an hour or less.
Re: (Score:2)
Are shorter certificate expirations better or worse?
It isn't so much "better" or "worse". They're generally more secure, and generally less convenient to set up.
The shorter the lifespan, the less time a hacker has before the cert is useless to them. Shrink it far enough (e.g. less than an hour) and it'd make it really hard for a hacker to actually grab the cert and turn around something malicious that uses it. That said, you can't make the lifespan that short without automating the process of distributing certs, but automated systems aren't particularly comm
If CAs don't like it (Score:2)
Maybe they should've done a better job putting their own houses in order.
Re: (Score:2)
Maybe they should've done a better job putting their own houses in order.
Is anyone reading this supposed to understand what it is you are even referring to?
Replacement Browser (Score:2)
They should allow other companies to replace their continually behind browser on iOS, and actually benefit their users.
Re: (Score:2)
Error:All other phones come bundled with Google spyware.
To clarify... (Score:4, Insightful)
Current 2 year certs will continue to be accepted, you just won't be able to issue new 2 years certs come September.
LetsEncrypt just got moved up my priority list a little bit.
So when the cert goes kaput as they so often do (Score:2)
do we have a way of ignoring it and seeing the page anyway?
Are the certs just something like domains that the FBI can seize?
This whole HTTPS thing is about control, tracking, etc, not security.
Re: (Score:3)
do we have a way of ignoring it and seeing the page anyway?
Are the certs just something like domains that the FBI can seize?
This whole HTTPS thing is about control, tracking, etc, not security.
So you have no idea what it is or how it works, but you're sure the purpose of it is not security.
The truth is, Apple made this change because unlike the CAs, they do actually care about security, and this makes browsers more secure, and makes it when a CA gets compromised, that doesn't cause problems for 3,4, 5 years to come.
Re: (Score:2)
When a CA gets compromised, everything they have issued under the compromised signing cert becomes untrustworthy. The duration of the expiration of the signed certificates is moot. And no, this does not make browsers more secure.
Re: (Score:2)
So you have no idea what it is or how it works, but you're sure the purpose of it is not security.
Seems contagious.
The truth is, Apple made this change because unlike the CAs, they do actually care about security, and this makes browsers more secure, and makes it when a CA gets compromised, that doesn't cause problems for 3,4, 5 years to come.
Nobody is talking about CAs getting compromised. Apple's validity restrictions do not apply to CAs.
Re: (Score:2)
Certs are not "just a different kind of cookie". You clearly do not know what Certs are for.
But you are right that this is a weak band-aid.
And the other poster is wrong that Apple cares more about security. They care about the same as all of the others and they believe in security theater more than actual security, just like all of the others.
Re: (Score:2)
Lol, sorry cat is out of the bag for you.
Certs themselves are not security theater, even if the industry around them is. A very important distinction to make!
Re: So when the cert goes kaput as they so often d (Score:2)
Yes, you click through the browser warning. Everything's still encrypted; nothing stops working.
Re: (Score:3)
Then someone comes along and says "users are getting into the habit of clicking through cert warnings" and starts to prevent them from doing it. Has happened before, will happen again.
Re: (Score:2)
Hey look, you have exactly zero clues about a foundational technology on the Internet that has literally been around for decades. Thanks for posting.
Re: (Score:2)
Lots of flawed ideas have been around for decades. If they work for most people they'll be around for many more decades. And certs are hardly fundamental. They are simply "good enough"... for most people, so they stop looking for anything better.
Certs are for more than browsers... (Score:2)
Certs have more uses than attesting to the browser that the bank website you connected to is really the bank and not some bogus server. For example, what about IPsec tunnels? Does this limit by Apple on Browser certs also mean that as an artifact of everyone shortening the lifespan of CA Certs in the browsers, I will not be able to buy certs with longer lifespans for other uses? If I am running a service that is effectively "air-gapped" behind an IPsec server, updating certs can be a little painful, dependi
Re: Certs are for more than browsers... (Score:2)
With IPSec, you're generally in control of both the clients and servers, right? You can just install your own root cert.
Re: (Score:2)
I do, usually. But I have a few servers where the client absolutely insists on a "publicly trusted cert" although they clearly have no understanding of what they are demanding. In these cases, I must run a public cert. So this is why I ask.
But the question of whether this is merely a browser thing, or the Apple IPsec client will also attempt to enforce is mainly what's on my mind. At the moment it does not seem to be an issue, I mainly worry that it will change.
Re: (Score:2)
This rule change by Apple looks to be in the Browser, but you can bet CA's will more than likely just move all their certs to the same time frame because it will likely net them more money.
If you are using IPsec that will not allow you to use a "self-signed" certificate... use another. There is no good reason to require use of a public CA for IPsec. And often times there is almost no reason to use a Public CA other than for being "lazy" purposes for IPsec
Re: (Score:3)
As I imperfectly explained, the demand for a public cert comes from an ignorant customer who insists they must use a "publicly trusted cert" due to "policy" and is clueless about the technology.
Rule #1: The customer is always right
Rule #2: When the customer is wrong, see rule #1
Rule #3: When the customer is stupid, see rule #1
In short, the reason for a public cert has nothing to do with reason, good or otherwise, and little to do with being lazy, or using it for IPsec, or even whether either the client or t
Re: (Score:3, Interesting)
With IPSec, you're generally in control of both the clients and servers, right?
"Usually" only for some use cases. You can in fact have IPSec arrangements that rely on PKI to establish trust between independently operated entities.
But it's not just IPSec. A lot of non-HTTPS internal server communications are TLS-secured, and those certs never get seen by the public. Changing them once annually is extra workload since they often involve systems that don't communicate on the open Internet, and automating the renewal process puts unwanted extra potential security holes into those syste
Re: (Score:2)
For any use other than public website verification, does anyone purchase a cert as opposed to use their own whitelisted certs or internal architecture?
Enough already (Score:5, Insightful)
The shorter expiration is all based on the utter failure to properly implement certificate revocation and the idea that theft of web server certs is a problem.
I can't seem to find any reports of an incident where a cert for a web server was stolen. I see some where other certs for things like drivers have been stolen, and even a 9 year old case where a CA's signing cert was stolen (since that allows forging certs at will, expiration of web certs won't help that one).
This is similar to rejecting self-signed certs on low value sites where a kid with photoshop could easily trick a CA into issuing a cert anyway.
Meanwhile, all the signed certs actually tell you is that company you've never heard of assures you other company you've never heard of is actually company you've never heard of.
There seems to be about a zillion CA's your browser will trust. Any one of them can wrongly issue a cert for any site that your browser will trust without question. At least one was infamously compromised and issued a bunch of fraudulent new certs. Even under the new expiration, that would give the bad guys "only" a year to impersonate your bank.
The browsers and standards have even studiously avoided the mechanism that could tell you the web site you are visiting is the same one you visited last week.
True story, wayyyyyy back in 1995, when all of this was being rolled out, I spoke to a representative of Verisign and asked "How do you verify that the person you are issuing a cert to isn't fraudulently claiming that they own the domain?". His answer "They sign an agreement that they won't commit fraud".
Re:Enough already (Score:5, Insightful)
Which is why Let's Encrypt is great. Certs don't tell us anything about the safety of the website. The only thing Certs do is ensure the connection is secure to the website you're visiting.
People have criticized Let's Encrypt for offering https certs to phishing sites but those critics completely ignore the fact that https certs never have meant the site is safe, just that you connected to the address in the address bar.
Re:Enough already (Score:5, Informative)
This needs modding up!
A lot of people misunderstand what Certs are for.
There are 2 pieces of security that Certificates perform.
#1. Verification of the Domain you are visiting. No CA should ever issue a Certificate for Microsoft.com to anyone other than of course... Microsoft.
#2. Encryption of the connection from your computer (browser) to the Website.
It has nothing to do with how safe a website is to visit at all.
The car equivalent would be... a Cert is like having an Armed Escort that you can call that will take you from your front door to the front door of Costco... but they do not enter the front with you... they stay outside... after that you are at the mercy of Costco's security and if they have been compromised by a 3rd party. If you make it back out of the store intact that security escort gets you safely back to your front door... where again... if your house is compromised... they don't help with that either. They are only good for getting you to Costco Only from your front door to theirs and nothing else. They don't detour or accept interference!
Re: (Score:2)
Which is why Let's Encrypt is great. Certs don't tell us anything about the safety of the website. The only thing Certs do is ensure the connection is secure to the website you're visiting.
Actually, they do a little bit more than that. In the case of "domain validated" certificates, the applicant must demonstrate that they have some level of control over the domain in question. This could be done through creating a special record in the DNS zone for that domain, or by hosting a special file on a webserver within the domain. (The latter method is particularly simple to use with Let's Encrypt, where clients like win-acme [github.com] can serve the file from memory as required during validation).
Is this type
Re: (Score:2)
Of course, that introduces another problem (but only because of anally retentive browsers).
If I have a device that presents an https interface, Let's Encrypt won't work. It is one of many, I don't know what it's address will be and it doesn't have a fixed public domain name at all. At most, it announces it's own hostname over mDNS. Firmware updates in themselves present a security risk.
It's time to stop waving flaming hoops at people and demanding they jump through and start actually coming up with decent
Re: (Score:2)
Of course, that introduces another problem (but only because of anally retentive browsers).
If I have a device that presents an https interface, Let's Encrypt won't work. It is one of many, I don't know what it's address will be and it doesn't have a fixed public domain name at all.
If your device doesn't have a public domain name, then a CA-signed certificate is not for you. You're probably left having to configure your client to trust whatever certificate is installed on the device.
Re: (Score:2)
Yes, and I don't object to that, but the damned browsers are making it harder and harder to do that.
Re: (Score:2)
Re: (Score:2)
Which is why Let's Encrypt is great. Certs don't tell us anything about the safety of the website. The only thing Certs do is ensure the connection is secure to the website you're visiting.
People have criticized Let's Encrypt for offering https certs to phishing sites but those critics completely ignore the fact that https certs never have meant the site is safe, just that you connected to the address in the address bar.
That is true, but giving phishing and malware sites an easy and free source of trusted certs means that I HAVE to run a forward proxy at the firewall to decrypt and inspect that traffic. That means breaking SSL security at the network perimeter and causing all sorts of problems.
It's getting ridiculous (Score:3)
The browser makers should just implement DANE [wikipedia.org] and end the pointless CA middlemen system. Side benefit: DANE requires DNSSEC, so that would be used more and help against DNS spoofing. Will they do it? No, they got invested in the CA scheme by all but monopolizing trust on the web through Let's Encrypt.
Re: (Score:2)
The browser makers should just implement DANE and end the pointless CA middlemen system. Side benefit: DANE requires DNSSEC, so that would be used more and help against DNS spoofing. Will they do it? No, they got invested in the CA scheme by all but monopolizing trust on the web through Let's Encrypt.
The registrars should just hand out certs as a basic part of domain ownership.
Otherwise DNS transport issues need to be solved and widely deployed before DNSSEC is.
One side benefit of this... (Score:2)
Re: (Score:2)
I can assure you the yearly cadence isn't any better for support.
"Yeah the admin who did this last year isn't with us, I don't know where the private key is."
Re: (Score:2)
One side benefit of this is with certs expiring every year, it should mean some orgs will be more aware of certs they have and when they are expiring. Can't count the number of "emergency" calls I've gotten over the years from customers who's multi-year certs expired and they have forgotten about them and needed help updating the certs on their systems so users could log in. Maybe a yearly cadence will mean a bit less of that type of fire drill.
A problem easily solved with a calendar. For much of the world (whom didn't call you) it just means more time wasted for no reason.
They should operate like Let's Encrypt (Score:2)
They may have to operate as Let's Encrypt does, using certbot to auto-renew the TLS cert when it gets close to expiry. Let's encrypt certs are only good for 90 days, but since they auto-renew by script it is all good. The big CA's could auto-renew yearly and do a more comprehensive audit at whatever intervals they see fit. They would not have to change how much they charge as far as I can see.
One thing that puzzles me. With OCSP and OCSP stapling, why was it so difficult for CA's to revoke in a timely fashi
Re: (Score:2)
If you can convince OS and browser makers to add your CA to the list of trusted root CAs, then go nuts.
Re: (Score:3)
Not required. DNSSEC coupled with distributing SSL keys or denoting trusted private CAs in DNS would do the job. It would be more sane than expecting all of the hundreds of trusted root CAs out there to remain uncompromised.
Re: (Score:2)
You do if you don't want every browser outside of your control throwing certificate trust errors.
Re: (Score:2)
If you can securely configure all your clients with a CA, it's a viable option for securing intranet-only services and server-to-server communications.
Does not help with any service you intend to offer to the public or clients which you cannot onboard, though.