Re: openssl s_client -dtls1 and ECC key
Hi Erwin, Thanks for the report. I found the bug and submitted a patch (#2628). You can also download it from our website at http://sctp.fh-muenster.de/dtls-patches.html and it would be very helpful if you can confirm that the patch fixes your issue. Robin On Oct 12, 2011, at 11:33 PM, Erwin Himawan wrote: Hi, Does anybody know whether openssl s_client and s_server support the use of -dtls1 option while the server uses ECC key? The issuing CA and root CA use ECC keypair. These are my openssl s_server and s_client options: openssl s_server -accept 12000 -cert server.pem -certform pem -key server_key.pem -keyform pem -CApath . -CAfile CAECCRoot.pem -dtls1 -cipher ALL -debug -msg -state openssl s_client -connect:10.8.122.106:12000 -CApath . -CAfile CAECCRoot.pem -dtls1 -cipher ALL -debug -msg -state When I attempted to do this, the s_client gives error: SSL3 alert write:fatal:decrypt error SSL_connect:error in SSLv3 read server key exchange B 5551756:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1610 further down, I notice that the Verify return code: 0 (ok). I also use openssl verify to verify the server certificate using the issuing CA and root CA. The result agrees with the result shown by the s_client debug message. On the second note, I also try the s_server with RSA keypair, issued by the same issuing CA; the server certificate has RSA public key with signature algorithm is ecdsa-with-SHA256. In this scenario, the s_client was able to establish tls connection with the s-server. Does this mean that the openssl s_client and s_server does not support ECC keypair? Any pointer or idea how further troubleshoot this? Thanks, Erwin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Access SSL connection in multiple threads
Hi Flo, On Sep 28, 2011, at 5:37 PM, Flo Wohlfart wrote: Is it safe to call SSL_write() in thread B, while thread A is blocking at DTLSv1_listen() for the same SSL connection? Here comes an example for better understanding: THREAD A: ... while (DTLSv1_listen(ssl, client_addr) = 0); pthread_mutex_lock(mutex); /* handle connection */ pthread_mutex_unlock(mutex); ... THREAD B: ... pthread_mutex_lock(mutex); SSL_write(ssl, buffer, len); pthread_mutex_unlock(mutex); ... This will not work, because the SSL object used for DTLSv1_listen() is not connected to any client. There is nothing SSL_write() could send to. DTLSv1_listen() will hold the SSL object until it is connected. Then you can use it with as many threads as you like, as long as you handle locking issues. Best regards Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to derive EAP-TLS key material from TLS?
Hi Neo, On Jun 1, 2011, at 4:02 AM, Neo Liu wrote: On Tue, May 31, 2011 at 6:41 PM, Michael Tüxen michael.tue...@lurchi.franken.de wrote: What about using SSL_tls1_key_extractor()? I didn't this function in OpenSSL source. I can get master secret from SSL_SESSION-master_key, but how can I find the PRF api used to calculate: RPF(master_secret, client EAP encryption, client_random || server_random) as Michael stated, the function SSL_tls1_key_exporter() is exactly what you're looking for. The TLS Key Exporter is described in RFC 5705. The patch #1830, which Michael also mentioned, is available for the current OpenSSL 1.0.0 release on http://sctp.fh-muenster.de/dtls-patches.html and already included in the development version of OpenSSL 1.0.1 in the CVS, which can be checked out with: cvs -d anonym...@cvs.openssl.org:/openssl-cvs co -rOpenSSL_1_0_1-stable openssl Best regards Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS new testing ways
Hi Sebastian, On Jan 24, 2011, at 2:27 PM, Sebastian Proca wrote: I'm using Ubuntu 10.04 with 2.6.32-27 kernel. So, I've been following your advice and put wireshark to check the packages on the lo wire. Besides the Destination unreachable(Host unreachable) message that I receive I can see the flow from Source port 40673 to Destination port 23232 both on 127.0.0.1, of course. Is this (at least) flow's correct behaviour? Besides this messages I don't get anything else. Destination unreachable tells you that you're not running a server or it's blocked by a firewall. Have you updated your OpenSSL installation? Ubuntu 10.04 comes with an old 0.9.8 release in which the DTLS implementation is entirely broken. You need to update OpenSSL to at least 1.0.0a. Make sure that you either overwrite your base installation or use appropriate paths when compiling. A ./configure make make install installs to /usr/local which is ignored because you already have an installation in /usr by default. So either configure OpenSSL with --prefix=/usr to overwrite your default installation or compile your client and server with -L and -I to the lib and include paths where you installed the newer OpenSSL, e.g. -L/usr/local/lib -I/usr/local/include. Best regards Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS new testing ways
Hi Sebastian, On Jan 19, 2011, at 11:50 AM, Sebastian Proca wrote: Thank you for your help! I understand now the way that this application should be used. Yet, I didn't manage to obtain a working dtls session. After I start the server : # ./dtls_udp_echo I start the client, but I receive the error bellow: # ./dtls_udp_echo 127.0.0.1 Unexpected error while writing: 1 error:14103138:SSL routines:DTLS1_READ_FAILED:read timeout expired, but the started server shows no error, nothing. So the message that both server and client have is Resource temporarily unavailable. Did someone have the same problem? How can this be solved? Which operating system are you using? Do you have a firewall active? Make sure nothing is blocking either server or client. If its still not working, use Wireshark or tcpdump to check what's happening on the wire. Best regards Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS new testing ways
Hi Sebastian, On Jan 17, 2011, at 4:12 PM, Sebastian Proca wrote: It's strange for me how comes that, depending on the specified arguments, I get two different errors: I case : # ./dtls_udp_echo 127.0.0.1 SSL_connect: Connection refused error::lib(0):func(0):reason(0) Unexpected error while writing: 5 error::lib(0):func(0):reason(0) II case : # ./dtls_udp_echo -p 23232 -V 127.0.0.1 SSL_connect: Connection refused error::lib(0):func(0):reason(0) Connected to 127.0.0.1 Segmentation fault Wireshark shows the beginning of dtls negotiation, but it's clear that after these errors, it stops. Does someone know the correct usage of this sample? I'm out of ideas! You probably don't have a server running. Use: ./dtls_udp_echo without any parameters to start a server listening on all available addresses. You can then start a client with: ./dtls_udp_echo 127.0.0.1 All of the examples listed on our website are both server and client. If you specify an address on the command line, it will use it to start a client which connects to it. Otherwise, without an address it will start a server and listen for incoming connections. Best regards Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLSv1 SSL_renegotiate
Hi David, Which version of OpenSSL are you using? The current 0.9.8 stable is *very* buggy and also in 1.0.0 beta 3 are still several known bugs. You should either use the development version in the CVS repository or apply our patches from sctp.fh-muenster.de to have them fixed. You can also find some DTLS example code there. If you still experience any problems, please supply a detailed description so that I can try to reproduce it. Regards, Robin On Nov 2, 2009, at 6:46 AM, David Isaac Wolinsky wrote: Hi all, I am implementing a project that uses OpenSSL DTLSv1. I noticed that even after sending approximately 1 GB of data, the cipher spec did not change. So I implemented a manual renegotiate and I attempted to verify that it worked. It didn't. For some reason, after the server receives the renegotiate message from the client, it gets stuck at SSLv3 read client hello B. I then tried the exact same code but switched the SSL_method to SSLv3 and TLSv1 and it worked just fine. The peers renegotiated a new cipher spec. Any thoughts? Regards, David __ 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
Re: Memory leak in threaded server
I was able to solve the problem, the session cache was activated and
stored all the sessions and a bug in DTLS caused that twice as much
sessions as necessary have been created. The bug will be fixed with an
updated version of bugfix #2028.
- Robin
Am 02.09.2009 um 10:47 schrieb Robin Seggelmann:
Hi all,
I have written an DTLS echo server and client for testing purposes.
In this case I want to test my new DTLSv1_listen() function, which
waits for new connections with responding to ClientHellos with
HelloVerifyRequest messages until a ClientHello with a valid cookie
arrives. The SSL object can then be used for that connection and
DTLSv1_listen() is called with a new SSL object again. Unfortunately
the server has a memory leak which I was unable to find yet.
According to my debug tools the problem seems to be that some
certificates aren't freed. However, there are no leaks in terms of
memory that is not accessible anymore. Here is the scheme of my
server:
void start_server(int port, in_addr_t* local_address) {
... (variables) ...
THREAD_setup();
OpenSSL_add_ssl_algorithms();
SSL_load_error_strings();
ctx = SSL_CTX_new(DTLSv1_server_method());
SSL_CTX_set_cipher_list(ctx, ALL:NULL:eNULL:aNULL);
pid = getpid();
if( !SSL_CTX_set_session_id_context(ctx, (void*)pid, sizeof pid) )
perror(SSL_CTX_set_session_id_context);
if (!SSL_CTX_use_certificate_file(ctx, certs/server-cert.pem,
SSL_FILETYPE_PEM))
printf(\nERROR: no certificate found!);
if (!SSL_CTX_use_PrivateKey_file(ctx, certs/server-key.pem,
SSL_FILETYPE_PEM))
printf(\nERROR: no private key found!);
if (!SSL_CTX_check_private_key (ctx))
printf(\nERROR: invalid private key!);
/* Client has to authenticate */
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE,
dtls_verify_callback);
SSL_CTX_set_read_ahead(ctx, 1);
SSL_CTX_set_cookie_generate_cb(ctx, generate_cookie);
SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);
... (create listening socket) ...
while (1) {
memset(client_addr, 0, sizeof(struct sockaddr));
/* Create BIO */
bio = BIO_new_dgram(fd, BIO_NOCLOSE);
/* Set and activate timeouts */
timeout.tv_sec = 5;
timeout.tv_usec = 0;
BIO_ctrl(bio, BIO_CTRL_DGRAM_SET_RECV_TIMEOUT, 0, timeout);
ssl = SSL_new(ctx);
SSL_set_bio(ssl, bio, bio);
SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);
while (!DTLSv1_listen(ssl, client_addr));
info = (struct pass_info*) malloc (sizeof(struct pass_info));
memcpy(info-server_addr, server_addr, sizeof(struct
sockaddr));
memcpy(info-client_addr, client_addr, sizeof(struct
sockaddr));
info-ssl = ssl;
if (pthread_create( tid, NULL, connection_handle, info) != 0) {
perror(pthread_create);
exit(1);
}
ERR_remove_state(0);
}
THREAD_cleanup();
}
The function connection_handle is called when DTLSv1_listen()
returned and therefore a new connection is about to be established.
The SSL object is passed and the handshake finished before data
transmission begins.
void* connection_handle(void *info) {
... (variables) ...
pthread_detach(pthread_self());
... (created connected socket) ...
/* Set new fd and set BIO to connected */
BIO_set_fd(SSL_get_rbio(ssl), fd, BIO_NOCLOSE);
BIO_ctrl(SSL_get_rbio(ssl), BIO_CTRL_DGRAM_SET_CONNECTED, 0,
client_addr);
/* Finish handshake */
if(SSL_accept(ssl) = 0) {
perror(SSL_accept);
goto cleanup;
}
... (read and write until client disconnects) ...
SSL_shutdown(ssl);
cleanup:
close(fd);
free(info);
SSL_free(ssl);
ERR_remove_state(0);
pthread_exit( (void *) NULL );
}
Any suggestions where I forgot any free or threading function? I
also read about a built-in memory leak detection in OpenSSL but
didn't find anything in the documentation. Since it might help, how
do I use that? When I use a shell script which continously starts a
client which connects, sends some messages and disconnects, the
server is working fine but constantly allocats memory which is never
freed. Since the client initiates the shutdown, there is no problem
with an unfinished shutdown process. The server's SSL_shutdown()
always returns 1.
Regards,
Robin
__
OpenSSL Project http://www.openssl.org
User
Re: DTLS communication problem
On Feb 3, 2009, at 11:27 PM, Russell, Joshua wrote: I am trying to get a sample DTLS application working. The following indications are provided when I try to connect with the client: After a successful call to dtls_connect(), I receive SSL_ERR_SYSCALL when attempting to write from the client. ERR_get_error() results in 0. rc from SSL_write = -1 errno shows “No route to host” I checked netstat on the server to confirm that a UDP port is bound at 8001 The return from netstat shows nothing at 8001. Before I start looking closer at my server, I would like to make sure a properly configured SSL server should show a UDP connection on the selected port. The error could be everywhere since you have not submitted any code or said which sample you're using. I suggest to visit http://sctp.fh-muenster.de and have a look at the samples there. They should be easy to understand and are working out of the box. To avoid several bugs, you have to use the latest OpenSSL version with the bugfixes also listed there anyway. Thanks. Josh Russell CSX Technology 904-633-3493 RNX 633-3493 This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
On Jan 26, 2009, at 5:24 PM, Daniel Mentz wrote:
I'm surprised that you can use accept() on UDP sockets. I checked
the man pages of a Debian GNU/Linux system. They say that you can
use accept() only with connection-based socket types (SOCK_STREAM,
SOCK_SEQPACKET). Is this something specific to FreeBSD? Could you
please provide me with more information. Maybe you could make your
source code available.
Hi Daniel,
sorry for causing confusion, of course you can't use accept() with
UDP. You have to create a new socket, use bind() to assign it to a
specific connection and create another socket. Everything else is like
handling TCP connections. Unfortunately it was too long ago that I
have written the code so I hadn't had all of it in mind anymore.
Probably you can use connected UDP sockets with Linux, but I'm not
sure. I'm working with FreeBSD and Mac OS X which support them.
Sample UDP server code:
while (1) {
memset((void *) client_addr, 0, sizeof(client_addr));
accfd = (int*) malloc (sizeof(int));
*accfd = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt (*accfd, SOL_SOCKET, SO_REUSEADDR, optval, sizeof(optval));
bind(*accfd, (const struct sockaddr *) server_addr,
sizeof(server_addr));
bio = BIO_new_dgram(*accfd, BIO_NOCLOSE);
ssl = SSL_new(ctx);
SSL_set_bio(ssl, bio, bio);
SSL_accept(ssl);
info = (struct pass_info*) malloc (sizeof(struct pass_info));
info-fd = *accfd;
info-client_addr = client_addr;
info-ssl = ssl;
rc = pthread_create( tid, NULL, connection_handle, info);
if (rc != 0) {
perror(pthread_create);
exit(1);
}
}
Regards,
Robin
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
On Jan 22, 2009, at 5:11 PM, Wes Hardaker wrote: RS As a workaround you can use connected UDP sockets. Just use accept() RS and connect() as you would with TCP connections and create new BIO and RS SSL objects for every connection. I have tested that and it works RS pretty well so far. And that keeps OpenSSL from reading too much data from a single socket? If so, that'd certainly be a good thing. If you meant keeps reading data from more than one connection, then yes. With connected UDP sockets the kernel handles the differentiation between connections and distributes incoming data to the corresponding sockets. Regards, Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to detect dead peers with DTLS?
Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: I think I will go for the hack that misuses re-negotiation as a kind of heartbeat, keep alive or echo request. I tried to avoid this hack at first because it is a computational burden. AFAIK re-negotiation means restarting from scratch which means that expensive public key operations have to be performed. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ OpenSSL Project http:// www.openssl.org User Support Mailing Listopenssl- us...@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
Re: How to detect dead peers with DTLS?
Hi Michael, since there seems to be no function, option or whatever to trigger session resumption for an established connection, I would have to modify the API to add this functionality. This is kind of critical because it would not only affect DTLS but also TLS which supports session resumption, too. In my opinion neither a DTLS specific method nor an untested generic method is a good solution. Regards, Robin Am 20.01.2009 um 19:42 schrieb Michael Tüxen: Hi Robin, what would be needed to add support for renegotiations in DTLS? Best regards Michael On Jan 20, 2009, at 7:01 PM, Robin Seggelmann wrote: Hi Michael, unfortunately, you're wrong. You need my patches to perform renegotiations at all, since the current implementation is broken in this respect. Technically, the abbreviated handshake is supported, but OpenSSL does not provide any API to initiate it without reconnecting. The functions for session handling can be used to save a session and reassign it before connecting to perform an abbreviated handshake. This has no effect on an established connections because your saving and overwriting the session with the same data without any further action. I already criticized this in a mail to the list but there were no answers beside the explanation how to use the session functions when reconnecting. Regards, Robin Am 20.01.2009 um 18:38 schrieb Michael Tüxen: Hi Giang, I think Robin tested it, so yes it works... But you need the bugfixes he sent to the list... Robin: Am I right? Best regards Michael On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote: I think I will go for the hack that misuses re-negotiation as a kind of heartbeat, keep alive or echo request. I tried to avoid this hack at first because it is a computational burden. AFAIK re-negotiation means restarting from scratch which means that expensive public key operations have to be performed. to avoid expensive full handshakes, what about using sessions? from what i read at http://tools.ietf.org/html/rfc4347#section-3, To the greatest extent possible, DTLS is identical to TLS. and from what i read at http://tools.ietf.org/html/rfc5238 section 3.4: multiple DTLS connections can be resumed from the same DTLS session, each running over its own DCCP connection. so my assumption here is that DTLS supports abbreviated handshakes for session resumptions. _ Windows Live™ Hotmail®: Chat. Store. Share. Do more with mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_hm_justgotbetter_explore_012009__ 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
Re: DTLS server implementation experiences and documentation
Hi Wes, The biggest issue comes from needing to deal with multiple clients trying to talk through the same UDP port, which isn't handled by at least the 0.9.8i code at least. Using multiple connections with one socket is still not implemented as the OpenSSL architecture and API does not support this. To be able to choose which connection within a socket you want to send to or receive from, major changes would be necessary, starting from SSL_read, SSL_write, etc. and ending with the relation between BIO and SSL objects. As a workaround you can use connected UDP sockets. Just use accept() and connect() as you would with TCP connections and create new BIO and SSL objects for every connection. I have tested that and it works pretty well so far. I'd love feedback on some of my conclusions. I'm not in any way an OpenSSL exert and dove further into the code this time than I have in the past. But I'm not swimming in the deep end yet. The write up is written on the Net-SNMP wiki, since that's what I was working on it for. It's written fairly generically so you don't need to understand SNMP (and people who know SNMP don't need to know a huge amount about OpenSSL). IE, There is a fair amount of introductory text. http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes To avoid getting into trouble with already fixed bugs you should apply the patches I sent to the dev list. I'll set up a website with a patch collection and some instructions soon. Regards, Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
On Jan 22, 2009, at 7:47 AM, David Woodhouse wrote: Is there anyone who actually cares about DTLS and getting patches applied? Very good question. I hope someone will apply at least the bugfixes soon. I have several patches adding new features in the pipe, but they understandably rely on the bugfixes. However, I'll probably publish a list of patches on a website with an explanation which of them have to be applied in which order for a feature. Not very satisfying, but that seems to be the only solution by now. I've had patches to make OpenSSL capable of talking to production servers out there in the wild, which use the OpenSSL-specific pre-RFC version of DTLS and I've been able to write a complete VPN client along with NetworkManager support, and get it into Linux distributions, in the time it's taken to get the patch into OpenSSL... and I'm still waiting... It's getting to the point where I wonder if it would be quicker and easier just to reimplement DTLS in GNUTLS and use that. Ya, I also thought about that already, but was afraid of starting from scratch yet. Regards, Robin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
