tags 658276 fixed-upstream
kthxbye
On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
> On Sat, Feb 04, 2012 at 10:11:31PM +0100, Alessandro Ghedini wrote:
> >
> > AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is
> > meant to keep compatibility with some older and broken SSL implementations
> > that don't support empty fragments, but it also re-introduces a security
> > issue.
> >
> > That's why such option was disabled in curl 7.24.0 (and backported to
> > stable-security). It was a mistake on the curl developers side to enable it
> > in the first place (it was done by accident because of the not-so-clear
> > OpenSSL documentation, according to upstream).
> >
> > I understand that this may cause problems (the incompatibility didn't show
> > up in my tests with live SSL servers though), but leaving a security issue
> > open *by default* is not a better solution IMO.
> >
> > Maybe an option, for both libcurl and curl, to explicitly enable the
> > SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick?
> >
> > Alternative solutions/opinions would be welcome, if you happen to have any.
>
> Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
> would be fine if I had the option to turn it on. In that case
> it's my decision to ignore the security consequences.
This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
