SSLSocket to support NIO - feature request voting
Hello All,
I know there were many discussions here regarding this subject.
I've seen the SSLEngine solution for the problem... But I didn't like it since it is too complicated.
For my understanding SSLSocket inherits Socket so an application that can handle Sockets should be able to handle SSLSocket without writing a specific code besides the factory.
NIO allows Socket to be none blocking... So why SSLSocket which is a Socket does not?
If I write a Web server in Java, why should I deal with none SSL and SSL connections in a different way?
I recently wrote one threaded NIO server and was amazed that I could not use SSL with the same implementation.
I've opened a feature request for Java, but they told me to gain support for this subject here before they will consider it...
As I understand I can re-implement SSLSocket to use SSLEngine and support NIO with blocking and none blocking support... But I think Sun should do it.
One caveat is to make sure that the SSLSocket HandshakeCompletedListener should be called by a daemon thread, so that it will not block other sockets while certificate verification occur.
Of course when I refer to SSLSocket I also refer to SSLServerSocket.
Can you please comment regarding this issue... Every comment will be welcomed!
Best Regards,
Alon Bar-Lev
[1384 byte] By [
alonbla] at [2007-10-1 17:08:36]
nah, I am very glad they released an engine separate from transport allowing encryption on any transport.
I am also working on an abstraction of nio that you may be interested in if you don't want to do the security yourself......it is here...
http://sourceforge.net/projects/channelmanager
Right now, it only contains the api, but there are 3 implementations behind it right now with 3 to be added.
1. Basic implementation that does just nio
2. Secure implementation that implements same api and uses implementation 1
3. Packettizer implementation which puts things in payloads with headers and footers
4. (to be added) Threadpool implementation allowing a threadpool to be inserted in the stack somewhere
5. (to be added) TestProxy implementation allowing exxceptions to be thrown on purpopse to test a system on a bad network....can test failure on bind, connect, read, write, etc....everything.
6. denial of service layer.
7. Exception catch layer to protect #1 and #4 mainly from bad clients that throw exceptions back to the channelmanager.
Each one of these layers (2 - 4) implements the same api and uses the same api so 2 -4 are all proxies. You can reorganize the proxies as you want.
The secure one is almost done. Any comments on the api will be welcome.
thanks,
dean
one last comment...what doesn't exist in sun's jdk alot of times exist and open source and probably should for a while because some of these problems are very complex and really should be coded up a few times and refactored, etc, etc before adding to sun's api. I think this is one of those beasts that maybe eventually should be in the sun api, but I am not so sure it should be put in now.
dean
After doing my own abstraction, I don't think they could support SSLSocketChannel. There would be a major flaw in the design. It turns out a close has to be done asynchronously as there is a handshake that goes on, and you are not closed immediately when calling close. In fact, you have to call close resulting in a message being sent to peer, and which time the purpose of nio was not to block, so that close that was called should return to be in the spirit of non-blocking...then a message comes back and the engine closes and the socket can finally close....it is a real pain as I see it so far and I am not sure what I am going to do in my abstraction yet.....you are free to use mine though which has TCPChannel interface and a TCPSecureChannelImpl and TCPChannelImpl also both implementing same api. It is easy to switch between both.
dean
This is not so, see your other thread. If you initiate the close, RFC 2246 permits you not to wait for the close_notify reply after calling closeOutbound(). If you received the close rather than initiating it, you have already received the close_notify, so in either case there is no necessity to block in close().
ejpa at 2007-7-11 1:47:41 >
SWEEEET....thanks for the info!
one side question to that. Is it necessary for me to closeInBound and closeOutBound then? Can I just closeOutBound, wrap and be done or does SSLEngine need me to call closeInBound which results in an exception every time if i haven't given it the handshake response.
ps. thanks for all your great replies ejp. I don't know who you are but they are much appreciated!!!!!!!!!!!!!!!!!!!!!!11
If you receive the close_notify and unwrap it, SSLEngine will internally call closeInbound. If you receive EOF you should call closeInbound and the SSLEngine will then throw an SSLException indicating a truncation attack. It could be either the client or the server that receives the close_notify or the EOF.
If you don't receive either of these you will get to a point where you want to close the socket. This is done by calling closeOutbound(). Whether you then read until one of the above things happens is up to you, the RFC doesn't require it.
For discussion see http://www.ietf.org/rfc/rfc2246.txt or Eric Rescorla's TLS/SSL book or my upcoming Fundamental Networking in Java book.
ejpa at 2007-7-11 1:47:41 >
May be it can help you, I released a small class that allow mixing NIOand SSL. This class upgrades an insecure channel to a secure one; very simple to use. I'm using it for a HTTP/HTTPS proxy server I'm working
dcra at 2007-7-11 1:47:41 >
don't know if you are interested, but all code for the channelmanager has been released(with and without threadpooling, with and without security). It also has a wrapper around SSLEngine which is much easier to use for any reliable transport. The SSLEngine is called AsynchSSLEngine, you add a listener and just feed it bytes, and it fires back to the listener giving you unecrypted bytes, encrypted bytes and you feed them up or down. It is really much simpler than SSLEngine.
http://sourceforge.net/projects/channelmanager
oh, and this is company supported now as I will be using it and fixing bugs for the current company I work at!!! It also hides many i/o bugs I ran into(around 6 bugs I ran into that were accepted by sun's bug report system.)
