Hello,
Dr. Stephen Henson st...@openssl.org wrote:
|On Fri, Feb 13, 2015, Viktor Dukhovni wrote:
| On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote:
| Some time ago, I had submitted a patch which allows administrators, but
| most importantly OS distributors to set their own strings
On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote:
I absolutely support all statements of Daniel Kahn Gillmore, but
especially that dynamism must be handled at a place that can be
adjusted without the necessity for any recompilation.
And i want to point to OPENSSL_config(3) which
Some time ago, I had submitted a patch which allows administrators, but
most importantly OS distributors to set their own strings in the configuration
file, which software can then rely on, to provide a consistent security level:
https://github.com/openssl/openssl/pull/192
And my intent is
Hello,
Nikos Mavrogiannopoulos n...@redhat.com wrote:
|On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote:
| And i want to point to OPENSSL_config(3) which states for a longer
| time duration:
|
|It is strongly recommended that all new applications call
|
On Fri, Feb 13, 2015, Viktor Dukhovni wrote:
On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote:
Some time ago, I had submitted a patch which allows administrators, but
most importantly OS distributors to set their own strings in the
configuration
file, which software can
On Fri, Feb 13, 2015 at 03:54:50PM +, Dr. Stephen Henson wrote:
Config modules were intended to be used for application setup so would
be a good place to add a system cipher string instead of a whole new
mechanism.
The only problem is that it would only work with application that
On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote:
Some time ago, I had submitted a patch which allows administrators, but
most importantly OS distributors to set their own strings in the
configuration
file, which software can then rely on, to provide a consistent security
Oh, this thread is about the OpenSSL configuration package that
Rich Salz promised!..
Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
|On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
| Note that for most applications the correct approach to configuring
| ciphersuites should be to start
On Wednesday 11 February 2015 20:21:37 Viktor Dukhovni wrote:
On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:
On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote:
I would like to make the following changes
I think these definitions should stay the same, but I have no
objection to disabling RC4 in DEFAULT, or entirely removing
EXPORT/LOW.
That seems inconsistent with your view that RC4 must remain in MEDIUM, yet you
are willing to drop other terms that other applications might be using.
On Wed, Feb 11, 2015 at 03:15:11PM +, Salz, Rich wrote:
Note that for most applications the correct approach to configuring
ciphersuites should be to start with DEFAULT and subtract what they don't
want. The library is then responsible for a generally sensible default
order
and
Also, what about changing order so that 128bit+ AEAD and PFS are
preferred over other ciphers (including 256 bit ones)?
I sent in a patch for exactly that a while ago.
Unfortunately I got zero feedback...
https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html
Sorry
On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
Note that for most applications the correct approach to configuring
ciphersuites should be to start with DEFAULT and subtract what they don't
want. The library is then responsible for a generally sensible default order
and default
Hi,
On Tue, 10 Feb 2015 21:46:46 +
Viktor Dukhovni openssl-us...@dukhovni.org wrote:
Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
compatibility issues for opportunistic TLS (e.g. Postfix) where
RC4 is still required for interop and is better than cleartext.
Let
On Wed, 11 Feb 2015 13:01:14 +0100
Hubert Kario hka...@redhat.com wrote:
Also, what about changing order so that 128bit+ AEAD and PFS are
preferred over other ciphers (including 256 bit ones)?
I sent in a patch for exactly that a while ago.
Unfortunately I got zero feedback...
Note that for most applications the correct approach to configuring
ciphersuites should be to start with DEFAULT and subtract what they don't
want. The library is then responsible for a generally sensible default order
and default exclusions.
I strongly disagree. Most applications should
On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:
On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the
master branch, which is planned for
On Tuesday 10 February 2015 21:15:36 Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the
master branch, which is planned for the next release after 1.0.2
Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
Anything that was 40-bit
On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the
master branch, which is planned for the next release after 1.0.2
Anything that uses RC4 or MD5
On Wednesday 11 February 2015 02:00:50 Viktor Dukhovni wrote:
On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote:
RC4 in LOW has a bit of pushback so far. My cover for it is that
the IETF says don't use it. So I think saying if you want it,
say so is the way to go.
By all
On Tue, Feb 10, 2015, Viktor Dukhovni wrote:
We should also recall that the master branch has introduced security
levels, which may still need some work to become production-ready,
but are likely a better mechanism for applications to move to more
secure settings than incompatible changes
On Tue, Feb 10, 2015 at 10:52:02PM +, Salz, Rich wrote:
I'd further suggest to move everything that's not PFSAEAD from HIGH to
MEDIUM.
I think it's a little early to do that. But once TLS 1.3 is out, then yes :)
This is NOT a decision a library should be making on behalf of
On Wed, Feb 11, 2015 at 12:22:44AM +, Salz, Rich wrote:
RC4 in LOW has a bit of pushback so far. My cover for it is that
the IETF says don't use it. So I think saying if you want it,
say so is the way to go.
By all means, don't use it, but it is not OpenSSL's choice to make
by breaking
By all means, don't use it, but it is not OpenSSL's choice to make by breaking
the meaning of existing interfaces.
Except that we've explicitly stated we're breaking things with this new release.
Those magic cipher keywords are point-in-time statements. And time has moved
on.
On Tue, Feb 10, 2015 at 06:17:38PM -0500, Daniel Kahn Gillmor wrote:
On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the
master branch, which is planned for the next release after 1.0.2
Anything that uses RC4 or MD5
Not all applications are browsers folks, and libraries need to provide stable
interfaces that mirror the application's intent consistent with expected
behaviour of existing interfaces.
Please point to where it is documented what the value of MEDIUM means and what
interface is being broken?
currently, this is an error:
0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
bash: !NO-SUCH-CIPHER: event not found
0 dkg@alice:~$
Yeah, but that's coming from bash, not openssl :)
; openssl ciphers -v ALL | wc
111 6758403
; openssl ciphers -v ALL:!FOOBAR | wc
111
On Tue 2015-02-10 19:22:44 -0500, Salz, Rich wrote:
currently, this is an error:
0 dkg@alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
bash: !NO-SUCH-CIPHER: event not found
0 dkg@alice:~$
Yeah, but that's coming from bash, not openssl :)
; openssl ciphers -v ALL | wc
111 675
On Wed, Feb 11, 2015 at 06:11:08AM +, Viktor Dukhovni wrote:
I think these definitions should stay the same, but I have no
objection to disabling RC4 in DEFAULT, or entirely removing
EXPORT/LOW.
And also MD5 (which subsumes all SSLv2 cipher-suites).
Note that for most applications the
On Wed, Feb 11, 2015 at 01:50:07AM -0500, Daniel Kahn Gillmor wrote:
RC4 in LOW has a bit of pushback so far. My cover for it is that the
IETF says don't use it. So I think saying if you want it, say so is
the way to go.
I think that's the correct position. People who want to be able
On Wed, Feb 11, 2015 at 03:33:03AM +, Salz, Rich wrote:
Not all applications are browsers folks, and libraries need to provide
stable
interfaces that mirror the application's intent consistent with expected
behaviour of existing interfaces.
Please point to where it is documented
On Tue, 10 Feb 2015 21:15:36 +
Salz, Rich rs...@akamai.com wrote:
Comments?
Sounds good.
I'd further suggest to move everything that's not PFSAEAD
from HIGH to MEDIUM.
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpwviI3Wtd4z.pgp
Description: OpenPGP
On Tue, Feb 10, 2015 at 09:15:36PM +, Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the master
branch, which is planned for the next release after 1.0.2
Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
Note, that RC4 is already
On Tue, Feb 10, 2015 at 10:38:01PM +0100, Hanno B?ck wrote:
On Tue, 10 Feb 2015 21:15:36 +
Salz, Rich rs...@akamai.com wrote:
Comments?
Sounds good.
I'd further suggest to move everything that's not PFSAEAD
from HIGH to MEDIUM.
Thus breaking applications that were previously
Sounds good.
Thanks.
I'd further suggest to move everything that's not PFSAEAD from HIGH to
MEDIUM.
I think it's a little early to do that. But once TLS 1.3 is out, then yes :)
___
openssl-dev mailing list
To unsubscribe:
On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
I would like to make the following changes in the cipher specs, in the master
branch, which is planned for the next release after 1.0.2
Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
yes, please!
Anything that was
36 matches
Mail list logo
