Re: it's all about trust [was: Firefox and HMC self-signed cert]
On 8/29/23 6:10 PM, Charles Mills wrote: Not browser publishers and CAs; ONE particular browser publisher! The CAs were on the other side of this one. Apple may have been the first to the microphone, but I know that other browser manufacturers were writing similar speeches. About the only thing I can say in their defense is that the revocation system is broken. On a technical level, I don't know that I agree with that. I believe that there were things in place that someone that wanted to could have checked revocation. Sadly, too many people -- probably the vast majority -- didn't do so for one reason or another. This might even partially be the tyranny of the default. I think most, if not all, browsers opted to forego much of the revocation check in the name of performance and page load time. Most people didn't know better, and most of those that did didn't know enough or weren't motivated to change it. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: it's all about trust [was: Firefox and HMC self-signed cert]
Not browser publishers and CAs; ONE particular browser publisher! The CAs were on the other side of this one. https://www.zdnet.com/article/apple-strong-arms-entire-ca-industry-into-one-year-certificate-lifespans/ About the only thing I can say in their defense is that the revocation system is broken. Charles On Tue, 29 Aug 2023 17:58:50 -0500, Grant Taylor wrote: >On 8/29/23 2:49 PM, Rick Troth wrote: >> When they say "certificates shall only last a year", there's little we >> can do about it, whether they're right or wrong. > >The browser manufacturers have power in the browser ecosystem and the >ecosystems that pander to them (*cough* CAs *couth*). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: it's all about trust [was: Firefox and HMC self-signed cert]
On 8/29/23 2:49 PM, Rick Troth wrote: When they say "certificates shall only last a year", there's little we can do about it, whether they're right or wrong. The browser manufacturers have power in the browser ecosystem and the ecosystems that pander to them (*cough* CAs *couth*). But browser manufacturers have exceedingly little say in how I configure TLS on my email server. Crypto alone doesn't make your systems secure. Faster refresh does not improve your posture all by itself. I believe the faster refresh is all about shortening the exposure window. If the CA is breached, then the issued certs are just as invalid on day one as they are on day 398. In that case, what has the shortened lifetime bought us? Recent history (last 10-20 years) has demonstrated that not enough people update their system (think software updates, not hardware upgrades) nearly as often as they should. As such, these people don't get the updates wherein the compromised root cert / public key therein is distrusted / banned. So, many in the industry are responding by shortening the natural lifetime of such certificates. Shortening the lifetime of a certificate does shorten the possible amount of time when that given compromised certificate can be used against people that updated to learn to not trust it. This is not to say that fast cycle advocates are idiots. Most of them are prolly way smarter than I am. It's just that they stopped short of solving the real problem. (And some of them are opportunists: if they can get you to buy their wares in a panic, then they've made a pretty penny and can retire sooner.) There have been at least three major attempts to convey that certificates should be distrusted before their expiration: - Certificate Revocation Lists (CRL) -- Client checks remote data - Online Certificate Status Protocol (OCSP) -- Client checks remote data - OCSP Stapling -- Server fetches remote data, hands it to the client, client check verifiable data it was handed. Sadly, all three of these have left more exposure than people are comfortable with. So, rather than trying to deal with early distrust of certificates, the Certificate Authority / Browser Forum (CA/B Forum) has decided to tackle things differently by shortening the possible exposure window. I almost regret this note because I haven't really offered a solution. Lots of really smart people have put forth multiple solutions. Some were widely deployed. Most were not as successful as many had hoped. Some say "security is a process". I hate that slogan, but it's kinda true. I DO say that we're foolish to try and shrink-wrap security into store-shelf remedies. There's no alternative to educating the staff. -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
it's all about trust [was: Firefox and HMC self-signed cert]
On 8/29/23 11:24, Grant Taylor wrote: On 8/29/23 10:07 AM, Tom Brennan wrote: And you can specify an expiration far in the future. Remember, some web browsers are capping the limit on the lifetime of certificates they will work with. The browser producers have the advantage over the rest of us because they affect such a large percentage of consumer clients. When they say "certificates shall only last a year", there's little we can do about it, whether they're right or wrong. They're wrong. They're at least "imperfect" in a conversation where perfection is the goal. So ... they're wrong. Shortening the viability lifetime brings hidden costs that the browser makers either don't see or don't care about. (Covering their own arse. They have no incentive to cover yours.) By contrast, physical indicia (credit cards, driver licenses, and other IDs that some of us cannot speak about) have lifetimes/expirations five years out. Shorter lifetimes for web site certs generate business for CAs and make work for web site admins. The latter is increasingly error prone. But higher frequency replacement is considered "more secure". It's like killing the dogs and cats during the plague, when they were the natural enemies of the true carriers of the disease. We protect the wrong things. (And we kill the wrong critters.) We also sprinkle such ideas as faster cert replacement and technology like cryptography as if it's fairy dust magically making things better. Crypto alone doesn't make your systems secure. Faster refresh does not improve your posture all by itself. Charles suggested snagging the private key from the CA. That's exactly the kind of attack a smart adversary would take. It's way less expensive and more likely to result in exfiltration of cleartext. If the CA is breached, then the issued certs are just as invalid on day one as they are on day 398. In that case, what has the shortened lifetime bought us? This is not to say that fast cycle advocates are idiots. Most of them are prolly way smarter than I am. It's just that they stopped short of solving the real problem. (And some of them are opportunists: if they can get you to buy their wares in a panic, then they've made a pretty penny and can retire sooner.) I almost regret this note because I haven't really offered a solution. Some say "security is a process". I hate that slogan, but it's kinda true. I DO say that we're foolish to try and shrink-wrap security into store-shelf remedies. There's no alternative to educating the staff. -- R; <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
