The nascent support for TLS is now enabled by the uncommenting of a line in "PlatformTLSFactories" which means that Stroke will now try and negotiate TLS when connecting to a server that offers it. Note that further changes will be required to allow configuring of client certificate and trust anchors. In performing testing, a couple of problems were found and have been fixed by this patch: - The "hack" field inside JSSEContext, which keeps track of whether the fake "<" character used to provoke an SSL handshake has been sent was mistakenly declared static, which meant that if you tried using TLS on more than one session, things didn't work properly. This has been fixed. - The buffer used for incoming encrypted data for the SSLEngine in JSSEContext is created with a size that matches "the largest SSL/TLS packet that is expected". But it turns out not to be big enough to cope with all the data that the JavaConnection class might provide when calling "handleDataRead()". So the "handleDataFromNetwork" method is changed to break this data into chunks that will fit into the buffer. The same technique is used in "handleDataFromApplication" for cases where the application provides more data than is will fit in a buffer. - All of the "ByteBuffer" values are initialised with a size as recommended by the Sun documentation, although in some cases it appears that these sizes may not be enough (you are cautioned to be able to cope with the buffers overflowing) So all of the ByteBuffers are able to grow, up to a maximum of ten times there initial size, using the "enlargeBuffer()" method. Note that in most cases, I could only provoke buffer overflows in my tests by deliberately starting off with buffers that are too small. - When testing with JRE7, it became apparent that the behaviour of the SSLEngine and SSLContext classes had changed, which initially resulted in "hangs" being seen as the SSLEngine did not appear to decrypt data being fed to it until subsequent SSL messages arrived and appeared and to prod it into life. This behaviour is influenced by the version of TLS handshake being used, which made it awkward to debug, since some versions of TLS handshake worked fine for JRE6 but not JRE7 and vice versa; also different servers would negotiate different with different handshakes. Eventually this turned out to be a pre-existing bug in the initial JSSEContext implementation: specifically the "unwrapPendingData()" method had been assuming that a call to SSLEngine.unwrap() would consume all pending data (which is the case for in all scenarios using JRE6, and is often, but not always, the case for JRE7). So the fix for the problem is to loop inside "unwrapPendingData" until calls to unwrap() don't consume any more data. - I also added some logging to JSSEContext - warnings when an error is emitted, and a "fine" message when buffer sizes have to be increased. - Also, double-slash comments are replaced by /*..*/ style in JSSEContext Test-information: Before this patch, TLS wasn't starting. Now it does. Before the bug fixes, concurrent TLS connections to more than one server resulted in "corruption" of the streams, with errors being generated relating to XML parsing errors at both client/server. Before the bug fixes, large messages from the server (~36K) would cause "BufferOverflow" exceptions and connections to drop. After the bug fixes, these problems are no longer seen. Before the bug fixes, TLS sessions would sometimes (depending on what version of TLS the server negotiated, and what version of JRE you were using) appear to "hang". Now they don't. I also tested creating artificially small buffers to make sure that the various "buffer overflow" situations are handled properly. I wasn't able to provoke all of these problems in a real configuration, so I suspect that the "enlargeBuffer" stuff may not actually get used much, but it has been tested. All tested with JRE6 and JRE7