[infinispan-issues] [JBoss JIRA] (ISPN-907) SSL access to Hot Rod

[Tristan Tarrant (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695123#comment-12695123 ] 

Tristan Tarrant commented on ISPN-907:
--------------------------------------

Working on updating the patch to 5.2 and also enabling SSL with NIO (the patch is based on blocking sockets)
                
> SSL access to Hot Rod
> ---------------------
>
>                 Key: ISPN-907
>                 URL: https://issues.jboss.org/browse/ISPN-907
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Cache Server
>            Reporter: Galder Zamarreño
>            Assignee: Galder Zamarreño
>              Labels: hotrod, ssl
>             Fix For: 5.2.0.FINAL
>
>         Attachments: ssl.patch, SSLEngineFactory.scala, SSLTest.java
>
>
> Investigate and integrate Adrian's patch for Hot Rod server so that it can accessed via SSL.
> Email from Adrian:
> "While I remember heres a patch to add ssl for infinispan clients.
> I did it a couple of weeks ago, but I dont know when Ill have time
> to finish it off/polish it. It was based on head a few weeks ago,
> but I dont remember which version. :-(
> The horrible part is the way I had to modify all the parameter lists.
> It could really do with passing some config object instead.
> I dont know how to make "git diff" include new uncommitted files so Ive attached them
> seperately.
> See the test for how to use it, but it is basically set the config properties
> (with the relevant infinispan package prefixes)
> use_ssl=true
> key_store_file_name=jks file containing our key
> key_store_password=secret
> trust_store_file_name=jks file containing public keys we trust for authentication
> trust_store_password=another-secret
> Optionally you can get the server to authenticate the client as well
> need_client_auth=true
> which means the server will need a trust store.
> I've also left it so if you dont set the properties it will use the default implementations.
> But this doesnt work out of the box unless you enable the "anon" alogorithms on
> the server, they aren't enabled by default. Those dont authenticate, they just encrypt the traffic.
> The main thing left to do would be change the test to get maven to generate the
> key/trust store in a well defined place in "target".
> Other comments:
> * The code on the serrver will also work for other protocols as well, e.g. memcached
> if the client supports ssl
> * The ssl context construction is pretty similar in the client/server
> and could probably be shared if I knew where to put shared stuff in the codebase. :-)
> * There is some commented out bits where I think the client/server should really
> be adding socket timeouts. Otherwise network drops/splits could cause the connection
> to hang forever. There should at least be a connection timeout on the socket construction, 
> if you dont want to implement a full blown ping to continually test the connection rather 
> than just ping on start - which doesnt run until after the connection timeout is needed.
> * I had to modify the system property handling so you can have a default of "null".
> I only did this for Strings, might not be relevant for others?
> * Why doesnt the client side do system property replacement like the server?
>  
> * Theres a lot of places in the code doing
> InputStream is = openStream();
> useIt(is);
> but never close the stream. While this is probably ok in infinispans use cases
> it is not good practice to leave files open for the gc to close - that could take a while
> to happen and you are hogging system resources.
> Either useIt() should close the stream or the code should be 
> InputStream is = openStream();
> try {
>    useIt(is);
> }
> finally {
>    is.close();
> }
> Feel free to post whatever parts of this message you like in the infinispan forum. :-)"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira