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.0.0.BETA1, 5.0.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. :-)"

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.1.0.BETA1, 5.1.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. :-)"

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. :-)"

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: Tristan Tarrant 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. :-)"