[Twisted-Python] dropping old pyOpenSSL versions

[Clayton Daley]

>
> 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.
>

I don't take it personally.  I do a little coding (hello startup) but I'm
actually the guy who:

   - Had to develop our Policies and Procedures (P&P) in conjunction with
   our Compliance consultant
   - Has to work with our lawyers to negotiate Information Security and
   Business Associate agreements with customers
   - Has to provide implementation details in request to our customers'
   security groups (I spent all day working through a 160 item self-assessment
   so it was top-of-mind for me)

When there's a vulnerability, you can fast track an upgrade because there's
a non-theoretical risk to doing nothing.  The problem is an "optional"
version bump.  It's all CYA.  If I don't follow my P&P, the federal
government, state government, and customers all have (extra) grounds to sue
my company (cofounder so literally *mine*).  If the consequence of waiting
are a transient Twisted bug or a delayed feature depending on a feature in
a blocked version, it's an easy choice.

Clayton Daley


On Thu, Jul 7, 2016 at 6:00 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> On Jul 7, 2016, at 2:06 PM, Clayton Daley <clayton.daley at 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).  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 at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160707/73b2fdbf/attachment-0002.html>