Bug#802159: Bug#765639: Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. Apparently Java 6 and 7 will fail to handshake if a server tries to use DH with larger than 1024 bit parameters (and Java 8 apparently fails with anything larger than 2048 bits which is not relavent to the current discussion but is sad anyway). This is especially an issue with Java 6 which does not support ECDH (most configurations put ECDH above DH in the ciphersuite preferences so java 7 ends up using ECDH). Personally I think the security advantages of moving away from 1024 bit DH (which is probablly breakable with nsa level resources) outweigh this breakage (especially as afaict changing the defaults for parameter generation will only impact new installs not upgrades) but it is probablly something that should be documented.
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote: > On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote: > > However 1.0.1q hasn't been in stable at all, which is presumably what > > you'd be proposing introducing to oldstable at this juncture. (and which > > we'd therefore need to introduce to stable first, if we were to agree to > > follow that path.) > > Picking this up again (I hadn't realised the above was so many weeks > ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k > really needs a newer upstream version to be in Jessie first. We also > likely only have two opportunities to get a package in to "Wheezy > proper" before it moves to LTS status - likely a point release in March > and then a "mop up" after the EOL of the base suite. > > > Admittedly, the description of the changes between 1.0.1k and 1.0.1q, > > according to NEWS/CHANGES don't immediately look crazy. > > Comparing those against the package changelog and Security Tracker and > ignoring changes which are apparently only relevant if SSLv2 is enabled > leaves us with: > > *) dhparam: generate 2048-bit parameters by default. > [Kurt Roeckx and Emilia Kasper] > > *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs. > This changes the decoding behaviour for some invalid messages, > though the change is mostly in the more lenient direction, and > legacy behaviour is preserved as much as possible. > [Emilia Käsper] > > *) In DSA_generate_parameters_ex, if the provided seed is too short, > return an error > [Rich Salz and Ismo Puustinen ] > > *) Build fixes for the Windows and OpenVMS platforms > [Matt Caswell and Richard Levitte] > > The last of those is obviously irrelevant. Have there been any reports > of issues related to the other fixes listed? I can't remember any report about one of the above changes, nor can I find any. The base64 change is that it did weird things when receiving invalid base64, which you shouldn't get in practice, and now at least acts sane. The DSA entry in CHANGES is actually wrong, that's how it was changed in the master branch. It was merged to the stable branches and then reverted without reverting the CHANGES, and then fixed to instead do what was previously documented and uses a random seed if the seed is too short. I'll see about getting that CHANGES entry fixed. We reverted that because we think it wasn't an acceptable change in behaviour in the stable branches. The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. You can always override this default when generating them. The most reports about breakage we get actually have to do with the security fixes themself, like enforcing the minimum size of 768 bit when using DH and then finding out that there is software that uses 512 bit DH. (The upcomming release will actually change that to 1024, as announced.) Kurt
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote: > However 1.0.1q hasn't been in stable at all, which is presumably what > you'd be proposing introducing to oldstable at this juncture. (and which > we'd therefore need to introduce to stable first, if we were to agree to > follow that path.) Picking this up again (I hadn't realised the above was so many weeks ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k really needs a newer upstream version to be in Jessie first. We also likely only have two opportunities to get a package in to "Wheezy proper" before it moves to LTS status - likely a point release in March and then a "mop up" after the EOL of the base suite. > Admittedly, the description of the changes between 1.0.1k and 1.0.1q, > according to NEWS/CHANGES don't immediately look crazy. Comparing those against the package changelog and Security Tracker and ignoring changes which are apparently only relevant if SSLv2 is enabled leaves us with: *) dhparam: generate 2048-bit parameters by default. [Kurt Roeckx and Emilia Kasper] *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs. This changes the decoding behaviour for some invalid messages, though the change is mostly in the more lenient direction, and legacy behaviour is preserved as much as possible. [Emilia Käsper] *) In DSA_generate_parameters_ex, if the provided seed is too short, return an error [Rich Salz and Ismo Puustinen ] *) Build fixes for the Windows and OpenVMS platforms [Matt Caswell and Richard Levitte] The last of those is obviously irrelevant. Have there been any reports of issues related to the other fixes listed? Regards, Adam
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Sun, Dec 06, 2015 at 11:46:01AM +0100, Moritz Mühlenhoff wrote: > Hi, > Personally I'm in favour of following the openssl point updates and I'd > like to add an additional data point to the discussion: > > CVE-2015-3196 was already fixed as a plain bugfix in an earlier point > release, but the security impact was only noticed later on, so following > the point updates would have fixed this bug five months ago. So now CVE-2015-7575 (SLOTH) has been made public. This is yet an other example of an issue fixed a long time ago. It only affected wheezy because was fixed just after the version in wheezy. Kurt
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, 2015-12-15 at 21:19 +0100, Kurt Roeckx wrote: > On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote: > > [dropped explicit CCs to RT and TC members] > > > > On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote: > > > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote: > > > > So from what I'm gathering, this looks like a case where there isn't > > > > enough eyeballs to adequately review this particularly set of updates, > > > > coupled with the importance of making sure that these updates are > > > > correct and don't cause any unintended issues. > > > > > > There is always the case that one persons bug is an other persons > > > feature. But those new upstream versions have been in stable and > > > testing for a while now without actually breaking anything. > > > > (I'm assuming "unstable".) > > I really meant stable. stable has a newer version than oldstable > from the same 1.0.1 series. Okay. However 1.0.1q hasn't been in stable at all, which is presumably what you'd be proposing introducing to oldstable at this juncture. (and which we'd therefore need to introduce to stable first, if we were to agree to follow that path.) Admittedly, the description of the changes between 1.0.1k and 1.0.1q, according to NEWS/CHANGES don't immediately look crazy. Regards, Adam
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Sun, 2015-12-06 at 11:46 +0100, Moritz Mühlenhoff wrote: > Hi, > Personally I'm in favour of following the openssl point updates and I'd Noted, thanks for the input. > like to add an additional data point to the discussion: > > CVE-2015-3196 was already fixed as a plain bugfix in an earlier point > release, but the security impact was only noticed later on, so following > the point updates would have fixed this bug five months ago. In isolation, that's an argument for accepting new upstream versions of most packages into stable, as there'll always be bugs for which the full impact may not be immediately apparent. Regards, Adam
