windows build
I've seen posts from time to time about difficulties building on Windows. I had some problems as well and wanted to send this out to maybe save others some time. The INSTALL.W32 and .W64 mention that you could use the Cygwin perl, but when I tried that it just hung on one of the invocations and did nothing. I had to download and install ActivePerl as mentioned to get do_win64a to work. I also found I could only get it to compile when configured for VC-WIN64A, not VC-WIN64I. I also found that ntdll.mak wouldn't work, but nt.mak would. All of this was on Windows 2003 with Visual Studio 2005. Wayne.
multithreading question
Our server does a raw socket accept first, and then spawns a thread for each that brings up the ssl connection if applicable. The code flow is like this: int fd; SSL_CTX* ctx; SSL* ssl; BIO* fdbio = BIO_new_socket((int)fd, 0); BIO* bio = BIO_new_ssl(ctx, client); BIO_push(bio, fdbio); BIO_get_ssl(bio, &ssl); The SSL_CTX is shared across the multiple threads. My question is whether BIO_new_ssl() should be serializing so that only one thread is instantiating an SSL instance at a time from the SSL_CTX. Wayne. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify fails if two certs with same subject are in the trustedCA lookup file
Take a look at subject key identifiers... On Mon, 2009-10-19 at 14:35 +0200, Steffen DETTMER wrote: > * Arno Garrels wrote on Sun, Oct 11, 2009 at 16:10 +0200: > > > > Why are issuers looked up by subject at all? > > > > > > > > > > Because that's what the standards (X.509, RFC3280 et al) require. > > > > Ah ok, but shouldn't name duplicates be taken into account when > > issuers are looked up, even though that might result in worse > > performance? > > I guess having duplicated Distinguished Names is wrong. > > oki, > > Steffen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: BIO_renegotiate_timeout and BIO_renegotiate_bytes
I spent some time in the debugger (yeah for open source) and figured out what's going on. This is a follow up for others who may run into the same issue. The auto renegotiate code is handled only by the SSL BIO implementation, not by the fd BIO implementation (which silently ignores the BIO_set_ssl_renegotiate_* calls. My new configuration code looks like the following SSL_CTX* ctx; BIO* bio = BIO_new_ssl(ctx, false); BIO_push(bio, BIO_new_socket((int)fd, 0); BIO_set_ssl_renegotiate_bytes(bio, bytes); BIO_set_ssl_renegotiate_timeout(bio, seconds); and calls to BIO_get_num_renegotiates(bio) show periodic increments. Wayne. On Thu, 2009-10-01 at 19:49 -0700, Wayne Feick wrote: > I'm having trouble getting BIO_renegotiate_timeout() and > BIO_renegotiate_bytes to work, and I'm hoping someone can help me out > with what I'm doing wrong. > > The socket is initially opened and a connection accepted, and then I > setup SSL with the following. > > SSL* ssl = SSL_new(ctx); > BIO* bio = BIO_new_socket((int)fd, 0); > SSL_set_bio(ssl, bio, bio); > > I then do the following to configure the auto renegotiation. > > BIO* rbio = SSL_get_rbio(ssl); > BIO_set_ssl_renegotiate_bytes(rbio, 1024*1024); > BIO_set_ssl_renegotiate_timeout(60); > > Our client/server protocol involves a heartbeat once per second, and in > there I'm printing out the return value of > > BIO_get_num_renegotiates(SSL_get_rbio(ssl)) > > but it's always 0. > > Is there some other sort of configuration I need to be doing to get this > to work? I've seen other people ask about this on the list, but never > any responses. Is anyone using this successfully? > > Thanks, > Wayne. > > > __ > 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
BIO_renegotiate_timeout and BIO_renegotiate_bytes
I'm having trouble getting BIO_renegotiate_timeout() and BIO_renegotiate_bytes to work, and I'm hoping someone can help me out with what I'm doing wrong. The socket is initially opened and a connection accepted, and then I setup SSL with the following. SSL* ssl = SSL_new(ctx); BIO* bio = BIO_new_socket((int)fd, 0); SSL_set_bio(ssl, bio, bio); I then do the following to configure the auto renegotiation. BIO* rbio = SSL_get_rbio(ssl); BIO_set_ssl_renegotiate_bytes(rbio, 1024*1024); BIO_set_ssl_renegotiate_timeout(60); Our client/server protocol involves a heartbeat once per second, and in there I'm printing out the return value of BIO_get_num_renegotiates(SSL_get_rbio(ssl)) but it's always 0. Is there some other sort of configuration I need to be doing to get this to work? I've seen other people ask about this on the list, but never any responses. Is anyone using this successfully? Thanks, Wayne. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: session renegotiation
Thanks for the quick response, David. I hadn't seen any documentation on BIO_set_ssl_renegotiate_bytes/timeout(), but that sounds like a simpler way to go. If I set them both, do they both reset whenever a renegotiation takes place? Any recommendations on reasonable settings for SSLv3/TLSv1? Re: the readers/writers, the writers are serialized on the semaphore, but the single reader is never serialized. I had though that configuration the mutex locking stuff (using CRYPTO_set_locking_callback() code lifted from "Network Security with OpenSSL", page 76) would allow multiple readers/writers. Is that not the case? Wayne. On Tue, 2009-05-19 at 21:09 -0700, David Schwartz wrote: > Wayne Feick wrote: > > > Our server has one background thread constantly calling SSL_read() > > to drain incoming data. There are multiple threads generating outgoing > > data but all the SSL_write() calls are serialized with a semaphore. > > All I/O is blocking. > > I'm not sure how you could make this work. If all I/O is blocking, the call > to SSL_read will block until data is available. If a thread generating > outgoing data wants to call SSL_write, how can it do so since the reader > thread will hold the sempahore? > > You do realize that you cannot concurrently call SSL_read and SSL_write on > the same SSL connection. You can concurrently call SSL_write on distinct SSL > connections. > > Also, OpenSSL will renegotiate automatically. > > BIO_set_ssl_renegotiate_bytes() sets the renegotiate byte > count to num. When set after every num bytes of I/O (read > and write) the SSL session is automatically renegotiated. > num must be at least 512 bytes. > > BIO_set_ssl_renegotiate_timeout() sets the renegotiate > timeout to seconds. When the renegotiate timeout elapses > the session is automatically renegotiated. > > DS > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org
session renegotiation
Hi All, I've been banging my head against the wall for the last few days trying to get session renegotiation working in a server I'm working on, and I'm hoping someone here can give me a clue. I'm using openssl-0.9.8i. Our server has one background thread constantly calling SSL_read() to drain incoming data. There are multiple threads generating outgoing data but all the SSL_write() calls are serialized with a semaphore. All I/O is blocking. The sockets are very long lived, so the renegotiation is used to periodically switch session keys. I've done a fair bit of web searching, and have found conflicting information on how to properly trigger a renegotiation, with different suggestions for server side vs. client side. A typical server side example is SSL_renegotiate(); SSL_do_handshake(); ssl->state = SSL_ST_ACCEPT; SSL_do_handshake(); while a typical client side example is SSL_renegotiate(); SSL_do_handshake(); Looking in O'Reilly's Network Security WIth Open SSL, it seems that as of 0.9.7 I can just do SSL_renegotiate() from either side of a connection and the underlying library will just do the right thing and I can use SSL_renegotiate_pending() to determine if/when the renegotiation has completed. The problem I'm running into is that this last approach seems to sometimes work, but periodically I get errors up from SSL_read() or SSL_write(). For example, "decryption failed or bad record mac" or "ssl handshake failure". I get the feeling I'm missing some piece of this puzzle. Can anyone help me out? Thanks, Wayne.
