There's a fair amount of grumbling that I see on Twitter about how
SSLv23_method is confusing -- what it does is the autonegotiation
capability.
So, could it perhaps get a new name (or alias) of something like
SSLnegotiate_method?
What would be the pros and cons of such an aliasing?
-Kyle h
how can i come up with online payroll code
This message contains confidential information and is intended only for
openssl-users@openssl.org. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately if you have
On 24 October 2014 07:37, Kyle Hamilton aerow...@gmail.com wrote:
There's a fair amount of grumbling that I see on Twitter about how
SSLv23_method is confusing -- what it does is the autonegotiation
capability.
So, could it perhaps get a new name (or alias) of something like
On 24 October 2014 09:16, Matt Caswell m...@openssl.org wrote:
I agree. This topic came up briefly at our recent OpenSSL team meeting
in Dusseldorf. I think there was a strong consensus within the team to
create a new name (probably with SSLv23_method #defined to point to
the new name). The
Hi,
To Get rid of openssl SSL3 Poodle bug, I upgraded from openssl 1.0.1g to
1.0.1j. Also Compiled openssl sources with no-ssl2 no-ssl3, so that only TLSv1
works in client server application.
On top of this, in my SSL config code, I added following code to create context.
if(server)
On 24 October 2014 10:03, Richard Moore richmoor...@gmail.com wrote:
On 24 October 2014 09:16, Matt Caswell m...@openssl.org wrote:
I agree. This topic came up briefly at our recent OpenSSL team meeting
in Dusseldorf. I think there was a strong consensus within the team to
create a new name
I have also had this same experience (1.0.1i) with SSLv3 being negotiated
though I used the SSL_OP_NO_SSLv3 flag on the SSL_set_options call. (I have NOT
re-built with SSLv3 disabled).
What I expected to see is 'unknown protocol' when an SSLv3 client tries to
connect to my server with the
Hi All,
Thanks for your detailed responses, specially Florian Weimer and Matt
Caswell. For the benefit of everyone and me, I am summarizing the thoughts
which I have understood through all your replies. Please correct
me wherever I am wrong.
To summarize:
1. Best way to prevent POODLE
On 24/10/2014 13:33, Aditya Kumar wrote:
Hi All,
Thanks for your detailed responses, specially Florian Weimer and Matt
Caswell. For the benefit of everyone and me, I am summarizing the
thoughts which I have understood through all your replies. Please
correct me wherever I am wrong.
To
On Fri, Oct 24, 2014 at 7:15 AM, mclellan, dave dave.mclel...@emc.com wrote:
I have also had this same experience (1.0.1i) with SSLv3 being negotiated
though I used the SSL_OP_NO_SSLv3 flag on the SSL_set_options call. (I have
NOT re-built with SSLv3 disabled).
If that's the case, then a
If that's the case (Jeffrey has not observed the behavior) then I have done
something wrong, which has been my suspicion anyway. But it seemed pretty
straightforward.
Should simply setting the SSL_OP_NO_SSLv3 flag take care of it? I have done
this both on the CTX and the session level.
You have SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 there. I assume v2 ... v2 is a
typo, but if that's what your code actually has, then that's the problem.
(Assuming there isn't some other problem, of course.)
Michael Wojcik
Technology Specialist, Micro Focus
From: owner-openssl-us...@openssl.org
On Fri, Oct 24, 2014 at 9:30 AM, Michael Wojcik
michael.woj...@microfocus.com wrote:
You have SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 there. I assume v2 ... v2 is
a typo, but if that's what your code actually has, then that's the problem.
(Assuming there isn't some other problem, of course.)
That's
Was trying to see why openssl doesn't like to connect to
elink-http8.bankofamerica.com.
Seems it sends an alert (fatal) Unrecognized name because the server
sends back an empty server_name extension, rightly so according to rfc
6066.
Reproduce using (1.0.1j):
openssl s_client -connect
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Jeffrey Walton
Sent: Friday, 24 October, 2014 09:42
To: OpenSSL Users List
Subject: Re: openssl SSL3 vulnerability
On Fri, Oct 24, 2014 at 9:30 AM, Michael Wojcik
michael.woj...@microfocus.com
To my earlier code, I have added these extra flags for client:
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
And server also has these same flags set, so that no way client and server can
communicate on sslv2, sslv3.
But again in logs I see SSL3 is negotiated:
ARGH! Good catch.Yes the second one is a typo -- the code shows SSLv3
for the second flag. s/b: copy and paste didn’t work so I had to re-fatfinger.
#0;. sslv23_method()
#0;. SSL_CTX_new()
#0;. ssl_set_options (SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3)
at session init:
On Fri, Oct 24, 2014 at 9:53 AM, Michael Wojcik
michael.woj...@microfocus.com wrote:
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Jeffrey Walton
Sent: Friday, 24 October, 2014 09:42
To: OpenSSL Users List
Subject: Re: openssl SSL3 vulnerability
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Jeffrey Walton
Sent: Friday, 24 October, 2014 10:26
To: OpenSSL Users List
Subject: Re: openssl SSL3 vulnerability
On Fri, Oct 24, 2014 at 9:53 AM, Michael Wojcik
michael.woj...@microfocus.com
dear all
i have made a client server. the server acts as CA the client sends a
certificate request and the CA reply with a certificate
my problem is i got an error with memory issue .also in order to
troubleshoot this program i have put the CA self signed certificate in a
file and also the
Thanks Jakob for correcting my understanding. In short, can I conclude the
following about FALLBACK flag.
1. Whenever client is sending the FALLBACK flag in its request, an updated
Server will interpret it that this client supports a higher version but
since that higher version protocol request
On 24/10/2014 18:19, Aditya Kumar wrote:
Thanks Jakob for correcting my understanding. In short, can I conclude
the following about FALLBACK flag.
1. Whenever client is sending the FALLBACK flag in its request, an
updated Server will interpret it that this client supports a higher
version
On 24/10/2014 15:53, Pradeep Gudepu wrote:
To my earlier code, I have added these extra flags for client:
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
And server also has these same flags set, so that no way client and server can
communicate on sslv2, sslv3.
But
Aha, that’s an interesting point:
Or does it just mean SSLv3.x (which includes TLSv1.x)?
Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)?
The reason I questioned my own setup, and piggy-backed on Pradeep’s first post
was this: I expected to see “TLS” when such a
I am still a little unclear by what exactly TLS_FALLBACK_SCSV option would
do.
What if the server only supports SSLv3 + TLSv1 and client only connects
with SSLv3? Without the patch, both would agree to SSLv3. So this is a
problem.
What happens with the patch only on the server? And what happens
That triggers my memory. I saw this too a long time ago, if I recall correctly,
if you get a TLSv1.2 connection, its still logged as SSLv3 (there is lack of
printable enums in the OpenSSL code. I looked at my negotiation with wireshark
and saw that I got TLSv1.2 despite what the debug trace said.
The plot thickens, but our mails must be crossing. I do indeed see TLSV1.2 in
that message, but if and only if a much more restrictive set of ciphers is
specified. That's why I was questioning the appearance of SSLv3 in other
cases, despite the case that I had set the options to disable
On Fri, Oct 24, 2014 at 12:51 PM, mclellan, dave dave.mclel...@emc.com wrote:
...
The reason I questioned my own setup, and piggy-backed on Pradeep’s first
post was this: I expected to see “TLS” when such a protocol is chosen.
There is a case where I specifically see TLSv1.2 in the cipher
There seems to be a difference between the SSL (protocol) version and
the Cipher version/description. You might try the following debug code
to clarify.
printf(SSL Version: %s\n, SSL_get_version(ssl));
const SSL_CIPHER *ciph = SSL_get_current_cipher(ssl);
if (ciph)
{
On Fri, Oct 24, 2014 at 12:09 PM, Amir Reda amirale...@gmail.com wrote:
dear all
i have made a client server. the server acts as CA the client sends a
certificate request and the CA reply with a certificate
my problem is i got an error with memory issue.
You might want to have a look at a
I have used wireshark, and captured packets details says:
Version : TLS 1.0(0x301), Client has sent hello with some 12 cipher suites.
Server returned Hello with same TLS 1.0, with
TLS_RSA_WITH_AES_128_CBC_SHA(0x002f)
Sorry, I could not copy packet details from wireshark, I could not see any
At 24.10.2014 19:03, David Li wrote:
I am still a little unclear by what exactly TLS_FALLBACK_SCSV option
would do.
What if the server only supports SSLv3 + TLSv1 and client only connects
with SSLv3? Without the patch, both would agree to SSLv3. So this is a
problem.
Where is the problem?
On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning
richard.koenn...@ts.fujitsu.com wrote:
At 24.10.2014 19:03, David Li wrote:
I am still a little unclear by what exactly TLS_FALLBACK_SCSV option
would do.
What if the server only supports SSLv3 + TLSv1 and client only connects
with SSLv3?
On 24/10/14 11:12, Pradeep Gudepu wrote:
But in logs, I still see, client and server are negotiated with SSLv3.
SSLConfig::Init: SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Fri
Oct 24 07:44:36 2014).
SSLSocket::Callback: Handshake done: AES256-SHA SSLv3
Kx=RSA
On 24/10/14 21:28, Richard Könning wrote:
SSLv3 alone is vulnerable. When you decide that this vulnerability is so
large that you don't want to use SSLv3 in any case than life is easy:
deactivate the usage of SSLv3 in all clients and servers and you have
not to think about fall back to
The server is sending back a servername extension where the extension_data
has length 2, and the data consists of two 0-bytes. An empty extension, as
required by the RFC, would have length 0, and empty data. That'd mean the
problem is on their end, I think.
Cheers,
Emilia
On Fri, Oct 24, 2014
On Fri, Oct 24, 2014 at 06:11:42PM +0200, Emilia K?sper wrote:
The server is sending back a servername extension where the extension_data
has length 2, and the data consists of two 0-bytes. An empty extension, as
required by the RFC, would have length 0, and empty data. That'd mean the
On Fri, Oct 24, 2014 at 1:28 PM, Richard Könning
richard.koenn...@ts.fujitsu.com wrote:
Am 24.10.2014 20:47, schrieb David Li:
On Fri, Oct 24, 2014 at 11:18 AM, Richard Könning
richard.koenn...@ts.fujitsu.com
mailto:richard.koenn...@ts.fujitsu.com wrote:
At 24.10.2014 19:03, David
The cherry-picking is not that big of a problem at the moment. Mainly
I want to let the OpenSSL people know what I've found. Also, I should
mention that I downloaded the latest revision of e_os.h from
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4fa17211bbb4865954a633a33a9d20a998b96971
39 matches
Mail list logo
