Comment 46 for bug 1068854
Revision history for this message
|
|
#46 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to comment #15)
> (In reply to comment #14)
> > The default has been changed to "off" in r1400700
>
> That's only on trunk, right? What about the default for 2.2.x and 2.4.x?
They will be changed, too. But due to the voting on backports, it will take a bit. For 2.4.x, the change has been committed as r1400962 and will be in 2.4.4.
(In reply to comment #16)
> 1) Are you going to backport this into the Debian versions?
Yes.
> 2) As long as there is no protocol level fix (or something like this),
> wouldn't it be better to generally and forcibly switch that off in the
> affected versions?
> I mean if someone would really want it in spite of the attack,... he should
> probably be able to patch the code accordingly.
> Otherwise people may just think that compression sounds like a good thing
> and "accidentally" enable it (which leads me to: (3)).
>
> 3) As far as I can see, the documentation of this directive does not refer
> to the CRIME attack.
> Unless (2) was done (and thus people can't accidentally enable it) I'd
> strongly recommend adding information that switching compression on allows
> the CRIME attack and which versions of SSL/TLS/etc. are affected (unless all
> are).
The documentation now states "Enabling compression causes security issues in most setups (the so called CRIME attack)." I think that is sufficient.