Version: (using KDE KDE 3.2.92) Installed from: Gentoo Packages OS: Linux Konqueror doesn't use the strongest cipher available if connecting to https. 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). I only found an option to deactivate certain ciphers, but there seems to be no option to tell konqueror to use the strongest cipher available. The same applies to KMail which doesn't use the strongest cipher by default as well.
Let's increase the severity to "major" (if it should not be raised even higher...)
When this code was written, that cipher was not included in OpenSSL. Since OpenSSL has no way (that I know of - perhaps this is a new feature too?) to compare "cipher strength", there is no way we can anticipate new additions and put them in the right place. There are a few options: 1) Hardcode this new one in 2) Ask OpenSSL to support "strength comparison" 3) Allow the user to manually order the cipher preferences I think the last thing we need is more options, so I don't really want to do #3.
This has nothing to do with newer openssl ciphers not supported in KDE. I'm pretty sure that RC-MD with 128 bit wasn't even in older openssl-versions the strongest cipher. Obviously, every other software is able to determine the best available cipher, since choosing the cipher is part of the handshake ("openssl s_client -connect host:25 -starttls smtp"). Why does KDE choose the weakest available cipher? AES256-SHA is activated in my konqueror-preferences, but not used, so it is supported by KDE but never used, so this is a bug.. Or do you have an explanation why KDE ignores the stronger ciphers? I wouldn't call RC4-MD5 very secure. IMO this is definitly not a wishlist-bug.
Please give us an example e.g. of a website to test this against.
E.g. https://www.fbunet.de/ Konqueror uses RC4-MD5 (128 Bit, tested with both KDE 3.2.3 and KDE 3.3 Beta2), Firefox uses AES256-SHA. Both client and server have openssl-0.9.7, so they support AES. Same applies to KMail sending mail via TLS.
Created attachment 6977 [details] KDE SSL Dialoge
Created attachment 6978 [details] SSL - all ciphers are available!
See attachments 6977 & 6978 for my reproduction of the behaviour. I use Konqueror 3.2.2 /using KDE 3.2.3) from Debian/unstable. Installed SSL packages are: ii libssl-dev 0.9.7d-5 SSL development libraries, header files and ii libssl0.9.7 0.9.7d-5 SSL shared libraries ii openssl 0.9.7d-5 Secure Socket Layer (SSL) binary and related 0.9.7, so AES is available.
On Tuesday 03 August 2004 00:56, Fridtjof Busse wrote: > This has nothing to do with newer openssl ciphers not supported in KDE. > I'm pretty sure that RC-MD with 128 bit wasn't even in older > openssl-versions the strongest cipher. Obviously, every other software is > able to determine the best available cipher, since choosing the cipher is > part of the handshake ("openssl s_client -connect host:25 -starttls smtp"). > Why does KDE choose the weakest available cipher? AES256-SHA is activated > in my konqueror-preferences, but not used, so it is supported by KDE but > never used, so this is a bug.. Or do you have an explanation why KDE > ignores the stronger ciphers? I wouldn't call RC4-MD5 very secure. IMO this > is definitly not a wishlist-bug. Well I wrote all of that code and I know why it is the way it is. OpenSSL requires that you list the ciphers you want in the order you want. There is now way to ask "is X stronger than Y" programatically. In the past, if we didn't specify what we wanted or we specified a list of ciphers just in any order as returned by OpenSSL, it would negotiate *really* weak ciphers. Search bugzilla history for this. The fix was to list the order we prefer our ciphers in, and stick any others we don't know about at the end. AES256-SHA is new, so it cannot be in this list at this point.
openssl seems to be able to select the strongest cipher, as demonstrated by s_client. Why should I have to define which cipher I want? AES256-SHA *is* in the list, but obviously not used (take a look at Ralfs screenshots). What's the purpose of the list if it doesn't change anything, I get RC4-MD5 everywhere I go. No matter if any other cipher is supported. I don't get it, why not use the the info from the handshake, like s_client, firefox and every other SSL-aware software I know? Let me rephrase: How do I tell konqueror/kmail which cipher to use without deactivating all the ciphers I don't want and thus breaking compability with other SSL-servers?
On Tuesday 03 August 2004 13:38, Fridtjof Busse wrote: > openssl seems to be able to select the strongest cipher, as demonstrated by > s_client. Why should I have to define which cipher I want? AES256-SHA *is* > in the list, but obviously not used (take a look at Ralfs screenshots). > What's the purpose of the list if it doesn't change anything, I get RC4-MD5 > everywhere I go. No matter if any other cipher is supported. I don't get > it, why not use the the info from the handshake, like s_client, firefox and There was no way to do this last time I looked. You give it a preference list, or say "use everything you have and do it all yourself". Well people didn't like the second option because they wanted to disable various ciphers and prefer certain well-known ones over others. > every other SSL-aware software I know? Let me rephrase: How do I tell > konqueror/kmail which cipher to use without deactivating all the ciphers I > don't want and thus breaking compability with other SSL-servers? You don't. That's what I wrote in my first response as an optional way to implement this. As I said, this is about a feature request, which is one of two (reasonable) things: 1) Add new ciphers to the preference list (requires extensive regression testing since this was fine tuned to make KIO most compatible over the past few years) 2) Allow the user to manually order his preferred cipher list. (requires lots of new code/UI/options)
As I said, there is definitly a way. How else would "openssl s_client -connect www.fbunet.de:443" know that the strongest supperted cipher is AES256-SHA: SSL handshake has read 1247 bytes and written 346 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA I have to explicitly use "-cipher EXP-RC4-MD5" to get openssl to use RC4-MD5.
On Tuesday 03 August 2004 13:50, Fridtjof Busse wrote: > As I said, there is definitly a way. How else would "openssl s_client > -connect www.fbunet.de:443" know that the strongest supperted cipher is > AES256-SHA: Because it just tells the library to connect and autonegotiate whatever it wants. It could connect with NULL-0 cipher even. You're allowed to ask what was negotiated in the end.... but that's after it was negotiated. Please read carefully what I am writing because you are definitely missing the point. If you want to see the code for how this works, it's in kdelibs/kio/kssl/. Just because we use a given library doesn't mean we will automatically support all new features in the library with simply a recompile.
I'm reading what your writing very carefully. You say ASE256 isn't supported yet, because it's a new cipher. But AES128 and AES256 appear at the top of my list of SSLv3 ciphers (I deactivated SSLv2), but they are not used. They appear, they are active, they are at the top of the list, they are supported by the local openssl-version, but they aren't used. Simple question: Why? Why do they appear if they don't get used?
On Tuesday 03 August 2004 13:57, Fridtjof Busse wrote: > I'm reading what your writing very carefully. > You say ASE256 isn't supported yet, because it's a new cipher. > But AES128 and AES256 appear at the top of my list of SSLv3 ciphers (I > deactivated SSLv2), but they are not used. They appear, they are active, > they are at the top of the list, they are supported by the local > openssl-version, but they aren't used. Simple question: Why? Why do they > appear if they don't get used? They are used, but as I said, they are stuck onto the end off the preference list because we don't know about them yet. For all we know, they could be null ciphers. They could indeed be used if all other cipher negotiations fail though.
OK, but why not use the list from "openssl ciphers" and let the user deactivate ciphers they don't want? I have no idea why anyone might want to do that (firefox doesn't have that option and I never heard anyone complain), but at compile time kssl could simply check what openssl supports and add/delete the options (e.g. some openssl-verisons hav IDEA disabled for a good reason). I'm definitly not happy with the current system since KDE doesn't make any use of strong ciphers. Choosing the ciphers currently doesn't do what the user thinks (AES256 at top of the list, but not even prefered over RC4-MD5 with 128 Bit). I've actually never seen konqueror using anything else than RC4-MD5. I see really no good reason not to use what "openssl thinks is best" and only disable the ciphers the user explicitly does not want, since the "prefer certain ciphers over others" doesn't work. RC4-MD5 is at the bottom of the list and there are many ciphers with 168Bit (like CBC3) above it, but they're not used and you can't change the order of the list. So this whole thing looks somewhat broken.
That's exactly what we do already. We ask openssl for the cipher list, we adjust the ones with stronger bit strength up, lower bit strength down, and then we have hardcoded these ciphers up at the very top: AdjustCipher("IDEA-CBC-MD5", 128); AdjustCipher("DES-CBC3-MD5", 168); AdjustCipher("RC2-CBC-MD5", 128); AdjustCipher("DES-CBC3-SHA", 168); AdjustCipher("IDEA-CBC-SHA", 128); AdjustCipher("RC4-SHA", 128); AdjustCipher("RC4-MD5", 128); Why did we do this? Because OpenSSL on its own was negotiating weak connection, or it was confusing servers and making it look like kio_http was buggy when in fact it was that the server out there just choked when it saw a cipher it didn't know at the top of the list. Please read the code or CVS history if you don't believe me. We'll add AES someday when it can be properly tested against all the misbehaving servers out there.
OK, I admit I never ever had trouble with the cipher openssl suggested (and all my mailservers run TLS), but I have take your word for it, too lazy for CVS changelogs right now. :) But then I still don't get the purpose of the list in the konqueror preferences with ciphers that won't be used anyway in the order displayed (and no way to change that order). I mean, this list suggests that you can fine-tune the ciphers konqueror will use, but in fact there is a hardcoded list of ciphers that has nothing to do with the order in the list. Why not make a decison: USe the hardcoded ciphers by default, but also give "advanced users" to choose their ciphers (and if it breaks, they can go back to the hardcoded ones). Would make life *much* easier. And why does konqueror, although DES-CBC3-MD5 is at the top of the list (I excluded IDEA in my openssl), which works fine with my server (openssl s_client -cipher EDH-RSA-DES-CBC3-SHA -connect www.fbunet.de:443), use RC4-MD5. Or is it going from the bottom to the top? Nevertheless, please let me also make this a strong feature request on supporting AES, since DES is now officially deprecated and AES will become the new standard. Ciphers like RC4-MD5 should work against most older servers out there and AES with the newer ones.
* George Staikos <staikos@kde.org>: > > I'm reading what your writing very carefully. > > You say ASE256 isn't supported yet, because it's a new cipher. > > But AES128 and AES256 appear at the top of my list of SSLv3 ciphers (I > > deactivated SSLv2), but they are not used. They appear, they are active, > > they are at the top of the list, they are supported by the local > > openssl-version, but they aren't used. Simple question: Why? Why do they > > appear if they don't get used? > > They are used, but as I said, they are stuck onto the end off the preference > list because we don't know about them yet. For all we know, they could be > null ciphers. They could indeed be used if all other cipher negotiations > fail though. But: Assume the KDE side only knows SOME old ciphers with an order imposed on the "strenght" of the ciphers. Why does is choose the WEAKEST cipher it knows? Shouldn't it at least go for some old DES or 3DES cipher that was known at the time of writing (given that the other side knows these as well).
The cipher selection scheme is specified in part by the TLSv1 standard: * The client sends the list of its supported ciphers, sorted by its preference. * The server now chooses a common cipher from this list. The standard does not impose any selection rules, it is just that the server makes the selection. For applications using an OpenSSL based server, the OpenSSL library does select the cipher according to the client's preference. The first cipher also supported by the server will be chosen. (Note: as of OpenSSL 0.9.7 we have added a new option that would make the server choose according to its own preferences, but probably very few servers will have this option activated.) Unless the cipher selection is overridden by an application, both OpenSSL client and server do use a strength based sorting with strength being defined by the effective key length (see "man ciphers"). An additional selection criterion is the actual availability of the requirements to use the cipher. Most ciphers will require an RSA key to be available (some others will require a DSS (DSA) key). The most important thing to evaluate is the use of ephemeral Diffie Hellman (EDH) key exchange which provided forward secrecy and is the standard for most cipher suites but requires explicit initialization at the API level. Please use "openssl ciphers -v" to get a sorted list of cipher suites including its properties (Kx=key exchange Au=authentication). I would also recommend to use the "ssldump" tool to analyze the actual list of ciphers sent by the client (this list is always sent in the clear) and some parts of the information sent by the server which are still send in the clear. There is no way to learn about the server's supported ciphers and selection rules from remote. (SSLv2 was different in that the server sent its preferred list...)
OK, this is what 3.3beta2 sends with all ciphers enabled (I still don't get why the strongest ciphers are not at the top, according to Lutz the server will simply pick the first one he supports and currently, that's almost everytime RC4-MD5, even if better ciphers are available): SSL_RSA_WITH_RC4_128_MD5 SSL2_CK_RC4 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_IDEA_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_RC2 SSL2_CK_3DES SSL2_CK_IDEA Unknown value 0x39 Unknown value 0x38 Unknown value 0x35 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0x33 Unknown value 0x32 Unknown value 0x2f SSL_DHE_DSS_WITH_RC4_128_SHA SSL2_CK_RC464 SSL2_CK_DES SSL_DHE_DSS_WITH_RC2_56_CBC_SHA SSL_RSA_EXPORT1024_WITH_RC4_56_SHA SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 SSL_RSA_EXPORT1024_WITH_RC4_56_MD5 SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL2_CK_RC2_EXPORT40 SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL2_CK_RC4_EXPORT40 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_NULL_MD5
Hmm. I am not familiar with the KDE source. If you could direct where to find the relevant pieces I could have a look into it. Actually I would be looking for SSL_CTX_set_cipher_list() or SSL_set_cipher_list() calls. Beyond that (and again: I am not familiar with the KDE build) I am talking about the behaviour of the OpenSSL library. There do exist other implemantions of SSL/TLS libraries the behaviour of which is beyond my scope.
According to George, KDE uses a static list of ciphers it will use via openssl. This list is fixed and since RC4-MD5 is at the top of the list, it will nearly always be the one that's used (only, if RC4-MD5 is not supported, kssl will try a different cipher). AES is not in the list, even if openssl0.9.7 is installed and so I've never seen a connection with anything else than RC4-MD5. The responsible code is here: http://lxr.kde.org/source/kdelibs/kio/kssl/ especially http://lxr.kde.org/source/kdelibs/kio/kssl/ksslsettings.cc (check the comment around line 155)
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)...
That's exactly my request and the reason I did this bugreport. But George disagrees, see #2 and #17 (and most of the other comments). I'd like to see openssl do the handshake. Currently, there's no way to get konqueror use AES or anything better than RC4-MD5 (without switching it off and breaking compatibility). I've never experienced problems with openssl-handshake, it always choose the strongest cipher available.
On Friday 06 August 2004 07:58, Fridtjof Busse wrote: > ------- Additional Comments From kde fbunet de 2004-08-06 13:58 ------- > That's exactly my request and the reason I did this bugreport. But George > disagrees, see #2 and #17 (and most of the other comments). I'd like to see > openssl do the handshake. Currently, there's no way to get konqueror use > AES or anything better than RC4-MD5 (without switching it off and breaking > compatibility). I've never experienced problems with openssl-handshake, it > always choose the strongest cipher available. How many times do I have to repeat? We had many bugs reported, and I discovered many other sites on my own, where Konqueror was not compatible with the server. This is not theoretical, this is real-world stuff. In many cases it was due to crappy server software, but that's irrelevant from my perspective. If it works with IE, it has to work with Konqueror. We also had to deal with crypto export rules (thereby disabling ciphers in Konqueror even if they're available in OpenSSL - yes this is a "real world situation"), we had to remove ADH ciphers (as-per RFC2246) since OpenSSL doesn't remove them by default, we had to push some ciphers down in priority and others up in priority to make certain servers talk to us, we had requests to make the list configurable for those who don't trust ciphers X or Y, and we had cases where OpenSSL by default was negotiating, as people claimed, "weaker ciphers" than necessary with the server. If OpenSSL has a way to compare cipher strength (whatever that means), then we'll support it. Otherwise, wait for the next KDE release and if I get time, I'll add the new ciphers into Konqueror's "acceptable" list assuming they pass at least some of my testcases. Finally, why is RC4-MD5 the top cipher on the list? Because there were (real) sites out there that just wouldn't talk to us otherwise and I hadn't found any other cipher that works.
Do you still have URL's of some of those webpages? I'd like to see what's going wrong there.
On Monday 09 August 2004 10:17, Fridtjof Busse wrote: > Do you still have URL's of some of those webpages? I'd like to see what's > going wrong there. None off-hand, though I remember that there were a couple in .za that were particularily annoying. Bugzilla has a better memory than I do anyway.
I searched bugs.kde.org and only found only three bugreports about ciphers (don't want to search for hours). I tested those pages with openssl and openssl choose one time the same cipher (RC4) as konqueror and twice a stronger one. Can't reproduce the problem, here are the pages I found in bugs.kde.org, tested with "openssl s_client -connect $page:443" #20094: www.hfcu.org -> DHE-RSA-AES256-SHA #16544: www.fortify.net -> EDH-RSA-DES-CBC3-SHA #40461: www.absadirect.co.za -> RC4-MD5 (bug is not about weak ciphers, but it's the only za-domain I found a report about) Nothing unusual. Are you sure there wan't an error in the API KDE used to communicate with openssl? Or maybe it was simply a long-fixed bug in openssl itself?
On Monday 09 August 2004 12:26, Fridtjof Busse wrote: > I searched bugs.kde.org and only found only three bugreports about ciphers > (don't want to search for hours). I tested those pages with openssl and > openssl choose one time the same cipher (RC4) as konqueror and twice a > stronger one. Can't reproduce the problem, here are the pages I found in > bugs.kde.org, tested with "openssl s_client -connect $page:443" > > #20094: www.hfcu.org -> DHE-RSA-AES256-SHA > #16544: www.fortify.net -> EDH-RSA-DES-CBC3-SHA > #40461: www.absadirect.co.za -> RC4-MD5 (bug is not about weak ciphers, but > it's the only za-domain I found a report about) Yes this is one of the reasons I gave for why we adjust certain ciphers up. > Nothing unusual. > Are you sure there wan't an error in the API KDE used to communicate with > openssl? Or maybe it was simply a long-fixed bug in openssl itself? It could be, but because I don't have evidence and things generally work the way they are, I am not going to risk breaking anything to add this new feature (any way you look at it, a new cipher is a new feature) until the next release, and until it is properly tested.
> Yes this is one of the reasons I gave for why we adjust certain ciphers up. Why? It clearly shows that openssl has no problem at all identifying the strongest cipher. Only one page uses RC4-MD5, konquerors current first choice. So leaving the choice to openssl works as supposed. I'm not suggesting to change anything in 3.3 (it's too late for that anyway), but for 3.4 this should definitly be changed (unless it's verified that openssl's cipher-choice is broken). Otherwise you would have too add all new ciphers to KDE everytime it changes, so it makes perfect sense to use the openssl-API and leave the handshake completly to openssl. And even if you use the openssl-API, IMHO you'd still have the ability to disable the use of certain ciphers (e.g. IDEA). I'm willing to test this stuff extensivly.
On Monday 09 August 2004 14:50, Fridtjof Busse wrote: > Why? It clearly shows that openssl has no problem at all identifying the > strongest cipher. Only one page uses RC4-MD5, konquerors current first > choice. So leaving the choice to openssl works as supposed. > > I'm not suggesting to change anything in 3.3 (it's too late for that > anyway), but for 3.4 this should definitly be changed (unless it's verified > that openssl's cipher-choice is broken). Otherwise you would have too add > all new ciphers to KDE everytime it changes, so it makes perfect sense to > use the openssl-API and leave the handshake completly to openssl. And even > if you use the openssl-API, IMHO you'd still have the ability to disable > the use of certain ciphers (e.g. IDEA). I'm willing to test this stuff > extensivly. ksslsettings.cc: ---------------------------- revision 1.19 date: 2001/07/26 03:11:32; author: staikos; state: Exp; lines: +34 -3 Try to make SSL even more compatible with stupid servers by doing stupid things. + // Hack time + // --------- + // A lot of these webservers suck. So in order to get around their + // sucking, we take the most common ciphers and make them the first ones + // we offer. This seems to make it work better. + // + + // Put least preferred first, most preferred last. + CipherNode tnode("", 0); + +#define AdjustCipher(X, Y) tnode.name = X; tnode.keylen = Y; \ + if (cipherSort.find(&tnode) != -1) { \ + cipherSort.remove(); \ + cipherSort.append(new CipherNode(tnode.name.latin1(), tnode.keylen)); \ + } + + AdjustCipher("IDEA-CBC-MD5", 128); + AdjustCipher("DES-CBC3-MD5", 168); + AdjustCipher("RC2-CBC-MD5", 128); + AdjustCipher("DES-CBC3-SHA", 168); + AdjustCipher("IDEA-CBC-SHA", 128); + AdjustCipher("RC4-SHA", 128); + AdjustCipher("RC4-MD5", 128); +#undef AdjustCipher I am really not inclined to change code that I put effort into writing in order to work around real world bugs. I am willing to consider placing the new ciphers in there, though most likely not higher than RC4-MD5 at this time.
Maybe this should be dragged to the "full-disclosure" mailinglist: "Konqueror selects low security encryption to be as insecure as IE". Or something like that.
See http://www.openssl.org/docs/apps/ciphers.html. Also the book Network Security with OpenSSL recommends to set ciphers with string: "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH" - @STRENGTH sorts the list by key length. Not sure if that sorting is what you really want, though.
*** This bug has been confirmed by popular vote. ***
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?
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.
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
It seems that this may at last have been changed in KDE 3.5 ? At least, Konqui 3.5.3 sends TLS_DHE_RSA_WITH_AES_256_CBC_SHA at the top of the cypher suite rather than SSL2_RC4_128_WITH_MD5, resulting in a rather more secure connection.