Re: Up-to-date Tutorial
On Wed, 16 Jun 2010 12:14:49 -0400 Brandon McCaig bamcc...@gmail.com wrote: Hello, I'm having trouble finding up-to-date tutorials (or any documentation at all) for the OpenSSL APIs. The best one that I have found is apparently from 2004: http://www.ibm.com/developerworks/linux/library/l-openssl.html I'm worried that it is out of date and I'll be wasting my time learning the 6-year-old API. I see that others have asked for tutorials a few times in the past, but it seems to have been a while. I'm aiming to eventually develop a secure messaging system, but I'm completely new to cryptography and OpenSSL (I still need guides to walk me through generating keys, and I don't fully understand which keys fit which locks...). BTW, anybody know why is the documentation so sparse? :\ A few of my bookmarks: http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html http://docs.sun.com/source/816-6156-10/contents.htm http://docs.sun.com/source/816-6154-10/contents.htm http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04.html http://sial.org/howto/openssl/ https://help.ubuntu.com/community/OpenSSL __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multi Threaded questions
On Sun, 18 Apr 2010 21:11:40 -0700 David Schwartz dav...@webmaster.com wrote: Sad Clouds wrote: 1) According to the FAQ, an SSL connection may not concurrently be used by multiple threads. Does this mean that an SSL connection can be used by different threads provided access is limited to one at a time? I assume that having a mutex for each SSL object would prevent it from being concurrently used by multiple threads. So this should be OK. Yes, that works. However, you can't use blocking operations in that case. Otherwise, a thread trying to write to the connection would be blocked potentially for ever as some other thread blocked trying to read from the connection held the connection lock. That's not the way to do it on Unix. However do you really need to use multiple concurrent threads with the same SSL object? Think of it as a TCP socket, each thread has a list of open sockets, or SSL objects, there is no need to share it with other threads. Actually, it's pretty common to do that with TCP connections. You may have one thread that's blocked trying to read from the connection all the time while another thread tries write to the connection as it discovers data that needs to be sent. You can't do this with OpenSSL. (At least, not precisely the same way.) It's a bad way of doing network programming. A server can potentialy have 1000s of open sockets, if you have two threads for each sockets, (one for reading, one for writing), pretty soon you'll run out of memory. Scheduling all those threads will have a negative impact on performance. The usual way to handle concurrent connections is to set sockets non-blocking and use event notification - poll, epoll, kqueue, ports, etc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Binding outgoing SSL connection to certain IP address
On Sun, 18 Apr 2010 23:35:16 +0200 (CEST)
Ondrej Jombik jom...@platon.org wrote:
[ Please Cc me in the answer as I'm not in the list. Thank you. ]
I was googlig for over two days and now I'm stuck. The thing I would
like to accomplish is to bind outgoing SSL connection to certain IP
address.
Our server has several IP addresses, but remote machine will accept
connections only from certain address, which I need to bind client to.
What I have learned I need to create my own filedescriptor (socket)
which will be binded to desired local IP address and connected to
desired remote host.
But how to join this FD with BIO? I know there is BIO_set_fd(), but
this is simply not working well for me. It does nothing. Do someone
have some working snippet of code with this? I would much appreciate
it.
From your description I don't understand if you're trying to bind a
particular IP address on client or server side.
Anyway, you need to use bind(2) system call AND set your IP address.
Then you can call SSL_set_fd() to set connected socket, this should
automatically create the needed BIO for SSL object. Below is a server
code example, which accepts connections only on IP address 192.168.1.1
#define SERV_ADDR 192.168.1.1
#define SERV_PORT 8000
int listenfd, connfd;
socklen_t clilen;
struct sockaddr_in cliaddr, servaddr;
/* Create IPv4 socket */
if((listenfd = socket(AF_INET, SOCK_STREAM, 0)) 0)
{
perror(socket() error);
exit(1);
}
memset(servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
inet_pton(AF_INET, SERV_ADDR, servaddr.sin_addr);
servaddr.sin_port = htons(SERV_PORT);
if(bind(listenfd, (struct sockaddr *)servaddr, sizeof (servaddr)) 0)
{
perror(bind() error);
exit(1);
}
if(listen(listenfd, BACKLOG) 0)
{
perror(listen() error);
exit(1);
}
/* Accept client connections */
clilen = sizeof(cliaddr);
if((connfd = accept(listenfd, (struct sockaddr *)cliaddr,
clilen)) 0 )
{
perror(accept() error);
exit(1);
}
...
/* Handle SSL connections */
if((ssl = SSL_new(ssl_ctx)) == NULL)
{
printf(SSL_new() error\n);
exit(1);
}
if(SSL_set_fd(ssl, connfd) != 1)
{
printf(SSL_set_fd() error\n);
exit(1);
}
if(SSL_accept(ssl) != 1)
{
printf(SSL_accept() error\n);
ERR_error_string_n(ERR_get_error(), buf, 2048);
printf(%s\n, buf);
exit(1);
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Binding outgoing SSL connection to certain IP address
On Mon, 19 Apr 2010 11:58:51 +0200 (CEST) Ondrej Jombik jom...@platon.org wrote: I do need this for client side. Machine where connection is originating has several IP addresses and the remote machine will accept connection only from one of those. So I need to choose exactly one source IP address when creating connection. Can your example be modified for this? The code for the client side is very similar. So you set IP address and port number and then call bind() to associate source IP address with the socket, otherwise OS kernel will choose IP address for you. To connect to the server you call connect(). Once you have a connected socket, you creae SSL object, call SSL_set_fd() to associate connected socket with SSL object and then call SSL_connect() to initiate SSL handshake. I think this should work, just give it a try. Also I noticed that in your example there is no BIO used at all. Now I'm even more confused, since I thought that BIO is something like must-have when dealing with SSL connections. If I ever properly create socket with desired properties, ie. correct originating source address and correct destination address and port, should I pass this socket to SSL with SSL_set_fd() or to BIO with BIO_set_fd() ? I think there are different ways of associating file descriptors with SSL objects. Calling SSL_set_fd() and passing it connected socket should automatically associate that socket with SSL object and create the necessary BIO. Have a look at the man page for SSL_set_fd if in doubt. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multi Threaded questions
On Mon, 19 Apr 2010 11:09:33 -0700 Jeremy Farrell jfarr...@pillardata.com wrote: That's the usual way to handle significant numbers of connections. For many programs handling a small number of connections, two threads per connection is the normal approach. It's simpler, and much easier to port between OSes. Horses for courses. I think that depends on simplicity (or complexity) of your application and how much shared data you have. Having two I/O threads (one for reading, one for writing) for each socket, means you need to use locking and condition variables to signal the start/completion of I/O. Making sure that you test the right predicates in a proper way, and avoid race conditions, can be quite tricky. A simple call to poll() might be much easier. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multi Threaded questions
Please note, I don't know the insides of OpenSSL, but I do a lot of
multithreaded programming on Unix, so the following are not authorative
answers, just my own opinions:
1) According to the FAQ, an SSL connection may not concurrently be
used by multiple threads. Does this mean that an SSL connection can
be used by different threads provided access is limited to one at a
time?
I assume that having a mutex for each SSL object would prevent it from
being concurrently used by multiple threads. So this should be OK.
However do you really need to use multiple concurrent threads with the
same SSL object? Think of it as a TCP socket, each thread has a list of
open sockets, or SSL objects, there is no need to share it with other
threads.
2) We've implemented the required locking and thread_id callbacks and
we're getting into a deadlock. OpenSSL is aquiring a lock and not
releasing it. Have there been any bug fixes to the static locking
since 0.9.7d? We've looked at the change log and nothing is jumping
out at us.
You don't say which platform this is, or which threading library is
being used. My guess is, this is more likely to be a problem with your
implementation, rather than OpenSSL bug.
3) Our application opens multiple SSL connections. We call
SSL_library_init() only once. However, we're calling
CRYPTO_set_locking_callback and CRYPTO_set_id_callback for each
connection, but always with the same function pointers. Is this
correct?
I don't think this is correct. The whole point of locking callbacks
is to provide mutual exclusion for critical sections. You need to
initialise static/dynamic threading callbacks before you call
SSL_library_init(). If you're in the middle of using the library and
locking callbacks are not set, this can result in race conditions.
I've attached a fragment from some of my code. It shows how to
initialise static and dynamic locking callbacks on Unix, using
Pthreads API. You can probably adapt it to your platform/programming
language.
/* Static locks */
static pthread_mutex_t *stlocks;
int stlocks_len;
/* Dynamic locks */
struct CRYPTO_dynlock_value
{
pthread_mutex_t mutex;
};
/* Static locking functions
--*/
static unsigned long id_callback(void)
{
return (unsigned long)errno;
}
static void locking_callback(int mode, int n, const char *file, int line)
{
if(mode CRYPTO_LOCK)
pthread_mutex_lock(stlocks[n]);
else
pthread_mutex_unlock(stlocks[n]);
}
static void init_openssl_stlocks(void)
{
int i;
stlocks_len = CRYPTO_num_locks();
if((stlocks = malloc(sizeof(pthread_mutex_t) * stlocks_len)) == NULL)
{
printf(malloc() error\n);
exit(1);
}
for(i = 0; i stlocks_len; i++)
{
pthread_mutex_init(stlocks[i], NULL);
}
CRYPTO_set_id_callback(id_callback);
CRYPTO_set_locking_callback(locking_callback);
}
/**/
/* Dynamic locking functions
--*/
static struct CRYPTO_dynlock_value *dynlock_create_callback(
const char *file, int line)
{
struct CRYPTO_dynlock_value *lock;
if((lock = malloc(sizeof(struct CRYPTO_dynlock_value))) == NULL)
{
printf(malloc() error\n);
exit(1);
}
pthread_mutex_init(lock-mutex, NULL);
return lock;
}
static void dynlock_destroy_callback(
struct CRYPTO_dynlock_value *lock, const char *file, int line)
{
pthread_mutex_destroy(lock-mutex);
free(lock);
}
static void dynlock_lock_callback(
int mode, struct CRYPTO_dynlock_value *lock, const char *file, int line)
{
if(mode CRYPTO_LOCK)
pthread_mutex_lock(lock-mutex);
else
pthread_mutex_unlock(lock-mutex);
}
static void init_openssl_dynlocks(void)
{
CRYPTO_set_dynlock_create_callback(dynlock_create_callback);
CRYPTO_set_dynlock_destroy_callback(dynlock_destroy_callback);
CRYPTO_set_dynlock_lock_callback(dynlock_lock_callback);
}
/**/
int main(void)
{
init_openssl_stlocks();
init_openssl_dynlocks();
SSL_library_init();
SSL_load_error_strings();
...
}
Re: Problems with DSA 2048-bit keys
On Sun, 11 Apr 2010 23:29:27 -0400 Dave Thompson dave.thomp...@princetonpayments.com wrote: Aside: do you really need this? FIPS 186-3 extended DSA to 2k and 3k, but SP 800-57 no longer approves classic DSA for USgovt use at all, even in the new sizes, it switches to ECDSA instead. I probably don't need DSA, I was testing different algorithms and key sizes for client/server interoperability reasons. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problems with DSA 2048-bit keys
I'm testing a very simple SSL web server. Everything seems to work OK
with RSA and DSA 1024-bit keys.
I tried using DSA 2048-bit key and now I'm getting errors:
# Generate DSA parameters
openssl dsaparam -out dsa_param.pem -outform PEM 2048
# Generate a certificate request
openssl req -newkey dsa:dsa_param.pem \
-keyout netcorp_privkey_dsa.pem -keyform PEM \
-out netcorp_req.pem -outform PEM
# Issue a certificate from a certificate request
openssl ca -in netcorp_req.pem
On the server side I set up a callback function for DH parameters:
DH *tmp_dh_callback(SSL *ssl, int is_export, int keylength)
{
printf(keylength = %d\n, keylength);
if(dh1024 == NULL || dh2048 == NULL)
init_dhparams();
switch(keylength)
{
case 1024:
return dh1024;
break;
case 2048:
return dh2048;
break;
default:
return dh1024;
}
}
Then when I use Firefox to connect to the server I get:
Thread starting
keylength = 1024
SSL_accept() error
error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
Any ideas why I'm getting decrypt error with OpenSSL? Is this related
to the fact that the tmp_dh_callback() is passed 1024-bit key length,
even though the certificate was set up with a 2048-bit key? Why does
this happen?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Problems with DSA 2048-bit keys
On Sat, 10 Apr 2010 15:55:38 +0100 Sad Clouds cryintotheblue...@googlemail.com wrote: I'm testing a very simple SSL web server. Everything seems to work OK with RSA and DSA 1024-bit keys. I tried using DSA 2048-bit key and now I'm getting errors: Maybe it's just the Firefox issue, trying 'openssl s_clien ...' results in a negotiated SSL connection: New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE ... GET / HTTP/1.1 HTTP/1.1 200 OK Content-type: text/plain Content-length: 25 Sat Apr 10 16:24:27 2010 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problems with DSA 2048-bit keys
On Sat, 10 Apr 2010 15:55:38 +0100 Sad Clouds cryintotheblue...@googlemail.com wrote: On the server side I set up a callback function for DH parameters: Could someone explain to me the relationship between DH parameters and DSA key lengths? For example, with larger keys, do I need to load larger DH parameters? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Server name indication
Hi, is there any sort of documentation on how to use SNI with OpenSSL? For example, what functions to use and what steps to take. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Server name indication
On Fri, 09 Apr 2010 16:50:48 +0200 Peter Sylvester peter.sylves...@edelweb.fr wrote: Sad Clouds wrote: Hi, is there any sort of documentation on how to use SNI with OpenSSL? As far as I know, only the source in s_client and s_server.c OK thanks. I'll have a look at the source code of those and see if I can figure it out. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Cipher suits
Greetings, I'm trying to develop a simple SSL module for a web server. I don't have much experience with cryptography and OpenSSL, so I am bit confused about various combinations of cipher suits when performing key exchange and authentication. 1. I assume RSA key exchange and authentication is the most widely used combination. I am I correct to assume that ephemeral RSA and Server Gated Cryptography are not deployed anymore, due to relaxation of the US export regulations? And nobody is using 512-bit keys. 2. If Diffie-Hellman key agreement and DSS authentication is used, ephemeral DH keys must be used. Do I need to do anything special in this case (i.e. loading parameters) or can OpenSSL handle all of this automatically? 3. What about Diffie-Hellman key agreement and RSA authentication. Is this normally handled with ephemeral keys? Is there any advantage of Diffie-Hellman over RSA key exchange? 4. Does anyone actually deploy Diffie-Hellman key agreement and DSS authentication these days? I would think that the majority people would use RSA (better performance). Is DSS simply for old software compatibility?? Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL algorithms vs. all algorithms...
On Tue, 6 Apr 2010 21:17:01 +0200 Dr. Stephen Henson st...@openssl.org wrote: Well that actual manual page is rather old and it still talks about PRNG initialisation which dates from the time OpenSSL didn't handle that automatically on many platforms. So are you saying there is no need to seed PRNG? Is there a way to check on a given platform if OpenSSL initialised PRNG? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Thread locking functions
On Mon, 15 Feb 2010 11:39:51 -0500 Lee Linkoff llink...@unitecelectronics.com wrote: Can someone please give me some links to some basic tutorials on locking callbacks. I tried different searches on Google, but no links to basic tutorials came up. I tried different search criteria. To date, I have never used them on the job and don't recall learning or hearing about them in school. Thanks. Regards, Lee Not sure about links on the Internet, but 'man openssl_threads' should give you a manual page that lists all functions used for setting up locking callbacks. Also, O'Reilly Network Security with OpenSSL has a chapter on setting up locking callbacks. Maybe try Google books and you might be able to view that chapter. Unfortunately, nobody has answered the first part of my question on this list, so I'm just as confused as you are about the best way to use OpenSSL with threads. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Thread locking functions
Hi, I've recently started looking at OpenSSL programming API and I'm a bit confused about thread locking funtions: 1. Static VS Dynamic locking callbacks Why have both? Does OpenSSL use dynamic callbacks? Can I omit static callbacks and only use dynamic, or maybe static callbacks are mandatory when using threads? How does OpenSSL choose a maximum number returned by CRYPTO_num_locks()? Does this number limit overall concurrency in OpenSSL? Is there a way to increase it in case I have to work with a large number of threads? 2. Rationale for callbacks? Pushing some of the responsibility for locking OpenSSL internal structures to application developers seems a bit lame. Why not get rid of locking callbacks and have OpenSSL handle it transparently inside the library? This promotes the idea of abstract data types and encapsulation and avoids the whole mess of static/dynamic callbacks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Thread locking functions
On Mon, 15 Feb 2010 15:19:23 +0100 Steffen DETTMER steffen.dett...@ingenico.com wrote: * Sad Clouds wrote on Mon, Feb 15, 2010 at 13:18 +: 2. Rationale for callbacks? Pushing some of the responsibility for locking OpenSSL internal structures to application developers seems a bit lame. Why not get rid of locking callbacks and have OpenSSL handle it transparently inside the library? This promotes the idea of abstract data types and encapsulation and avoids the whole mess of static/dynamic callbacks. (I'm just guessing - please correct me where I'm wrong). Delegating functionality via callbacks allows arbitrary implementations; I would not consider this lame - but clean, strong, orthogonal, KISS and divide-and-conquer :) Neither ANSI-C nor ISO-C tell anything about multi-threading or mutex locking, so handling that transparently inside the library would introduce additional dependencies (e.g. to POSIX threads) and thus would not be portable. I think pretty much every Unix platform standardised on Posix threads by now. Using locking implies that you're using threads, and that is Pthreads API on Unix. Non Unix platforms should be dealt with on individual basis, using whatever native threading/locking primitives they provide. I still think it's library's responsibility to pick the most efficient locking primitives for a given platform and use them transparently, without exposing the semantics to the application code. What happens if your application is linked to other libraries which use OpenSSL and try to set their own locking callbacks? I have a feeling the locking callbacks mechanism is the leftover from the 90s era. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
