[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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".


- 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...

l=2001;main(i){float o,O,_,I,D;for(;O=I=l/571.-1.75,l;)for(putchar(--l%80?
("  Harry 'Piru' Sintonen <sintonen@iki.fi> http://www.iki.fi/sintonen";);}

Reply to: