Re: Cipher Negotiation
On Thu, Jun 29, 2006 at 12:28:44PM -0700, Chris Clark wrote: I have written a client program in which I allow the user to configure which cipher groups they want to allow as well as a cipher strength of low, medium, or high. The problem is I can't find a way of selecting the order in which I want the cipher negotiated. For example if all ciphers are enabled in the configuration, I would perfer if AES is selected during negoitation. What real problem is this intended to solve? Currently I specify the group (HIGH/MEDIUM/LOW) and remove some ciphers from a group (IDEA and ADH). I also remove AES at the beginning (Shif +=-AES:) and add it later because if I don't remove AES there is no way to separate AES128 and AES256. (Due to an OpenSSL bug, HIGH selects both AES128 and AES256) Is this a real problem? What's wrong with: !EXPORT:!LOW:!MEDIUM:DEFAULT:-DHE-RSA-AES128-SHA:-DHE-DSS-AES128-SHA:-AES128-SHA Is there a way I can force the client to negotiate using AES as the perfered method, and if the server will not allow AES then it selects some other cipher? So you want AES(128) to be preferred over DES(168)? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher Negotiation
On Fri, Jun 30, 2006 at 07:19:39AM -0400, Victor Duchovni wrote: On Thu, Jun 29, 2006 at 12:28:44PM -0700, Chris Clark wrote: I have written a client program in which I allow the user to configure which cipher groups they want to allow as well as a cipher strength of low, medium, or high. The problem is I can't find a way of selecting the order in which I want the cipher negotiated. For example if all ciphers are enabled in the configuration, I would perfer if AES is selected during negoitation. What real problem is this intended to solve? Currently I specify the group (HIGH/MEDIUM/LOW) and remove some ciphers from a group (IDEA and ADH). I also remove AES at the beginning (Shif +=-AES:) and add it later because if I don't remove AES there is no way to separate AES128 and AES256. (Due to an OpenSSL bug, HIGH selects both AES128 and AES256) Is this a real problem? What's wrong with: !EXPORT:!LOW:!MEDIUM:DEFAULT:-DHE-RSA-AES128-SHA:-DHE-DSS-AES128-SHA:-AES128-SHA Sorry, I guess this (DEFAULT: should have been first) does not work, because removing the 128 bit ciphers also removes the 256 bit ciphers. With: $ openssl ciphers -v \ 'DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 and $ openssl ciphers -v \ 'DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 producing the same results you are out of luck, if you want 256 bit AES, you always also get 128 bit AES. In practice (SSLv3/TLSv1) this is not a problem, because the client and server always choose the strongest common cipher. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher Negotiation
On Fri, Jun 30, 2006 at 07:29:04AM -0400, Victor Duchovni wrote: Currently I specify the group (HIGH/MEDIUM/LOW) and remove some ciphers from a group (IDEA and ADH). I also remove AES at the beginning (Shif +=-AES:) and add it later because if I don't remove AES there is no way to separate AES128 and AES256. (Due to an OpenSSL bug, HIGH selects both AES128 and AES256) It's not a bug that AES182 is classified as HIGH, although it is a missing feature that there is no class that encompasses only the 256-bit ciphers. That's why there now is @STRENGTH, which does not add any ciphers and just sorts the one enabled so far. Is this a real problem? What's wrong with: !EXPORT:!LOW:!MEDIUM:DEFAULT:-DHE-RSA-AES128-SHA:-DHE-DSS-AES128-SHA:-AES128-SHA Sorry, I guess this (DEFAULT: should have been first) does not work, because removing the 128 bit ciphers also removes the 256 bit ciphers. With: $ openssl ciphers -v \ 'DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 and $ openssl ciphers -v \ 'DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 producing the same results you are out of luck, if you want 256 bit AES, you always also get 128 bit AES. It appears that you are using OpenSSL 0.9.8 or 0.9.8a here. This is a bug that should be fixed in OpenSSL 0.9.8b, so that the DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA ciphersuite specification (with or without :STRENGTH appended) will only yield the three ciphersuites intended. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher Negotiation
The problem is I can't find a way of selecting the order in which I want the cipher negotiated. For example if all ciphers are enabled in the configuration, I would perfer if AES is selected during negoitation. What real problem is this intended to solve? Because AES is faster then other ciphers such as RC4 and 3DES, I want to use AES as the default if both the client and server allow it. So you want AES(128) to be preferred over DES(168)? In my client, the user can select which cipher-suites are allowed, and the following strengths: low, medium, high. If all cipher-suites are selected, and also all strengths are selected then I want the negotiation to use AES256 instead of 3DES if the server also allows this. -Chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher Negotiation
It's not a bug that AES182 is classified as HIGH, although it is a missing feature that there is no class that encompasses only the 256-bit ciphers. That's why there now is @STRENGTH, which does not add any ciphers and just sorts the one enabled so far. I assume AES182 is a typo for AES128. This is indeed a bug in OpenSSL according to the documentation at http://www.openssl.org/docs/apps/ciphers.html): HIGH - with key lengths larger than 128 bits. MEDIUM - those using 128 bit encryption. LOW - those using 64 or 56 bit encryption algorithms excluding export ciphers. But if I just use 'Medium' it does not select AES128. and If I use 'High' then it selects both AES128 and AES256. -Chris Is this a real problem? What's wrong with: !EXPORT:!LOW:!MEDIUM:DEFAULT:-DHE-RSA-AES128-SHA:-DHE-DSS-AES128-SHA:-AES128-SHA Sorry, I guess this (DEFAULT: should have been first) does not work, because removing the 128 bit ciphers also removes the 256 bit ciphers. With: $ openssl ciphers -v \ 'DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 and $ openssl ciphers -v \ 'DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 producing the same results you are out of luck, if you want 256 bit AES, you always also get 128 bit AES. It appears that you are using OpenSSL 0.9.8 or 0.9.8a here. This is a bug that should be fixed in OpenSSL 0.9.8b, so that the DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA ciphersuite specification (with or without :STRENGTH appended) will only yield the three ciphersuites intended. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher Negotiation
On Fri, Jun 30, 2006 at 09:41:08AM -0700, Chris Clark wrote: It's not a bug that AES182 is classified as HIGH, although it is a missing feature that there is no class that encompasses only the 256-bit ciphers. That's why there now is @STRENGTH, which does not add any ciphers and just sorts the one enabled so far. I assume AES182 is a typo for AES128. Yes, sorry. This is indeed a bug in OpenSSL according to the documentation at http://www.openssl.org/docs/apps/ciphers.html): HIGH - with key lengths larger than 128 bits. MEDIUM - those using 128 bit encryption. LOW - those using 64 or 56 bit encryption algorithms excluding export ciphers. But if I just use 'Medium' it does not select AES128. and If I use 'High' then it selects both AES128 and AES256. Oh, I see. Actually this is a bug in the documentation since it was an intentional between from OpenSSL 0.9.8 and 0.9.8a to classify AES128 as HIGH (like triple DES, elevating these over 128-bit RC4, which remains MEDIUM). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Cipher Negotiation
I have written a client program in which I allow the user to configure
which cipher groups they want to allow as well as a cipher strength of
low, medium, or high.
The problem is I can't find a way of selecting the order in which I
want the cipher negotiated. For example if all ciphers are enabled in
the configuration, I would perfer if AES is selected during
negoitation.
Currently I specify the group (HIGH/MEDIUM/LOW) and remove some ciphers
from a group (IDEA and ADH). I also remove AES at the beginning (Shif
+=-AES:) and add it later because if I don't remove AES there is no
way to separate AES128 and AES256.
(Due to an OpenSSL bug, HIGH selects both AES128 and AES256)
Here is the code:
if (g_MaxC=2 g_MinC=2)
{
Shif+=HIGH:;
}
if (g_MaxC=1 g_MinC=1)
{
Shif+=MEDIUM:;
}
if (g_MaxC=0 g_MinC=0) Shif+=LOW:EXP:;
Shif+=!IDEA:!ADH:;
Shif +=-AES:;
if (g_MaxC=2 g_MinC=2 g_AES)
{
Shif
+=AECDH-AES256-SHA:AES256-SHA:DHE-DSS-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:;
Shif
+=ECDHE-RSA-AES256-SHA:ECDH-RSA-AES256-SHA:;
}
if (g_MaxC=1 g_MinC=1 g_AES)
{
Shif
+=AECDH-AES128-SHA:AES128-SHA:DHE-DSS-AES128-SHA:ECDH-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:;
Shif
+=ECDHE-RSA-AES128-SHA:ECDH-RSA-AES128-SHA:;
}
if (!g_RC2) Shif += -RC2:;
if (!g_RC4) Shif += -RC4:;
if (!g_DES) Shif += -DES:;
if (!g_3DES) Shif += -3DES:;
if (!g_AES) Shif += -AES:;
lfb-SetContextChipers(Shif.GetBuffer(255));
The result that when all ciphers are enabled, the client and sever
negotitate a 3DES protocol. If I disable 3DES, then they negotiate
using RC4.
Is there a way I can force the client to negotiate using AES as the
perfered method, and if the server will not allow AES then it selects
some other cipher?
-Chris
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
How to change cipher negotiation sequence?
Hello all, Netscape browsers fail on our site if the DHE-RSA-AES128-SHA cipher is enabled on the browser. I have tried for many hours to use the openssl ciphers command on the web server to push this cipher to the end of the list, without any luck. Am I attacking the problem correctly, or am I way off base? What really confuses me is our test server has the exact same version of openssl and works fine. Redhat 9 Sun Java j2sdk1.4.2_02 jakarta-tomcat-4.1.29 OpenSSL 0.9.7a Thanks, Jim O. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to change cipher negotiation sequence?
On Fri, Jun 25, 2004, Olkovikas, James wrote: Hello all, Netscape browsers fail on our site if the DHE-RSA-AES128-SHA cipher is enabled on the browser. I have tried for many hours to use the openssl ciphers command on the web server to push this cipher to the end of the list, without any luck. What really confuses me is our test server has the exact same version of openssl and works fine. Am I attacking the problem correctly, or am I way off base? Redhat 9 Sun Java j2sdk1.4.2_02 jakarta-tomcat-4.1.29 OpenSSL 0.9.7a The server side cipher string normally just decides which ciphers to use and the client specifies the order. I say *normally* because there is an option to allow OpenSSL to enforce its server side preferences but your server software may have no option to enable that. You could try disabling the cipher altogether on the server. I suggest you also try a newer version of OpenSSL: it should work fine with that ciphersuite and Netscape: what version of Netscape are you using? Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
How to change cipher negotiation sequence?
Hello all, Netscape browsers fail on our site if the DHE-RSA-AES128-SHA cipher is enabled on the browser. I have tried for many hours to use the openssl ciphers command on the web server to push this cipher to the end of the list, without any luck. What really confuses me is our test server has the exact same version of openssl and works fine. Am I attacking the problem correctly, or am I way off base? Redhat 9 Sun Java j2sdk1.4.2_02 jakarta-tomcat-4.1.29 OpenSSL 0.9.7a Thanks, Jim O. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Cipher negotiation failure
[moved to openssl-users] On Wed, Aug 30, 2000 at 01:07:45PM -0500, mandyam wrote: I have a simple client-server app. performing both client and server authentication using the 9.5a toolkit. I am forcing the server to use DES-CBC3-SHA by calling SSL_set_cipher_list(ssl, "DES-CBC3-SHA"). My client-server app. runs for a day and then suddenly fails to negotiate ciphers. SSL_get_cipher() returns NONE. Why does this happen? Why isn't the client using the only cipher the server wants to use? Are you sure your analysis is correct? The SSL_get_cipher() call will return NONE if the TLS handshake failed, so you may only see the symptom, not the reason of your problem. Please check the return values of your SSL_connect()/accept() calls and check the error stack for error messages. The OpenSSL library routines will always log an error message when something is going wrong. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Cipher negotiation failure
Thanks. I noticed that I do have the following code in my server app.
-
err = SSL accept(ssl);
if (err==-1) {
ERR_print_errors_fp(stderr);
return err;
}
SSL_get_cipher(ssl) returns NONE;
At this point I issue SSL_get_peer_certificate() and I am able to read
the client's (or server's) certificate and print it.
-
I do have the same code for SSL_connect() on my client..
Does the SSL_accept/connect() function return error values other than -1?
I also noticed that after cipher=NONE, the SSL_read() call hangs in the
server.
-Original Message-
From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 30, 2000 2:20 PM
To: [EMAIL PROTECTED]
Cc: mandyam
Subject: Re: Cipher negotiation failure
[moved to openssl-users]
On Wed, Aug 30, 2000 at 01:07:45PM -0500, mandyam wrote:
I have a simple client-server app. performing both client and server
authentication using the 9.5a toolkit. I am forcing the server to use
DES-CBC3-SHA by calling
SSL_set_cipher_list(ssl, "DES-CBC3-SHA").
My client-server app. runs for a day and then suddenly fails to negotiate
ciphers. SSL_get_cipher() returns NONE.
Why does this happen? Why isn't the client using the only cipher the
server
wants to use?
Are you sure your analysis is correct? The SSL_get_cipher() call will return
NONE if the TLS handshake failed, so you may only see the symptom, not
the reason of your problem.
Please check the return values of your SSL_connect()/accept() calls
and check the error stack for error messages.
The OpenSSL library routines will always log an error message when something
is going wrong.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Cipher negotiation failure
On Wed, Aug 30, 2000 at 03:25:48PM -0500, mandyam wrote:
Thanks. I noticed that I do have the following code in my server app.
-
err = SSL accept(ssl);
if (err==-1) {
ERR_print_errors_fp(stderr);
return err;
}
SSL_get_cipher(ssl) returns NONE;
At this point I issue SSL_get_peer_certificate() and I am able to read
the client's (or server's) certificate and print it.
-
I do have the same code for SSL_connect() on my client..
Does the SSL_accept/connect() function return error values other than -1?
Yes. It returns -1 on SSL failure, +1 on success and 0, when the connection
was closed.
You should hence use
if (err != 1) {
errval = SSL_get_error(ssl, err);
/* interprete the error value as describe an the SSL_get_error() manual
page */
}
I also noticed that after cipher=NONE, the SSL_read() call hangs in the
server.
Maybe, because the "ssl" structure does not point to a vaild ssl connection.
Best regards,
Lutz
PS. As it seems that it only happens after having your program running for some
time. Are you sure that you don't have a leak somewhere in your software?
Maybe you are not closing all file descriptors, so that your new connection
cannot be initiated (and so can't the SSL connection). But that is a stupid
suggestion, as you of course check all of these error possibilities in your
code :-)
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
SSL3 session cipher negotiation failure
Hi.
I am fairly new to OpenSSL programming, so let me describe my problem
in detail first. I have a program which uses OpenSSL 0.9.3a to
connect to a HTTPS server. It uses the following logic:
init SSL libraries
select SSL method (SSLv23_client_method)
create SSL context (SSL_CTX_new)
create SSL session (SSL_new)
while (not done) {
create a new socket
bind SSL session to socket (SSL_set_fd)
perform SSL negotiation (SSL_connect)
read/write data
close socket
}
free SSL session (SSL_free)
free SSL context (SSL_CTX_free)
I'm getting an error during the second pass of the while loop:
85494:error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:old session
cipher not returned:s3_clnt.c:635:
During the first pass, the cipher is negotiated between client and
server as RC4-MD5. The interesting thing is that I do not get this
error at all when connecting to a different server (both hardware and
software) which, incidentally, negotiates to use the DES-CBC3-SHA
cipher.
Any ideas on how to fix this? Is it as simple as setting a
configuration flag in the context or session, or should I re-create
the context and session during each pass of the while loop? It seems
like the latter should not be the case since the program logic works
fine when pointed to another server. Any help would be greatly
appreciated!
kevin
--
Kevin Hendrix
---
The number of arguments is unimportant unless some of them
are correct.
- Ralph Hartley
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSL3 session cipher negotiation failure
James K Hendrix [EMAIL PROTECTED]:
I am fairly new to OpenSSL programming, so let me describe my problem
in detail first. I have a program which uses OpenSSL 0.9.3a to
connect to a HTTPS server.
Let me guess, a Netscape server?
[...]
create SSL session (SSL_new)
while (not done) {
create a new socket
bind SSL session to socket (SSL_set_fd)
perform SSL negotiation (SSL_connect)
read/write data
close socket
}
I'm getting an error during the second pass of the while loop:
85494:error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:old session
cipher not returned:s3_clnt.c:635:
[...]
The interesting thing is that I do not get this
error at all when connecting to a different server (both hardware and
software) [...]
Any ideas on how to fix this? Is it as simple as setting a
configuration flag in the context or session, [...]
Yes, it appears to be; and the above error message pointed you to the
place in the source code where you can point the name of the flag: You
should know that 635 is the line number inside the s3_clnt.c file.
There you can find that the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
disables the check that leads to the above message. You can use
SSL_CTX_set_options(ctx, SSL_blah_blah_BUG) to set that option (in
case you want to set other options to, or them togehter).
or should I re-create the context and session during each pass of
the while loop?
Instead of doing this (I think you mean "re-create the SSL", not
the SSL_CTX), you could call SSL_set_session(ssl, NULL) after each
iteration. But it would disable sessions completely, which is bad
for performance -- use the workaround option instead.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
