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
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
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 }
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
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)
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
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
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
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
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
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
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
12 matches
Mail list logo
