> From: owner-openssl-us...@openssl.org On Behalf Of Sebastián Treu > Sent: Thursday, 03 September, 2009 06:06
> After writing a server in C using select() (a > multiplexed server) and a java client ... > I decided to secure the conection > using openssl. > > I have the examples of the book I've mentioned and with > clients wrote in C the thing goes ok. But, when I try to use > a java client I can't establish a connection. I always fail > on SSL_accept() (using BIO or not it's the same result) with > error code from ERR_get_errors() number 5, with I assume that > is SSL_ERROR_SYSCALL as "openssl/ssl.h" file said so. The > 'ret' parameter es equals to 0. > There is no ERR_get_errors(). (There is only Zul. <G>) SSL_ERROR_SYSCALL is one of the (summary) values returned by SSL_get_error(). The errors returned by ERR_peek/get_error(), and printed by ERR_print_errors() etc., are much more detailed, and consist of bit fields that look like large numeric values. > Can anyone guide/tell me if what I want to do is really > possible? I think so, but I'm not a Java master so I think > the problem is out there, in the java code. I try finding an > openSSL for java, but all I found was outdated packages, as > javassl, and itissl. > It is certainly possible for Java-SSL programs to interoperate with C (or C++) ones using OpenSSL. > Also, java does not support SSLv2 because I got that > exception. So I set SSLv3_server_method() as method. > To be exact, the standard JSSE provider included in Sun distros does not support v2. If you really wanted v2, you could find or create a different provider that does support it, and use that; the Java architecture would allow it. But v3 or TLS is better, and now ubiquitous, so there is no reason to use v2. Yes, if you try to connect standard/SunJSSE client to an SSLv2 server, using a protocol that has SSLv2Hello (which it does by default), the Java client aborts the handshake and the server gets an error -- although I get 6 _ZERO_RETURN not 5 _SYSCALL, but this may depend on the platforms and particularly the TCP stacks. If the client is configured to exclude SSLv2Hello, then the (v3/TLS) hello won't work at all to v2-only server. > I followed a couple of examples out there on the web on how > to connect to an SSL server and all say almost the same as: > > SSLSocketFactory s = (SSLSocketFactory) > SSLSocketFactory.getDefault(); Socket ns = s.createSocket(host, port); > There are other possibilities, but that's a simple and straightforward way. If you use SocketFactory (the base type) you don't need the cast. As you've discovered, for an authenticated ciphersuite (commonly RSA or DH-DSA) the client's truststore must include the root/CA cert used (relied on) by the server's cert, or the server's selfsigned cert (relies on itself); this means using your own truststore if the default one in JRE/lib/security/cacerts doesn't include it. SunJSSE/com.sun.net.whatever supports unauthenticated ciphersuites (ADH) but not by default. OpenSSL also disallows them by default. You must configure the Java side with SSLSocket.setEnabledCipherSuites and the OpenSSL side with SSL_[CTX_]set_cipher_list. And of course without authentication you are open to MITM attacks. (Note that you must downcast the socket to SSLSocket to do this; the Socket's from an SSL factory are in fact SSLSocket's, but are upcast to conform to the generic-over-all-transports architecture.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
