[openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
The fix was committed in 995207bedcc58f2fa1bd7c460ee530b92c7dfbfe, so I think we can resolve this ticket. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Hello, Stephen Henson via RT r...@openssl.org wrote: |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: | If people start using SSL_CONF_CTX as they are supposed to with | v1.0.2, then it can be expected that users start using strings | like, e.g. (from my thing), | | set ssl-protocol=ALL,-SSLv2 |If you print out the additional error data it should also indicate which |command and value it is objecting to, though it will only \ |say it doesn't like |the whole string and not the specific part of it it is rejecting. Oh i'm not complaining on that, error handling is always weird, and i think strings like error:140D00CF:SSL routines:SSL_write:protocol is shutdown are hard (not only to parse) for users but there is a lot of information for good in very few bytes; sad is Received SIGPIPE during IMAP operation IMAP write error: error::lib(0):func(0):reason(0) but as i think for most (Open)SSL related problems this is all my / our fault, users should not be bothered with that. Strings are intransparent for application programmers, but myriads of error enumerations can be too. Whatever. Regarding #3625: i think no user (that made it so far at first glance, which maybe even required buying a book and reading a lot!) would expect an error for saying -SSLv2. But since it was an accidental oversight and the _OP_NO_SSLv2 is still defined (what i didn't even look for after reading the commit message) i think it'll be ok anyway once committed and this can be closed? Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Hello, Stephen Henson via RT r...@openssl.org wrote: |On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: | If people start using SSL_CONF_CTX as they are supposed to with | v1.0.2, then it can be expected that users start using strings | like, e.g. (from my thing), | | set ssl-protocol=ALL,-SSLv2 |If you print out the additional error data it should also indicate which |command and value it is objecting to, though it will only \ |say it doesn't like |the whole string and not the specific part of it it is rejecting. Oh i'm not complaining on that, error handling is always weird, and i think strings like error:140D00CF:SSL routines:SSL_write:protocol is shutdown are hard (not only to parse) for users but there is a lot of information for good in very few bytes; sad is Received SIGPIPE during IMAP operation IMAP write error: error::lib(0):func(0):reason(0) but as i think for most (Open)SSL related problems this is all my / our fault, users should not be bothered with that. Strings are intransparent for application programmers, but myriads of error enumerations can be too. Whatever. Regarding #3625: i think no user (that made it so far at first glance, which maybe even required buying a book and reading a lot!) would expect an error for saying -SSLv2. But since it was an accidental oversight and the _OP_NO_SSLv2 is still defined (what i didn't even look for after reading the commit message) i think it'll be ok anyway once committed and this can be closed? Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: are hard (not only to parse) for users but there is a lot of information for good in very few bytes; sad is Received SIGPIPE during IMAP operation IMAP write error: error::lib(0):func(0):reason(0) OpenSSL itself should never generate that error through (for example) ERR_print_errors(): if anyone can do that I'd like details and it will be fixed. If ERR_get_error() returns zero it indicates there is no error in the error queue if an application doesn't check for that value and attempts to interpret it as an error code you get the result above... Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Dr. Stephen Henson st...@openssl.org wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: | are hard (not only to parse) for users but there is a lot of | information for good in very few bytes; sad is | | Received SIGPIPE during IMAP operation | IMAP write error: error::lib(0):func(0):reason(0) | |OpenSSL itself should never generate that error through (for example) |ERR_print_errors(): if anyone can do that I'd like details and it will be |fixed. If ERR_get_error() returns zero it indicates there is no error in Ok. I really have a lot of work to do with my thing... |the error queue if an application doesn't check for that value |and attempts to interpret it as an error code you get the result above... Sigh. And then these old codebases that jump around like grazy from the middle of nowhere. Amazing how stable all that is with all the, also thread-safe, third party libaries linked into it, just like OpenSSL. But that is not your problem, of course. Thank you. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Dr. Stephen Henson st...@openssl.org wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: | are hard (not only to parse) for users but there is a lot of | information for good in very few bytes; sad is | | Received SIGPIPE during IMAP operation | IMAP write error: error::lib(0):func(0):reason(0) | |OpenSSL itself should never generate that error through (for example) |ERR_print_errors(): if anyone can do that I'd like details and it will be |fixed. If ERR_get_error() returns zero it indicates there is no error in Ok. I really have a lot of work to do with my thing... |the error queue if an application doesn't check for that value |and attempts to interpret it as an error code you get the result above... Sigh. And then these old codebases that jump around like grazy from the middle of nowhere. Amazing how stable all that is with all the, also thread-safe, third party libaries linked into it, just like OpenSSL. But that is not your problem, of course. Thank you. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: Commit [45f55f6] (Remove SSLv2 support, 2014-11-30) completely removed SSLv2 support and the commit message states The only support for SSLv2 left is receiving a SSLv2 compatible client hello. If people start using SSL_CONF_CTX as they are supposed to with v1.0.2, then it can be expected that users start using strings like, e.g. (from my thing), set ssl-protocol=ALL,-SSLv2 This results in the obvious problem that when they (get) upgrade(d) their OpenSSL library they will see a completely intransparent error message that no normal user will understand: SSL_CONF_CTX_cmd() failed:\ error:1414E180:SSL routines:SSL_CONF_CTX_cmd:bad value (Ah ja, my _CTX_ diff also works in practice.) I think it would be much better if at least a user request to explicitly disable SSLv2 is silently ignored. Another option would be to enhance the error message, of course... If you print out the additional error data it should also indicate which command and value it is objecting to, though it will only say it doesn't like the whole string and not the specific part of it it is rejecting. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Kurt Roeckx via RT r...@openssl.org wrote:
|On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
| set ssl-protocol=ALL,-SSLv2
|
| This results in the obvious problem that when they (get)
| upgrade(d) their OpenSSL library they will see a completely
| intransparent error message that no normal user will understand:
|
|It was actually my intention to keep supporting that, but I seem
|to have removed that line. I think the following patch should fix
|that:
|--- a/ssl/ssl_conf.c
|+++ b/ssl/ssl_conf.c
|@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
|const char *value)
|static const ssl_flag_tbl ssl_protocol_list[] =
|{
|SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
|+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
|SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
|SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
|SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.
--steffen
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Kurt Roeckx via RT r...@openssl.org wrote:
|On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
| set ssl-protocol=ALL,-SSLv2
|
| This results in the obvious problem that when they (get)
| upgrade(d) their OpenSSL library they will see a completely
| intransparent error message that no normal user will understand:
|
|It was actually my intention to keep supporting that, but I seem
|to have removed that line. I think the following patch should fix
|that:
|--- a/ssl/ssl_conf.c
|+++ b/ssl/ssl_conf.c
|@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
|const char *value)
|static const ssl_flag_tbl ssl_protocol_list[] =
|{
|SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
|+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
|SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
|SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
|SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.
--steffen
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
set ssl-protocol=ALL,-SSLv2
This results in the obvious problem that when they (get)
upgrade(d) their OpenSSL library they will see a completely
intransparent error message that no normal user will understand:
It was actually my intention to keep supporting that, but I seem
to have removed that line. I think the following patch should fix
that:
--- a/ssl/ssl_conf.c
+++ b/ssl/ssl_conf.c
@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
const char *value)
static const ssl_flag_tbl ssl_protocol_list[] =
{
SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Kurt
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
