RE: disabling SSLV2 on server dosent work.
In this case the handshake itself is failing. So I need to change in such a way that even though SSLv2 is disabled on the server the server should be able to manage the first packet from the client (i.e V2 hello). We cant set this ion the Cipher List rt? From this context i want to know how to proceed. Do i need to set the same upcall argument in the initial stage for both V2 and V3 ?? here in my previous case if both V2 and V3 are running on the server the upcall argumnet func is ssl23_accept(). But if my V3 is only enalbed then the upcall argument is ssl3_accept(). So is this a problem and do we need to have same upcall argument ??? Or is this Ok and do we need to change some where else? -shashidhar From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton [noloa...@gmail.com] Sent: Friday, November 04, 2011 3:52 PM To: openssl-users@openssl.org Subject: Re: disabling SSLV2 on server dosent work. On Fri, Nov 4, 2011 at 6:05 AM, Shashidhar RP shashidhar...@hcl.com wrote: HI I disabled SSLv2 on the server. When the client which is capable of SSLV2 and SSLV3 sends the hand shake, client sends first V2 hello rt So the server is not capable of handling V2 packet as SSLV2 is disabled on server. Can you please help me here how to proceed. From our side, they are asking us to change in the server side itself. So in ssl23_srvr.c there is a function ssl23_accept(). From where this will be called.??? and how to proceed to change this. You probably want SSL_CTX_set_options (not SSL_set_cipher_list). Also see http://marc.info/?l=openssl-usersm=13149855822752 and http://marc.info/?l=openssl-usersm=129165895207103. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: disabling SSLV2 on server dosent work.
On Fri, Nov 4, 2011 at 6:05 AM, Shashidhar RP shashidhar...@hcl.com wrote: HI I disabled SSLv2 on the server. When the client which is capable of SSLV2 and SSLV3 sends the hand shake, client sends first V2 hello rt So the server is not capable of handling V2 packet as SSLV2 is disabled on server. Can you please help me here how to proceed. From our side, they are asking us to change in the server side itself. So in ssl23_srvr.c there is a function ssl23_accept(). From where this will be called.??? and how to proceed to change this. You probably want SSL_CTX_set_options (not SSL_set_cipher_list). Also see http://marc.info/?l=openssl-usersm=13149855822752 and http://marc.info/?l=openssl-usersm=129165895207103. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
On Sat, Sep 3, 2011 at 7:16 AM, Michael S. Zick open...@morethan.org wrote: On Fri September 2 2011, Michael B Allen wrote: On Fri, Sep 2, 2011 at 4:07 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Coda Highland wrote: Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. It would be very nice if there was a cipher list option that applications could not override so that you can absolutely block SSLv2 on the whole machine by only editing one file (openssl.cnf and not httpd/conf.d/ssl.conf, postfix/main.cf, dovecot.conf, etc). I do not want to build anything from source anymore. Then I would have to watch for updates and rebuild all the time. As a position statement I understand your point. But you seem to have survived skipping all of the library updates between 0.9.8e and the 1.0 series while depending on your package manager. So if you __did not__ watch for updates and rebuild all the time you would be no worse off than you are now. Not true. CentOS (which is just RedHat without the branding) does the watch for udpates part and backports anything of real importance. Meaning some security vulnerability fixed in 1.0 would, in theory, be backported to 0.9.8e. I would much rather just rely on the distribution's package repository to keep me up-to-date. I'm currently using openssl 0.9.8e from CentOS 5.6. But CentOS 6 has openssl 1.0 and it also has Postfix 2.6 which supports the smtpd_tls_protocols = !SSLv2 directive which is required to disable SSLv2 in Postfix at the app-level. So it sounds like I will need to migrate to CentOS 6. OR, modify your package manager control files to select OpenSSL and Postfix packages from the newer distribution repository rather than migrate the entire OS to a new distribution. OR, from a centOS-5 repository that tracks updates to the packages that you feel are critical to your usage more closely than the release repo. Lots of ways you could choose to shape your administration tasks to your liking. ;-) All of those decisions are best made by yourself. Back to your original question - Building a dynamic library that refers to an on-disk control file seems a bit impractical for a library that may be used on systems that do not have any file system to speak of. ;-) Red herring. Configuration options are equally effective regardless of whether or not they come from a disk file. It so happens that the people hanging out on this list are also the type that use compiler options to build a tailor made package for their appliance / device. But in practice, most of us regular civilians are using a stock package provided by their distribution. Mike Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
On Mon September 5 2011, Michael B Allen wrote: On Sat, Sep 3, 2011 at 7:16 AM, Michael S. Zick open...@morethan.org wrote: On Fri September 2 2011, Michael B Allen wrote: On Fri, Sep 2, 2011 at 4:07 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Coda Highland wrote: Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. It would be very nice if there was a cipher list option that applications could not override so that you can absolutely block SSLv2 on the whole machine by only editing one file (openssl.cnf and not httpd/conf.d/ssl.conf, postfix/main.cf, dovecot.conf, etc). I do not want to build anything from source anymore. Then I would have to watch for updates and rebuild all the time. As a position statement I understand your point. But you seem to have survived skipping all of the library updates between 0.9.8e and the 1.0 series while depending on your package manager. So if you __did not__ watch for updates and rebuild all the time you would be no worse off than you are now. Not true. CentOS (which is just RedHat without the branding) does the watch for udpates part and backports anything of real importance. Meaning some security vulnerability fixed in 1.0 would, in theory, be backported to 0.9.8e. I would much rather just rely on the distribution's package repository to keep me up-to-date. I'm currently using openssl 0.9.8e from CentOS 5.6. But CentOS 6 has openssl 1.0 and it also has Postfix 2.6 which supports the smtpd_tls_protocols = !SSLv2 directive which is required to disable SSLv2 in Postfix at the app-level. So it sounds like I will need to migrate to CentOS 6. OR, modify your package manager control files to select OpenSSL and Postfix packages from the newer distribution repository rather than migrate the entire OS to a new distribution. OR, from a centOS-5 repository that tracks updates to the packages that you feel are critical to your usage more closely than the release repo. Lots of ways you could choose to shape your administration tasks to your liking. ;-) All of those decisions are best made by yourself. Back to your original question - Building a dynamic library that refers to an on-disk control file seems a bit impractical for a library that may be used on systems that do not have any file system to speak of. ;-) Red herring. Re-read the original post, subject was run-time configuration file for the dynamic library (not for the utility applications which are part of the OpenSSL distribution). Mike Configuration options are equally effective regardless of whether or not they come from a disk file. It so happens that the people hanging out on this list are also the type that use compiler options to build a tailor made package for their appliance / device. But in practice, most of us regular civilians are using a stock package provided by their distribution. Mike Mike __ 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
Re: Disabling SSLv2
On Fri, Sep 2, 2011 at 1:07 PM, Dr. Stephen Henson st...@openssl.org wrote: Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. Would this be worth adding environment variables for? -Kyle H Verify This Message with Penango.p7s Description: S/MIME Cryptographic Signature
Re: Disabling SSLv2
On Fri September 2 2011, Michael B Allen wrote: On Fri, Sep 2, 2011 at 4:07 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Coda Highland wrote: Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. It would be very nice if there was a cipher list option that applications could not override so that you can absolutely block SSLv2 on the whole machine by only editing one file (openssl.cnf and not httpd/conf.d/ssl.conf, postfix/main.cf, dovecot.conf, etc). I do not want to build anything from source anymore. Then I would have to watch for updates and rebuild all the time. As a position statement I understand your point. But you seem to have survived skipping all of the library updates between 0.9.8e and the 1.0 series while depending on your package manager. So if you __did not__ watch for updates and rebuild all the time you would be no worse off than you are now. I would much rather just rely on the distribution's package repository to keep me up-to-date. I'm currently using openssl 0.9.8e from CentOS 5.6. But CentOS 6 has openssl 1.0 and it also has Postfix 2.6 which supports the smtpd_tls_protocols = !SSLv2 directive which is required to disable SSLv2 in Postfix at the app-level. So it sounds like I will need to migrate to CentOS 6. OR, modify your package manager control files to select OpenSSL and Postfix packages from the newer distribution repository rather than migrate the entire OS to a new distribution. OR, from a centOS-5 repository that tracks updates to the packages that you feel are critical to your usage more closely than the release repo. Lots of ways you could choose to shape your administration tasks to your liking. ;-) All of those decisions are best made by yourself. Back to your original question - Building a dynamic library that refers to an on-disk control file seems a bit impractical for a library that may be used on systems that do not have any file system to speak of. ;-) Mike Mike __ 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
Re: Disabling SSLv2
On Fri, Sep 02, 2011, Michael B Allen wrote: Hello, Is there a way to disable SSLv2 system-wide (assuming non-static linking)? I am trying to get a CentOS 5.6 system to pass a PCI credit card processing certification and the scanning company blindly flags SSLv2 as non-compliant. Rather than try to disable SSLv2 in each application (postfix, Apache, Dovecot, etc), I was hoping there was a low-level directive that would block SSLv2 (but not SSLv3 or TLSv1). Is there any such directive to torpedo SSLv2 specifically? Which version of OpenSSL are you using? In OpenSSL 1.0.0 and later the cipher string determines whether SSLv2 support is advertised or accepted and the default cipher string includes on SSLv2 ciphers. Alternatively try no-ssl2 on the command line but that hasn't been tested for a while. If you use that you will get linker errors in applications that reference SSLv2 directly. Third option. At the end SSL_CTX_new in ssl/ssl_lib.c the options flag has some settings added. Add something to disable SSLv2: ret-options |= SSL_OP_NO_SSLv2; 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
On Fri, Sep 2, 2011 at 2:09 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Michael B Allen wrote: Hello, Is there a way to disable SSLv2 system-wide (assuming non-static linking)? I am trying to get a CentOS 5.6 system to pass a PCI credit card processing certification and the scanning company blindly flags SSLv2 as non-compliant. Rather than try to disable SSLv2 in each application (postfix, Apache, Dovecot, etc), I was hoping there was a low-level directive that would block SSLv2 (but not SSLv3 or TLSv1). Is there any such directive to torpedo SSLv2 specifically? Which version of OpenSSL are you using? In OpenSSL 1.0.0 and later the cipher string determines whether SSLv2 support is advertised or accepted and the default cipher string includes on SSLv2 ciphers. Alternatively try no-ssl2 on the command line but that hasn't been tested for a while. If you use that you will get linker errors in applications that reference SSLv2 directly. Third option. At the end SSL_CTX_new in ssl/ssl_lib.c the options flag has some settings added. Add something to disable SSLv2: ret-options |= SSL_OP_NO_SSLv2; Hi Steve, Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. Thanks, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. /s/ Adam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
On Fri September 2 2011, Michael B Allen wrote: On Fri, Sep 2, 2011 at 2:09 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Michael B Allen wrote: Hello, Is there a way to disable SSLv2 system-wide (assuming non-static linking)? I am trying to get a CentOS 5.6 system to pass a PCI credit card processing certification and the scanning company blindly flags SSLv2 as non-compliant. Rather than try to disable SSLv2 in each application (postfix, Apache, Dovecot, etc), I was hoping there was a low-level directive that would block SSLv2 (but not SSLv3 or TLSv1). Is there any such directive to torpedo SSLv2 specifically? Which version of OpenSSL are you using? In OpenSSL 1.0.0 and later the cipher string determines whether SSLv2 support is advertised or accepted and the default cipher string includes on SSLv2 ciphers. Alternatively try no-ssl2 on the command line but that hasn't been tested for a while. If you use that you will get linker errors in applications that reference SSLv2 directly. Third option. At the end SSL_CTX_new in ssl/ssl_lib.c the options flag has some settings added. Add something to disable SSLv2: ret-options |= SSL_OP_NO_SSLv2; Hi Steve, Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But if you did it that way, wouldn't the entire PCI credit card processing certification depend on that configuration file being used, un-altered, from that point onwards? That sounds sort of long-term fragile to me. The better sounding answer to me is Steve's third suggestion, disable SSLv2 in the source and re-build. __AND__ be sure that the controls of the CentOS package manager (Yum?) are set so it will not blindly update either the custom built package or the special-purposed configuration file. As appropriate to whichever route you decide to take. Mike But based on your answer it's fairly clear that there is no such option. Thanks, Mike __ 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
Re: Disabling SSLv2
On Fri, Sep 02, 2011, Coda Highland wrote: Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Disabling SSLv2
On Fri, Sep 2, 2011 at 4:07 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Sep 02, 2011, Coda Highland wrote: Well I was hoping there was some kind of global configuration file directive that would affect the behavior of the openssl library and at least everything dynamically linked with it. But based on your answer it's fairly clear that there is no such option. He said that for OpenSSL 1.0.0 that the cipher list controls it. You can configure the cipher list from openssl.cnf. Actually you can't. Applications generaally have their own way of setting the cipherlist or just rely on the default value and don't allow it to be changed at all. It would be very nice if there was a cipher list option that applications could not override so that you can absolutely block SSLv2 on the whole machine by only editing one file (openssl.cnf and not httpd/conf.d/ssl.conf, postfix/main.cf, dovecot.conf, etc). I do not want to build anything from source anymore. Then I would have to watch for updates and rebuild all the time. I would much rather just rely on the distribution's package repository to keep me up-to-date. I'm currently using openssl 0.9.8e from CentOS 5.6. But CentOS 6 has openssl 1.0 and it also has Postfix 2.6 which supports the smtpd_tls_protocols = !SSLv2 directive which is required to disable SSLv2 in Postfix at the app-level. So it sounds like I will need to migrate to CentOS 6. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
