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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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,
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
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
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
|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
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
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.
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.
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.
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.
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.
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
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
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
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
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
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,
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
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
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
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
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
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
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
41 matches
Mail list logo
