6 ms·

"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 opens

by aisio 5y ago

"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

tux3 5y ago
Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.
- jstrom 5y ago
  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.
- josephcsible 5y ago
  Yes, 100% this. The best evidence is probably that Dual_EC_DRBG got FIPS approval, but ChaCha20/Poly1305 and Curve25519 have not.
  - tptacek 5y ago
    https://csrc.nist.gov/publications/detail/fips/186/5/draft https://csrc.nist.gov/publications/detail/fips/186/5/draft
    - xyzzy123 5y ago
      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.
      - tptacek 5y ago
        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. :) (FIPS is very bad).
        xyzzy123 5y ago
        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. I had a longer rant about that here: https://news.ycombinator.com/item?id=15215756 https://news.ycombinator.com/item?id=15215756
- kstrauser 5y ago
  It is. You can be secure or you can be FIPS-compliant, but not both.
- rsj_hn 5y ago
  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.
  - josephcsible 5y ago
    > prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs 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.
dtech 5y ago
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.
- aisio 5y ago
  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
  - tyingq 5y ago
    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.
  - jeroenhd 5y ago
    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.
    - 0xbadcafebee 5y ago
      > 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.
nix23 5y ago
If you need FIPS then pay for your Cert. No one wants to be stopped by such a stupid standard (except you get payed for it)

by aisio 5y ago

tux3 5y ago

Isn't the point of FIPS accreditation that the organization wants to prioritize compliance over functionality/security? A FIPS device being unpatched or broken for a few months almost seems like the natural state of things, at this point.

jstrom 5y ago
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.
josephcsible 5y ago
Yes, 100% this. The best evidence is probably that Dual_EC_DRBG got FIPS approval, but ChaCha20/Poly1305 and Curve25519 have not.
- tptacek 5y ago
  https://csrc.nist.gov/publications/detail/fips/186/5/draft https://csrc.nist.gov/publications/detail/fips/186/5/draft
  - xyzzy123 5y ago
    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.
    - tptacek 5y ago
      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. :) (FIPS is very bad).
      - xyzzy123 5y ago
        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. I had a longer rant about that here: https://news.ycombinator.com/item?id=15215756 https://news.ycombinator.com/item?id=15215756
kstrauser 5y ago
It is. You can be secure or you can be FIPS-compliant, but not both.
rsj_hn 5y ago
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.
- josephcsible 5y ago
  > prevents use of hobbyist or non-approved algorithms including some sketchy PRNGs 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.

dtech 5y ago

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.

aisio 5y ago
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
- tyingq 5y ago
  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.
- jeroenhd 5y ago
  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.
  - 0xbadcafebee 5y ago
    > 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.

nix23 5y ago

If you need FIPS then pay for your Cert. No one wants to be stopped by such a stupid standard (except you get payed for it)