On Tuesday 16 December 2014 04:53:11 Viktor Dukhovni wrote:
On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote:
On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
Firefox and Chrome support authenticated encryption via TLS 1.2 and
GCM these days. However they have for
On Tue, 16 Dec 2014 15:14:13 +0100
Hubert Kario hka...@redhat.com wrote:
No, this is problem with OpenSSL cipher order - it prefers key size
over other factors - it should prefer AEAD and PFS ciphers before
ordering on key size, doubly so that in practice you can't get
anywhere near 256 bit
On Tuesday 16 December 2014 15:38:01 Hanno Böck wrote:
On Tue, 16 Dec 2014 15:14:13 +0100
Hubert Kario hka...@redhat.com wrote:
No, this is problem with OpenSSL cipher order - it prefers key size
over other factors - it should prefer AEAD and PFS ciphers before
ordering on key size,
On Tue, 16 Dec 2014 15:42:43 +0100
Hubert Kario hka...@redhat.com wrote:
Last time we have discussed it[1], the only voices against were about
removal of RC4 ciphers from default
The boringssl patch was quite invasive, so I gave up to try to port
their changes.
But in essence it's quite
The boringssl patch was quite invasive, so I gave up to try to port their
changes.
We're working with the Boring folks to keep closer in sync so maybe something
will happen in this area.
___
openssl-dev mailing list
openssl-dev@openssl.org
On Tue, 16 Dec 2014 17:11:34 +0100
Hubert Kario hka...@redhat.com wrote:
they don't differ...
oh sorry, must've pasted the wrong string.
But please ignore my first patch, I don't think this is optimal. I'll
do another one later.
What I think is a sane approach is to leave the current code
On Tue, Dec 16, 2014 at 05:11:34PM +0100, Hubert Kario wrote:
there are few issues still
- aRSA preferred before aECDSA
- AES256 before AES128 in general
- few export grade ciphers placed before secure ciphers
- 3DES is placed arbitrarily
I'd prefer not only change the order, but
On Tuesday 16 December 2014 18:15:19 Hanno Böck wrote:
On Tue, 16 Dec 2014 17:11:34 +0100
Hubert Kario hka...@redhat.com wrote:
they don't differ...
oh sorry, must've pasted the wrong string.
But please ignore my first patch, I don't think this is optimal. I'll
do another one later.
In particular there MUST NOT be any fragile hand-tuning. All ordering needs
to be based on general principles.
This is not a universally-held view.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
___
On Tue, 16 Dec 2014 17:17:01 +
Viktor Dukhovni openssl-us...@dukhovni.org wrote:
However, where do we fit ChaCha20/Poly-1305? Again, not
hand-placement, but some extensible algorithm.
How about this simpler criterion:
AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno B?ck wrote:
However, where do we fit ChaCha20/Poly-1305? Again, not
hand-placement, but some extensible algorithm.
How about this simpler criterion:
AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
it.
That does not
On Tue, Dec 16, 2014 at 06:15:19PM +0100, Hanno B?ck wrote:
On Tue, 16 Dec 2014 17:11:34 +0100
Hubert Kario hka...@redhat.com wrote:
they don't differ...
oh sorry, must've pasted the wrong string.
But please ignore my first patch, I don't think this is optimal. I'll
do another one
On Tue, Dec 16, 2014 at 12:26:32PM -0500, Salz, Rich wrote:
In particular there MUST NOT be any fragile hand-tuning. All ordering needs
to be based on general principles.
This is not a universally-held view.
I think the key word is fragile, not hand-tuning.
Subtracting (in local
Subtracting (in local configuration) algorithms from a keyword denoting all
known-strong algorithms is hand-tuning, but not fragile hand-tuning.
Three years ago RC4 was known-strong. Two years ago DES-CBC was known-strong.
Now we only have AES-GCM. At what point do we think ChaCha/Poly is
On Tue, Dec 16, 2014 at 05:17:01PM +, Viktor Dukhovni wrote:
In particular there MUST NOT be any fragile hand-tuning. All
ordering needs to be based on general principles.
+1.
One might for example say that any CBC cipher at 128+ bits gets a
baseline sorting strength of 128 bits. One
On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote:
Subtracting (in local configuration) algorithms from a keyword denoting all
known-strong algorithms is hand-tuning, but not fragile hand-tuning.
Three years ago RC4 was known-strong. Two years ago DES-CBC was
known-strong. Now
On Tue, Dec 16, 2014 at 11:55:37AM -0600, Nico Williams wrote:
Internally using such numeric strength assignments is fine.
In particular I want you to avoid the problem that Cyrus SASL had (and
still has) with the security strength factor (SSF), where entire
security mechanisms get boiled
On Tue, Dec 16, 2014 at 06:26:50PM +, Viktor Dukhovni wrote:
Internally OpenSSL has a multi-dimensional property matrix, and
preferences between numerically equal ciphers are based on other
properties. The (stable) numeric sorting just re-arranges blocks
of ciphers already sorted by other
On Tue, Dec 16, 2014 at 12:43:13PM -0600, Nico Williams wrote:
My preference would be: subtract undesired algorithms from a named set,
then specify order of preference via some method other than iteratively
adding and subtracting algorithms. Something like:
On Tue, Dec 16, 2014 at 06:56:14PM +, Viktor Dukhovni wrote:
And the browsers should implement SHA-384, and why the hell are we
using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
the SHA256 HMAC construction has adequate strength in this context?
With GCM the collision
On Dec 16, 2014, at 7:28 PM, Hanno Böck ha...@hboeck.de wrote:
On Tue, 16 Dec 2014 17:17:01 +
Viktor Dukhovni openssl-us...@dukhovni.org wrote:
However, where do we fit ChaCha20/Poly-1305? Again, not
hand-placement, but some extensible algorithm.
How about this simpler criterion:
On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
On Tue, Dec 16, 2014 at 06:56:14PM +, Viktor Dukhovni wrote:
And the browsers should implement SHA-384, and why the hell are we
using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
the SHA256 HMAC construction has
On Tuesday 16 December 2014 12:43:13 Nico Williams wrote:
On Tue, Dec 16, 2014 at 06:26:50PM +, Viktor Dukhovni wrote:
Internally OpenSSL has a multi-dimensional property matrix, and
preferences between numerically equal ciphers are based on other
properties. The (stable) numeric
On Tue, Dec 16, 2014 at 09:50:32PM +0100, Hubert Kario wrote:
My preference would be: subtract undesired algorithms from a named set,
then specify order of preference via some method other than iteratively
adding and subtracting algorithms. Something like:
On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno Böck wrote:
On Tue, 16 Dec 2014 17:17:01 +
Viktor Dukhovni openssl-us...@dukhovni.org wrote:
However, where do we fit ChaCha20/Poly-1305? Again, not
hand-placement, but some extensible algorithm.
How about this simpler criterion:
There's clearly only one solution: I'll implement a DWIM keyword in OpenSSL
1.1 Maybe @BEST sorting order.
It's hard. You aren't doing people a service by attempting magic.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
On Tue, Dec 16, 2014 at 10:48:08PM +0100, Kurt Roeckx wrote:
On Tue, Dec 16, 2014 at 07:57:08PM +, Viktor Dukhovni wrote:
On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
On Tue, Dec 16, 2014 at 06:56:14PM +, Viktor Dukhovni wrote:
And the browsers should
Hi,
Sorry for crossposting this to three lists but I feel this is a
multi-software-issue and I feel all software involved need to find a
way to resolve this.
I feel the current software setting of tls server configs and browsers
leads to the unoptimal result that often CBC modes are preferred
Is this a theoretical issue, or have you seen it in widespread use?
I thought most servers these days picked what they wanted, and used the client
ordering as a suggestion, at best.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
On Mon, 15 Dec 2014 20:31:53 -0500
Salz, Rich rs...@akamai.com wrote:
Is this a theoretical issue, or have you seen it in widespread use?
www.openssl.org would be an example where you can see it live and
real :-)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
On Mon, 15 Dec 2014 17:36:40 -0800
Ryan Sleevi rsle...@chromium.org wrote:
* Server operator uses apache+openssl wiht cipher string
HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH. This seems reasonable.
Only HIGH security ciphers and sort them by strength.
* Browser (Chrome or Firefox) will take
On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi rsle...@chromium.org wrote:
I fear you may have misread again.
SSLHonorCipherOrder is on by default, and respects the client
preferences. The mainstream clients generally prefer GCM over CBC,
ergo, honoring the cipher order is the right thing.
On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM
these days. However they have for some reason decided not to support
AES-256 but only AES-128.
In which case, they will never use AES-256, and yet:
This is in
On Tue, 16 Dec 2014 03:09:53 +
Viktor Dukhovni openssl-us...@dukhovni.org wrote:
On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
Firefox and Chrome support authenticated encryption via TLS 1.2 and
GCM these days. However they have for some reason decided not to
support
On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote:
On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
Firefox and Chrome support authenticated encryption via TLS 1.2 and
GCM these days. However they have for some reason decided not to
support AES-256 but only
35 matches
Mail list logo
