openssl: be less verbose about cipher translation errors
PATCH 1/1 openssl: be less verbose about cipher translation errors
Translation errors are usually not a real problem, since we don't maintain the complete list of ciphers OpenSSL supports. So, be less verbose if we can not find a translation.
Also, add 'translations' for commonly used negated cipher suites to suppress messages about those completely.
--- src/openvpn/ssl.c | 21 +++++++++++---------- src/openvpn/ssl_openssl.c | 2 +- 2 files changed, 12 insertions(+), 11 deletions(-)
src/openvpn/ssl.c +11 -10
@@ -232,18 +232,19 @@ static const tls_cipher_name_pair tls_cipher_name_translation_table[] = { {"SRP-RSA-AES-128-CBC-SHA", "TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA"}, {"SRP-RSA-AES-256-CBC-SHA", "TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA"}, #ifdef ENABLE_CRYPTO_OPENSSL +/* OpenSSL-specific group names */ {"DEFAULT", "DEFAULT"}, {"ALL", "ALL"}, - {"HIGH", "HIGH"}, - {"MEDIUM", "MEDIUM"}, - {"LOW", "LOW"}, - {"ECDH", "ECDH"}, - {"ECDSA", "ECDSA"}, - {"EDH", "EDH"}, - {"EXP", "EXP"}, - {"RSA", "RSA"}, - {"kRSA", "kRSA"}, - {"SRP", "SRP"}, + {"HIGH", "HIGH"}, {"!HIGH", "!HIGH"}, + {"MEDIUM", "MEDIUM"}, {"!MEDIUM", "!MEDIUM"}, + {"LOW", "LOW"}, {"!LOW", "!LOW"}, + {"ECDH", "ECDH"}, {"!ECDH", "!ECDH"}, + {"ECDSA", "ECDSA"}, {"!ECDSA", "!ECDSA"}, + {"EDH", "EDH"}, {"!EDH", "!EDH"}, + {"EXP", "EXP"}, {"!EXP", "!EXP"}, + {"RSA", "RSA"}, {"!RSA", "!RSA"}, + {"kRSA", "kRSA"}, {"!kRSA", "!kRSA"}, + {"SRP", "SRP"}, {"!SRP", "!SRP"}, #endif {NULL, NULL} };
src/openvpn/ssl_openssl.c +1 -1
@@ -272,7 +272,7 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers)// Issue warning on missing translation // %.*s format specifier expects length of type int, so guarantee // that length is small enough and cast to int. -msg (M_WARN ,"No valid translation found for TLS cipher '%.*s'" , +msg (D_LOW ,"No valid translation found for TLS cipher '%.*s'" ,constrain_int (current_cipher_len,0 ,256 ), current_cipher); }else
Signature · 1 line
2.1.4
Hi,
Quoted 3 lines · Steffan Karger
Translation errors are usually not a real problem, since we don't maintain the complete list of ciphers OpenSSL supports. So, be less verbose if we can not find a translation.
I wonder what the motivation on this one is. If the user requests a certain cipher, and we can't give it to him - shouldn't this be warned about quite prominently?
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Am 08.10.15 um 08:43 schrieb Gert Doering:
Quoted 11 lines
Hi,
Quoted 3 lines · Steffan Karger
Translation errors are usually not a real problem, since we don't maintain the complete list of ciphers OpenSSL supports. So, be less verbose if we can not find a translation.
I wonder what the motivation on this one is. If the user requests a certain cipher, and we can't give it to him - shouldn't this be warned about quite prominently?
The user request a cipher that exists, but is not our translation table. Gets a confusion error message.
Arne
Hi,
Quoted 6 lines · Arne Schwabe
Am 08.10.15 um 08:43 schrieb Gert Doering:
Quoted 5 lines · Steffan Karger
Quoted 3 lines
Translation errors are usually not a real problem, since we don't maintain the complete list of ciphers OpenSSL supports. So, be less verbose if we can not find a translation.
Quoted 6 lines
Quoted 3 lines
I wonder what the motivation on this one is. If the user requests a certain cipher, and we can't give it to him - shouldn't this be warned about quite prominently?
The user request a cipher that exists, but is not our translation table. Gets a confusion error message.
But what happens in that case? PolarSSL build, user requests something he knows from OpenSSL, we don't have a translation entry for it - will he receive "the default cipher set" (not what he is asking for) then?
I'm not sure I truly understand the scenarios where a user would trigger that warning, which is why I'm asking.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Hi,
Quoted 11 lines · Gert Doering
Quoted 10 lines · Arne Schwabe
Am 08.10.15 um 08:43 schrieb Gert Doering:
Quoted 8 lines · Steffan Karger
Quoted 3 lines
Translation errors are usually not a real problem, since we don't maintain the complete list of ciphers OpenSSL supports. So, be less verbose if we can not find a translation.
I wonder what the motivation on this one is. If the user requests a certain cipher, and we can't give it to him - shouldn't this be warned about quite prominently?
Quoted 6 lines
Quoted 2 lines
The user request a cipher that exists, but is not our translation table. Gets a confusion error message.
But what happens in that case? PolarSSL build, user requests something he knows from OpenSSL, we don't have a translation entry for it - will he receive "the default cipher set" (not what he is asking for) then?
What our translation does is "if we know a translation for a cipher, then replace with translation, else warn and leave original". The resulting cipher string is then passed to the crypto library. The crypto library will then either connect or give a (sometimes cryptic) error. We do this, because we simply can't keep track of all (new, or just exotic) cipher names, but do want to offer config compatibility for most standard setups between polar<>openssl.
However, as Arne said, the current warning about cipher translations often puts users on the wrong track when debugging connection problems. (Although that usually just means they should no use --tls-cipher...) So, add some commonly used negated ciphers and hide the (often innocent) warning a bit more.
-Steffan
Hi,
Quoted 11 lines · Steffan Karger
Quoted 3 lines
But what happens in that case? PolarSSL build, user requests something he knows from OpenSSL, we don't have a translation entry for it - will he receive "the default cipher set" (not what he is asking for) then?
What our translation does is "if we know a translation for a cipher, then replace with translation, else warn and leave original". The resulting cipher string is then passed to the crypto library. The crypto library will then either connect or give a (sometimes cryptic) error. We do this, because we simply can't keep track of all (new, or just exotic) cipher names, but do want to offer config compatibility for most standard setups between polar<>openssl.
OK, now I understand. So if a User puts in a polarssl cipher, he might end up with a (non-useful) warning about "translation not found!" while polarssl is all happy about it - and if he puts in a totally unknown OpenSSL cipher, polarssl will refuse it anyway, so no need to have an extra warning.
This is perfectly fine for me, then - I was just a bit worried about "unexpected behaviour happening, with no clear warning".
(ACK)
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...ACK. Your patch has been applied to the master branch.
commit 7246ccfdbe6039c5c578ecaa07505307d53b8e84
Author: Steffan Karger Date: Tue Oct 6 20:38:27 2015 +0200
openssl: be less verbose about cipher translation errors
Signed-off-by: Steffan Karger <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10198
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering