Hi,
I am setting SSL client method as SSLv23_Client_method().
And i set the cipher suite using SSL_CTX_set_cipher_list() with cipher name as
RC4-MD5.
But when I check the Client Hello packet, 2 cipher suites are going
1. TLS_RSA_WITH_RC4_128_MD5 (0x0004)
2. Unknown (0x00FF)
Can any
On Mon Dec 15 13:39:43 2014, v.badal...@open-bs.ru wrote:
Got assert
d1_both.c(296): OpenSSL internal error, assertion failed: s-init_num ==
(int)s-d1-w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH
To confirm: you did retain your change to check the return value from
dtls1_output_cert_chain?
The
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
I wonder about this interface oddity.
There is
int SSL_CTX_set_cipher_list(SSL_CTX *ctx, const char *str);
int SSL_set_cipher_list(SSL *ssl, const char *str);
but only
STACK_OF(SSL_CIPHER) *SSL_get_ciphers(const SSL *ssl);
const char *SSL_get_cipher_list(const SSL *ssl, int priority);
Stephen Henson via RT r...@openssl.org wrote:
All i can parse from your answer is that the statement that is
long in OpenSSL documentation and was referred to by Rich Salz
(unless i'm mistaken) in a different #issue, namely the following
paragraph from OPENSSL_config(3):
It is strongly
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
From: openssl-dev On Behalf Of Douglas E Engert
Sent: Tuesday, December 16, 2014 11:40
On 12/16/2014 12:18 AM, Philip Prindeville wrote:
Is there an easy way to get at the parameter 'y' (DSA-pub_key, which is
a
BIGNUM *) in ASN.1 format? (See (2) below.)
Better yet, how to take that and
[DSAPublicKey] defined where you would expect, in dsa/dsa_asn1.c .
But it's defined as a choice that does either the standard INTEGER
(from internal BIGNUM) *OR* the above SEQUENCE which is named
'dsa_pub_internal' suggesting that it should be internal to OpenSSL
i.e. not interoperable or
33 matches
Mail list logo
