Re: Test of disabled renegotiation in 0.9.8l
Quoting joshi chandran joshichandran...@gmail.com: Hi ALL, I have Applied this patch http://cvs.openssl.org/chngview?cn=18791 on openssl 9.8k . when i have tried renegotiation , it is disconnecting the connection . SSL_accept:before accept initialization TLS 1.0 Alert [length 0002], fatal handshake_failure 02 28 SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client hello A ERROR 344264:error:1408A13F:SSL routines:SSL3_GET_CLIENT_HELLO:no renegotiation:s3_srvr.c:725: shutting down SSL CONNECTION CLOSED ACCEPT For the security issue CVE-2009-3555, Which all patch i need to apply on Openssl 9.8k and openssl 9.8h so that connection gets disconnected if renegotiation is attempted . ( As i can see in openssl 0.9.8l gets into hang state whenever renegotiation is attempted). I can confirm that openssl-0.9.8l doesn't handle CVE-2009-3555 satisfactorily (it hangs in a read state). If your application is exclusively apache httpd and you're at version 2.2.14, there is also a patch to mod_ssl that will have the same effect (break connection if client renegotiates) before we get into openSSL. This is a bit simpler to apply (you only need to re-build a module) and will work with any version of openSSL. See: http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch Rgds, Owen Boyle Thanks In Advance Joshi On Tue, Nov 17, 2009 at 12:10 PM, joshi chandra joshichandran...@gmail.com wrote: Hi , I have lot patch from cvs of Openssl which will disable all the renegotiation and also will drop the connection if renegotiation is tried . This is the patch from the cvs http://cvs.openssl.org/chngview?cn=18791 http://cvs.openssl.org/chngview?cn=18794 http://cvs.openssl.org/chngview?cn=18795 As i am using this patch in older version of openssl (9.8h and 9.8k ). will this patch disable the renegotiation and also drop the connection if renegotiation is done . Thanks in Advance Joshi Lutz Jaenicke wrote: Boyle Owen wrote: PPS: Although I have subscribed to this list, I am not getting the mails (I have to keep checking the archives). Is there anyone who can check out my account? Hmm. If memory serves me right there was a subscribe message sent to the list instead of the mailing list manager (which I then moderated away)... Please try again, we do have some handy form on the web page. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Test-of-disabled-renegotiation-in-0.9.8l-tp26301719p26385119.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Regards Joshi Chandran __ 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 #2102] 1.0.0 incompatible with openfire servers
Hi Eren! On Mon, 16 Nov 2009 01:19:11 +0200 Eren Türkay e...@pardus.org.tr wrote: The only way to get established ssl handshake openssl s_client is to use the -ssl3 option. In some cases such as: This is the same situation in 0.9.8-stable branch, too. The only way to connect to the server is -ssl3 option. With -tls1, openssl cannot get hello message from the server. Problem reported by Tomas should be unrelated to the recent renegotiation fixes as it's reproducible with 0.9.8k too (when using -tls1 argument for s_client) and -no_ticket was reported to help. However, when I pass -tls1 option, localhost just works fine.. Also, renegotiation is done. If I'm not wrong, 0.9.8-stable branch contains TLS extension for renegotiation issue. ... I think, there are some problems with s_client, rather than implementation. As seen from this, -tls1 option works fine with newer openssl on both client and server. The difference between 1.0.0 and 0.9.8 should be caused by what I mentioned here (different client hello versions): http://marc.info/?l=openssl-devm=125803022028046w=2 The same difference between versions is likely to be the reason why the openfire issue was only reported for 1.0.0. th. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2105] Please reconsider the client side of the CVE-2009-3555 fix in 1.0.0
The TLS client in openssl-1.0.0 branch aborts the connection if SSL_OP_ALLOW_UNSAFE_RENEGOTIATION (or SSL_OP_ALL) flag is not set by the calling application and the connected server does not return the extension in the server hello message. Unfortunately too many applications do not set SSL_OP_ALL which makes them incompatible with currently virtually every server as the renegotiation extension supporting servers are not deployed yet. I propose adding a new flag for the client which would explicitely disable connection to unsafe servers and to allow this connection by default. For now in Fedora I am forced to just disable the client side check. See also: https://bugzilla.redhat.com/show_bug.cgi?id=537962 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2106] s_client man page doesn't mention STARTTLS support for XMPP
Hi, just noticed that the s_client man page [1] doesn't mention the XMPP support for -starttls which has been introduced with 0.9.8j. -starttls protocol send the protocol-specific message(s) to switch to TLS for communication. protocol is a keyword for the intended protocol. Currently, the only supported keywords are smtp, pop3, imap, and ftp. Don't know whether it also affects other locations, but I guess xmpp could at least be mentioned in that list of supported protocols. Sebastian [1] http://www.openssl.org/docs/apps/s_client.html#item__starttls __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
ssl_write returned ssl_error_ssl: urgent help needed
Hi, I got some weird error. help needed urgent. SSL_write() is returned with error SSL3_WRITE_PENDING:bad write retry. I have tried with flags PARTIAL_WRITE and AUTO_RETRY and MOVING BUFFER. Still i am facing this problem. Any temporary workaround will also be appreciated. Thanks Regards, Sandeep Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: SHA-2 support in openssl?
smitha daggubati wrote: Does openssl have support for SHA-2. ? I know that SHA-2 is part of the crypto library but looking at the way the context is setup in ssl_ctx_new we are setiing up ret-sha1=EVP_get_digestbyname(ssl3-sha1)) So is there a way to establish an openssl connection using SHA-2 currently? Yes openssl has support for SHA-2, but what it doesn't have is support for a SSL cipher suite using SHA-2. It's a bit late in being updated to support the SHA-2 suites from RFC5289. I suppose this not the main priority of the development team, since sha1 inside tls is not actually endangered at the moment. Any help in implementing it, and rearchitecturing the code where use of SHA-1 is hardcoded, would certainly be welcomed. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-2 support in openssl?
Marc, Thanks for the reply. On Wed, Nov 18, 2009 at 2:54 PM, Jean-Marc Desperrier jmd...@free.frwrote: smitha daggubati wrote: Does openssl have support for SHA-2. ? I know that SHA-2 is part of the crypto library but looking at the way the context is setup in ssl_ctx_new we are setiing up ret-sha1=EVP_get_digestbyname(ssl3-sha1)) So is there a way to establish an openssl connection using SHA-2 currently? Yes openssl has support for SHA-2, but what it doesn't have is support for a SSL cipher suite using SHA-2. It's a bit late in being updated to support the SHA-2 suites from RFC5289. I suppose this not the main priority of the development team, since sha1 inside tls is not actually endangered at the moment. Any help in implementing it, and rearchitecturing the code where use of SHA-1 is hardcoded, would certainly be welcomed. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: how to create an already revoked certificate?
Thanks for the reply, I have control of the CA in creating certificates. The CRL contains the SN of the certs that are revoked. I also noticed we have an SRL file which shows the last SN used for the certificates and it increments by 1 for every certificate created. You said: Having the same serial on CA2 as on CA1 is totally irrelevant. Does that mean the CRL goes by more than the SN? I was thinking of doing this: edit the SRL and replace it with the SN of the revoked cert, after using it i revert back to the correct SN pattern. If the CRL does need to have a perfect match to treat the created cert as a revoked cert do i need to create a perfect replication in terms of all input parameters or the CRL will be smart enough to know they are still different? thanks --- On Tue, 11/17/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: how to create an already revoked certificate? To: openssl-dev@openssl.org Date: Tuesday, November 17, 2009, 4:06 PM From: owner-openssl-...@openssl.org On Behalf Of Al Sent: Monday, 16 November, 2009 15:40 I am trying to create a certificate that is already revoked (for testing purposes). I noticed the CRL has the SNs of the certificates and i am wondering if i could set the SN to Yes, certs are identified for many purposes, including revocation on a CRL, by serial within CA. revoked cert SNs during new certificate creation? This is not entirely clear; I assume you mean create a new cert with a serial that is already on a CRL issued by the (same) CA. (You can't change the serial on an issued cert; it's part of the signed content. You legally could create/issue a new cert, with new CA/serial, and all other contents the same as an existing cert, even validity. But it's usual to redo the validity. Having the same serial on CA2 as on CA1 is totally irrelevant.) If you control the CA, maybe; it depends on what the CA software does. A CA is not SUPPOSED to ever issue different certs with the same serial, but you may be able to override or fake yours. openssl ca|x509(ca)depend on text files you can clobber; openssl req(self)|x509(self) obey the command line. If you do create two (or more) certs with the same serial, and both (or multiple) of them are ever present in any environment, you have a very good chance of creating chaos. The purpose of the serial is to uniquely identify the cert within a given CA, and lots of software assumes this. If there are two different certs with the same serial for the same CA, all kinds of things can go wrong that you can spend months debugging. But if you control the CA, you should be able to easily issue a new CRL about as easily as you can issue a new cert. If you don't control the CA, and it is competently run, no. It will always create new certs with unique serials, as it should. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@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: how to create an already revoked certificate?
The CRL identifies certificates by serial number only; the issuer is implied. You cannot have a CRL that revokes certificates from more than one issuing certificate. The only parameter from a certificate to determine if it is revoked is the serial number. However, it's important to note that a certificate can only be revoked by a CRL that has the same issuer. Two certificates issued by different CAs can have the same serial number. A CRL from CA1 can only revoke the certificate from CA1; it cannot revoke a certificate from CA2, even if both certificates have the same serial number. Given that you're controlling the CA, I suppose the method you list below could work, but you'll also need to remove the original certificate from the .index file and from the .certs directory that OpenSSL creates to manage the CA. Failure to do that will result in OpenSSL giving an error message. If the goal is to have a CRL whose lastUpdate is before the notBefore parameter on one of the certificates it revokes, I would recommend instead to set the clock backwards, and then generate a new CRL. I would be surprised if OpenSSL checks the current date against the dates on the certificate(s) that are revoked. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Al Sent: Wednesday, November 18, 2009 9:12 AM To: dave.thomp...@princetonpayments.com Cc: openssl-dev@openssl.org Subject: RE: how to create an already revoked certificate? Thanks for the reply, I have control of the CA in creating certificates. The CRL contains the SN of the certs that are revoked. I also noticed we have an SRL file which shows the last SN used for the certificates and it increments by 1 for every certificate created. You said: Having the same serial on CA2 as on CA1 is totally irrelevant. Does that mean the CRL goes by more than the SN? I was thinking of doing this: edit the SRL and replace it with the SN of the revoked cert, after using it i revert back to the correct SN pattern. If the CRL does need to have a perfect match to treat the created cert as a revoked cert do i need to create a perfect replication in terms of all input parameters or the CRL will be smart enough to know they are still different? thanks --- On Tue, 11/17/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: how to create an already revoked certificate? To: openssl-dev@openssl.org Date: Tuesday, November 17, 2009, 4:06 PM From: owner-openssl-...@openssl.org On Behalf Of Al Sent: Monday, 16 November, 2009 15:40 I am trying to create a certificate that is already revoked (for testing purposes). I noticed the CRL has the SNs of the certificates and i am wondering if i could set the SN to Yes, certs are identified for many purposes, including revocation on a CRL, by serial within CA. revoked cert SNs during new certificate creation? This is not entirely clear; I assume you mean create a new cert with a serial that is already on a CRL issued by the (same) CA. (You can't change the serial on an issued cert; it's part of the signed content. You legally could create/issue a new cert, with new CA/serial, and all other contents the same as an existing cert, even validity. But it's usual to redo the validity. Having the same serial on CA2 as on CA1 is totally irrelevant.) If you control the CA, maybe; it depends on what the CA software does. A CA is not SUPPOSED to ever issue different certs with the same serial, but you may be able to override or fake yours. openssl ca|x509(ca)depend on text files you can clobber; openssl req(self)|x509(self) obey the command line. If you do create two (or more) certs with the same serial, and both (or multiple) of them are ever present in any environment, you have a very good chance of creating chaos. The purpose of the serial is to uniquely identify the cert within a given CA, and lots of software assumes this. If there are two different certs with the same serial for the same CA, all kinds of things can go wrong that you can spend months debugging. But if you control the CA, you should be able to easily issue a new CRL about as easily as you can issue a new cert. If you don't control the CA, and it is competently run, no. It will always create new certs with unique serials, as it should. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List
RE: how to create an already revoked certificate?
I tried replacing the SRL SN and it does create a new cert with same SN with only the CN being different (since it is unique). I do get the problem with CRL trying to revoke the 2nd cert with the same SN. I get: ERROR:name does not match /C=US/ST=foo/L=bar/CN=2 R 09234567Z 09234567Z E95C35AC12345676unknown /C=US/ST=foo/L=bar/CN=1 ERROR:revokeCert:revoke failed the SN is E95C35AC12345676. You did suggest removing .index file and .certs of the original but i am not sure which files you mean. Is the .index file the CRL index file with the rejected SNs? if that is the case then arent i rewritting the CRL which unrevokes the original? The CA folder only has index.txt where the CRL stuff are and the index.txt.attr. the directory is like: /FooCA: /cert1 - etc/ - ca/ , cert files... /cert2 . /etc I guess i could remove the SN from the CRL temporarily, after the 2nd cert gets revoked successfully (since the cert1 with same SN is not revoked anymore..) i re-edit the CRL file and put back the Cert1's info. Not sure what effect it will have later on though.. So basically right now i can create a cert with same SN as the cert in the CRL and could make every parameter the same except CN.. --- On Wed, 11/18/09, Thomas Francis, Jr. thomas.fran...@pkware.com wrote: From: Thomas Francis, Jr. thomas.fran...@pkware.com Subject: RE: how to create an already revoked certificate? To: openssl-dev@openssl.org Date: Wednesday, November 18, 2009, 10:01 AM The CRL identifies certificates by serial number only; the issuer is implied. You cannot have a CRL that revokes certificates from more than one issuing certificate. The only parameter from a certificate to determine if it is revoked is the serial number. However, it's important to note that a certificate can only be revoked by a CRL that has the same issuer. Two certificates issued by different CAs can have the same serial number. A CRL from CA1 can only revoke the certificate from CA1; it cannot revoke a certificate from CA2, even if both certificates have the same serial number. Given that you're controlling the CA, I suppose the method you list below could work, but you'll also need to remove the original certificate from the .index file and from the .certs directory that OpenSSL creates to manage the CA. Failure to do that will result in OpenSSL giving an error message. If the goal is to have a CRL whose lastUpdate is before the notBefore parameter on one of the certificates it revokes, I would recommend instead to set the clock backwards, and then generate a new CRL. I would be surprised if OpenSSL checks the current date against the dates on the certificate(s) that are revoked. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl- d...@openssl.org] On Behalf Of Al Sent: Wednesday, November 18, 2009 9:12 AM To: dave.thomp...@princetonpayments.com Cc: openssl-dev@openssl.org Subject: RE: how to create an already revoked certificate? Thanks for the reply, I have control of the CA in creating certificates. The CRL contains the SN of the certs that are revoked. I also noticed we have an SRL file which shows the last SN used for the certificates and it increments by 1 for every certificate created. You said: Having the same serial on CA2 as on CA1 is totally irrelevant. Does that mean the CRL goes by more than the SN? I was thinking of doing this: edit the SRL and replace it with the SN of the revoked cert, after using it i revert back to the correct SN pattern. If the CRL does need to have a perfect match to treat the created cert as a revoked cert do i need to create a perfect replication in terms of all input parameters or the CRL will be smart enough to know they are still different? thanks --- On Tue, 11/17/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: how to create an already revoked certificate? To: openssl-dev@openssl.org Date: Tuesday, November 17, 2009, 4:06 PM From: owner-openssl-...@openssl.org On Behalf Of Al Sent: Monday, 16 November, 2009 15:40 I am trying to create a certificate that is already revoked (for testing purposes). I noticed the CRL has the SNs of the certificates and i am wondering if i could set the SN to Yes, certs are identified for many purposes, including revocation on a CRL, by serial within CA. revoked cert SNs during new certificate creation? This is not entirely clear; I assume you mean create a new cert with a serial that is already on a CRL issued by the (same) CA. (You can't change the serial on an issued cert; it's part of the signed content. You legally could create/issue a new cert, with new CA/serial, and all other contents the same
Re: Test of disabled renegotiation in 0.9.8l
Er, *why* are you dropping the connection when renegotiation is tried? The appropriate response, per RFC, if you don't want to renegotiate is to send a warning no_renegotiation alert. -Kyle H On Mon, Nov 16, 2009 at 10:40 PM, joshi chandra joshichandran...@gmail.com wrote: Hi , I have lot patch from cvs of Openssl which will disable all the renegotiation and also will drop the connection if renegotiation is tried . This is the patch from the cvs http://cvs.openssl.org/chngview?cn=18791 http://cvs.openssl.org/chngview?cn=18794 http://cvs.openssl.org/chngview?cn=18795 As i am using this patch in older version of openssl (9.8h and 9.8k ). will this patch disable the renegotiation and also drop the connection if renegotiation is done . Thanks in Advance Joshi Lutz Jaenicke wrote: Boyle Owen wrote: PPS: Although I have subscribed to this list, I am not getting the mails (I have to keep checking the archives). Is there anyone who can check out my account? Hmm. If memory serves me right there was a subscribe message sent to the list instead of the mailing list manager (which I then moderated away)... Please try again, we do have some handy form on the web page. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Test-of-disabled-renegotiation-in-0.9.8l-tp26301719p26385119.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ 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
Engines, versioning, --with-engines-dir in Configure
Hello. Different versions of OpenSSL install shared libraries with different names, e.g. libssl.0.9.8.extension and libssl. 1.0.0.extension. However, engines are always installed under $prefix/ lib/engines. Having said that, a) do/will engines follow the same semantics of OpenSSL versions, i.e., API/ABI compatibility? b) would it be possible to have a Configure parameter, e.g. --with- engines-dir, to specify the location of engines (ENGINESDIR)? That would allow coexistence of different OpenSSL versions engine-wise. Cheers, -- monipol __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: how to create an already revoked certificate?
Creating a CRL using openssl does nothing else than reading the certificatedatabase and creating an entry for all serialnumbers that have a R. You can create such a file by hand. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Renegotiation denied wrong?
I think it's pretty well understood at this point that 0.9.8l does the wrong thing when a client asks for a renegotiation (hangs the negotiation, basically). But it looks to me like 0.9.8-stable also gets it wrong. AFAICT by code inspection 0.9.8-stable (yesterday's snapshot) sends a Fatal INVALID PARAMETER alert and ends the session. That seems wrong. I believe a Warning NO RENEGOTIATION alert should be sent, and if the client then wants to close, it can do so -- or not. The code now seems to disconnect clients in violation of the standard; is there really a security reason to do this? I started to implement this but then discovered that there's other code which suppresses any attempt to send the NO RENEGOTIATION alert (commented with don't send :-)) -- what's with that? It seems like, though the quick implementation of the new renegotiation extension was very impressive, the handling of clients which try to do unsafe renegotiations is either still quite broken, or I am suffering from a serious misunderstanding of either the spec or the code. Could someone from the OpenSSL team please comment on this? Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
