Shared publicly  - 
 
Here is the timeline from my (OpenSSL) perspective for the recent CCS Injection (MITM) vulnerability as well as the other flaws being fixed today.

** SSL/TLS MITM vulnerability (CVE-2014-0224)

2014-04-22 (Date we were told the reporters shared the issue with
                        JPCERT/CC)
2014-05-01 JPCERT/CC make first contact with OpenSSL security
2014-05-02 JPCERT/CC send detailed report and reproducer to        
                        OpenSSL security (issue details are not complete and
                        doesn't look possible for a general purpose MITM at                               this point)
2014-05-09 CERT/CC make first contact with OpenSSL security      
                         and send an updated report and reproducer which
                         shows full MITM is possible
2014-05-09 OpenSSL verify the issue and assign CVE-2014-0224
2014-05-12 JPCERT/CC contact OpenSSL with updated reproducer
2014-05-13 OpenSSL start communication directly to reporters to  
                       share updated patch and other technical details
2014-05-21 JPCERT/CC notify OpenSSL they have notified
                       "vendors who have implemented  OpenSSL in their          
                        products" under their framework agreement
2014-05-21 CERT/CC request permission to prenotify vendors of
                       the issue
2014-05-21 OpenSSL work with two major infrastructure providers
                       to test the fix and  ensure the fix is sufficient
2014-06-02 CERT/CC notify their distribution list about the security
                        update but with no details
2014-06-02 "OS distros" private vendor list is given headsup and
                        ability to request the patches and draft advisory
                        (0710).  Told Red Hat (0710) Debian (0750) FreeBSD
                        (0850),  AltLinux (1050), Gentoo (1150), Canonical
                        (1150), IBM (1700), Oracle (1700), 
                        SUSE (2014-06-03:0820), Amazon AMI
                        (2014-06-03:1330), NetBSD/pkgsrc (2014-06-04:0710),
                        Openwall (2014-06-04:0710)
2014-06-02 Red Hat find issue with patch (1400), updated patch
                        sent to vendors
2014-06-02 Canonical find regression with patch (1700), Stephen
                         produces updated patch, sent to vendors (1820)
2014-06-03 "ops-trust" (1015) and selected OpenSSL Foundation
                         contracts (0820) are told a security  update will be
                         released on 2014-06-05 but with no details
2014-06-05 Security updates and advisory is released (1130)

** DTLS recursion flaw (CVE-2014-0221)

2014-05-09 Reporter contacts OpenSSL security
2014-05-09 OpenSSL contacts reporter with possible patch for
                       verification
2014-05-16 Reporter confirmes patch
2014-05-18 OpenSSL tells reporter CVE name
2014-06-02 "OS distros" notification as above
2014-06-03 OpenSSL lets reporter know the release date
2014-06-05 Security updates and advisory is released

** DTLS invalid fragment vulnerability (CVE-2014-0195)

2014-04-23 HP ZDI contact OpenSSL security and pass on security
                        report
2014-05-29 OpenSSL let ZDI know the release date
2014-06-02 "OS distros" notification as above
2014-06-05 Security updates and advisory is released

** Anonymous ECDH denial of service (CVE-2014-3470)

2014-05-28 Felix Gröbert and Ivan Fratrić at Google report to
                       OpenSSL
2014-05-29 OpenSSL tell reporters CVE name and release date
2014-06-02 "OS distros" notification as above
2014-06-05 Security updates and advisory is released

(All times UTC)
13
9
Tamotsu TAKAHASHI's profile photoHuzaifa Sidhpurwala's profile photoJörg Stephan's profile photoAtsushi Morioka's profile photo
17 comments
 
Interesting how the CVE-2014-0224 patches that were shared & tested privately between OpenSSL, JPCert and certain unnamed vendors for a month, were  found to be flawed within hours, once finally shared with Linux distro vendors!
 
+Daniel Berrange I'll do another post when the dust settles about why we chose the disclosure policy we did, and who added value.  You can see that out of all the people that knew in advance only really 4 companies added value.
 
This is why even some serious security people release bugs as zero days. Why should some companies have a competitive security advantage over the general FOSS community?
 
+Sebastian Rother Hi; I'm not sure of the politics around why OpenBSD don't want to join the distros list, but if they join they'd be able to work with other distros on issues in advance (just like FreeBSD etc).  
 
Security "professional" that is no programmer?
But I agree, this is completely childish. It's really hard to argue with OpenBSD's "unhealthy community" arguments after we saw this.
 
+Mark J Cox , after searching I couldn't find any description of how to join the distros list. Is there a published way to join the list?
 
Sebastian,

Rather than tar and feather you personally I'd just like to correct you. As the former lead accreditor for UK MoD on all things Unix/BSD/Solaris/AIX/Linux and embedded can I just point out you are wrong.

There is NO OpenBSD in UK military - at all. Period. Nowhere. If there is and you know different please message me because it's not supposed to be there. How do I know ? I spent three years signing it all off and knowing the position of every single piece of architecture in deployed and battlespace in theatre, maritime and across partner networks into four eyes (US/Canadian/Australian/New Zealand) partner forces. The sole embedded kit which was publically availably listed as XTS400 being retired in 2007 for forward fire control units. Endpoint encryption equipment being CentOS based and publically listed as procurement stock,in fact CentOS is the predominant flavour of Linux / Unix across MoD, US DoD and US.Mil. Solaris, AIX and Red Hat making up the remainder in actual order. 

Genuinely you are really punching above your weight
 
US DoD uses NetBSD for imaging. Thats all. No other use of BSD in any part of DoD. Period. Please check your facts and I'm not an analyst I'm a security professional who is extremely confused at your thoughts and lack of coherence.
 
It's a very simple trade off.

In an ideal world. there are no security issues and programs are flawless.

In the real world, there are both flaws and people willing to do damage to others.

In order to deal with an issue, you can:
- tell everybody, including the 'evil', where the vulnerabilities are. Ordinary users will have no remedy and skilled 'evil' will have the information needed to harm the sitting duck users
or
- try to only tell people who make software for users just barely enough in advance that when you hit the public with the information about your vulnerabilities, there are fixes available for users that they can deploy, thus trying to protect the majority of users as best as possible

The latter approach is what was used here.
It requires the group of people being informed in advance that they keep the information confidential, and prepare fixes.
People who have a philosophical problem with keeping vulnerabilities confidential even for a week are thus unsuited to participation.

It is obvious (and is commonly applied) that when a vulnerability is known in the 'evil' community (is seeing exploits) the public should get informed immediately, since in this case "keep it away from the bad people" is no longer an option.
 
Also: there is a wider Open Source community that also organizes itself for security issue handling. OpenBSD chose not to participate. That is their call. Complaining about not reaping the benefits of this participation, however, is delusional.
 
Hi, Mark. We found your article great and useful!
We are CCS Injection original reporter.
We want to translate this article into Japanese, and post to our own blog.
May I please have your permission to do so?
Thanks in advance.
 
+Sebastian Rother
 You claim that I am spreading untruth. What part of my comment on "how open source vulnerabilities are commonly handled, and why" do you take exception to?
Also: could you explain why you see the need to be grossly impolite?
 
The original question asked why OpenBSD were not notified in advance and the answer is that OpenSSL notified OS distributors subscribed to the private distros list http://oss-security.openwall.org/wiki/mailing-lists/distros (and OpenBSD previously chose not to be members of that list http://seclists.org/oss-sec/2014/q2/233  ).  OpenBSD have approached us to be notified about future issues and we've asked them to join the list as they certainly would qualify and would find it beneficial not just for any future OpenSSL issues.
 
Thanks Mark, this was very interesting and pertinent. You can't win on disclosure, your approach is inline with the RFCs (yeap there is one). Some of those missed will always feel aggrieved, the alternative is spring it on an unprepared world, which is sometimes right, and sometimes reckless. The full disclosure debate will rumble on with or without you, without is probably a better use of your time.

I'm curious which vendors it was disclosed to under framework agreement, as several big vendor seems to be struggling at assessing impact, let alone getting to updates. But I'm guessing you don't know, or can't say, or probably shouldn't. I'd have thought OpenSSL updating would be fresh in their minds (alas).
 
[June 13: I've disabled comments and deleted one as they were becoming personal and abusive attacks that added no value, if you want to discuss OpenSSL disclosure policies then you should do it on the public OpenSSL lists so the whole team who decide these things can take part]