[openssl-users] [openssl-dev] Proposed cipher changes for post-1.0.2

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich
> Sent: Wednesday, February 11, 2015 13:26
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for
> post-1.0.2
> 
> > All sorts of things can be done. Clearly, in the Brave New World of well-
> > funded OpenSSL, they'll have to be, because it's apparent that we're going to
> > see a lot of disruptive change made on the flimsiest of pretexts, with
> > objections from the user community brushed aside. That's your prerogative,
> > of course, and anyone's free to fork OpenSSL. But it's a shame.
> 
> I am surprised by the strength of your reaction.  Hmm.

Well, let me try to explain.

There are two related issues here. One is simply that we're seeing a lot of OpenSSL roadmap announcements. That's good in the sense that before the funding boost, progress was of course much slower and communication much less frequent. On the other hand, it's worrying because those changes have consequences for developers working with OpenSSL, and so we need to account for them in our plans. And while those announcements are generally couched as requests for feedback, arguments against them usually don't seem to carry much weight. Things are changing relatively quickly with OpenSSL and that is a destabilizing circumstance in itself.

(The obvious answer would be to delay adopting new OpenSSL releases, and only pick up fixes. Sometimes that's a solution. Sometimes new fix levels change behavior, though; and sometimes, in these post-Heartbleed days, customers demand the latest release for no very good reason. Right now I have a customer insisting we update one product line to OpenSSL 1.0.1m, which obviously is a little difficult.)

The second issue is that any user-visible change in behavior that's not solely a fix to a vulnerability is significant work for us, particularly if it involves code changes. We have to make the necessary updates, test, provide documentation, and ensure customers are aware of the change. It's a substantial effort if the change in OpenSSL requires a corresponding change in our code, but at least in that case the integration process catches it. If it's a runtime behavior change, then we have to make sure all the affected development teams are aware of it, because we can't be sure that everyone has tests that will catch it.

We have multiple teams in the organization using OpenSSL independently. We're working on a plan to bring all our OpenSSL builds under a single group which can be responsible for tracking changes, but that's a long way off yet. We have product lines that use our other products internally to provide SSL/TLS, and those teams don't know what's happening with OpenSSL - they just expect it to work.

(This does raise a rather delicate point: sponsorship. Let's just say that I've suggested it in the past and it hasn't gotten a lot of traction. I keep meaning to donate personally but ... oh, hell, let's just do it now. Done. Coals to Newcastle these days, but every bit helps, I suppose.)

So, for the components I personally work on, this change (RC4 into LOW) isn't a big deal. One product line sets ciphers explicitly, either using its own default list or one configured by the user; another might need a change (haven't checked) to maintain existing behavior, but it's time to review that anyway. It's the 20-odd other product lines that I'm more worried about, because i don't even know what all of them are.

And I don't know how changes like this in OpenSSL behavior affect, say, the SUSE division - how many updated packages they'll have to integrate and test. Maybe it's not a big deal; maybe it's a lot of work. Maybe they welcome this particular change regardless. (I'll have to ask on our next security call.)

Anyway, this has gone on too long already. The basic point is that these changes affect us, the users of OpenSSL, sometimes in quite disruptive ways. And sometimes they leak through to our users, and we have to handle that situation. So yes, some of us will be resistant to changes that we think aren't strongly justified.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com