RE: sgc
Dr Henson, Thanks for your reply. According to your answer I need to check the following ciphers: DEFAULT:!EXPORT56 DEFAULT:!MD5 DEFAULT:!SHA1 The problem is that I minimized the IE 5.01's problematic ciphers to one: RC4-MD5. So I use DEFAULT:!RC4-MD5 and still there are some browsers that needs the RC4-MD5 cipher in order to work. So this solution isn't good for me. Is there a way to get into the code and disable the SGC in openssl ? Can I solve the problem by using a server certificate that doesn't support SGC ? Thanks, Itai. -Original Message- From: Dr S N Henson [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 01, 2001 7:00 PM To: [EMAIL PROTECTED] Subject: Re: sgc Itai Levy wrote: Hi, I'm using a web server based on openssl 0.9.5. When I use a certificate which enables the use of SGC, I have a problem to connect with IE 5.01 browsers. I know that the reason for this is that there is a bug in the implementation of SGC in IE 5.01. I use the cipher group DEFAULT:!RC4-MD5 as a work around (with these ciphers I can connect with IE 5.01). The problem with this is that this ciphers group is not enough for some of the browsers. Is there a way to disable SGC in openssl 0.9.5 ? I know that openssl 0.9.4 doesn't support SGC, so there should be no problem, but I don't want to downgrade. OpenSSL 0.9.4 didn't support SGC but then you probably aren't using SGC either. You are probably using "step up" which is Netscapes version. The problem is related to some new ciphersuites in OpenSSL 0.9.5 and a bug in MSIE which is triggered by the use of step up and an attempt to use two ciphersuites with different digests. There are several cipher strings you can try: DEFAULT:!EXPORT56 DEFAULT:!MD5 DEFAULT:!SHA1 If some versions of Netscape you are using don't support SHA1 strong ciphersuites then you may need the last one. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: sgc
Itai Levy wrote: Dr Henson, Thanks for your reply. According to your answer I need to check the following ciphers: DEFAULT:!EXPORT56 DEFAULT:!MD5 DEFAULT:!SHA1 The problem is that I minimized the IE 5.01's problematic ciphers to one: RC4-MD5. The problem is not RC4-MD5 at all its the fact that the first weak cipher uses SHA1 and the second is MD5. By disabling RC4-MD5 it ends up using two ciphers that both use SHA1. So I use DEFAULT:!RC4-MD5 and still there are some browsers that needs the RC4-MD5 cipher in order to work. So this solution isn't good for me. Is there a way to get into the code and disable the SGC in openssl ? Can I solve the problem by using a server certificate that doesn't support SGC ? Yes that will also work and it should be cheaper too. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Man in the middle attacks
I am replying to -users even though the original post was sent to -dev. First, a nit on terminology. The protocols should be referred to as the SSL protocols or perhaps more accurately the SSL/TLS protocols, not the openssl protocol. OpenSSL is an implementation of these protocols. The attack you are referring to is defeated by the client checking the identity that is contained in the certificate. I do not know why you are so sure that this checking is not normally done. IE and Netscape Nav. do it, for example, The mere possession of some valid certificate is not in and of itself likely to be good enough for any SSL-secured protocol, and certainly not for HTTPS. See RFC 2818 (http://www.rfc-editor.org/rfc/rfc2818.txt). I can conceive of some scenarios where the only checking needed to trust a peer is that the peer's certificate is rooted at some specially-trusted CA, but this is clearly a specialized scenario. In the case of OpenSSL, no such checking is performed, because it is not appropriate. The SSL protocol is always used by some higher layer protocol, such as HTTP over SSL. The SSL protocol merely provides for certificate-based authentication. It is the job of this higher-level protocol to decide what identifying information in the certificate must be checked. OpenSSL faithfully adheres to this. It checks the validity of the certificates as much as it possibly can, but it cannot sensibly enforce a check on the identity contained in the certificate since these can vary from application to application. It can, and does, provide ample hooks for developers to get at this identity information to complete the steps needed to authenticate the peer. This information is typically contained in the subject name and sometime also in the extensions. Perhaps the only complaint one *might* make is the absence in OpenSSL of an example to perform the most common identity check, that the hostname contained in the CN field of the subject name matches the hostname the client intended to connect to. I am not complaining, though. _ Greg Stark Ethentica, Inc. [EMAIL PROTECTED] _ - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 04, 2001 8:16 AM Subject: Man in the middle attacks I have been thinking that the openssl protocol might be vulnerable to man in the middle attacks. From a general standpoint here is what I am thinking and I will use an https example although I think it is apparent that any protocol is vulneable. And I will admit that I may be out to lunch here too. Suppose we set up the classic Man in the Middle attack: client proxy host In this situation our proxy takes the host website for example and fully duplicates it including going to the effort of going to say Tawtie and getting a valid cert. A connection like client host will in fact look identical to client proxy and it is clear that our proxy can extablish a connection to the host just as a client can. I don't see how the openSSL protocol prohibits this or even accomodates either the client or the host knowing that it is even taking place.. One way to address this would be to take the IP address of the host and the client and encode this within the message being transmitted - and this may be done. But this STILL does not solve the problem. Since the client in general will not know the IP address of the host, our proxy in the middle can still completely mimic the actions of the host. Furthermore, in general most clients may in fact live behind a firewall and this would mean the host will be talking literally to millions of clients at 192.168.1.x. I think there _may_ be a way to address this. In the foregoing situation the proxy had to obtain a valid cert from a CA. The https protocol just expects a valid cert to be there and says nothing about who this cert was issued to. What is to stop a repressive governement like say Iraq for instance from funneling 100% of their citizens IP traffic through a proxy that inserts "THEIR" cert in place of the host cert in the authentication process. What has to take place is that the software that runs in the client computer must issue some sort of message indicating "who" it is establishing a connection with in all cases. Then it _could_ come up and say something to the effect of "secure connection established to "Iraq Proxy" and presuming the code the client is running has not been tampered with - at least the client would know. As it stands now - I think there is ZERO in the way of security against this kind of attack and I don't even think the host can find out if a proxy in the middle is really there. SUppose the IP address of the computer doing the encryption is encoded into the record. Then a host could potentially keep a list of proxys that may be set up and simply refuse to talk to them. Note that any message sent to an
Netscape accepts cert from evil empire
First off - I am new to this and I'm learning. I do not claim to know very much about it and asked the question in openssl-dev because it seemed to me that if the DNS is highjacked that the transaction can be masqueraded. I did a test with Netscape 4.07. This browser is not terribly old. I created a cert with the host name known as www.evilempire.com and netscape was quite happy to accept it and never reported that the URL I typed in does not match the name carried within the cert. However - it did warn me all over the place that I was accepting a cert from an known CA. It properly displayed the identification information but NOT the recorded host name. Perhaps this works differently in a proper cert issued by say Verisign. I do know that they put the host name in the CommonName field of the cert. It is just that in my test I was quite surprised that Netscape did not tell me that there is a mismatch. So I may well have come to an improper conclusion. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Netscape accepts cert from evil empire
[EMAIL PROTECTED] wrote: I created a cert with the host name known as www.evilempire.com and netscape was quite happy to accept it and never reported that the URL I typed in does not match the name carried within the cert. You're wrong. Even those old Netscape Navigator 4.0x certainly asks if the host name component of the URL does not match CN attribute of the server cert. There was a bug in Netscape browser (4.72 and earlier version) related to session caching. Maybe this is what you're experiencing. (But I doubt it.) Compare with: http://www.cert.org/advisories/CA-2000-05.html http://www.cert.org/advisories/CA-2000-08.html Ciao, Michael. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_shutdown() ?
After calling SSL_shutdown() is it still nesc to close the underlying socket associated with the SSL Connection? Is it also nesc to free() the SSL stuct return from SSL_new() or is that done somewher in the shutdown? Thnaks in advance G. -- - Gil Peeters CANCAS I.T. (bvba) Willemsstraat 2 3000 Leuven, Belgium - JAVA and Distributed Object Specialists - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Netscape accepts cert from evil empire - found it!!
Micheal, thankyou. I did find it under "more info". This sure is not obvious mind you... thanx for the clarification. On Sun, Feb 04, 2001 at 06:08:20PM +0100, Michael Strder wrote: [EMAIL PROTECTED] wrote: I created a cert with the host name known as www.evilempire.com and netscape was quite happy to accept it and never reported that the URL I typed in does not match the name carried within the cert. You're wrong. Even those old Netscape Navigator 4.0x certainly asks if the host name component of the URL does not match CN attribute of the server cert. There was a bug in Netscape browser (4.72 and earlier version) related to session caching. Maybe this is what you're experiencing. (But I doubt it.) Compare with: http://www.cert.org/advisories/CA-2000-05.html http://www.cert.org/advisories/CA-2000-08.html Ciao, Michael. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown() ?
On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote: After calling SSL_shutdown() is it still nesc to close the underlying socket associated with the SSL Connection? SSL_shutdown() will only send the close-alert to the peer and switch the setting of the SSL to "shutdown mode". It does not touch the underlying connection, so: yes, you have to close the underlying socket connection yourself. Is it also nesc to free() the SSL stuct return from SSL_new() or is that done somewher in the shutdown? Once you have called SSL_shutdown(), you can either free the SSL object via SSL_free() (call SSL_new() to obtain a new one later) or call SSL_clear() to reset the SSL object and make it ready for a new connection. 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: SSL_shutdown() ?
Lutz Jaenicke wrote: On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote: After calling SSL_shutdown() is it still nesc to close the underlying socket associated with the SSL Connection? SSL_shutdown() will only send the close-alert to the peer and switch the setting of the SSL to "shutdown mode". It does not touch the underlying connection, so: yes, you have to close the underlying socket connection yourself. So closing the socket will not hurt. Will this be a problem if I want to re-use the session??? i.e will closing the userlying socket cause problems when re-using the session info. Is it also nesc to free() the SSL stuct return from SSL_new() or is that done somewher in the shutdown? Once you have called SSL_shutdown(), you can either free the SSL object via SSL_free() (call SSL_new() to obtain a new one later) or call SSL_clear() to reset the SSL object and make it ready for a new connection. I notice in the code for SSL_free that the SSL_SESSION is also freed. (call to SS_SESSIO_free). Will the SSL_SESSION still be 'cached' because I told the SSL_CTX to cahce client sessions? Thanks again. -- - Gil Peeters CANCAS I.T. (bvba) Willemsstraat 2 3000 Leuven, Belgium - JAVA and Distributed Object Specialists - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown() ?
On Sun, Feb 04, 2001 at 07:30:27PM +0100, Gil Peeters wrote: On Sun, Feb 04, 2001 at 06:12:39PM +0100, Gil Peeters wrote: After calling SSL_shutdown() is it still nesc to close the underlying socket associated with the SSL Connection? SSL_shutdown() will only send the close-alert to the peer and switch the setting of the SSL to "shutdown mode". It does not touch the underlying connection, so: yes, you have to close the underlying socket connection yourself. So closing the socket will not hurt. Will this be a problem if I want to re-use the session??? i.e will closing the userlying socket cause problems when re-using the session info. No. The network/socket layer does not affect the session handling, but see below. Is it also nesc to free() the SSL stuct return from SSL_new() or is that done somewher in the shutdown? Once you have called SSL_shutdown(), you can either free the SSL object via SSL_free() (call SSL_new() to obtain a new one later) or call SSL_clear() to reset the SSL object and make it ready for a new connection. I notice in the code for SSL_free that the SSL_SESSION is also freed. (call to SS_SESSIO_free). Will the SSL_SESSION still be 'cached' because I told the SSL_CTX to cahce client sessions? The session in question should have a reference count of two, because it is used two times. Once it is used in the SSL object, once it is contained in the cache. SSL_SESSION_free() will only reduce the reference count once, as the SSL object will be deleted. This leaves one reference count for the session still being in the cache. But: just before the SSL_SESSION_free() there is a ssl_clear_bad_session(s); When the session was not successfully closed (if you reverse engineer the source you will easily find what I mean) by either calling SSL_shutdown() or SSL_set_shutdown() for the SSL before SSL_free(), the session will be considered faulty and will be removed from the cache, so that after the SSL_free() it will be finally gone. I am currently writing the manual pages for the session caching but this is one of the things that I have to add in the next days. 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]
Message status - undeliverable
The message that you sent was undeliverable to the following: SHARSHAD Information about your message: Subject: Re: SSL_shutdown() ?
Message status - undeliverable
The message that you sent was undeliverable to the following: SHARSHAD Information about your message: Subject: Message status - undeliverable
Message status - undeliverable
The message that you sent was undeliverable to the following: SHARSHAD Information about your message: Subject: Message status - undeliverable
Message status - undeliverable
The message that you sent was undeliverable to the following: SHARSHAD Information about your message: Subject: Message status - undeliverable
Brand New E-Mail pager for FR-EE! 7681
Accessmate E-Mail display pager. This is the top of the line PCS technology pager made today. This side viewable display pager has a retail value of $189.00and comes with its own e-mail address so you can receive your e-mails as well as alpha-numeric and numeric messages instantly where ever you are. Your new e-mail pager has features like 50,000 character memory, message time stamping, automatic garbled message correction, beeps or vibrates, incandescent backlight, saved message folder, a unique never out of range feature that allows your pager to retrieve messages sent earlier when your pager was out of range or turned completely off. You can also receive weather, news and sports .The Motorola e-mail pager is very small and uses only a single double A battery. All we ask before we ship you your Free pager is for you to allow us to provide the airtime for you. There is no long term contract or credit check. Airtime is month to month and can be cancelled at any time. This pager will comes pre-programmed with its own e-mail address as well as a local telephone number to receive numeric pages. This pager comes with a complete 30 day money back guarantee, if after receiving this pager you're not completely happy, send it back and receive a full refund. For immediate delivery call Paging America at toll free at 877-699-8546 Brand New E-Mail pager for FREE! No long term contract No activation fee No big prepayment of airtime No credit check PAGING AMERICA is going to give you absolutely Free the Brand new Motorola __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Fw: How to add Key usage attribute...
Hi all, I have a question regarding the adding of the Key usage attribute to the PKCS10 certificate request. I tried using the following code.. ikeyUsageAttr = X509v3_KU_DIGITAL_SIGNATURE; iRetVal = X509_REQ_add1_attr_by_NID(preq, NID_key_usage,V_ASN1_INTEGER, (ikeyUsageAttr), 4); When I try to print the request using X509_REQ_print, it is not printing the key usage attribute. It is giving "Unable to print the value of the attribute" In X509_REQ_print ( ) function , there is no option to print the value of attribute of either type V_ASN1_INTEGER or V_ASN1_BIT_STRING My question is whether I am following the correct way to add the Key usage attribute.. If not what is the correct way to add it. If Yes What is the way to check and print the value of the key usage attribute... Any help regarding this is highly appreciated... Regards Suram __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
