Re: [openssl-users] Re: connection problem with the version 1.0.1e

2013-10-14 Thread Erwann Abalea 

Le 11/10/2013 19:57, nehakochar a écrit :

Erwann ABALEA wrote

The server and client are both compliant.

With the first command, you tell the client to use TLS1.0 only. No more,
no less. The server is ok with it, and both negociate TLS1.0.
With the second command, you tell the client to use TLS1.2 only, again
no more no less. The server receives a TLS1.2 negociation, replies with
a TLS1.0 server hello message, and the client refuses it, cleanly
(because you told it to do so).

If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2
-no_ssl3 options instead.

In my case, SSL client is using OpenSSL 1.0.1e. I do not which version is
the server using, but must be an older version. When the client is sending
ClientHello with version 0x0303 (TLS1.2), the server does not respond at
all. In which versions of OpenSSL is the above server behavior expected?


I used the same server you're talking about earlier in the thread:
emea.webservices.travelport.com:443

And this server behaves as I wrote, correctly, sending a TLS1.0 
ServerHello, refused by the client.


Are you talking about another one?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: connection problem with the version 1.0.1e

2013-10-13 Thread Dr. Stephen Henson 
On Fri, Oct 11, 2013, nehakochar wrote:

 
 In my case, SSL client is using OpenSSL 1.0.1e. I do not which version is
 the server using, but must be an older version. When the client is sending
 ClientHello with version 0x0303 (TLS1.2), the server does not respond at
 all. In which versions of OpenSSL is the above server behavior expected?
 

Are you sure the server is using OpenSSL at all? I'm not aware of any verison
which hangs but other TLS implementations do, see:

http://www.openssl.org/support/faq.html#USER17

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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: connection problem with the version 1.0.1e

2013-10-12 Thread nehakochar 
Erwann ABALEA wrote
 Bonjour,
 
 Hi,
 I ran into the same problem and then came across this thread. According
 to
 http://tools.ietf.org/html/rfc5246#appendix-E:
A TLS 1.2 client who wishes to negotiate with such older servers will
 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
 ClientHello.client_version.  If the server does not support this
 version, it will respond with a ServerHello containing an older
 version number.

 Why then the server isn't responding at all to the Client Hello for
 TLS1.2?
 Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
 need to be fixed as it is not compliant with the RFC.
 
 The server and client are both compliant.
 
 With the first command, you tell the client to use TLS1.0 only. No more, 
 no less. The server is ok with it, and both negociate TLS1.0.
 With the second command, you tell the client to use TLS1.2 only, again 
 no more no less. The server receives a TLS1.2 negociation, replies with 
 a TLS1.0 server hello message, and the client refuses it, cleanly 
 (because you told it to do so).
 
 If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2 
 -no_ssl3 options instead.

In my case, SSL client is using OpenSSL 1.0.1e. I do not which version is
the server using, but must be an older version. When the client is sending
ClientHello with version 0x0303 (TLS1.2), the server does not respond at
all. In which versions of OpenSSL is the above server behavior expected?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/connection-problem-with-the-version-1-0-1e-tp45935p46880.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-10-11 Thread nehakochar 
Rajesh Malepati wrote
 On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;

 kirpit@

 gt; wrote:
 
 The server doesn't seem to care to respond to clients supporting TLS 1.2
 
 ok:
  openssl s_client -tls1 -connect emea.webservices.travelport.com:443
 
 no reply:
 openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443
 
 such servers should be beaten to pulp.

Hi,
I ran into the same problem and then came across this thread. According to
http://tools.ietf.org/html/rfc5246#appendix-E:
  A TLS 1.2 client who wishes to negotiate with such older servers will
   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
   ClientHello.client_version.  If the server does not support this
   version, it will respond with a ServerHello containing an older
   version number.

Why then the server isn't responding at all to the Client Hello for TLS1.2?
Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
need to be fixed as it is not compliant with the RFC.



--
View this message in context: 
http://openssl.6102.n7.nabble.com/connection-problem-with-the-version-1-0-1e-tp45935p46868.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-10-11 Thread nehakochar 
nehakochar wrote
 Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
 need to be fixed as it is not compliant with the RFC.

Correction: I am not sure if it is 1.0.1e that is the problematic version.
But would like to know if this is expected behavior (although incorrect)
with OpenSSL, and if yes, is it true for all versions (including 1.0.1e)?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/connection-problem-with-the-version-1-0-1e-tp45935p46869.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: connection problem with the version 1.0.1e

2013-10-11 Thread Erwann Abalea 

Bonjour,

Le 11/10/2013 03:35, nehakochar a écrit :

Rajesh Malepati wrote

On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;
kirpit@
gt; wrote:

The server doesn't seem to care to respond to clients supporting TLS 1.2

ok:
  openssl s_client -tls1 -connect emea.webservices.travelport.com:443

no reply:
openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443

such servers should be beaten to pulp.

Hi,
I ran into the same problem and then came across this thread. According to
http://tools.ietf.org/html/rfc5246#appendix-E:
   A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version.  If the server does not support this
version, it will respond with a ServerHello containing an older
version number.

Why then the server isn't responding at all to the Client Hello for TLS1.2?
Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
need to be fixed as it is not compliant with the RFC.


The server and client are both compliant.

With the first command, you tell the client to use TLS1.0 only. No more, 
no less. The server is ok with it, and both negociate TLS1.0.
With the second command, you tell the client to use TLS1.2 only, again 
no more no less. The server receives a TLS1.2 negociation, replies with 
a TLS1.0 server hello message, and the client refuses it, cleanly 
(because you told it to do so).


If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2 
-no_ssl3 options instead.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl-users] Re: connection problem with the version 1.0.1e

2013-10-11 Thread Dave Thompson 
 From: owner-openssl-users On Behalf Of Erwann Abalea
 Sent: Friday, October 11, 2013 08:49

 Le 11/10/2013 03:35, nehakochar a écrit :
  Rajesh Malepati wrote
  On Wed, Jul 24, 2013 at 9:30 PM, kirpit lt;kirpit@gt; wrote:
  The server doesn't seem to care to respond to clients supporting TLS
1.2
snip
  I ran into the same problem and then came across this thread. According
to
  http://tools.ietf.org/html/rfc5246#appendix-E: snip
  Why then the server isn't responding at all to the Client Hello for
TLS1.2?
  Is this expected behavior with OpenSSL 1.0.1e? If it is, then this would
  need to be fixed as it is not compliant with the RFC.
 
 The server and client are both compliant.
 
 With the first command, you tell the client to use TLS1.0 only. No more,
 no less. The server is ok with it, and both negociate TLS1.0.
 With the second command, you tell the client to use TLS1.2 only, again
 no more no less. The server receives a TLS1.2 negociation, replies with
 a TLS1.0 server hello message, and the client refuses it, cleanly
 (because you told it to do so).
 
If the server responds with a lower version, yes the client refuses it
when told to require higher. That's not what the OP described, or the 
earlier thread (and several others) said. They said *NOT ANY* response. 
I'm not sure about the particular thread cited here, but some threads 
said and experiment confirmed that s_client default (no versions 
required or prohibited) also failed the same way.

That's broken, although it's arguably not actually noncompliant. 5246 
can't impose requirements on a 4346 or 2246 implementation; note 
the old-server behavior is worded as 'will' while the 1.2-client handling 
of downrev is 2119 MUST (send alert 70). Neither earlier RFCs nor 5246 
explicitly requires the server to handle ClientHello over about 256 bytes, 
which was observed to cause the problem, although since 3546 and 4346 
it's known that this message can and does grow, and a competent 
implementation should handle that reasonably.

 If you want to allow only TLS1.0, TLS1.1 and TLS1.2, use -no_ssl2
 -no_ssl3 options instead.

1.0.0+ defaults to SSL3/TLS format so it already won't succeed in 
negotiating SSL2 even if you don't explicitly -no_ssl2. But this 
doesn't help with broken servers. As long as 1.2 is enabled, 
OpenSSL client sends the longer ClientHello. You can use -no_tls1_2 
to allow only lower versions, select a specific lower version, or restrict 
the cipherlist so that it shrinks the ClientHello small enough. 

And you should complain to the server operator(s) -- although if 
they're on old software and can't easily upgrade, that may not help.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-07-25 Thread kirpit 
I understand the main problem is the server not responding clients
supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull
data by python not curl so we don't have the fancy to pass openssl
parameters for connections and such. It uses the protocols whatever version
of openssl it was compiled with.

I am definitely going to complain about this issue to the service provider
but I don't have much hope for them to take this seriously. So I wonder if
next versions of openssl should care about workarounds for these painful
servers?

cheers.
Roy


On Wed, Jul 24, 2013 at 11:02 PM, Dave Thompson dthomp...@prinpay.comwrote:

 From: owner-openssl-us...@openssl.org On Behalf Of Rajesh Malepati
 Sent: Wednesday, 24 July, 2013 13:03

 On Wed, Jul 24, 2013 at 9:30 PM, kirpit kir...@gmail.com wrote:
 ... requests to one of our API provider
 ... works fine with 0.9.8o but 1.0.1e.

 The server doesn't seem to care to respond to clients supporting TLS 1.2
 ok: openssl s_client -tls1 -connect emea.webservices.travelport.com:443
 no reply: openssl s_client -tls1_2 -connect
 emea.webservices.travelport.com:443

 More exactly, it appears to be one of the several servers that
 fail for the longer ClientHello used in TLS1.2 by default:
 -ssl3 or -tls1 uses a shorter hello and works.
 -no_tls1_2 ditto and works negotiating 1.0.
 -tls1_1 ditto gets 1.0 response which s_client rejects.
 -tls1_2 -cipher (shortlist) ditto ditto.
 (default) -cipher (shortlist) ditto gets 1.0 response and works.

 such servers should be beaten to pulp.

 Agreed, but in the meantime, according to curl.haxx.se,
 curl has options to specify TLS1(.0?), SSL3, and/or cipherlist,
 which should allow a workaround. -1 or -3 looks easier
 than figuring out a good cipherlist for the (each?) host.


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-07-25 Thread Dr. Stephen Henson 
On Thu, Jul 25, 2013, kirpit wrote:

 I understand the main problem is the server not responding clients
 supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull
 data by python not curl so we don't have the fancy to pass openssl
 parameters for connections and such. It uses the protocols whatever version
 of openssl it was compiled with.
 
 I am definitely going to complain about this issue to the service provider
 but I don't have much hope for them to take this seriously. So I wonder if
 next versions of openssl should care about workarounds for these painful
 servers?
 

There are two workarounds but they have to be enables at compile time.

You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or restrict
the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for
example 50.

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
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-07-25 Thread kirpit 
 There are two workarounds but they have to be enables at compile time.

 You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or
 restrict
 the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for
 example 50.



I believe we will be solving our problem like this temporarily. Meantime,
I'm just wondering that it sounds a bit strange to use TLS 1.2 as a default
version while only 16% of the websites are supporting it according to wiki:

https://en.wikipedia.org/wiki/Transport_Layer_Security#Applications_and_adoption

Maybe I might be bias if there is any changing protocol negotiation or
something. Thanks for all the help by the way.

Roy.



On Thu, Jul 25, 2013 at 4:00 PM, Dr. Stephen Henson st...@openssl.orgwrote:

 On Thu, Jul 25, 2013, kirpit wrote:

  I understand the main problem is the server not responding clients
  supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we
 pull
  data by python not curl so we don't have the fancy to pass openssl
  parameters for connections and such. It uses the protocols whatever
 version
  of openssl it was compiled with.
 
  I am definitely going to complain about this issue to the service
 provider
  but I don't have much hope for them to take this seriously. So I wonder
 if
  next versions of openssl should care about workarounds for these painful
  servers?
 

 There are two workarounds but they have to be enables at compile time.

 You can stop TLS 1.2 for clients using -DOPENSSL_NO_TLS1_2_CLIENT or
 restrict
 the cipher list length using -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XXX for
 example 50.

 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
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: connection problem with the version 1.0.1e

2013-07-24 Thread Rajesh Malepati 
On Wed, Jul 24, 2013 at 9:30 PM, kirpit kir...@gmail.com wrote:

 Hi,

 I had been struggling for couple of days to figure out why requests to one
 of our API provider simply do not work in Debian Wheezy while it does in
 Squeeze.

 I am really not sure if the real problem is about the server it tries to
 connect or a bug in openssl. However, it simply works fine with 0.9.8o but
 1.0.1e.


 https://emea.webservices.travelport.com/B2BGateway/service/XMLSelect?WSDL


The server doesn't seem to care to respond to clients supporting TLS 1.2

ok:
 openssl s_client -tls1 -connect emea.webservices.travelport.com:443

no reply:
openssl s_client -tls1_2 -connect emea.webservices.travelport.com:443

such servers should be beaten to pulp.

RE: connection problem with the version 1.0.1e

2013-07-24 Thread Dave Thompson 
From: owner-openssl-us...@openssl.org On Behalf Of Rajesh Malepati
Sent: Wednesday, 24 July, 2013 13:03

On Wed, Jul 24, 2013 at 9:30 PM, kirpit kir...@gmail.com wrote:
... requests to one of our API provider 
... works fine with 0.9.8o but 1.0.1e.

The server doesn't seem to care to respond to clients supporting TLS 1.2
ok: openssl s_client -tls1 -connect emea.webservices.travelport.com:443
no reply: openssl s_client -tls1_2 -connect
emea.webservices.travelport.com:443

More exactly, it appears to be one of the several servers that 
fail for the longer ClientHello used in TLS1.2 by default:
-ssl3 or -tls1 uses a shorter hello and works.
-no_tls1_2 ditto and works negotiating 1.0.
-tls1_1 ditto gets 1.0 response which s_client rejects.
-tls1_2 -cipher (shortlist) ditto ditto.
(default) -cipher (shortlist) ditto gets 1.0 response and works.

such servers should be beaten to pulp.

Agreed, but in the meantime, according to curl.haxx.se, 
curl has options to specify TLS1(.0?), SSL3, and/or cipherlist,
which should allow a workaround. -1 or -3 looks easier 
than figuring out a good cipherlist for the (each?) host.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org