Re: [openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
On Tue, Jun 20, 2006 at 07:03:49PM +0200, Kurt Roeckx wrote: Applications are also expected to provide a thread ID callback by calling CRYPTO_set_id_callback(), although the failure to do so should not be a problem on Linux where different threads run with different PIDs, since OpenSSL uses the PID as a default for the thread ID. I believe this is the only LinuxThreads implementation that you're talking about. Since kernel 2.6 there is also support for the Native POSIX Thread Library (NPTL). Afaik, that doesn't change PID for each process anymore. I guess in that case one must use pthread_self(), which returns a pthread_t. Yes, true. Sorry for the incomplete and incorrect description. (OpenSSL requires the thread ID that is an unsigned long. Not all systems may provide this, but in practice, you can work around this problem by casting a pointer of any per-thread object in shared memory space into an unsigned long; e.g., do foo=malloc(1); and then use (unsigned long)(void *)foo as the thread ID. You might want to add assert(sizeof(void *) = sizeof(long)); to the program if you use this approach.) This would a problem on platforms like windows x64 which are LLP64, where a long is still 32 bit and a pointer is 64 bit. Fortuantly, we don't need that on windows. OK, I have implemented something new for OpenSSL 0.9.9-dev (this will become available in openssl-SNAP-20060624.tar.gz at ftp://ftp.openssl.org/snapshot/ in about 12 hours, and of course in later 0.9.9-dev snapshots): In addition to void CRYPTO_set_id_callback(unsigned long (*func)(void)); there will be void CRYPTO_set_idptr_callback(void *(*func)(void)); Same thing, just here the type of the ID is void * rather than unsigned long. Thus the malloc() trick will work. OpenSSL compares both IDs and believes that it is in a previous thread only if both values agree with what they previously were. The default value I have chosen for the pointer-type thread ID (if an application does not provide a callback) is errno. For most, if not all, platforms, this default might end all worries about CRYPTO_set_id_callback(). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1328] FW: (Repost) SSL_shutdown and SSL_free issues
Hello Matt, I am interested in your issue with: SSL_shutdown(ssl); SSL_free(ssl); causing disruption of other SSL connections open within the same application. There should be nothing wrong not checking the return values of SSL_shutdown() is your application does not need a guaranteed end of session and doesn't need to ensure the SSL session cache keeps the session-id around to be re-used again. A guaranteed end of session are for applications that must ensure (cryptographically / securely) that all the data the other end was going to send has been received, and allows your end to signal to the other end its not going to send any more data. This is what the SSL_shutdown() provides, a secure end of transmission indication. This is to stop an attacker from prematurely terminating a network connection (man in the middle) to make each end presume the other end had finished. Most applications dont need this facility. The two calls above like that, would make the SSL_shutdown() attempt to send the shutdown notify alert, which may or may not get commited from application into kernel buffer (to be sent to your peer). You then SSL_free() and presumably a close(fd) takes place. I am thinking your SSL_ERROR_SSL on an SSL_read() of a different (SSL *) is an application programming error. Maybe you can indicate how many other SSL connections the application had open at the time, the amount of throughput/data traffic it was doing, the amount of time a connection stayed open. If you are using: SSL_set_shutdown(c-ssl, SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN); SSL_free(c-ssl); I belive the SSL_set_shutdown() call is redundant in that situation. Since SSL_free() does not initiate an automatic shutdown it just tears down the resources for the SSL socket and you can do no futher work with it. AFAIK SSL_free() will not cause a read() or write() to take place. Best Regards, Darryl -- Darryl L. Miles __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES FAQ openssl/crypto/bn/ bn.h bn_blind.c...
On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote: Log: New functions CRYPTO_set_idptr_callback(), CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type thread ID, since the 'unsigned long' type of the existing thread ID does not always work well. To clarify this, if CRYPTO_get_idptr_callback() is used, is it unnecessary to also call CRYPTO_set_id_callback? Does C9x actually guarantee that you can take the address of errno? From C99, section 7.5: [#1] The header errno.h defines several macros, all relating to the reporting of error conditions. [#2] The macros are EDOM EILSEQ ERANGE which expand to integer constant expressions with type int, distinct positive values, and which are suitable for use in #if preprocessing directives; and errno which expands to a modifiable lvalue170) that has type int, the value of which is set to a positive error number by several library functions. It is unspecified whether errno is a macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name errno, the behavior is undefined. [...] 170The macro errno need not be the identifier of an object. It might expand to a modifiable lvalue resulting from a function call (for example, *errno()). And: 6.5.3.2 Address and indirection operators Constraints [#1] The operand of the unary operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit- field and is not declared with the register storage-class specifier. I believe you can take the address of errno. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1328] FW: (Repost) SSL_shutdown and SSL_free issues
Hi Darryl, As you suspect we don't really need guaranteed secure stream termination, so really all I was interested in was closing the socket cleanly. I also suspected an application programming error on my part, but I really couldn't track it down, and as I say using the same method that Stunnel uses (the set_shutdown/free) just 'fixed it'. You're almost certainly right, the set_shutdown() is probably redundant, except I think in the case of caching connection attempts (my understanding is this will say 'Yes, we cleanly shut down, so store this connection in the cache'. We're not actually using the connection cache (apologies if I'm using the wrong terminology, I'm rusty on this code now!). So really, I'm now happy with what we're doing to close sockets, and all I can say is I wish I had time to get a replicable test case for this (which in doing so might show me the application error I've made, if any). My contract is up here soon, and once I'm between contracts I might be able to knock something up! Thanks for the reply, Warm regards, Matt Contract Coder, PKR -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darryl L. Miles via RT Sent: 23 June 2006 17:24 To: Matt Godbolt Cc: openssl-dev@openssl.org Subject: [openssl.org #1328] FW: (Repost) SSL_shutdown and SSL_free issues Hello Matt, I am interested in your issue with: SSL_shutdown(ssl); SSL_free(ssl); causing disruption of other SSL connections open within the same application. There should be nothing wrong not checking the return values of SSL_shutdown() is your application does not need a guaranteed end of session and doesn't need to ensure the SSL session cache keeps the session-id around to be re-used again. A guaranteed end of session are for applications that must ensure (cryptographically / securely) that all the data the other end was going to send has been received, and allows your end to signal to the other end its not going to send any more data. This is what the SSL_shutdown() provides, a secure end of transmission indication. This is to stop an attacker from prematurely terminating a network connection (man in the middle) to make each end presume the other end had finished. Most applications dont need this facility. The two calls above like that, would make the SSL_shutdown() attempt to send the shutdown notify alert, which may or may not get commited from application into kernel buffer (to be sent to your peer). You then SSL_free() and presumably a close(fd) takes place. I am thinking your SSL_ERROR_SSL on an SSL_read() of a different (SSL *) is an application programming error. Maybe you can indicate how many other SSL connections the application had open at the time, the amount of throughput/data traffic it was doing, the amount of time a connection stayed open. If you are using: SSL_set_shutdown(c-ssl, SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN); SSL_free(c-ssl); I belive the SSL_set_shutdown() call is redundant in that situation. Since SSL_free() does not initiate an automatic shutdown it just tears down the resources for the SSL socket and you can do no futher work with it. AFAIK SSL_free() will not cause a read() or write() to take place. Best Regards, Darryl -- Darryl L. Miles __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ CHANGES FAQ openssl/crypto/bn/ bn.h bn_blind.c...
On Fri, Jun 23, 2006 at 06:42:10PM +0200, Kurt Roeckx wrote: On Fri, Jun 23, 2006 at 04:36:07PM +0100, Joe Orton wrote: Log: New functions CRYPTO_set_idptr_callback(), CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type thread ID, since the 'unsigned long' type of the existing thread ID does not always work well. To clarify this, if CRYPTO_get_idptr_callback() is used, is it unnecessary to also call CRYPTO_set_id_callback? Yes, exactly. Does C9x actually guarantee that you can take the address of errno? From C99, section 7.5: [...] And: 6.5.3.2 Address and indirection operators [...] I believe you can take the address of errno. Yes, that is what I too was reading from the standard. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
support for TLS extension
Is this RFC supported in current version of openssl?http://www.ietf.org/rfc/rfc3546.txtthanks,Weidong
Re: support for TLS extension
This message should have gone to the openssl-users list. To answer your question, it depends on what you mean by supports. There is currently no means in place to define your own extension ID numbers and write handlers for them, to possibly modify the SSL_CTX or SSL structure that is associated with the BIO. However, there is some small support for some of the extensions, if I recall correctly. There has been a lot of discussion about it, in any case, a lot of it on the -users mailing list. I would suggest reading there, searching for anything with '3546' in it. -Kyle H On 6/23/06, Weidong Shao [EMAIL PROTECTED] wrote: Is this RFC supported in current version of openssl? http://www.ietf.org/rfc/rfc3546.txt thanks, Weidong __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
