Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Thu, Dec 11, 2014 at 07:37:39PM +0100, Steffen Nurpmeso wrote: Salz, Rich via RT r...@openssl.org wrote: So you want a separate openssl-conf package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. Yes it does. :) A newer simpler API that does what you want \ seems exactly the way forward. Go for it. You sound pretty good and done here.. Gratulations. [Laughter] Emails sent to an RT issue are automatically forwarded by the system to the openssl-dev ML. There's no need to explicitly cc: openssl-dev as you're doing - all that does is clutter the ML with duplicates. --mancha pgpEIPrzJdpDY.pgp Description: PGP signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Thu, Dec 11, 2014 at 07:37:39PM +0100, Steffen Nurpmeso wrote: Salz, Rich via RT r...@openssl.org wrote: So you want a separate openssl-conf package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. Yes it does. :) A newer simpler API that does what you want \ seems exactly the way forward. Go for it. You sound pretty good and done here.. Gratulations. [Laughter] Emails sent to an RT issue are automatically forwarded by the system to the openssl-dev ML. There's no need to explicitly cc: openssl-dev as you're doing - all that does is clutter the ML with duplicates. --mancha pgpZ4yK6BYk8V.pgp Description: PGP signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | Personally i am willing to put enough trust in the OpenSSL team *even | insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' | and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is enough to be responsible for the code. | |There are better alternatives, including bettercrypto.org \ |and another proposal from RedHat to have site/distro-specific 'profiles' Sorry but i simply fail to understand your point of view. I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as MIN/MAX/SECURE (bring, but.. understandable). But i really missed (and still miss) the possibility on the _OP_NO_ level, and being able to completely bypass my own thing and give the user a direct hook into OpenSSL via _CONF_ is a great thing to have. That is what is actual fact in normal user space applications, if you want to replace that by some installation-wide policy then this is a nice idea, but it'll take decades until it reaches the last (maintained) application. Many programs support multiple TLS/SSL implementations and need to be able to configure the one which the user actually chooses to use / is available on the box. So your proposal needs to be adhered to by other TLS/SSL providers too in order to release applications from their compatibility problem. Of course i need an application internal compatibility layer for those implementations which don't support a direct _CONF_ hook as OpenSSL will start to support with v1.0.2 (though reducing my own thing to only support OpenSSL was one of the first steps i did, yet support for others will be readded later again). And for those i need to know relationships, what is secure etc. But i also need to know actual protocol names anyway, so whatever i do, without active maintainership things will rot. This is why i would be very happy if there would be NEWEST, because even a rotted codebase would be automatically secure -- should the NEWEST protocol be secure. And if NEWEST is not supported by some counterpart server, then the user can still fine-tune and lower as far as necessary. I think this is the much better way 'round. Giving a user an option to actively deselect what is known not to be secure for a library release that still needs to support old protocols due to compatibility reasons can't be wrong. Of course users are capable to understand that a library update is necessary to overcome a newly detected insecurity. The maintenance burden of the OpenSSL library seems to be pretty drastic; regarding these strings those could be placed into ssl.h, maybe encapsulated in some library-built-time preprocessor toggle. Surely my own thing can be enhanced a lot, with more configuration options for users, with adhering to system wide defaults, but i am only one and that needs more time. I neither have the time nor the will (i am an elder man in the end) to spend time on rat racing some stylish internet pages. If i want communication i listen to good interprets of classical music. Thanks for your consideration. Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Yoav Nir ynir.i...@gmail.com wrote: | On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org \ | wrote: | Salz, Rich rs...@akamai.com wrote: ||I think magic names -- shorthands -- are a very bad idea. \ | | I _completely_ disagree. | || They are point-in-time statements whose meaning evolves, \ ||if not erodes, over time. | | Because i don't think that a normal user, or even normal | administrators and programmers is and are willing or even capable | to understand what they are doing. |decision than most administrators. Nevertheless, if upgrading \ |OpenSSL from version X to version Y causes a ciphersuite (or \ |TLS version) to be dropped into VULNERABLE, there are going \ |to be angry phone calls from users whose browser or application \ |has stopped working. It is the administrator who is going \ Applications don't need to use -VULNERABLE/+SECURE. Heck, the monster ones have become so intransparent that i have to place such an enormous trust into them that i only use one, Firefox, but that does terrible things and there is no knob that i can toggle wheresoever. (I've used Opera for over a decade and am very new to Firefox: i'm pretty sure there is some kind of registry that experienced users can tweak. But still: certainly neither in the Advanced nor the Security Tab.) _How_ i would appreciate being able to enter -VULNERABLE in some text field. And have a nicer and easier exception handling, too. Can be imagined. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update \ |that added the broken crypto to the VULNERABLE list, and \ |everyone didn't update immediately. | |Policy and configuration should be on a separate, arguably \ |faster, distribution pattern than code. Which is why I favor \ |a profile mechanism in openssl.conf and not hardwired magic \ |keywords embedded in code. So you want a separate openssl-conf package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. | |Perhaps modesty prevented you from posting the link, but it \ |won't stop me (we're both in the acknowledgements section :) | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I have to look into OCSP. (But it has nothing to do with #3627.) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | I'd love to see a version of bettercrypto.org that only \ | has to say to configure | OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a magic string? I mean i hope we come to an end with this soon... But doesn't a OpenSSL library installation _as such_ represent such an immense combination of magic, regarding the internal configuration settings..? I wouldn't have a problem if you would add even more VULNERABLE, also to other _CONF_ settings. But i'm simple minded and as of today Protocol is just about anything that my thing is concerned of. :-) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Hi. Richard Moore richmoor...@gmail.com wrote: | Programs which use the OpenSSL library generally just want to flip a | switch and know that they've turned on security, instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect that if it works in the browser it |should work everywhere - even when the browser is jumping through hoops |like fetching missing intermediate certificates, downgrading security etc. But now that it is christmas they can at least donate some dollars to some charitable aid organisation. |If the world were perfect and the browsers didn't do this then life would |be a lot easier. Ah, come on. No. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | Personally i am willing to put enough trust in the OpenSSL team *even | insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' | and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is enough to be responsible for the code. | |There are better alternatives, including bettercrypto.org \ |and another proposal from RedHat to have site/distro-specific 'profiles' Sorry but i simply fail to understand your point of view. I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as MIN/MAX/SECURE (bring, but.. understandable). But i really missed (and still miss) the possibility on the _OP_NO_ level, and being able to completely bypass my own thing and give the user a direct hook into OpenSSL via _CONF_ is a great thing to have. That is what is actual fact in normal user space applications, if you want to replace that by some installation-wide policy then this is a nice idea, but it'll take decades until it reaches the last (maintained) application. Many programs support multiple TLS/SSL implementations and need to be able to configure the one which the user actually chooses to use / is available on the box. So your proposal needs to be adhered to by other TLS/SSL providers too in order to release applications from their compatibility problem. Of course i need an application internal compatibility layer for those implementations which don't support a direct _CONF_ hook as OpenSSL will start to support with v1.0.2 (though reducing my own thing to only support OpenSSL was one of the first steps i did, yet support for others will be readded later again). And for those i need to know relationships, what is secure etc. But i also need to know actual protocol names anyway, so whatever i do, without active maintainership things will rot. This is why i would be very happy if there would be NEWEST, because even a rotted codebase would be automatically secure -- should the NEWEST protocol be secure. And if NEWEST is not supported by some counterpart server, then the user can still fine-tune and lower as far as necessary. I think this is the much better way 'round. Giving a user an option to actively deselect what is known not to be secure for a library release that still needs to support old protocols due to compatibility reasons can't be wrong. Of course users are capable to understand that a library update is necessary to overcome a newly detected insecurity. The maintenance burden of the OpenSSL library seems to be pretty drastic; regarding these strings those could be placed into ssl.h, maybe encapsulated in some library-built-time preprocessor toggle. Surely my own thing can be enhanced a lot, with more configuration options for users, with adhering to system wide defaults, but i am only one and that needs more time. I neither have the time nor the will (i am an elder man in the end) to spend time on rat racing some stylish internet pages. If i want communication i listen to good interprets of classical music. Thanks for your consideration. Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Yoav Nir ynir.i...@gmail.com wrote: | On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org \ | wrote: | Salz, Rich rs...@akamai.com wrote: ||I think magic names -- shorthands -- are a very bad idea. \ | | I _completely_ disagree. | || They are point-in-time statements whose meaning evolves, \ ||if not erodes, over time. | | Because i don't think that a normal user, or even normal | administrators and programmers is and are willing or even capable | to understand what they are doing. |decision than most administrators. Nevertheless, if upgrading \ |OpenSSL from version X to version Y causes a ciphersuite (or \ |TLS version) to be dropped into VULNERABLE, there are going \ |to be angry phone calls from users whose browser or application \ |has stopped working. It is the administrator who is going \ Applications don't need to use -VULNERABLE/+SECURE. Heck, the monster ones have become so intransparent that i have to place such an enormous trust into them that i only use one, Firefox, but that does terrible things and there is no knob that i can toggle wheresoever. (I've used Opera for over a decade and am very new to Firefox: i'm pretty sure there is some kind of registry that experienced users can tweak. But still: certainly neither in the Advanced nor the Security Tab.) _How_ i would appreciate being able to enter -VULNERABLE in some text field. And have a nicer and easier exception handling, too. Can be imagined. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update \ |that added the broken crypto to the VULNERABLE list, and \ |everyone didn't update immediately. | |Policy and configuration should be on a separate, arguably \ |faster, distribution pattern than code. Which is why I favor \ |a profile mechanism in openssl.conf and not hardwired magic \ |keywords embedded in code. So you want a separate openssl-conf package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. | |Perhaps modesty prevented you from posting the link, but it \ |won't stop me (we're both in the acknowledgements section :) | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I have to look into OCSP. (But it has nothing to do with #3627.) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote: | I'd love to see a version of bettercrypto.org that only \ | has to say to configure | OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a magic string? I mean i hope we come to an end with this soon... But doesn't a OpenSSL library installation _as such_ represent such an immense combination of magic, regarding the internal configuration settings..? I wouldn't have a problem if you would add even more VULNERABLE, also to other _CONF_ settings. But i'm simple minded and as of today Protocol is just about anything that my thing is concerned of. :-) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Hi. Richard Moore richmoor...@gmail.com wrote: | Programs which use the OpenSSL library generally just want to flip a | switch and know that they've turned on security, instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect that if it works in the browser it |should work everywhere - even when the browser is jumping through hoops |like fetching missing intermediate certificates, downgrading security etc. But now that it is christmas they can at least donate some dollars to some charitable aid organisation. |If the world were perfect and the browsers didn't do this then life would |be a lot easier. Ah, come on. No. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
So you want a separate openssl-conf package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. Yes it does. :) A newer simpler API that does what you want seems exactly the way forward. Go for it. I've said that adding new magic keywords is not something we're going to do, and I've tried to explain the reasoning. I am sorry that you don't like it. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote: Hello, and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. Just to add my 2p to this thread which seems to have veered into rather different territory... I don't think it's appropriate to have a VULNERABLE option as a protocol selection value partly because vulnerability rarely affects a whole protocol version, just aspects of it. You can (for example) restrict yourself to TLS v1.2 and still do insecure things such as talk to servers with 512 bit RSA keys or using 256 bit DH parameters. Your request seems closer to the security levels code which is currently only in the OpenSSL master branch. It will by default reject many things: including the RSA, DH examples above. An application can increase the security level to make things stricter (but this will fail for many existing servers so it isn't the default), disable it completely and handle everything themselves (which is what previous versions of OpenSSL do) or have finer control using an application specific callback. 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 #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote:
| So you want a separate openssl-conf package. Fine, then provide it and
| give an easy mechanism for applications to hook into it.
| And for users to be able to overwrite system defaults.
| But this has not that much to do with #3627.
|
|Yes it does. :) A newer simpler API that does what you want \
|seems exactly the way forward. Go for it.
You sound pretty good and done here.. Gratulations. [Laughter]
Regarding the interface: back in 2011 i have started (only) writing
a Python (grr) script, which had a really simple way of doing
_any_ socket connection via
class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator
The basic concept was that all you can do is
def create_connection(serv, cafile=None, all_fingerprints=False):
where serv is a class Service,
class Service(Config.Section):
that directly maps to a configuration type (shortened by doc)
[service]
uid = UID
url = NAME
proto = proto
port = NUMBER
upgrade-secure = BOOLEAN
fetch-folders = mailbox, another-mailbox, ...
options = protocol-dependend (comma separated list of options)
So wether TLS or not you simply
(err, conn) = SaSo.create_connection(serv)
if err:
return (intro + 'connect failure: ' + err, ESTAT_CONNECTION)
print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT)
_maximally_ extended by (for non-initially secured transport)
# Shall we try to upgrade to TLS (RFC 2595)?
if self.service.upgrade_secure:
resp = self._single('STLS')
if not resp:
self.error_append('\nServer does not seem to support secure ' +
'transport.\nYou need to disable the *upgrade-secure* ' +
'configuration setting.')
return
resp = SaSo.wrap_connection(self.conn)
if resp is not None:
self.error = 'failed to perform *upgrade-secure*: ' + resp
return
Cool, eh? S-postman.py was that thing.
_That_ is in essence what i mean -- just think about the current
Python urllib is it CVE-2014-9365: not even programmers that know
do it the right way, how can you expect administrators and normal
users to do so, even _if_ the software allows the necessary
configuration. Nono.
|I've said that adding new magic keywords is not something \
|we're going to do, and I've tried to explain the reasoning. \
| I am sorry that you don't like it.
Despite that i continue to disagree _completely_.
The other way around would be the right way to go for
configuration, and if that doesn't work then the _library_ had to
be adjusted. E.g. by splitting off a small config update package
that updates cipher lists and whatever (i am really not an expert.
Nor do i plan to become one) without the need to recompile
OpenSSL. Cool. But you are not there yet, are you? :-)
So please please, give us MIN and MAX.
Ciao,
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich via RT r...@openssl.org wrote:
| So you want a separate openssl-conf package. Fine, then provide it and
| give an easy mechanism for applications to hook into it.
| And for users to be able to overwrite system defaults.
| But this has not that much to do with #3627.
|
|Yes it does. :) A newer simpler API that does what you want \
|seems exactly the way forward. Go for it.
You sound pretty good and done here.. Gratulations. [Laughter]
Regarding the interface: back in 2011 i have started (only) writing
a Python (grr) script, which had a really simple way of doing
_any_ socket connection via
class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator
The basic concept was that all you can do is
def create_connection(serv, cafile=None, all_fingerprints=False):
where serv is a class Service,
class Service(Config.Section):
that directly maps to a configuration type (shortened by doc)
[service]
uid = UID
url = NAME
proto = proto
port = NUMBER
upgrade-secure = BOOLEAN
fetch-folders = mailbox, another-mailbox, ...
options = protocol-dependend (comma separated list of options)
So wether TLS or not you simply
(err, conn) = SaSo.create_connection(serv)
if err:
return (intro + 'connect failure: ' + err, ESTAT_CONNECTION)
print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT)
_maximally_ extended by (for non-initially secured transport)
# Shall we try to upgrade to TLS (RFC 2595)?
if self.service.upgrade_secure:
resp = self._single('STLS')
if not resp:
self.error_append('\nServer does not seem to support secure ' +
'transport.\nYou need to disable the *upgrade-secure* ' +
'configuration setting.')
return
resp = SaSo.wrap_connection(self.conn)
if resp is not None:
self.error = 'failed to perform *upgrade-secure*: ' + resp
return
Cool, eh? S-postman.py was that thing.
_That_ is in essence what i mean -- just think about the current
Python urllib is it CVE-2014-9365: not even programmers that know
do it the right way, how can you expect administrators and normal
users to do so, even _if_ the software allows the necessary
configuration. Nono.
|I've said that adding new magic keywords is not something \
|we're going to do, and I've tried to explain the reasoning. \
| I am sorry that you don't like it.
Despite that i continue to disagree _completely_.
The other way around would be the right way to go for
configuration, and if that doesn't work then the _library_ had to
be adjusted. E.g. by splitting off a small config update package
that updates cipher lists and whatever (i am really not an expert.
Nor do i plan to become one) without the need to recompile
OpenSSL. Cool. But you are not there yet, are you? :-)
So please please, give us MIN and MAX.
Ciao,
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Stephen Henson via RT r...@openssl.org wrote: |On Mon Dec 08 20:20:44 2014, sdao...@yandex.com wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |Just to add my 2p to this thread which seems to have veered into rather |different territory... Please. Oh yes, i think i have digressed a lot by now. |I don't think it's appropriate to have a VULNERABLE option as a protocol |selection value partly because vulnerability rarely affects a whole protocol |version, just aspects of it. You can (for example) restrict yourself to TLS |v1.2 and still do insecure things such as talk to servers \ |with 512 bit RSA keys |or using 256 bit DH parameters. | |Your request seems closer to the security levels code which \ |is currently only |in the OpenSSL master branch. It will by default reject many \ |things: including |the RSA, DH examples above. An application can increase the \ |security level to |make things stricter (but this will fail for many existing \ |servers so it isn't |the default), disable it completely and handle everything \ |themselves (which is |what previous versions of OpenSSL do) or have finer control using an |application specific callback. Ok, i've never ment to go that much into the details, what i've also said in the other responses. Yours is the view of someone who deeply penetrates the problem for i think way over a decade, mine is rather restricted to a well-known book, what you hear here and there plus some manual reading, no more and no less. On this level SSLv2 is very insecure and so for a very long time, SSLv3 was insecure and now has made it to the same level as is predecessor. After reading the draft linked in a message of this thread and following some references it seems that i drive very well with restricting myself (and recommend users that ask) to TLSv1.2, which i do for well over a year, when i can. I just _never_ played with any other setting regarding TLS/SSL, though i have to admit that i once adjusted a MACs SSH configuration setting (to be able to connect). That is all i know -- and _my_ opinion is that if that is not sufficient, something is wrong. Because _i_ will _never_ accomplish an intellectual penetration of -- short -- anything involved to get at a permanently secured encrypted transport. Just never. And, when that far, i'm a buddhist, actually i'm even disgusted of secure transport as such. Here is all about reflection, canalisation and transformation, but now i think i'm really off-topic. So if that doesn't clash a desire to intellectually penetrate secure transport then i don't know. :-) I'm still hoping for at least (OLDEST/MIN and) NEWEST/MAX. Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) That's partly due to the API naming conventions for enums. :-) Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: | Richard Moore richmoor...@gmail.com wrote: ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org | wrote: || and finally i propose three new values for the Protocol slot of || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. || ||In Qt we've added an enum value for TLS versions that is SecureProtocols | so ||that we could remove versions as required without requiring apps to be ||updated. It's an open question which is more likely to get updated - Qt | or ||the apps of course. For Qt 5.4 which is due out this week we've removed ||SSL3 from this enum so apps will silently get updated to drop support for ||it. | | I see. And i think this is the most impressive or, lesser | enthusiastic, important feature of the slow _CONF_ interface: that | users can use strings and that those are directly swallowed by the | OpenSSL library, so that neither recompilation nor understanding | is necessary on the program side in order to upgrade to a new | level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. | (As a side note: SecureProtocols is such a Volvo wording... | Doesn't vulnerable energises a deeper feeling of insecurity? | I think Hitchcock would have used the naked and bare vulnerable.) | | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Kurt Roeckx via RT r...@openssl.org wrote: |On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |I actually find the option unfortunate and I think it should have |been one that sets the minimum and maximum version. But I think |we're too late 1.0.2 process to still change this. A good benefit for a three line patch. Being able to say -ALL,=TLSv1.1 etc. is surely on the list of many, and much more complicated to implement than that. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
|Kurt Roeckx via RT r...@openssl.org wrote: ||been one that sets the minimum and maximum version. But I think ||we're too late 1.0.2 process to still change this. Attached a git format-patch MBOX for 1.0.2 (on top of [6806b69]). It boils anything down into two changesets (SSL_CONF_CTX and pseudo protocols). Remarks: - I've adjusted anything for SSLv2 (in the PODs, as OLDEST, in VULNERABLE). - s_client.pod and s_server.pod did not yet state that they support the SSL_CONF_CTX arguments, so i've added that (which s_cb.c seems to support already). - make make test work, rest yet just installed. Let me know if you want the same for [master] again. I really hope you do that, and Ciao from Germany --steffen ossl-1_0_2.mbox Description: application/mbox ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. How many people have read all the RFCs that are involved? And how many people have sufficient knowledge to _really_ understand the mathematical concepts and actual algorithms? Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. Imagine that. I have already implemented the necessary _CONF_ wrapper for OpenSSL v1.0.1 and it'll gave you a hand (shall the list receive this message). --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can’t make on their behalf. So there’s bettercrypto.org and there’s Qualys and there’s this BCP document that the UTA working group at the IETF is writing, but ultimately we can’t shove security down people’s throat - just make good tools for them and provide (hopefully) good advice. Yoav ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can’t make on their behalf. So there’s bettercrypto.org and there’s Qualys and there’s this BCP document that the UTA working group at the IETF is writing, but ultimately we can’t shove security down people’s throat - just make good tools for them and provide (hopefully) good advice. Yoav ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE --dkg signature.asc Description: OpenPGP digital signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE --dkg signature.asc Description: PGP signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE That can happen but not by embedding magic strings into code. See http://rt.openssl.org/Ticket/Display.html?id=3266 http://rt.openssl.org/Ticket/Display.html?id=3299 ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called “best_practice_2015”, and when a future version of OpenSSL added “best_practice_2017”, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (“you’ll lose support for all versions of Chrome below 52”) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called “best_practice_2015”, and when a future version of OpenSSL added “best_practice_2017”, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (“you’ll lose support for all versions of Chrome below 52”) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) That's partly due to the API naming conventions for enums. :-) Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: | Richard Moore richmoor...@gmail.com wrote: ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org | wrote: || and finally i propose three new values for the Protocol slot of || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. || ||In Qt we've added an enum value for TLS versions that is SecureProtocols | so ||that we could remove versions as required without requiring apps to be ||updated. It's an open question which is more likely to get updated - Qt | or ||the apps of course. For Qt 5.4 which is due out this week we've removed ||SSL3 from this enum so apps will silently get updated to drop support for ||it. | | I see. And i think this is the most impressive or, lesser | enthusiastic, important feature of the slow _CONF_ interface: that | users can use strings and that those are directly swallowed by the | OpenSSL library, so that neither recompilation nor understanding | is necessary on the program side in order to upgrade to a new | level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. | (As a side note: SecureProtocols is such a Volvo wording... | Doesn't vulnerable energises a deeper feeling of insecurity? | I think Hitchcock would have used the naked and bare vulnerable.) | | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Hello, and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I included OLDEST for completeness sake, NEWEST is in effect what i've always forced for my thing whenever possible, and encouraged users to use themselve, but of course it was pretty inflexible before the advent of NEWEST. :) I think VULNERABLE is a good thing to have despite it's humiliating name, because it could be used to automatically secure users by simply updating the OpenSSL library, effectively giving the option to obsolete insecure protocols faster than what was possible in the past, and of course: only possibly so. But anyway: in my opinion it would be a real security improvement if users could either use -ALL,NEWEST, or, shall that not be possible, ALL,-VULNERABLE, rather in the spirit configure once and forget, but stay secure. Or something along these lines. Find attached a patch that does this and can be applied on top of the other two patches i've send regarding SSL_CONF_CTX. Notes: - Readds a dummy SSLv2 value (thus includes a patch for the other issue i've opened). - Fixes some whitespace-at-eol issues of the .pod. Thanks and ciao. P.S.: i plan to release a new minor of my thing before the christian christmas feast, it would be _really_ great to know what the OpenSSL thinks regarding the function renaming and these new values, since i'm switching over to the new SSL_CONF_CTX interface and am implementing a wrapper unless HAVE_OPENSSL_CONF_CTX becomes omnipresent. Thank you. --steffen diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod index b6aa600..4e8b67c 100644 --- a/doc/ssl/SSL_CONF_CTX_cmd.pod +++ b/doc/ssl/SSL_CONF_CTX_cmd.pod @@ -74,7 +74,7 @@ Bprime256v1). Curve names are case sensitive. =item B-named_curve -This sets the temporary curve used for ephemeral ECDH modes. Only used by +This sets the temporary curve used for ephemeral ECDH modes. Only used by servers The Bvalue argument is a curve name or the special value Bauto which @@ -85,7 +85,7 @@ can be either the BNIST name (e.g. BP-256) or an OpenSSL OID name =item B-cipher Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is -currently not performed unless a BSSL or BSSL_CTX structure is +currently not performed unless a BSSL or BSSL_CTX structure is associated with Bcctx. =item B-cert @@ -111,7 +111,7 @@ operations are permitted. =item B-no_ssl3, B-no_tls1, B-no_tls1_1, B-no_tls1_2 -Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 +Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 by setting the corresponding options BSSL_OP_NO_SSL3, BSSL_OP_NO_TLS1, BSSL_OP_NO_TLS1_1 and BSSL_OP_NO_TLS1_2 respectively. @@ -177,7 +177,7 @@ Note: the command prefix (if set) alters the recognised Bcmd values. =item BCipherString Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is -currently not performed unless an BSSL or BSSL_CTX structure is +currently not performed unless an BSSL or BSSL_CTX structure is associated with Bcctx. =item BCertificate @@ -244,7 +244,7 @@ Bprime256v1). Curve names are case sensitive. =item BECDHParameters -This sets the temporary curve used for ephemeral ECDH modes. Only used by +This sets the temporary curve used for ephemeral ECDH modes. Only used by servers The Bvalue argument is a curve name or the special value BAutomatic which @@ -259,9 +259,17 @@ The supported versions of the SSL or TLS protocol. The Bvalue argument is a comma separated list of supported protocols to enable or disable. If an protocol is preceded by B- that version is disabled. All versions are enabled by default, though applications may choose to -explicitly disable some. Currently supported protocol values are -BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2. The special value BALL refers -to all supported versions. +explicitly disable some. +Currently supported protocol values are +BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2. + +Some special values are understood: +BALL refers to all supported versions, +BNEWEST will always refer to the newest of the supported protocols, +currently BTLSv1.2, +BOLDEST refers to the oldest supported protocol, currently BSSLv3, +and BVULNERABLE includes all protocols which have known vulnerabilities +(in the default configuration). =item BOptions @@ -339,16 +347,16 @@ The value is a directory name. The order of operations is significant. This can be used to set either defaults or values which cannot be overridden. For example if an application calls: - SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv2); + SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv3); SSL_CONF_CTX_cmd(ctx, userparam, uservalue); -it will disable SSLv2 support by default but the user can override it. If +it will disable SSLv3 support by default but the user can override it. If however the call sequence is: SSL_CONF_CTX_cmd(ctx, userparam, uservalue); - SSL_CONF_CTX_cmd(ctx,
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: Hello, and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I actually find the option unfortunate and I think it should have been one that sets the minimum and maximum version. But I think we're too late 1.0.2 process to still change this. Kurt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. In Qt we've added an enum value for TLS versions that is SecureProtocols so that we could remove versions as required without requiring apps to be updated. It's an open question which is more likely to get updated - Qt or the apps of course. For Qt 5.4 which is due out this week we've removed SSL3 from this enum so apps will silently get updated to drop support for it. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
