http://lists.netsys.com/pipermail/full-disclosure/2004-November/029524.html Konqueror doesn't use the strongest cipher available if connecting using https. This was first spotted by Fridtjof Busse in http://bugs.kde.org/show_bug.cgi?id=86332 go there for the gory details. E.g. konqueror uses 128bit RC4-MD5 even if 256bit AES is supported on both sides. Firefox on the same machine automagically uses the strongest cipher (in this case AES-256). Problem: Instead of relying on the built-in autonegotation and auto-selection that OpenSSL offers, a hardcoded list of ciphers is being used. This list chooses low-strengh ciphers by default to be compatible with broken servers. This way, one cannot take neither take advantage of new ciphers (since recompilation is required), nor of the strongest encryption possible. Lutz J
http://lists.netsys.com/pipermail/full-disclosure/2004-November/029524.html Konqueror doesn't use the strongest cipher available if connecting using https. This was first spotted by Fridtjof Busse in http://bugs.kde.org/show_bug.cgi?id=86332 go there for the gory details. E.g. konqueror uses 128bit RC4-MD5 even if 256bit AES is supported on both sides. Firefox on the same machine automagically uses the strongest cipher (in this case AES-256). Problem: Instead of relying on the built-in autonegotation and auto-selection that OpenSSL offers, a hardcoded list of ciphers is being used. This list chooses low-strengh ciphers by default to be compatible with broken servers. This way, one cannot take neither take advantage of new ciphers (since recompilation is required), nor of the strongest encryption possible. Lutz Jänicke, OpenSSL developer says: "I do not think that I understand this mess. I don't like code that bypasses the given API (see the meth->get_cipher) access... man SSL_get_ciphers and friends may help. I would rather recommend to simply leave the cipher selection to the OpenSSL library (from time to time we do think about our default settings)... " -- Ralf Hildebrandt (i.A. des IT-Zentrum) Ralf.Hildebrandt@charite.de ____________________________
kde please verify and advise.
We should wait a little while longer to see how the KDE upstream team handles this. It's not critical in my eyes, but we can definitely implement some form of patch once the KDE people decide what's prudent.
A month have now passed and apparently still nothing upstream.
I vote to resolve it UPSTREAM then - it's up the the KDE devs to decide how to fix this.
Caleb: Did you read what George Staikos wrote? Maybe I'm as paranoid as others obviously are, but lowering security for compatibility with broken software/servers is something a Redmond based corporation is known for. I strongly disagree on his /pragmatical reasons/ he mentioned in comment #26. Having the harcoded cipher list available optionally and by default disabled as a compatibility mode with a big fat warning, when you enable it, would be acceptable, but definitely not as it is now.
Another month has passed. Apparently upstream is not going to fix this:-(
I think we should close this as CANTFIX. Konqi uses by default insecure ciphers and this is by design. So what, use a real browser :)
>So what, use a real browser :) And this is? Don't say Mozilla/Firefox, since you'd mention the bunch of developers, who are known to have hidden (and silently fixed) vulnerabilities. I don't think it harms, if the bug stays open, so why close it. Maybe I'll be the asshole and send some emails, so KDE will get bad IT press. While this sucks, I see no better way, to get the ball rolling.
carlo: I was just kidding. We'll leave it open as a default config bug, as this is not a vulnerability per se.
last two comments on the KDE bug: ------- Additional Comment #37 From George Staikos 2005-02-27 17:44 ------- On Sunday 27 February 2005 02:43, Fridtjof Busse wrote: > Well, since nothing has changed and noone seems want to fix this, the bug > might as well get closed (I'm using firefox now, which has a sane way of > choosing the cipher). Or is anybody working on fixing this? One day someone may fix it, but it's not a bug. It's a feature that is presently unimplemented. If you want to use those ciphers, you can just edit the source code and remove the preference ordering. You won't get any support for sites that don't work though. ------- Additional Comment #38 From George Staikos 2005-02-27 19:56 ------- CVS commit by staikos: Enable support for stronger ciphers, and throw away old code that made us more compatible with older servers. Very likely breaks many sites. Please report ASAP so I can fix or revert this. FEATURE: 86332 M +71 -100 ksslsettings.cc 1.32
KDE have you tried the fix and will it be in 3.4?
The fix is not in 3.4 yet.
KDE any news on this one? Are we waiting for the next maintenance release or going to patch?
I for one won't have a look at it, before kde.org finished their cvs -> svn conversion. Atm both web{cvs,svn}.kde.org are unusable.
FYI: the fix will not be in maintainence releases (3.4.x), it will appear in kde 3.5. But since there's no vulnerability here, I don't think we are forced to backport and maintain it for all the 3.4.x lifetime...
Gregori can you confirm that this is in 3.5?
Yes, the rewrite of cypher selection is in 3.5.
Ok, I think we can close it as resolved upstream, but i'm not quite sure about this - so feel free to reopen or comment your rejection if you have another opinion.
