RE: bad mac decode error
What version of SSL is the client using using? I've had this problem before, and there are other mails in the archive which describe this error, when a "broken" server cannot perform SSL version negotiation properly, i.e if your client is using SSL version 23. Hardcoding the version to 2 or 3 usually works. G. -Original Message- From: Tat Sing Kong [mailto:[EMAIL PROTECTED]] Sent: 04 April 2001 15:08 To: openssl Subject: bad mac decode error I have got an LDAP client talking to an LDAP server using SSL no problems. I am now using the openssl s_client program to talk to the LDAP server using the name security certs etc. However, after the ChangeCipherSpec mesages I get bad mac decode So I guess something has gone very wrong somewhere. I thought there was only one SSL protocol, if it works for one SSL server/client, it should work for all clients, servers etc? Any ideas? Tat. __ 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]
Closing SSL connections
Hi, I'm working with an HTTP application, and according to the RFC when sending the HTTP response it is permissible to signal the end of the response by closing the socket (rather than using the Content-Length header). When implementing the HTTP client using SSL, SSL_read will return SSL_ERROR_ZERO_RETURN. Is it safe to treat this as a non-error. i.e. there are no other circumstances in which this return code will signal a true error? When implementing the HTTP server using SSL, is it safe to issue an SSL_shutdown and a socket disconnect while the client is listening? Thanks, G. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Closing SSL connections
Thanks Greg, Does this mean that SSL v2 would return a different return code from SSL_read? And if not then how can I check for the particular circumstance of a socket disconnection in this mode. I'm just trying to get a handle on how I can support the RFC with SSL v2, it must have been done by others before now. G. -Original Message- From: Greg Stark [mailto:[EMAIL PROTECTED]] Sent: 18 April 2001 18:14 To: [EMAIL PROTECTED] Subject: Re: Closing SSL connections It is safe to treat this as a non-error if you are using SSL version 3 or higher, but not if you connected with SSL version 2. So do not use SSL v2. Sending an SSL_shutdown() is the safe way to close the connection, but it may have performace implications because of the rules OpenSSL uses for managing session resumption. See the documentation for SSL_set_shutdown() (http://www.openssl.org/docs/ssl/SSL_set_shutdown.html#) for some hints of what to do. _ Greg Stark Ethentica, Inc. [EMAIL PROTECTED] _ - Original Message - From: "Shaw, George" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 18, 2001 12:38 PM Subject: Closing SSL connections > Hi, > > I'm working with an HTTP application, and according to the RFC when sending > the HTTP response it is permissible to signal the end of the response by > closing the socket (rather than using the Content-Length header). > > When implementing the HTTP client using SSL, SSL_read will return > SSL_ERROR_ZERO_RETURN. Is it safe to treat this as a non-error. i.e. there > are no other circumstances in which this return code will signal a true > error? > > When implementing the HTTP server using SSL, is it safe to issue an > SSL_shutdown and a socket disconnect while the client is listening? > > Thanks, > > G. > __ > 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] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Closing SSL connections
Hi, Not my option, unfortunately, as we sell a toolkit for customer implementations. But I guess I have the same problem in a non-SSL environment in any case, so I have to handle it some way. G. -Original Message- From: Greg Stark [mailto:[EMAIL PROTECTED]] Sent: 19 April 2001 16:04 To: [EMAIL PROTECTED] Subject: Re: Closing SSL connections George, Do you really need to allow SSLv2? I'm curious, as I would think that by now there are almost no systems left which CANNOT use SSLv3. _ Greg Stark Ethentica, Inc. [EMAIL PROTECTED] _ - Original Message - From: "Shaw, George" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 19, 2001 6:12 AM Subject: RE: Closing SSL connections > Thanks again Greg, > > I did a little more testing. As you indicated in your earlier mail, if I > receive SSL_ERROR_ZERO_RETURN I can test SSL_get_shutdown() and for TLSv1 > and SSLv3 this will indicate the connection closure, which will be safe > enough for me I think. But this state is not set for SSLv2. > > Your comment about how to know that the HTTP response is complete is > entirely appropriate. The use of the Content Length header or data chunking > is recommended in the RFC, but socket closure as an indicator is allowed by > HTTP 1.0, and by 1.1 due to backwards compatibility. And if I test my > client against Apache, with the URL configured to return no Content Length, > then if you use HTTP 1.1, Apache will include data chunking to indicate the > end-of-response, but if you use HTTP 1.0, then there is no indication at > all, you just have to wait for the socket closure. This is all in a non-SSL > environment, but I would guess that this is the same using SSL. > > So this leaves me with a problem using HTTP 1.0 and SSL v2. SSL v2 still > returns SSL_ERROR_ZERO_RETURN when the connection is closed. As I'm working > in a B2B environment, I guess I'll have to make some kind of restriction on > the application, or to issue a warning/alert of some kind. > > Unless somebody else has experience of this ... > > Thanks again, > > G. > > > -Original Message- > From: Greg Stark [mailto:[EMAIL PROTECTED]] > Sent: 18 April 2001 20:10 > To: [EMAIL PROTECTED] > Subject: Re: Closing SSL connections > > > George, > > I don't really know what happens in the SSLv2 case. SSLv2 has no > close_notify message, so there's no secure way for SSL to know that a > connection is being closed. The higher level protocol must provide some > equivalent secure mechanism for connection closure, or you are vulnerable to > truncation attacks. > > When you call SSL_shutdown() on an SSLv2 connection, the library doesn't > actually do much of anything except mark the connection as having been > shutdown. So I don't know what happens, you'll have to try it and see or > perhaps someone else can answer. > > In SSLv2, without a Content-Length header or some other heursitic (like > looking for the tag), how can your client be certain the transport > closure packet (TCP FIN) wasn't spoofed? > > > _ > Greg Stark > Ethentica, Inc. > [EMAIL PROTECTED] > _ > > > > - Original Message - > From: "Shaw, George" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, April 18, 2001 1:25 PM > Subject: RE: Closing SSL connections > > > > Thanks Greg, > > > > Does this mean that SSL v2 would return a different return code from > > SSL_read? And if not then how can I check for the particular circumstance > > of a socket disconnection in this mode. I'm just trying to get a handle > on > > how I can support the RFC with SSL v2, it must have been done by others > > before now. > > > > G. > > > > -Original Message- > > From: Greg Stark [mailto:[EMAIL PROTECTED]] > > Sent: 18 April 2001 18:14 > > To: [EMAIL PROTECTED] > > Subject: Re: Closing SSL connections > > > > > > It is safe to treat this as a non-error if you are using SSL version 3 or > > higher, but not if you connected with SSL version 2. So do not use SSL v2. > > > > Sending an SSL_shutdown() is the safe way to close the connection, but it > > may have performace implications because of the rules OpenSSL uses for > > managing session resumption. See the documentation for SSL_set_shutdown() > > (http://www.openssl.org/docs/ssl/SSL_set_shutdown.html#) for some hints of > > what to do. > > > > _ > >
IIS and closing SSL connections
Hi, As an addendum to my other thread on closing SSL connections safely in an HTTP environment, most of my testing there was done between my own client and server. Now I start testing with IIS, and the IIS server looks like it closes the SSL connection "illegally", as my client gets SSL_ERROR_SYSCALL instead of SSL_ERROR_ZERO_RETURN, ERR_get_error() returns 0, and the SSL_read returned 0. According to the manual this is a protocol violation. Does anybody have experience of this, and how to work around it? G. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Return code from SSL_write
Hi, I'm encountering a problem with SSL_write when writing a large amount of data (about 1Mb) using non-blocking sockets. For smaller amounts of data (about 1kb), the return code (bytes written) what you would expect. For the larger amount of data, the return code is -1. When checking SSL_get_error() the result is SSL_ERROR_NONE (0). If I then repeat the write, as if the result want SSL_WANT_READ or SSL_WANT_WRITE, then the behaviour just repeats itself. There is no apparent explanation in the man pages to SSL_write of what action to take if the bytes written is -1, but SSL_get_error() returns 0. Then I considered that I might want to implement partial writing. So I changed the code to add: (void)SSL_CTX_set_mode(sslContextP, SSL_MODE_ENABLE_PARTIAL_WRITE); ... and then the behaviour does change. Now the bytes written returns a block of data (16384 bytes), until I have written about 300k, when the same behaviour above occurs. Can anybody enlighten me on how to handle this combination. Using blocking sockets, there was no problem. Thanks, G. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Return code from SSL_write
Duhhh. Of course, a foolish code error, declaring bytesWritten as size_t rather than int and comparing with 0. Thanks for your tolerance. I'm regularly amazed by the good humour that you all show to idiot users. G. -Original Message- From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]] Sent: 10 July 2001 21:04 To: '[EMAIL PROTECTED]' Subject: Re: Return code from SSL_write On Tue, Jul 10, 2001 at 03:55:24PM +0100, Shaw, George wrote: > I'm encountering a problem with SSL_write when writing a large amount of > data (about 1Mb) using non-blocking sockets. > > For smaller amounts of data (about 1kb), the return code (bytes written) > what you would expect. > > For the larger amount of data, the return code is -1. When checking > SSL_get_error() the result is SSL_ERROR_NONE (0). If I then repeat the > write, as if the result want SSL_WANT_READ or SSL_WANT_WRITE, then the > behaviour just repeats itself. With all due respect: there must be something wrong with your code. There is just one place in SSL_get_error(), at which SSL_ERROR_NONE is returned: in the case "i>0", meaning that the return code was positive. Are you sure, that your call to SSL_get_error() is correct? > There is no apparent explanation in the man pages to SSL_write of what > action to take if the bytes written is -1, but SSL_get_error() returns 0. Yes, that is because it cannot happen... 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] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL connection without certificate and private key?
You can use Anonymous Diffie-Hellman cipher, which is excluded from the default cipher list. But beware ... this will not stop a man-in-the-middle attack. You should look at the set cipher functions in the manual pages. G. -Original Message- From: Petr Knez [mailto:[EMAIL PROTECTED]] Sent: 28 January 2002 13:56 To: [EMAIL PROTECTED] Subject: SSL conection without certificate and private key? Hi, can I establish SSL conection without certificate and private key? I need only secure conection without authentication. I have tried this but SSL_accept return this error: (1) error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher. Thanks, Petr __ 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_pending() and SSL_ERROR_WANT_READ
Hi, SSL_pending() returns the number of bytes in the SSL buffer that have been decrypted by not requested by SSL_read(). This will occur when there is a mismatch between the number of bytes requested by SSL_read() and the block size used to encrypt/decrypt the data. SSL_ERROR_WANT_READ (and SSL_ERROR_WANT_WRITE) are returned to indicate that an SSL handshake is going on, and is not complete, so you should re-call the same function. No data will be decrypted into the SSL buffer, so SSL_pending() will always return zero. This is described in the manual pages, I believe, and in Mr Rescorla's excellent book. G. -Original Message- From: Patrick Li [mailto:[EMAIL PROTECTED]] Sent: 12 March 2002 20:35 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: SSL_pending() and SSL_ERROR_WANT_READ Hi, I am experiencing the followings when running my SSL client on nonblocking sockets. 1. SSL_read() fails and SSL_get_error() returns SSL_ERROR_WANT_READ 2. my client program calls SSL_pending() and it returns non-zero. 3. since SSL_pending() is returning non zero, that is data available and my program won't select on the read socket. 4. call SSL_read() again and it returns SSL_ERROR_WANT_READ My question is the SSL_pending() returning of non-zero is misleading. As the subsequent SSL_read() call at step 4 is returning SSL_ERROR_WANT_READ again. So, may be I should not check SSL_pending() when SSL_read() returns SSL_ERROR_WANT_READ? Can someone confirm? Thanks a lot. Patrick __ 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]
