[HN Gopher] Let's Encrypt DST Root CA X3 Expiration - September ...
___________________________________________________________________
Let's Encrypt DST Root CA X3 Expiration - September 2021
Author : jorislacance
Score : 95 points
Date : 2021-05-17 08:55 UTC (14 hours ago)
(HTM) web link (letsencrypt.org)
(TXT) w3m dump (letsencrypt.org)
| Maxburn wrote:
| At some point old devices that aren't receiving updates really
| need to go away, a good thing for security.
| fnord77 wrote:
| and a bad thing for e-waste.
| kstrauser wrote:
| 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.
| Wowfunhappy wrote:
| I don't understand. The human wouldn't cease to exist
| regardless of how fast or slow their computer is, right?
| kstrauser wrote:
| It's easier if you imagine an office full of people. If
| you have slower systems, you have to hire more people to
| do the same amount of work.
| Wowfunhappy wrote:
| 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.
| Tepix wrote:
| You're underestimating the amount of resources required for
| chip production.
| selfhoster11 wrote:
| 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).
| kstrauser wrote:
| 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.
| ses1984 wrote:
| Devices that can't be updated all face an early ewaste
| destiny, don't blame expiring certs.
| bombcar wrote:
| 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.
| fnord77 wrote:
| well maybe a trust system that forces devices that can't be
| updated into obsolescence is not a good system.
| josephcsible wrote:
| Maybe having devices that can't be updated is not a good
| system.
| Spivak wrote:
| 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.
| tialaramex wrote:
| 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.
| Spivak wrote:
| 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.
| doublerabbit wrote:
| 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.
| notRobot wrote:
| The solution is not to throw away old devices, it's to figure
| out how to keep them updated
| crazypython wrote:
| I wish Let's Encrypt had a plan to get cross-signed by a CA those
| older devices still trust.
| Aissen wrote:
| Which devices ? They did find a solution for most Android
| devices, and it is now the default chain provided via ACME.
| mrtesthah wrote:
| How about macOS for example? After September, Let's Encrypt
| will become untrusted on all versions prior to 10.12.
| TonyTrapp wrote:
| 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.
| mrtesthah wrote:
| 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.
| tialaramex wrote:
| 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.
| crazypython wrote:
| iPhone 4.
| aisio wrote:
| "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 wrote:
| 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.
| rsj_hn wrote:
| 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.
| kstrauser wrote:
| It is. You can be secure or you can be FIPS-compliant, but
| not both.
| jstrom wrote:
| 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 wrote:
| Yes, 100% this. The best evidence is probably that
| Dual_EC_DRBG got FIPS approval, but ChaCha20/Poly1305 and
| Curve25519 have not.
| tptacek wrote:
| https://csrc.nist.gov/publications/detail/fips/186/5/draft
| xyzzy123 wrote:
| 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 wrote:
| 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).
| dtech wrote:
| 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 wrote:
| 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
| hannob wrote:
| I guess that will give them an incentive to fix those
| devices quickly.
| josephcsible wrote:
| 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."
| hannob wrote:
| Ain't gonna happen. Let's Encrypt is too big to be
| ignored.
|
| You can't practically use the web like that.
| josephcsible wrote:
| We know this, but I don't think everyone does. I'm sure
| that at least some places will learn this the hard way.
| 0xbadcafebee wrote:
| 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.
| hannob wrote:
| 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.
| ethbr0 wrote:
| > _You can 't practically use the web like that._
|
| _is looking at a corporate firewall blocking Stack
| Overflow right now_
|
| ... "practical" is setting your expectations a bit high.
| jeroenhd wrote:
| 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 wrote:
| > 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.
| jeroenhd wrote:
| 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.
| alias_neo wrote:
| 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.
|
| [0]https://www.ncsc.gov.uk/collection/passwords/updating-
| your-a...
| slownews45 wrote:
| 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.
| jeroenhd wrote:
| 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.
| benlivengood wrote:
| 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.
| slownews45 wrote:
| 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).
| alias_neo wrote:
| 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.
| slownews45 wrote:
| 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.
|
| I could go on.
| tyingq wrote:
| 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.
| nix23 wrote:
| 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)
| gregoriol wrote:
| Is there another provider that could be an alternative to this?
| (zerossl maybe?)
| currysausage wrote:
| Basically ZeroSSL and Buypass, yes. Buypass certificates have
| the additional benefit of being valid for 180 days. The rate
| limits are a bit stricter than with Let's Encrypt, I believe:
| https://www.buypass.com/ssl/resources/go-ssl-technical-speci...
| crazypython wrote:
| I assume they are more trusted by older devices than Let's
| Encrypt. Source?
| gregoriol wrote:
| Not sure its reliable but I've found this comparison:
| https://www.xf.is/2020/06/30/list-of-free-acme-ssl-
| providers...
| currysausage wrote:
| Relevant for Apple OSs: https://support.apple.com/en-
| us/HT209143
|
| "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.
| Deathmax wrote:
| ZeroSSL's current RSA intermediate is
| https://crt.sh/?id=2427368505, which chains up to USERTrust
| RSA Certification Authority (https://crt.sh/?caid=1167).
|
| 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.
| tialaramex wrote:
| 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.
| barbazoo wrote:
| Is there a range of trust? AFAIK you either trust a cert
| (directly or transitively) or not.
| tialaramex wrote:
| 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).
| cmeacham98 wrote:
| I think what they meant was "I assume they are trusted by
| [more] older devices..."
___________________________________________________________________
(page generated 2021-05-17 23:01 UTC)