Having perfectly functional devices that become obsolete because the world moves around them is also not a good system. We don't have to design our support targets to be a moving window of >= $current_version - 2.
Arguing with time's arrow is fruitless. The world will change, it isn't going to wait around for your OK.
For the most part we aren't talking about needless turnover here. The trust store represents an institutional claim, between now and whenever you stop using this device, all the people who have these private keys will take proper care of them. I actually think that claim is extremely dubious for these Android devices today, it relies on people we meanwhile judged as incompetent to have nevertheless correctly destroyed key materials in their possession when they ceased to do business. I would not be astonished to discover that this already did not happen at least once since the devices ceased to get updates.
For example I imagine all the Symantec roots are included, and likewise StartCom/ WoSign.
My dad had to replace his working but older Motorola phone because MMS stopped working because of outdated certs and he couldn't update anything to get them working again.
This is kinda silly. These are problems that, as an industry, we make for ourselves. The fact that you can't make a network connected device that continues to function for decades without a constant maintenance is a problem not a feature.
Sure you can. Make an application that is frozen from future features but can still communicate with the platform at a basic level. Text Messages have been with us for centuries and still compatible with nearly 99% of devices.
Feature updates normally consist of "your device isn't supported and lock the user out without saying Good Bye.
If you create a platform that holds the basic for all versions and don't introduce new features to that; you won't have so much e-waste nor much maintenance upkeep.
To a point. The environmental footprint of a 486 tower system today would be much higher than modern system because the humans that use it more slowly and who have to maintain it use a lot more resources.
Given lightweight software, a 486 tower is usable indefinitely with a zero environmental footprint as long as the electricity comes from a sustainable source (such as solar).
It is as long as you don’t consider the footprint of the person using it. If it runs more slowly than a modern system such that a human has to spend more time working with it, then it’s almost certainly less resource friendly.
486s ran plenty fast in their time. With a tiny bit of modern hardware like the addition of an SSD, the only thing stopping them from being blazing-fast is modern bloated software stacks.
I suppose that's lowering your carbon footprint in a sense of the word, but only because you've pushed the carbon production onto someone else (ie, those people are still out there in the world.)
I'm also not very convinced on the premise. Unless you're doing something fairly specialized (scientific modeling, compiling) or your software is unduly bloated (which a lot of software is, but that is its own problem), the difference in speed really shouldn't add up to that much.
"In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail"
All current FIPS accredited devices use openssl 1.0.X, so the lets encrypt cross-signing hack will essentially break multiple corporate networks until the next openssl fips module is released at the end of this year. And could take another 6 months to make it into live systems
My experience with HW HSMs has been that the FIPS process is so expensive that companies are only willing to put out a new FIPS-certified version once year. Also the certification itself seems to be more concerned with high-level security requirements rather than proof that any particular features of your HSM work correctly.
So the answer to any particular bug is typically wait until next year's version which includes all bug fixes that the normal releases have built up over the past year, or re-evaluate if you really need the certification.
This is a great start. More or less all web sites are technically non-compliant with Australian government security standards (ISM) because TLS has diverged so widely from NIST and those standards dictate NIST approved cryptography.
Nobody cares, of course, but it causes pointless conversations and wasted time with auditors.
I'm just pointing it out because I once confidently stated that Curve25519 illustrates everything that is wrong with FIPS, which would, on principle, never accept it, and was thoroughly served with the existence of this document. :)
I just want to run a "best-practice-ish" TLS setup and have that be compliant :(
Re: FIPS, agree that it is fractally bad [Fully realise I am preaching to choir].
The funny/sad part is that there are financial incentives to be able to say "yes" to customers inquiring about "FIPS compliance" which perpetuates the sham. Service providers (e.g. Amazon, Azure) then necessarily apply "compliance lawyering" (selective interpretation and omission) to give themselves a tick in the box. They can get away with this because their customers are also only pretending to care.
All this serves to create a false impression that "FIPS compliance" might be a real property of nontrivial systems rather than a form of expensive signalling.
That is a pretty skewed interpretation. FIPS mode does things for you like flag uses of the same private key for encryption and authentication, it prevents the use of weak keys, and prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs. The executable signing also makes monkey-patching harder, so it's more difficult to hook into an implementation and compromise it without detecting this at the compilation stage. That can and does have real security benefits.
The downside of FIPS mode is that because the certification process is so costly and time consuming, it will generally run behind and not get the latest algorithms until a few years have passed. That type of conservatism in cryptography can be good or bad, but overall I'd rather use a FIPS system than not, given the large number of dubious systems in use, and the FIPS system will be more secure than the average non-FIPS system, but less secure than a non-FIPS system carefully reviewed by experts.
Afaik what lets encrypt did is not a "hack" and perfectly valid. It sounds like users who have FIPS requirement need to fix it for their won use-case since its a bug in what they use and already fixed for everyone else.
Many enterprises use a FIPS SSL proxy for all employees web traffic, so all websites with these lets encrypt will effectively be invalidated if the proxies are using openssl FIPs modules, same for FIPS client side applications
I don't have a lot of sympathy for the companies in this situation. If you want to MITM all your employee's traffic, then you accept the burden of dealing with stuff like this periodically.
It seems quite silly to me to enforce a massive MitM attack while at the same time sticking to the FIPS standards. Then again, a lot of governmental and financial security requirements are nonsensical to me, like mandatory password changes.
When I, as a website host, need to choose between accepting millions of Android devices or a few organizations with an esoteric security configuration, I'll go for the Android devices.
AFAIK Windows FIPS mode is unaffected by the OpenSSL bug, so not all FIPS modules will have trouble with the Let's Encrypt certificate. A Windows-based MitM-attack won't have this problem.
The best solution here would be for OpenSSL to have a FIPS release ready before September, or to release a patched version of 1.0.X, but that still won't help companies that cannot or will not update their software.
> It seems quite silly to me to enforce a massive MitM attack while at the same time sticking to the FIPS standards.
Well they're two different things. One is an often government-mandated security standard. The other is a business requirement to be able to audit network traffic, which is also often a government-mandated requirement (due to regulations, due diligence, contractual requirements, etc).
People making tech stuff very often forget that the entire world does not work based on "technical best practices", it works on laws and contracts and customer/business requirements. In the real world there is often no perfect way to satisfy all requirements.
The reason the government wants FIPS is that it's been verified to be secure according to the national agencies. Enforcing that that security and then putting all if your sensitive traffic in the hands of one key on one box directly contradicts the security requirements FIPS is intended to ensure.
I don't expect the government to have different departments work together around this stuff, but knowing the technical details, the end result is still impractical and stupid. The end result of stupid rules and requirements is that the real world application of technology is stupid, as we have probably all experienced one way or another during our lives.
Just because there's a real business need for something, doesn't stop that from being silly. Correcting the silliness is clearly not a technological challenge, we'll have to wait for politicians and managers to do that, but the end result is still a confusing and contradictory mess.
Some of it is misguided, some of it is legacy, other parts _do_ make sense to the people involved.
Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided.
As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network.
FIPS and OpenSSL is an interesting subject. Many organisations rely on it, yet relatively few contribute financially. When 1.1.X and subsequent versions came along and had no FIPS 140-2, orgs were forced to wait it out until someone else pays to get it accredited or pony up and help the process along. I haven't looked lately at how much has been contributed to the effort but I suspect it's still pretty low considering how much of the world relies on OpenSSL.
Mandatory 90 day password changes are still required by the IRS in the US at least.
High complexity / weird rules too - and not one password across systems as they have endless DIFERRENT login systems.
So your tax software itself will require 90 day resets for all staff using that, every interface to IRS requiring it (which means every login for little used systems). It's bonkers. My worry - how do they even correlate / track login risk given all these different systems. Google (which has never required a password rotation) seems to be able to really figure out when risk is higher (new device from a new location) and lower (same device from 5 minutes ago). That makes turning on 2 factor with a hardware device MUCH easier - because it doesn't annoy you unnecessarily.
Ouch that sounds painful. If I'm not mistaken, all/most Americans have to interact with the IRS regularly? So this is an issue for many of you? By that I mean as a Brit who is salaried (PAYE) and doesn't own a business I have never had to interact directly with HMRC so even if it was as bad (it's not) it would be an infrequent experience.
This primarily affects professionals dealing with the IRS.
Individuals have been migrated a few times and a few different logins.
IRS had a "get transcript" service. It had things like super secure passwords and password rotations, but password reset and setup could be done with social security + some real basic info from credit reports (ie, where did you live etc) and didn't not timeout.
So think - 100's of thousands of fake accounts for the hackers, and pain for the real users.
That's pretty common in the US for govt systems - the password reset process is often ridiculously easy because some systems have so many reset requests you can't function with anything careful.
Imagine folks in govt - 10 systems, 90 day password rollover and there was a move for a while to 12 character passwords with no reuse and upper / lower / special / numbers (but special characters are limited so password generators often error out). It got so bad there was one reset process that was outsourced to a third party AND all you had to provide was the username which was derived from the users full name. They then gave you a new password over the phone. It was honestly easier to reset then even fight the system. You have a new intern whose forgotten their password, IT just calls reset help desk for a new one.
The security problems in all this are
1) reset process so weak
2) everyone - and I mean everyone, writes these passwords down in a text file on computer
3) because new account setup can be ridiculously long - a fair bit of password sharing, so these passwords tend to end up all over the place (training documents etc etc) which then of course end up online somewhere.
90 days is such a silly time frame. It won't defend against passwords like Spring2018! (11 characters, capital letter, special character, yyet ccompletely predictable) and people will only pick easier passwords when they're forced to pick new ones.
Even Microsoft has stopped recommending regular password changes. I think password changes can certainly be necessary, for example when problems are found during an audit or when there are indications of abuse, but these old rules are making everyone's lives so much harder than they need to be. I hope the IRS will reconsider soon.
Google's method is quite advanced (different tiers of trust for different kinds of services). It makes total sense that you can search the web using an old session, but need to redo the whole 2FA flow if you want to change your password or recovery options. Unfortunately, working such a system out can be quite a challenge because it's hard to get the API segregated into the right trust levels without massively complicating the code flow.
There are two risk classes; reused passwords exposed by a breach, and targeted attacks (phishing, dictionary/brute-force attacks, etc). The first is easiest to detect by finding password dumps and by observing login attempts. Targeted attacks are best prevented by 2FA. There never was any middle ground where password rotation improved security. For any high security systems worried about insider risk or espionage they should have been using multi-factor authentication all along.
My own view - reused passwords come from leaks - should be a penalty of $100 per leaked password - come on, salt and hash them! This would at least put some pressure on that side. Class actions allowed. This would push more towards oauth etc.
Then for targeted attacks, allow non-sms two factor with multiple keys and recovery codes. I'm non SMS two factor on google with recovery codes in a drawer. Have never changed my password and actually have it memorized (and I only use it for google). Same password for 15+ years or so now. Feel totally secure. Google authenticator on phone is pretty good because people really keep track of their phone (more so than yubico keys). I have a yubico on keychain which works 90% (a bit awkward in some cases).
Reused passwords are also really common and so cracking new dumps of salted and hashed passwords will yield a pretty high success rate.
At this point I just assume that any password that's been leaked (hashed or not) is in plaintext in some database. Obviously 20-character random passwords aren't going to get reversed but there's no guarantee that they were always hashed and weren't leaked from the login process itself, etc.
Ha, good one. For the average company that breaks SSL, I expect something like this instead: "new corporate policy update: for security reasons, you're no longer allowed to visit HTTPS Web sites that use Let's Encrypt. If the Web site you want to visit still allows HTTP, that continues to be acceptable."
They will just add an additional TLS proxy with a self-signed cert that ignores all validation. Security will be broken but users will be able to continue to do their work.
Maybe we just had a misunderstanding. What I was trying to say: Once this happens and everything breaks they will have an incentive to fix things quickly.
By no means do I expect vendors of "SSL inspection" devices to act any sooner than that.
I was going to migrate over to ZeroSSL, but there were red flags in the form of missing documentation that you would expect from a CA, like what is the chain of trust for certificates that are being issued? If I have to issue myself a certificate to check which CA is being used to sign the cert, that doesn't feel right.
I suspect there is no source that tracks exactly what's trusted on a large range of devices. Perhaps somebody should maintain this information, although it seems like a really thankless volunteer task, I'm really interested in such stuff and still it makes me feel tired just thinking about it.
There aren't degrees of trust in the system, but it is common for more sophisticated systems to have conditional or constrained trust. For example https://wiki.mozilla.org/CA/Additional_Trust_Changes or Microsoft's "NotBefore" constraint in newer versions of their operating system (not to be confused with the "notBefore" parameter in an X.509 certificate itself).
"Buypass Class 3 Root CA", which appears to be the root certificate they currently use, is present for all listed iOS versions (7+), which seems like a good sign. Let's Encrypt's "ISRG Root X1" is present in iOS 10+.
Similar lists for Android would be wonderful but probably impossible to compile due to ecosystem fragmentation. I guess there is no caniuse.com for root certificates.
Doesn't macOS allow you to add new root certificates to its certificate store? If not, you could still use a browser that brings its own certificate store (e.g. Firefox). This is significantly different from locked-down or embedded IoT devices you have no control over.
Oh, I keep my computer up to date. It's everyone else's computer that needs to work with my Let's-Encrypt-certificate-using software that's the problem.
One small piece of good news for Let's Encrypt is that it's so common chances are even your most hardcore fans, who presumably first notice this issue on your site because they visit so often, will then also get the same problem on half a dozen other sites they visit.
This applies especially for the case where what goes wrong is exactly that the visitor doesn't trust ISRG and ceases to trust DST Root CA X3 when its self-signed root expires. A lot of other problems will bite those who get new certificates first, but this problem will bite every site with a Let's Encrypt certificate at essentially the same moment regardless.
So at least the blame will be spread around thinly and for most users there will be an overwhelming impression they need to actually do something on their side and not just moan and hope the problem goes away.
71 comments
[ 8.5 ms ] story [ 114 ms ] threadFor the most part we aren't talking about needless turnover here. The trust store represents an institutional claim, between now and whenever you stop using this device, all the people who have these private keys will take proper care of them. I actually think that claim is extremely dubious for these Android devices today, it relies on people we meanwhile judged as incompetent to have nevertheless correctly destroyed key materials in their possession when they ceased to do business. I would not be astonished to discover that this already did not happen at least once since the devices ceased to get updates.
For example I imagine all the Symantec roots are included, and likewise StartCom/ WoSign.
Feature updates normally consist of "your device isn't supported and lock the user out without saying Good Bye.
If you create a platform that holds the basic for all versions and don't introduce new features to that; you won't have so much e-waste nor much maintenance upkeep.
I'm also not very convinced on the premise. Unless you're doing something fairly specialized (scientific modeling, compiling) or your software is unduly bloated (which a lot of software is, but that is its own problem), the difference in speed really shouldn't add up to that much.
All current FIPS accredited devices use openssl 1.0.X, so the lets encrypt cross-signing hack will essentially break multiple corporate networks until the next openssl fips module is released at the end of this year. And could take another 6 months to make it into live systems
A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.
So the answer to any particular bug is typically wait until next year's version which includes all bug fixes that the normal releases have built up over the past year, or re-evaluate if you really need the certification.
Nobody cares, of course, but it causes pointless conversations and wasted time with auditors.
(FIPS is very bad).
Re: FIPS, agree that it is fractally bad [Fully realise I am preaching to choir].
The funny/sad part is that there are financial incentives to be able to say "yes" to customers inquiring about "FIPS compliance" which perpetuates the sham. Service providers (e.g. Amazon, Azure) then necessarily apply "compliance lawyering" (selective interpretation and omission) to give themselves a tick in the box. They can get away with this because their customers are also only pretending to care.
All this serves to create a false impression that "FIPS compliance" might be a real property of nontrivial systems rather than a form of expensive signalling.
I had a longer rant about that here: https://news.ycombinator.com/item?id=15215756
The downside of FIPS mode is that because the certification process is so costly and time consuming, it will generally run behind and not get the latest algorithms until a few years have passed. That type of conservatism in cryptography can be good or bad, but overall I'd rather use a FIPS system than not, given the large number of dubious systems in use, and the FIPS system will be more secure than the average non-FIPS system, but less secure than a non-FIPS system carefully reviewed by experts.
It prevents use of good algorithms like ChaCha20/Poly1305, and it allowed the sketchiest PRNG of them all: Dual_EC_DRBG.
> The executable signing also makes monkey-patching harder
Monkey-patching means patching at runtime. This is just as easy to do after the signature has already been verified.
> it will generally run behind and not get the latest algorithms until a few years have passed
It also won't get fixes for vulnerabilities until a few years have passed.
When I, as a website host, need to choose between accepting millions of Android devices or a few organizations with an esoteric security configuration, I'll go for the Android devices.
AFAIK Windows FIPS mode is unaffected by the OpenSSL bug, so not all FIPS modules will have trouble with the Let's Encrypt certificate. A Windows-based MitM-attack won't have this problem.
The best solution here would be for OpenSSL to have a FIPS release ready before September, or to release a patched version of 1.0.X, but that still won't help companies that cannot or will not update their software.
Well they're two different things. One is an often government-mandated security standard. The other is a business requirement to be able to audit network traffic, which is also often a government-mandated requirement (due to regulations, due diligence, contractual requirements, etc).
People making tech stuff very often forget that the entire world does not work based on "technical best practices", it works on laws and contracts and customer/business requirements. In the real world there is often no perfect way to satisfy all requirements.
I don't expect the government to have different departments work together around this stuff, but knowing the technical details, the end result is still impractical and stupid. The end result of stupid rules and requirements is that the real world application of technology is stupid, as we have probably all experienced one way or another during our lives.
Just because there's a real business need for something, doesn't stop that from being silly. Correcting the silliness is clearly not a technological challenge, we'll have to wait for politicians and managers to do that, but the end result is still a confusing and contradictory mess.
Mandatory password changes for example have not been recommended[0] by NCSC in the UK since ~2018. Continuing to do so is either legacy or misguided.
As for "MitM" it's usually due to regulatory requirements to protect and inspect at boundaries to and from an organisations network.
FIPS and OpenSSL is an interesting subject. Many organisations rely on it, yet relatively few contribute financially. When 1.1.X and subsequent versions came along and had no FIPS 140-2, orgs were forced to wait it out until someone else pays to get it accredited or pony up and help the process along. I haven't looked lately at how much has been contributed to the effort but I suspect it's still pretty low considering how much of the world relies on OpenSSL.
[0]https://www.ncsc.gov.uk/collection/passwords/updating-your-a...
High complexity / weird rules too - and not one password across systems as they have endless DIFERRENT login systems.
So your tax software itself will require 90 day resets for all staff using that, every interface to IRS requiring it (which means every login for little used systems). It's bonkers. My worry - how do they even correlate / track login risk given all these different systems. Google (which has never required a password rotation) seems to be able to really figure out when risk is higher (new device from a new location) and lower (same device from 5 minutes ago). That makes turning on 2 factor with a hardware device MUCH easier - because it doesn't annoy you unnecessarily.
Individuals have been migrated a few times and a few different logins.
IRS had a "get transcript" service. It had things like super secure passwords and password rotations, but password reset and setup could be done with social security + some real basic info from credit reports (ie, where did you live etc) and didn't not timeout.
So think - 100's of thousands of fake accounts for the hackers, and pain for the real users.
That's pretty common in the US for govt systems - the password reset process is often ridiculously easy because some systems have so many reset requests you can't function with anything careful.
Imagine folks in govt - 10 systems, 90 day password rollover and there was a move for a while to 12 character passwords with no reuse and upper / lower / special / numbers (but special characters are limited so password generators often error out). It got so bad there was one reset process that was outsourced to a third party AND all you had to provide was the username which was derived from the users full name. They then gave you a new password over the phone. It was honestly easier to reset then even fight the system. You have a new intern whose forgotten their password, IT just calls reset help desk for a new one.
The security problems in all this are
1) reset process so weak
2) everyone - and I mean everyone, writes these passwords down in a text file on computer
3) because new account setup can be ridiculously long - a fair bit of password sharing, so these passwords tend to end up all over the place (training documents etc etc) which then of course end up online somewhere.
I could go on.
Even Microsoft has stopped recommending regular password changes. I think password changes can certainly be necessary, for example when problems are found during an audit or when there are indications of abuse, but these old rules are making everyone's lives so much harder than they need to be. I hope the IRS will reconsider soon.
Google's method is quite advanced (different tiers of trust for different kinds of services). It makes total sense that you can search the web using an old session, but need to redo the whole 2FA flow if you want to change your password or recovery options. Unfortunately, working such a system out can be quite a challenge because it's hard to get the API segregated into the right trust levels without massively complicating the code flow.
Then for targeted attacks, allow non-sms two factor with multiple keys and recovery codes. I'm non SMS two factor on google with recovery codes in a drawer. Have never changed my password and actually have it memorized (and I only use it for google). Same password for 15+ years or so now. Feel totally secure. Google authenticator on phone is pretty good because people really keep track of their phone (more so than yubico keys). I have a yubico on keychain which works 90% (a bit awkward in some cases).
At this point I just assume that any password that's been leaked (hashed or not) is in plaintext in some database. Obviously 20-character random passwords aren't going to get reversed but there's no guarantee that they were always hashed and weren't leaked from the login process itself, etc.
You can't practically use the web like that.
By no means do I expect vendors of "SSL inspection" devices to act any sooner than that.
is looking at a corporate firewall blocking Stack Overflow right now
... "practical" is setting your expectations a bit high.
I was going to migrate over to ZeroSSL, but there were red flags in the form of missing documentation that you would expect from a CA, like what is the chain of trust for certificates that are being issued? If I have to issue myself a certificate to check which CA is being used to sign the cert, that doesn't feel right.
"Buypass Class 3 Root CA", which appears to be the root certificate they currently use, is present for all listed iOS versions (7+), which seems like a good sign. Let's Encrypt's "ISRG Root X1" is present in iOS 10+.
Similar lists for Android would be wonderful but probably impossible to compile due to ecosystem fragmentation. I guess there is no caniuse.com for root certificates.
ZeroSSL seems to have their chained "AAA Certificate Services" in the list for iOS 7 (until 2028)
This applies especially for the case where what goes wrong is exactly that the visitor doesn't trust ISRG and ceases to trust DST Root CA X3 when its self-signed root expires. A lot of other problems will bite those who get new certificates first, but this problem will bite every site with a Let's Encrypt certificate at essentially the same moment regardless.
So at least the blame will be spread around thinly and for most users there will be an overwhelming impression they need to actually do something on their side and not just moan and hope the problem goes away.