Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-15 Thread Adrian Kotelba
I did some extra test using OpenSSL 1.0.1, nginx, and Firefox and
Opera browsers.

Nginx is configuration:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 
DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA;
ssl_prefer_server_ciphers on;

With Firefox the Server Hello message is:

TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 65
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 61
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 0
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Compression Method: null (0)
Extensions Length: 21
Extension: server_name
Extension: renegotiation_info
Extension: ec_point_formats
Extension: SessionTicket TLS

With Opera the Server Hello messages are different  depending on
handshake version:

TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 85
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 81
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 32
Session ID: 02fd01b86400fd845c51cedd8451496c0caefff9910e0b87...
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Compression Method: null (0)
Extensions Length: 9
Extension: server_name
Extension: renegotiation_info

and

TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 85
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 81
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 32
Session ID: 1a57909ce2d3f919169c1a789bbcea4eb81a70b10be3c2e1...
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Compression Method: null (0)
Extensions Length: 9
Extension: server_name
Extension: renegotiation_info

I am wondering whether the server response is correct. The server
responds with TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in both cases, that
is, when TLS1.0 or TLS1.2 is used. Should it be rather
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 when TLS1.2 is used and
TLS_ECDHE_RSA_WITH_RC4_128_SHA when TLS1.0 is used?

Adrian

2012/3/3 Adrian Kotelba :
> Well, it seems that I am not able to reproduce this behavior using
> s_client. Apparently, the server picks up the correct cipher RC4. Part
> of connection log below:
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 4538 bytes and written 363 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
>    Protocol  : TLSv1
>    Cipher    : ECDHE-RSA-RC4-SHA
>
> It could be the problem of Qualys scanner or yet something else.
>
> Adrian
>
> 2012/3/2 Dr. Stephen Henson :
>> On Fri, Mar 02, 2012, Adrian Kotelba wrote:
>>
>>> It seems that it misleads Qualys scanner and may cause some problems
>>> with BEAST vulnerability. With the following ciphers enabled (in order
>>> of preference)
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>>> TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>>> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
>>> TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
>>> TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
>>> TLS_RSA_WITH_RC4_128_SHA (0x5)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>> TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
>>> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
>>> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>>> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
>>> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
>>> the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS
>>> 1.0. I think that the server should respond with
>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess,
>>> the configuration of ciphers in s3_lib.c is the main reason f

Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-02 Thread Adrian Kotelba
Well, it seems that I am not able to reproduce this behavior using
s_client. Apparently, the server picks up the correct cipher RC4. Part
of connection log below:
---
No client certificate CA names sent
---
SSL handshake has read 4538 bytes and written 363 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: ECDHE-RSA-RC4-SHA

It could be the problem of Qualys scanner or yet something else.

Adrian

2012/3/2 Dr. Stephen Henson :
> On Fri, Mar 02, 2012, Adrian Kotelba wrote:
>
>> It seems that it misleads Qualys scanner and may cause some problems
>> with BEAST vulnerability. With the following ciphers enabled (in order
>> of preference)
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>> TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
>> TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
>> TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
>> TLS_RSA_WITH_RC4_128_SHA (0x5)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>> TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
>> TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
>> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
>> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
>> TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
>> the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS
>> 1.0. I think that the server should respond with
>> TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess,
>> the configuration of ciphers in s3_lib.c is the main reason for this
>> behavior. Check full discussion on
>> https://community.qualys.com/thread/9340.
>>
>
> I can't see why the server responds with the AES cipher instead of the RC4 one
> with that configuration. Can you reproduce this behaviour using s_server and
> s_client?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-02 Thread Adrian Kotelba
It seems that it misleads Qualys scanner and may cause some problems
with BEAST vulnerability. With the following ciphers enabled (in order
of preference)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
the server responds with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS
1.0. I think that the server should respond with
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) when using TLS 1.0. I guess,
the configuration of ciphers in s3_lib.c is the main reason for this
behavior. Check full discussion on
https://community.qualys.com/thread/9340.

Adrian

2012/3/2 Dr. Stephen Henson :
> On Thu, Mar 01, 2012, Adrian Kotelba wrote:
>
>> In s3_lib.c ciphers 0x3B to 0x40 and 0x67 to 0x6D with SHA256 are set
>> as SSL_TLSV1. Should it be SSL_TLSV1_2?
>>
>
> Well I've seen implementations uses them in TLS 1.0 and 1.1 and it seemed
> harmless to keep that. Anything not supporting them wont use them.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-01 Thread Adrian Kotelba
In s3_lib.c ciphers 0x3B to 0x40 and 0x67 to 0x6D with SHA256 are set
as SSL_TLSV1. Should it be SSL_TLSV1_2?

Adrian
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org