> On Jul 7, 2016, at 2:06 PM, Clayton Daley <clayton.da...@gmail.com> wrote: > > I don't object to this specific change (we're on shiny new code), but want to > offer some food-for-thought: > > 1) Is newer really better in cryptography? Heartbleed affected 1.0.1, but > not 1.0.0 and there are a bunch of vulnerabilities that only affect the newer > libraries (https://www.openssl.org/news/vulnerabilities.html > <https://www.openssl.org/news/vulnerabilities.html>). It even makes sense > that the older libraries have been more-thoroughly tested... so new code may > just mean new vulnerabilities.
I can understand the point here - that upgrades are not zero-risk - but this is a very dangerous line of reasoning. (I think "in cryptography" you really mean the general english word "cryptography" and not like "PyCA™ Cryptography™".) It's dangerous because, as application developers, you and I aren't really _qualified_ to evaluate whether newer versions of security-critical libraries are more or less secure; the best we can do is always, always, always upgrade. The solution to heartbleed was to upgrade to a newer version of 1.0.1, not to roll back to 0.9.8. More importantly, heartbleed itself is not a general category of defect, in the sense that heartbleed itself shone a bright light directly on OpenSSL and exposed the real problem, which was massive underinvestment in critical security infrastructure. The issue isn't that upgrading is dangerous, it's that letting critical infrastructure decay is dangerous. One way that you can promote the decay of critical infrastructure is to defer upgrading out of vague fears about the upgrade going poorly rather than specific technical issues. I should take the opportunity to point out that if you're a professional network software developer, you should really be giving a couple of bucks to the OpenSSL foundation: <https://www.openssl.org/support/donations.html>. The most direct way to fight the decay of critical infrastructure is to fund it with cash money. (And, for that matter, <https://twistedmatrix.com/trac/#DonatetoTwisted>...) > 2) How does this impact regulated industries. In healthcare (my current > industry), changing a library (especially cryptography) could mean: > An internal review to select a new version of the library > An internal change management process > Technical testing (perhaps a 3rd party audit) > A notification to clients of the change > Secondary reviews/testing at clients > The intensity of this process depends on the risk level of the system and > this could be a long and complicated process for some organizations. Seems > like a more deliberate deprecation policy would make it easier to plan ahead. The problem with a lot of the regulatory standards that require this sort of laborious change-control is that during the entire period where all this redundant analysis and re-analysis of the change is happening, customers are still vulnerable (and in a health care context, this may mean even that lives remain at risk!). My (entirely secondhand) understanding is that recognition is dawning in many compliance fields (HIPPA, PCI-DSS, SOX) that there is a mismatch between the realities of software development (delay in making changes == risk) and industrial change control (every change == risk), and auditors and regulators are beginning to take this into account. This means that the ability to make changes quickly to ensure safe operation is slowly gaining ground over the ability to delay changes until sufficient evaluation has taken place. This recognition is dawning because many of these reviews are, in fact, nonsense. For example: "an internal review to select a new version of the library" - does every healthcare project have a qualified cryptographer and penetration tester to each independently spend the 6 months of careful code audits required to actually evaluate the relative security of new versions of OpenSSL, or does this internal review consist mainly of unqualified people pontificating about hypothetical risks, divorced from the technical realities of the upgrade in question? My own experience has taught me that fear of changes like this is mostly developers being afraid of audit or compliance, rather than audit or compliance actually requiring it. If you tell your auditor "we absolutely have to upgrade OpenSSL every week if an update is available", they'll usually figure out a way to do it. I don't mean to jump down your throat here; the tone is definitely harsher than I would like, but I want it to be very clear why I have such strong feelings about upgrading security-critical dependencies. Additionally, the Netscape SPKI APIs are disappearing from OpenSSL itself eventually, so this specific issue isn't just about upgrading - it's about preventing it from being difficult to upgrade in the future. If we wait until the APIs are actually gone, rather than just deprecated, this may create friction around a critical security update. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
