Re: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )
Must be SPARC-specific, all tests pass on my x86/x64 Solaris 11.4 using latest GCC (11.2) >-- Original Message -- > >What Ben suggests is a great start. > >Note that none of the core developers have Solaris access, so that >debugging could be problematic. > > >Pauli > > >On 12/9/21 1:39 pm, Benjamin Kaduk via openssl-users wrote: >> On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users >> wrote: >>> This is slightly better than the beta release : >>> >>> Test Summary Report >>> --- >>> 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) >>>Failed test: 1 >>>Non-zero exit status: 1 >>> 90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1) >>>Failed test: 1 >>>Non-zero exit status: 1 >>> >>> >>> What can I dig into here to get more information and perhaps we solve >>> these two little tests fails? >> `make V=1 TESTS="test_internal_modes test_ige" test` >> >> -Ben >> >
Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
>-- Original Message -- > > >>-- Original Message -- >> >>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: >> >>> >Is the handshake explicit, or does the application just call >>> >SSL_read(), with OpenSSL performing the handshake as needed? >>> >>> I occasionally (somewhat rarely) see the issue mentioned by the OP. >>> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >>> does effectively hides the issue and connection works fine. I predominantly >>> run on Solaris 11. In my case, I open the socket myself, set non-blocking >>> mode and associates with an SSL object using SS_set_fd(). >>> The initial handshake is done explicitly. >> >>Recoverable errors should not result in SSL_ERROR_SYSCALL. This >>feels like a bug. I'd like to hear from Matt Caswell on this one. >>Perhaps someone should open an issue on Github... >> >I will scan my logs later this evening and see if this is still an issue. >Last time I remember seeing it was quote some long time ago (couple of years) > > ok, I checked my logs (3+ years worth of them) and I have not seen this error in that timeframe. so it must have been a much older OpenSSL version I used way back when I remember doing this workaround. Doesnt seem to be needed for me anymore.
Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
>-- Original Message -- > >On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote: > >> >Is the handshake explicit, or does the application just call >> >SSL_read(), with OpenSSL performing the handshake as needed? >> >> I occasionally (somewhat rarely) see the issue mentioned by the OP. >> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE >> does effectively hides the issue and connection works fine. I predominantly >> run on Solaris 11. In my case, I open the socket myself, set non-blocking >> mode and associates with an SSL object using SS_set_fd(). >> The initial handshake is done explicitly. > >Recoverable errors should not result in SSL_ERROR_SYSCALL. This >feels like a bug. I'd like to hear from Matt Caswell on this one. >Perhaps someone should open an issue on Github... > I will scan my logs later this evening and see if this is still an issue. Last time I remember seeing it was quote some long time ago (couple of years)
Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
I can add some of my own observations to this below ... >> I haven't looked at the code, but my impression is that WANT_READ and >> WANT_WRITE are returned in two cases: when OpenSSL has received or sent a >> partial record and needs to complete it; or when the TLS state is such that >> OpenSSL needs to perform the associated operation and it hasn't been >> requested by the application - for example, if the application is trying to >> receive data but OpenSSL needs to send renegotiation information. >> >> If you do a non-blocking receive at a record boundary (so you don't have an >> incomplete record) and OpenSSL doesn't currently need to send for TLS >> reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on >> platform). I think in this case it does just return SSL_ERROR_SYSCALL, >> because OpenSSL itself doesn't "want" to receive. If OpenSSL had already >> received a partial record, then you'd get WANT_READ. > >I think the above guess is not correct. A cursory look at the >code suggests that even user-initiated reads normally return >SSL_ERROR_WANT_READ when the network bio signals a retriable >failure. > >The OP has not provided much detail about the connections in >question are created. Is the connection made by the >application, and SSL negotiated over an existing socket, or >is the connection established by OpenSSL over a "connect bio"? > >Is the handshake explicit, or does the application just call >SSL_read(), with OpenSSL performing the handshake as needed? > I occasionally (somewhat rarely) see the issue mentioned by the OP. Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE does effectively hides the issue and connection works fine. I predominantly run on Solaris 11. In my case, I open the socket myself, set non-blocking mode and associates with an SSL object using SS_set_fd(). The initial handshake is done explicitly.
Re: Openssl Version 1.1.1b fails to compile on Solaris platform(Intel & Sparc)
I see this is Solaris 10, dont use that anywhere anymore.
But in Solaris 11, its fine. From ld(1)
-M mapfile
Reads mapfile as a text file of directives to the link-editor. This
option can be specified multiple times. If mapfile is a directory,
then all regular files, as defined by stat(2), within the directory
are processed. See Chapter 10, Mapfiles in the Link-Editor in Ora-
cle Solaris 11.4 Linkers and Libraries Guide. Example mapfiles are
provided in /usr/lib/ld. See also FILES.
>-- Original Message --
>
>Hi All,
>
>We are trying to build OpenSSL version 1.1.1b on Solaris, but it fails with
>following error:
>
>libcrypto.map: file format not recognized; treating as linker script
>collect2: error: ld returned 1 exit status
>gmake[2]: *** [libcrypto.so] Error 1
>gmake[1]: *** [all] Error 2
>
>$ uname -a
>SunOS mh-vmss3fnpb32.enguk.acresso.com 5.10 Generic_147147-26 sun4v sparc
>sun4v
>
>
>This is happening because of the flags defined in
>Configurations/10-main.conf:
>
> Solaris configurations
>"solaris-common" => {
>inherit_from => [ "BASE_unix" ],
>template => 1,
>lib_cppflags => "-DFILIO_H",
>ex_libs => add("-lsocket -lnsl -ldl"),
>dso_scheme => "dlfcn",
>thread_scheme=> "pthreads",
>shared_target=> "self",
>shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
>shared_ldflag=> "-Wl,-Bsymbolic",
>shared_defflag => "-Wl,-M,",
>shared_sonameflag=> "-Wl,-h,",
>},
>
>After changing the shared_defflag to "-Wl, -Map," it works fine. i.e "-Wl,
>-M" is not recognized on Solaris, it needs to be "-Wl, -Map,".
>Couple of queries here:
>1. Is it not a bug on Solaris with OpenSSL 1.1.1b version?
>2. Can we modify 'Configurations/10-main.conf' in our local copy of OpenSSL
>which is used internally by our product?Will it cause any licensing
>problem(OpenSSL license and GPL)?
>
>Any help would be greatly appreciated.
>
>Regards,
>Parth
Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist
hmm, been reading this whole thread.
I dont have any current issues building with Sun Studio 12.6 in 2011 mode (but
I only do Intel x86 and x86_64)
However, I do have a preference for using gcc for openssl builds though.
Do note however, that in my opinion, for Solaris, one MUST do the -R linker
options
to avoid runtime issues with Solaris builds of OpenSSL, But I suppose thats for
everyone to
discover for themselves. I discovered it the hard way during the 1.0.1 era.
The -strict mode I think is impossible as of now
(dot-asm) I do want to see your PR for adding support for -R to get
incorporated, been sitting for a while -:)
Here are my preferred config settings for Solaris cc
"efca-x64-cc" => {
inherit_from=> [ "solaris-common", asm("x86_64_asm") ],
CC => "cc",
CFLAGS => add_before(picker(debug => "-g",
release => "-xO5 -xdepend
-xbuiltin")),
cflags => add_before("-m64 -xarch=generic -xstrconst
-std=gnu11"),
cppflags=> add(threads("-D_REENTRANT")),
lib_cppflags=> add("-DL_ENDIAN"),
lflags => add(threads("-mt")),
ex_libs => add(threads("-lpthread")),
bn_ops => "SIXTY_FOUR_BIT_LONG",
perlasm_scheme => "elf",
shared_cflag=> "-KPIC",
shared_ldflag => add_before("-G -dy -z text
-R\$(INSTALLTOP)/\$(LIBDIR)"),
multilib=> "/64",
},
>-- Original Message --
>
>On 1/18/19 1:53 AM, Dennis Clarke wrote:
>>
>> Going in circles trying to compile 1.1.1a with strict C99 and no
>> optimizations and with a ready to debug and single step resultant
>> library.
>
>Ignore all this. Thou shalt not C99 here.
>
>Dennis
>
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Compilation error in ssl/t1_trce.c
There are missing comma's in ssl/t1_trce.c that causes compilation to fail.
You have to configure with enable-ssl-trace to see it though.
gcc -I. -Iinclude -I../src -I../src/include -fPIC -std=gnu90 -march=core2
-Wall -O3 -fomit-frame-pointer -pthread -DFILIO_H -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
-DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/ssl/lib/engines-1.1\"" -DL_ENDIAN
-DOPENSSL_NO_INLINE_ASM -DNDEBUG -MMD -MF ssl/t1_trce.d.tmp -MT ssl/t1_trce.o
-c -o ssl/t1_trce.o ../src/ssl/t1_trce.c
../src/ssl/t1_trce.c:484:5: error: expected '}' before '{' token
{TLSEXT_TYPE_signature_algorithms_cert, "signature_algorithms_cert"}
^
*** Error code 1
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
>-- Original Message -- > > As for -lm, which symbol was undefined? > Undefined first referenced symbol in file fabs test/ct_test.o >>> >>> ??? One can only wonder where does it come from. I see no fabs >>> anywhere... > >Ah! Missed it! There is fabs call in ct_test. I was looking for >reference in binary code. On multiple platforms including Solaris x86. >Question is how come it isn't a problem anywhere else. It looks like >it's customarily inlined, but not here. Well, you insist on >-xbuiltin=%none, so I suppose this has to be it. In such case it's on you... Most compilers (including gcc) inlines fabs() Solaris cc does not when using -O0 -g which I use when debugging. If I remember correctly, solaris cc also inlines when using higher level of optimization but I may remember wrong. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
>-- Original Message --
>
>>> As for -lm, which symbol was undefined?
>>>
>>
>> Undefined first referenced
>> symbol in file
>> fabs test/ct_test.o
>
>??? One can only wonder where does it come from. I see no fabs anywhere...
>
/*
* Tests that the CT_POLICY_EVAL_CTX default time is approximately now.
* Allow +-10 minutes, as it may compensate for clock skew.
*/
static int test_default_ct_policy_eval_ctx_time_is_now()
{
int success = 0;
CT_POLICY_EVAL_CTX *ct_policy_ctx = CT_POLICY_EVAL_CTX_new();
const time_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) /
1000;
const time_t time_tolerance = 600; /* 10 minutes */
if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
fprintf(stderr,
"Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
goto end;
}
if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
fprintf(stderr,
"Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
goto end;
}
success = 1;
end:
CT_POLICY_EVAL_CTX_free(ct_policy_ctx);
return success;
}
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
as that is the ONLY -lm reference and the fact its in test code, why not simply avoid using fabs(), that is so trivial here ? if (value < 0) value = -value; >-- Original Message -- > >On 24/02/18 04:47 AM, Andy Polyakov wrote: >>> So testsuite is running but this is a non-optimal debug build and only >>> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the >>> ELF header below which is somewhat restrictive. >>> >>> e_flags: [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] >> >> If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and >> EF_SPARC_SUN_US3 ... > > >I wasn't clear. I know exactly what causes this. I am saying that I will >have to redo everything again and get the process down to a baseline >config. > >> As for -lm, which symbol was undefined? >> > >Undefined first referenced > symbol in file >fabstest/ct_test.o > >dc >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
>-- Original Message -- > >On 20/02/18 12:47 PM, Norm Green wrote: >> On 2/20/2018 5:43 AM, Michael Wojcik wrote: >>> Not by default. The comments in /usr/include/sys/feature_tests.h (on a >>> Solaris system) explain this in excruciating detail, but in short you >>> need either -DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the >>> equivalent in the code) to compile with XPG6 (aka IEEE 1003.1-2001). >> Thanks for the suggestions Michael. Neither resolves the problem. In >> fact, adding -D_XOPEN_SOURCE=600 causes a new problem: >> >> /opt/solarisstudio12.3/bin/c99 -I. -Icrypto/include -Iinclude -m64 >> -xtarget=ultra2 -D_XOPEN_SOURCE=600 -xstrconst -Xa -DB_ENDIAN -DBN_DIV2W >> -KPIC -xildoff -mt -xcode=pic32 -g -DDSO_DLFCN -DHAVE_DLFCN_H >> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ >> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM >> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> -DPOLY1305_ASM -DFILIO_H -DB_ENDIAN -DBN_DIV2W -D_REENTRANT >> -DOPENSSLDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/ssl\"" >> >> -DENGINESDIR="\"/hamburg4/users/normg/gs64trunk/slow10/openssl_1.1/install10/lib/engines-1.1\"" >> >> -c -o crypto/bio/b_addr.o crypto/bio/b_addr.c >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXHOST >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: host >> "crypto/bio/b_addr.c", line 198: undefined symbol: NI_MAXSERV >> "crypto/bio/b_addr.c", line 198: variable length array can not be >> initialized: serv >> c99: acomp failed for crypto/bio/b_addr.c >> Makefile:881: recipe for target 'crypto/bio/b_addr.o' failed >> >> >> I also tried building with c99 instead of cc, without success. >> > I build my Solaris OpenSSL binaries using studo compiler 12.4 cc -xc99 Havent tried latest 1.1.1 snapshot yet though, probably a good time -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is anyone else getting spammed by databreachtoday.com, or is it just me?
Havent seen any. >-- Original Message -- > >Over the last many months, I have received a constant flow of >"newsletters" from databreachtoday.com to my OpenSSL posting >address. > >I am wondering if this is specific to me, or if they are >sending to most other subscribers too. > >Enjoy > >Jakob >-- >Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com >Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 >This public discussion message is non-binding and may contain errors. >WiseMo - Remote Service Management for PCs, Phones and Embedded > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Building libcrypto/libssl without symbolic link
Not sure what platform the other person is using, but, for the record the soname 1.0.0 causes big problems on Solaris 11 and up. Solaris 11 ships an OpenSSL 1.0.0 version in standard library locations, if anyone just builds anything higher than that, and do NOT modify build to add -R runtime load paths, you will see the libssl built link with Solaris 11 libcrypto which is not good. There are functions in 1.0.1 that do not exist in 1.0.0 I have seen a change in version naming strategy in main branch, so hopefully this will soon be not an issue. FYI, changing LD_LIBRARY_PATH using crle, is a bad idea on Solaris 11, made my boot environment un-bootable. For Solaris at least, I think its a good idea to modify makefiles to always provide the -R option to the linker. I have used that for a very long time, and avoided any collisions with standard Solaris versions. -- Original Message -- On Wed, Apr 22, 2015 at 12:12:45AM +, Shanku Roy wrote: lrw-r--r-- root root 2015-04-10 02:33 libcrypto.so - libcrypto.so.1.0.0 -rw-r--r-- root root 1988088 2015-04-10 02:27 libcrypto.so.1.0.0 Is there any configure option in OpenSSL build scripts to not generate the symbolic links and rather generate actual binary as libcrypto.so/libssl.so from the build process like following: The library soname is part of the ABI. What platform are you building for where it would not be appropriate to encode the ABI compatibility name into the library name? -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Web site problem
Starting a few days ago, www.openssl.org when clicking on the Source tab, then selecting the GitWeb tab, redirects you to git.openssl.org (probably ok ? ) but that page returns the OpenSSL home page (same as www.openssl.org) so no web git access. DNS issues perhaps ? ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: openssl SSL3 vulnerability
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. I hope this could be fixed one day ? -- Original Message -- 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 again in logs I see SSL3 is negotiated: [2014-10-24 18:00:17.063, Info proxysrv:10684] SSLConfig::Init: SSL initiated (OpenSSL 1.0.1j 15 Oct 2014 built on: Mon Oct 20 15:08:32 2014). [2014-10-24 18:02:11.640, Info proxysrv:10684] SSLSocket::Callback: Handshake done: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 Does this really mean SSLv3.0 protocol negotiated? Or does it just mean SSLv3.x (which includes TLSv1.x)? Or perhaps SSLv3 compatible cipher suite (which also includes TLSv1.x)? On server, I have these ciphers set: ::SSL_CTX_set_cipher_list(ctx, ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM); Is there something wrong with these ciphers? What are best cipher argument for only TLSv1 communication. I think, I need not set ciphers on client side. Thanks – Pradeep reddy. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How does cipher selection and TLS protocol negotiation interact
I have a weird case that I cannot properly explain. Using OpenSSL 1.0.1c for both client and server, I was testing various combinations of ciphers and protocol version requests. Basically, the server uses SSLv23_server_method(). The client code uses SSLv23_client_method() and SSL_OP_NO_SSLv2 Then, if I have the following cipher list (which I have used for a long time) TLSv1+HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH (same for client and server side) I always get a SSLv3 connection, regardless what client asks for. Changing the cipher list to (removing the TLSv1) HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH I start getting TLS1.2 connections. Question is, in the first case, why dont I get a TLSv1 connection ? Furthermore, high strength ciphers from TLSv1 should still be usable for TLS 1.1 and 1.2, so why dont I get a TLS1.2 connection in the first case ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How does cipher selection and TLS protocol negotiation interact
To answer my own question, seems the code that generates the SSL_CIPHER_description() output does not make any difference between SSLv3, TLSv1.0 and TLSv1.1. Only TLSv1.2 is displayed as such. So in my case, I probably did have a TLSv1 connection. Confusing ... A followup question, is it correct that TLSv1 in the cipher string disables TLSv1.2 ciphers ? I didnt expect that. -- Original Message -- Date: Fri, 15 Jun 2012 14:34:27 -0700 From: Erik Forsberg e...@efca.com Subject: How does cipher selection and TLS protocol negotiation interact To: openssl-users@openssl.org Reply-To: openssl-users@openssl.org I have a weird case that I cannot properly explain. Using OpenSSL 1.0.1c for both client and server, I was testing various combinations of ciphers and protocol version requests. Basically, the server uses SSLv23_server_method(). The client code uses SSLv23_client_method() and SSL_OP_NO_SSLv2 Then, if I have the following cipher list (which I have used for a long time) TLSv1+HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH (same for client and server side) I always get a SSLv3 connection, regardless what client asks for. Changing the cipher list to (removing the TLSv1) HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH I start getting TLS1.2 connections. Question is, in the first case, why dont I get a TLSv1 connection ? Furthermore, high strength ciphers from TLSv1 should still be usable for TLS 1.1 and 1.2, so why dont I get a TLS1.2 connection in the first case ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
