Bug#674142: make it possible to disable ssl compression in apache2
It *IS* backported already and we *WILL* upload it as an update to
Stable. But since this is not a critical issue [1] and since uploads to
Stable are extremely sensitive it may well be we wait for another issue
we need to fix in Stable as well.
[1] it is a browser issue in reality, no really.
I cannot fully agree with this assessment. IMHO lack of option to disable
compression should be considered a critial issue, and it should be fixed
speedily at server side as well.
SSL compression is an optional feature that is only used if both the
server and client support it, and the server agrees to enabling it. Thus
the issue can be mitigated in two different ways:
- Modify the clients so that they do not report supporting compression at
"client hello".
and/or:
- Fix servers so that they do not enable compression, even if the client
is advertising the support in "client hello". Either remove compression
support completely or make it configurable.
The root of the problem is that current stable apache2 enables the
compression if requested by the client, and there is no way to mitigate
this issue (and the CRIME attack) from the server side.
The most efficient way of fixing this is to patch the server. While
clients may have received updates disabling the compression, no-one can
guarantee that everyone has installed those patches.
It may even be a direct security threat for the server since an attacker
may perform a targetted attack against some administrative functionality
(steal admin's session token) to gain privileged access to the server.
Another argument speaking in behalf of fixing this on the server side is
the asymmetry: There are thousands of clients per one server. Fixing the
server mitigates the issue for all of the clients (even the unpatched
ones!).
Finally, failing PCI compliance is a major issue. To quote
pcisecuritystandards.org:
"But if you are not compliant, it could be disastrous:
o Compromised data negatively affects consumers, merchants, and
financial institutions
o Just one incident can severely damage your reputation and your ability
to conduct business effectively, far into the future
o Account data breaches can lead to catastrophic loss of sales,
relationships and standing in your community, and depressed share
price if yours is a public company
o Possible negative consequences also include:
- Lawsuits
- Insurance claims
- Cancelled accounts
- Payment card issuer fines
- Government fines
"
Strictly speaking this of course isn't Debian's problem, but nevertheless
I think it reflects poorly on Debians reputation if vendor is slow to fix
an issue that may lead to PCI complicance issues.
You're of course right in that the problem goes away if all clients have
been updated. However, I think it would be much better security
management to promptly fix it at server side as well. And it would get
all those PCI bound parties happy...
Regards,
--
l=2001;main(i){float o,O,_,I,D;for(;O=I=l/571.-1.75,l;)for(putchar(--l%80?
i:10),o=D=l%80*.05-2,i=31;_=O*O,O=2*o*O+I,o=o*o-_+D,o+_+_<4+D&i++<87;);puts
(" Harry 'Piru' Sintonen <sintonen@iki.fi> http://www.iki.fi/sintonen";);}
Reply to: