[openssl.org #2762] OpenSSL 1.0.1 bug report
Building with darwin-x86_64-cc. Error is: paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64 I have attached my diff which fixes it. Please let me know if you need further information. Regards, Jeremiah Rothschild Systems Administrator Franz Inc. diff -r -u openssl-1.0.1.stock/Configure openssl-1.0.1.working/Configure --- openssl-1.0.1.stock/Configure 2012-03-03 05:18:06.0 -0800 +++ openssl-1.0.1.working/Configure 2012-03-15 16:12:55.0 -0700 @@ -128,7 +128,7 @@ my $x86_elf_asm=$x86_asm:elf; -my $x86_64_asm=x86_64cpuid.o:x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o::aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o::md5-x86_64.o:sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o::rc4-x86_64.o rc4-md5-x86_64.o:::wp-x86_64.o:cmll-x86_64.o cmll_misc.o:ghash-x86_64.o:; +my $x86_64_asm=x86_64cpuid.o:x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o modexp512-x86_64.o::aes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o::md5-x86_64.o:sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o::rc4-x86_64.o rc4-md5-x86_64.o:::wp-x86_64.o:cmll-x86_64.o cmll_misc.o:ghash-x86_64.o:; my $ia64_asm=ia64cpuid.o:bn-ia64.o ia64-mont.o::aes_core.o aes_cbc.o aes-ia64.o::md5-ia64.o:sha1-ia64.o sha256-ia64.o sha512-ia64.o::rc4-ia64.o rc4_skey.o:ghash-ia64.o::void; my $sparcv9_asm=sparcv9cap.o sparccpuid.o:bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o:des_enc-sparc.o fcrypt_b.o:aes_core.o aes_cbc.o aes-sparcv9.o:::sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o:::ghash-sparcv9.o::void; my $sparcv8_asm=:sparcv8.o:des_enc-sparc.o fcrypt_b.o:void; diff -r -u openssl-1.0.1.stock/crypto/evp/e_aes.c openssl-1.0.1.working/crypto/evp/e_aes.c --- openssl-1.0.1.stock/crypto/evp/e_aes.c 2011-11-15 04:19:56.0 -0800 +++ openssl-1.0.1.working/crypto/evp/e_aes.c2012-03-15 16:16:05.0 -0700 @@ -166,7 +166,7 @@ #define VPAES_CAPABLE (OPENSSL_ia32cap_P[1](1(41-32))) #endif #ifdef BSAES_ASM -#define BSAES_CAPABLE VPAES_CAPABLE +#define BSAES_CAPABLE (OPENSSL_ia32cap_P[1](1(41-32))) #endif /* * AES-NI section
[openssl.org #2764] modexp512-x86_64.pl generates incomplete file
Hi,
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11 qwords
When generating the file perl also throws this error:
Can't locate object method size via package expr at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, line 436.
With warnings on I get this instead:
my variable $pDst masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 627.
my variable $pDst_o masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 627.
my variable $pDst masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 711.
my variable $pDst_o masks earlier declaration in same scope at
./crypto/bn/asm/modexp512-x86_64.pl line 711.
Use of uninitialized value $flavour in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 62.
Use of uninitialized value $flavour in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 64.
Use of uninitialized value $output in pattern match (m//) at
./crypto/bn/asm/modexp512-x86_64.pl line 64.
Use of uninitialized value $flavour in concatenation (.) or string at
./crypto/bn/asm/modexp512-x86_64.pl line 71.
Use of uninitialized value $output in concatenation (.) or string at
./crypto/bn/asm/modexp512-x86_64.pl line 71.
Can't locate object method size via package expr at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, line 436.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
Hello, My reading of RFC4492 is that the ECC ciphersuites apply only to TLS 1.0 or later. According to it: This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines So it seems that SSL 3.0 shouldn't be negotiated with these ciphersuites. However it seems that openssl s_server negotiates ECC ciphersuites even under SSL 3.0. For example: $ openssl version OpenSSL 1.0.0h 12 Mar 2012 $ openssl s_server -cert x509/cert-rsa.pem -key x509/key-rsa.pem -port 5556 Using default temp DH parameters Using default temp ECDH parameters ACCEPT $ ./gnutls-cli localhost -p 5556 --x509cafile ../doc/credentials/x509/ca.pem -d 99 ... |3| HSK[0x1d0bdc0]: Server's version: 3.0 ... |2| unsupported cipher suite C0.13 ... *** Handshake has failed GnuTLS error: Could not negotiate a supported cipher suite. So it seems that gnutls rejected the connection because the ciphersuite isn't valid for this TLS version. [*] The credentials are just an RSA CA certificate and an RSA server certificate. regards, Nikos __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
[n...@gnutls.org - Sat Mar 17 14:57:31 2012]: Hello, My reading of RFC4492 is that the ECC ciphersuites apply only to TLS 1.0 or later. According to it: This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines So it seems that SSL 3.0 shouldn't be negotiated with these ciphersuites. However it seems that openssl s_server negotiates ECC ciphersuites even under SSL 3.0. For example: $ openssl version OpenSSL 1.0.0h 12 Mar 2012 $ openssl s_server -cert x509/cert-rsa.pem -key x509/key-rsa.pem -port 5556 Using default temp DH parameters Using default temp ECDH parameters ACCEPT $ ./gnutls-cli localhost -p 5556 --x509cafile ../doc/credentials/x509/ca.pem -d 99 ... |3| HSK[0x1d0bdc0]: Server's version: 3.0 ... |2| unsupported cipher suite C0.13 ... *** Handshake has failed GnuTLS error: Could not negotiate a supported cipher suite. So it seems that gnutls rejected the connection because the ciphersuite isn't valid for this TLS version. [*] The credentials are just an RSA CA certificate and an RSA server certificate. The EC codes does need a bit of revising, that is one of its many quirks. I'm trying to work out though how that client ends up producing that condition. The only way I can think s_server with those command line options could end up using SSL v3.0 is if the client sent a v3.0 client hello. That would mean that it was sending a list of supported ciphers including some it wasn't willing to support... not something you'd expect to see in practice. 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.org #2763] Possible bug - TLS 1.2 compliance
[fol...@cisco.com - Sat Mar 17 14:55:45 2012]: Using openssl s_server as the application with libcrypto 1.0.1, it appears the TLS 1.2 behavior may not be compliant with RFC 5246. Page 49 of RFC 5246 states: If the client provided a signature_algorithms extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Using the certificate attached to this email, which is signed using RSA/SHA-512, s_server continues to establish the TLS session even though the client has not offered RSA/SHA-512 in the ClientHello signature algorithms extension. Maybe I'm misinterpreting the specification, but shouldn't the sever fail this handshake since the client has indicated it doesn't support RSA/SHA-512? Yes OpenSSL currently doesn't obey that restriction in common with many other implementations. There has been a discussion about this in the tls mailing lists. This will be fixed at some point but full support requires some non-trivial revision of certificate handling. Currently OpenSSL supports one chain per EE key type and fully supporting that would potentially need support for many different chains for each key type. Very few existing applications would support that (possibly none...). 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.org #2760] possible bug report: DSA_verify() doesn't correctly account for len
The documentation doesn't reflect current behaviour. The type parameter to DSA_sign and DSA_verify is currently ignored, it should arguably check the length is consistent with the passed digest type. The actual algorithm implementation is OK though. The supplied digest will be truncated if it exceeds the size of the q parameter as mentioned in FIPS 186-3 for example. 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
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote: The EC codes does need a bit of revising, that is one of its many quirks. I'm trying to work out though how that client ends up producing that condition. The only way I can think s_server with those command line options could end up using SSL v3.0 is if the client sent a v3.0 client hello. That would mean that it was sending a list of supported ciphers including some it wasn't willing to support... not something you'd expect to see in practice. I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? regards, Nikos handshake.cap Description: application/vnd.tcpdump.pcap
Re: [openssl.org #2762] OpenSSL 1.0.1 bug report
Building with darwin-x86_64-cc. Error is: paes-x86_64.s:203:32-bit absolute addressing is not supported for x86-64 Sounds like bug in assembler, as it's not absolute address there. What does 'as -v' print on your system? I can't reproduce the problem with Apple Inc version cctools-822, GNU assembler version 1.38. I have attached my diff which fixes it. Crocodile should be beheaded! Isn't it too harsh? Maybe cutting the tail is sufficient to teach him lesson? All right! Tail it is, but up to the neck! Verify http://cvs.openssl.org/chngview?cn=22279. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11 qwords
I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
comes out truncated.
When generating the file perl also throws this error:
Can't locate object method size via package expr at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, line 436.
expr does not have size method and shouldn't have... Double-check
that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: FINGERPRINT_premain not called?
Is incore part of the validation, or is it like fipsld - allowed to be modified as needed without invalidating FIPS certification? It shouldn't void certification, no. But why is it concern for you? You have to aim for change letter and therefore there is window for including even this modification. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT r...@openssl.orgwrote: My reading of RFC4492 is that the ECC ciphersuites apply only to TLS 1.0 or later. According to it: This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines Well, SSL 3.0 was never passed as an IETF spefication, so if SSL 3.0 is the common protocol version, everything's an ad hoc interpretation of the RFCs (or, worse, you're really following draft-freier-ssl-version3-01.txt by the letter). SSL 3.0 behavior is just out of the scope of the RFCs; there's not good reason not to use the ECC ciphersuites in SSL 3.0 (apart from the various good reasons to entirely avoid SSL 3.0). $ ./gnutls-cli localhost -p 5556 --x509cafile ../doc/credentials/x509/ca.pem -d 99 ... |3| HSK[0x1d0bdc0]: Server's version: 3.0 Does this indicate that the server was actually configured to to only support SSL 3.0, not TLS? Bodo
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11 qwords
I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
comes out truncated.
When generating the file perl also throws this error:
Can't locate object method size via package expr at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, line 436.
expr does not have size method and shouldn't have... Double-check
that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
Ok,
So the problem is that I had this patch:
--- openssl-1.0.1.orig/crypto/perlasm/x86_64-xlate.pl
+++ openssl-1.0.1/crypto/perlasm/x86_64-xlate.pl
@@ -786,7 +786,7 @@
chomp($line);
-$line =~ s|[#!].*$||; # get rid of asm-style comments...
+#$line =~ s|[#!].*$||; # get rid of asm-style comments...
$line =~ s|/\*.*\*/||; # ... and C-style comments...
$line =~ s|^\s+||; # ... and skip white spaces in beginning
If I remember right, this was needed to be able to use preprocessor
commands in the .S files. (The file was also renamed from .s to
.S)
But I don't need that anymore, so I removed that patch, and you
can close this.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2764] modexp512-x86_64.pl generates incomplete file
On Sat, Mar 17, 2012 at 05:21:47PM +0100, Andy Polyakov via RT wrote:
modexp512-x86_64.s ends here:
| #
| # X2 = Xh * M2 + Xl
| # do first part (X2 = Xh * M2)
| addq$80,%rdi# rdi - pXh ; 128 bits, 2 qwords
| #Xh is actually { [rdi+8*1], rbp }
| addq$64,%rsi# rsi - M2
| leaq296(%rsp),%rcx# rcx - pX2 ; 641 bits, 11 qwords
I can't reproduce this, i.e. I can't confirm that modexp512-x86_64.s
comes out truncated.
When generating the file perl also throws this error:
Can't locate object method size via package expr at
./crypto/bn/asm/../../perlasm/x86_64-xlate.pl line 831, line 436.
expr does not have size method and shouldn't have... Double-check
that your copy of modexp512-x86_64.pl and x86_64-xlate.pl are pristine.
Ok,
So the problem is that I had this patch:
--- openssl-1.0.1.orig/crypto/perlasm/x86_64-xlate.pl
+++ openssl-1.0.1/crypto/perlasm/x86_64-xlate.pl
@@ -786,7 +786,7 @@
chomp($line);
-$line =~ s|[#!].*$||; # get rid of asm-style comments...
+#$line =~ s|[#!].*$||; # get rid of asm-style comments...
$line =~ s|/\*.*\*/||; # ... and C-style comments...
$line =~ s|^\s+||; # ... and skip white spaces in beginning
If I remember right, this was needed to be able to use preprocessor
commands in the .S files. (The file was also renamed from .s to
.S)
But I don't need that anymore, so I removed that patch, and you
can close this.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 03:53 PM, Stephen Henson via RT wrote: The EC codes does need a bit of revising, that is one of its many quirks. I'm trying to work out though how that client ends up producing that condition. The only way I can think s_server with those command line options could end up using SSL v3.0 is if the client sent a v3.0 client hello. That would mean that it was sending a list of supported ciphers including some it wasn't willing to support... not something you'd expect to see in practice. I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? regards, Nikos handshake.cap Description: application/vnd.tcpdump.pcap
[openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]: I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? That's strange. I tried OpenSSL 1.0.0h server (which supports up to TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 and 1.2) and it ends up negotiating TLS v1.0 which is what I'd expect. I'll see what that handshake capture reveals. 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
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? That's strange. I tried OpenSSL 1.0.0h server (which supports up to TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 and 1.2) and it ends up negotiating TLS v1.0 which is what I'd expect. I'll see what that handshake capture reveals. Indeed interesting. I downloaded 1.0.0h from source I saw the behavior you describe. The issue is triggered on the version 1.0.0h as distributed by debian. regards, Nikos __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FINGERPRINT_premain not called?
Understood. I asked in part because I want to minimize the number/scope of modifications so that the change letter validation is viable and straightforward; and, I asked out of curiosity. Kevin On Sat, Mar 17, 2012 at 12:26 PM, Andy Polyakov ap...@openssl.org wrote: Is incore part of the validation, or is it like fipsld - allowed to be modified as needed without invalidating FIPS certification? It shouldn't void certification, no. But why is it concern for you? You have to aim for change letter and therefore there is window for including even this modification. __ 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.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote: On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? That's strange. I tried OpenSSL 1.0.0h server (which supports up to TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 and 1.2) and it ends up negotiating TLS v1.0 which is what I'd expect. I'll see what that handshake capture reveals. Indeed interesting. I downloaded 1.0.0h from source I saw the behavior you describe. The issue is triggered on the version 1.0.0h as distributed by debian. The only think I can think of why it would behave different is that we configured it with no-ssl2. The full options we call Configure with is: no-idea no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 I think the zlib option might also cause some behaviour changes. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2282] AutoReply: [PATCH] Add PVK to usage of rsa and dsa commands
ping? this should be trivial. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sun, Mar 18, 2012 at 12:20:48AM +0100, Kurt Roeckx via RT wrote: On Sat, Mar 17, 2012 at 09:13:51PM +0100, Nikos Mavrogiannopoulos via RT wrote: On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: I captured the handshake (attached), and it seems the client advertises TLS 1.2. Could it be that the fallback is on the lowest supported version rather than the next available? That's strange. I tried OpenSSL 1.0.0h server (which supports up to TLS 1.0) against OpenSSL 1.0.1 client (which also supports TLS 1.1 and 1.2) and it ends up negotiating TLS v1.0 which is what I'd expect. I'll see what that handshake capture reveals. Indeed interesting. I downloaded 1.0.0h from source I saw the behavior you describe. The issue is triggered on the version 1.0.0h as distributed by debian. The only think I can think of why it would behave different is that we configured it with no-ssl2. The full options we call Configure with is: no-idea no-mdc2 no-rc5 zlib enable-tlsext no-ssl2 I can confirm that removing the no-ssl2 part gets me a TLS instead of SSLv3 connection. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote: I can confirm that removing the no-ssl2 part gets me a TLS instead of SSLv3 connection. The problem seems to be this code in s_client.c: #if !defined(OPENSSL_NO_SSL2) !defined(OPENSSL_NO_SSL3) meth=SSLv23_client_method(); #elif !defined(OPENSSL_NO_SSL3) meth=SSLv3_client_method(); #elif !defined(OPENSSL_NO_SSL2) meth=SSLv2_client_method(); #endif SSLv23_client_method still exist when OPENSSL_NO_SSL2 is defined. There is no reason to use SSLv3_client_method() there. Using SSLv23_client_method when build using no-ssl2 does seem to work as expected. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
