Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)
On 14/09/2018 16:01, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/14/18 08:34, Mark Thomas wrote: On 14/09/18 13:11, Tim K wrote: Using latest Tomcat 9.0.11. I'm using the securePort attribute for both the NioReceiver and StaticMembers but when capturing and inspecting the traffic over the secure ports with WireShark, I'm seeing all my session data in clear text, even my username as password (user principal)! I tried removing the port attribute from both, elements, leaving just the securePort there but this does not encrypt the traffic. To my knowledge, the port was added but TLS was never implemented. It may be better if we remove that code entirely. Why you'd want a secure port and an insecure port at the same time for a cluster never did make much sense to me. The typical TLS configuration is a poor choice for clusters It would require quite a lot of configuration. Encryption based on a pre-shared private key would be a better approach. Why? Long (and bitter) experience tells me that most folks have a hard time setting up TLS so it works. Generating a single file (for the shared secret - which we can easily provide a script to generate) and copying that one file to multiple machines is a much simpler process. Each server with a server-cert and each client with a bag of trusted certs doesn't seem that big of a deal. Even mutual-authentication just adds another bag of trust on each server and a client-cert on each client. If you set up a private signing authority, it gets even easier. But I agree, there shouldn't be two ports to configure. Just one, and if we decide to add encryption, you should just be able to say "yes, please" and have it work over the same port... assuming all nodes are configured the same, of course. Applying encryption shouldn't be too hard, code-wise, if all we wanted to do was encrypt each message going over the (otherwise plaintext) wire. Each node needs to know the encryption flavor in use (cipher, padding, etc.) and a pre-shared key. That's just two configuration elements in server.xml and one of them (the cipher) can default to something reasonable such as AES/CBC/PKCS5Padding. This would be a good Google Summer of Code project, though it wouldn't actually take that long. Maybe Google Midsummer of Code :) Worth adding a BZ enhancement for this. Mark - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubzUkACgkQHPApP6U8 pFi8Sw/+McP0UxnqhcWKe+ErhWXX/AmiMdsvx1URDIw3GGec0P6p7zyIDldllnjr /nbXDmYTRX3SUcXAd80h0p86HG44G0NKtRkzMwCbdUkKLtwHxASsYAnuzMSL7Xaf Vh+ohgEfqjDurcor+xJZRFPweCFn+a7ID41jv5i42oYr0QC4o1xBCPzXYNcb6UnP JYGBuxOVthaHnEBcGej3sQCNMNWQvoyQphvsprXUkHMjXZt3/esTRe0Nj0d9O+sQ AEGli/gN4UQeIPU0yU1nZXyrKuHE/qupU4TLkIDlFE36XHMY8SHX3bEnVD23fEkk goftmlsefu+SyXlemO0q9h2X/eL2GFKFJn0ALQUb4u354QKpyDYh4FTK8VJnnN/2 lOVjbCfq39gBnZ4wZntJUVN+4BB2elQs4PrLOrDAwrZYCNzvKgfmI6V0xEQCTrfO 7tiJ+YJnIgUuFqyfKi5b4RnvZC5LasZ0Uw/nWjlHyVd5xwrRgspdEDRRKapsnzb8 3y7vle6UM/nOdmbQ99cnERtQ8qdmiy6FGnaVm8Gt96Se4Gj3SlpwfHx1tO+py5Us Gc3sxDiXzlhs79CqYwqJDaAzK5iQfATVUKJ1f8GT+Zc6RGbIUL/ERkTrJhDD0rbL eZSSKArJj6DwzkjS8CjapJGs/UhmeShb0wX29KLploEofVqfRIc= =JMu5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/14/18 08:34, Mark Thomas wrote: > On 14/09/18 13:11, Tim K wrote: >> Using latest Tomcat 9.0.11. I'm using the securePort attribute >> for both the NioReceiver and StaticMembers but when capturing and >> inspecting the traffic over the secure ports with WireShark, I'm >> seeing all my session data in clear text, even my username as >> password (user principal)! I tried removing the port attribute >> from both, elements, leaving just the securePort there but this >> does not encrypt the traffic. > > To my knowledge, the port was added but TLS was never implemented. > It may be better if we remove that code entirely. Why you'd want a > secure port and an insecure port at the same time for a cluster > never did make much sense to me. > > The typical TLS configuration is a poor choice for clusters It > would require quite a lot of configuration. Encryption based on a > pre-shared private key would be a better approach. Why? Each server with a server-cert and each client with a bag of trusted certs doesn't seem that big of a deal. Even mutual-authentication just adds another bag of trust on each server and a client-cert on each client. If you set up a private signing authority, it gets even easier. But I agree, there shouldn't be two ports to configure. Just one, and if we decide to add encryption, you should just be able to say "yes, please" and have it work over the same port... assuming all nodes are configured the same, of course. Applying encryption shouldn't be too hard, code-wise, if all we wanted to do was encrypt each message going over the (otherwise plaintext) wire. Each node needs to know the encryption flavor in use (cipher, padding, etc.) and a pre-shared key. That's just two configuration elements in server.xml and one of them (the cipher) can default to something reasonable such as AES/CBC/PKCS5Padding. This would be a good Google Summer of Code project, though it wouldn't actually take that long. Maybe Google Midsummer of Code :) - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlubzUkACgkQHPApP6U8 pFi8Sw/+McP0UxnqhcWKe+ErhWXX/AmiMdsvx1URDIw3GGec0P6p7zyIDldllnjr /nbXDmYTRX3SUcXAd80h0p86HG44G0NKtRkzMwCbdUkKLtwHxASsYAnuzMSL7Xaf Vh+ohgEfqjDurcor+xJZRFPweCFn+a7ID41jv5i42oYr0QC4o1xBCPzXYNcb6UnP JYGBuxOVthaHnEBcGej3sQCNMNWQvoyQphvsprXUkHMjXZt3/esTRe0Nj0d9O+sQ AEGli/gN4UQeIPU0yU1nZXyrKuHE/qupU4TLkIDlFE36XHMY8SHX3bEnVD23fEkk goftmlsefu+SyXlemO0q9h2X/eL2GFKFJn0ALQUb4u354QKpyDYh4FTK8VJnnN/2 lOVjbCfq39gBnZ4wZntJUVN+4BB2elQs4PrLOrDAwrZYCNzvKgfmI6V0xEQCTrfO 7tiJ+YJnIgUuFqyfKi5b4RnvZC5LasZ0Uw/nWjlHyVd5xwrRgspdEDRRKapsnzb8 3y7vle6UM/nOdmbQ99cnERtQ8qdmiy6FGnaVm8Gt96Se4Gj3SlpwfHx1tO+py5Us Gc3sxDiXzlhs79CqYwqJDaAzK5iQfATVUKJ1f8GT+Zc6RGbIUL/ERkTrJhDD0rbL eZSSKArJj6DwzkjS8CjapJGs/UhmeShb0wX29KLploEofVqfRIc= =JMu5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Encryption for Cluster Conversations (NioReceiver and Members)
On 14/09/18 13:11, Tim K wrote: > Using latest Tomcat 9.0.11. I'm using the securePort attribute for both > the NioReceiver and StaticMembers but when capturing and inspecting the > traffic over the secure ports with WireShark, I'm seeing all my session > data in clear text, even my username as password (user principal)! I tried > removing the port attribute from both, elements, leaving just the > securePort there but this does not encrypt the traffic. To my knowledge, the port was added but TLS was never implemented. It may be better if we remove that code entirely. Why you'd want a secure port and an insecure port at the same time for a cluster never did make much sense to me. The typical TLS configuration is a poor choice for clusters It would require quite a lot of configuration. Encryption based on a pre-shared private key would be a better approach. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org