Luke, That memory leak appears to be on outgoing connection attempts, not incoming ones. So conscript should be fine for server side usage with that... or are you also using the client?
As for options to avoid conscript, would offloaded SSL that communicates via a unix socket rather than localhost be acceptable? Currently this would use the not-really-ready-for-production JNR wrappers, but latest JVMs do have unix socket support, so it is something we may soon add support for. On Mon, 15 Mar 2021 at 01:55, Luke B <[email protected]> wrote: > Hi Shawn, > > Unfortunately my clients want that illusion of safety and it is just > easier to give them that rather than argue with them. I really don't care > to argue this point. > > Do you have any ideas for solving the problem at hand? > > cheers, > > Luke > > On Mon, Mar 15, 2021 at 11:42 AM Shawn Heisey <[email protected]> > wrote: > >> On 3/14/2021 5:50 PM, Luke B wrote: >> > Setting up jetty to listen only on localhost without SSL and having an >> > nginx (or other web server) reverse proxy to provide SSL is possible >> but >> > unlikely something that is acceptable as encryption is required all the >> > way to the java process. In this case a tcp dump would reveal passwords. >> >> Think about what would have to happen for somebody to get that packet >> capture. >> >> 1) If the reverse proxy is on a different machine than Jetty, one way in >> is for the attacker to have physical access to the hardware. They could >> patch a rogue machine in with two network ports and capture everything >> going over the machine's wire. A raspberry pi with a USB network dongle >> could probably be used for that -- relatively easy to hide. >> >> 2) If the attacker manages to acquire remote access and admin/root >> privileges, they could install tools on the machine (like tcpdump or >> wireshark) to capture those packets whether the two processes are on the >> same machine (using localhost) or on separate machines. >> >> If you have good physical security, the first attack is not going to >> happen. >> >> If the second attack succeeds, you've got bigger problems than a lack of >> encryption on the back end of your web services. They've got admin/root >> access, and might be able to obtain those privileges on other machines >> through software vulnerabilities. They would probably already have >> access to everything they might glean from capturing unencrypted >> packets. An example: Credentials in config files for services like >> mail, database, microservices, etc. >> >> It is my strong opinion that encrypting the connection between a >> front-end reverse proxy or load balancer and back end web services is an >> illusion of safety that comes at the expense of CPU time needed for the >> extra encryption. >> >> Anybody is welcome to disagree with me. >> >> I worked at a company that was setting up services for a very high >> profile customer. That customer wanted the back end encrypted like you >> do. We did it, but I think it was unnecessary. >> >> Thanks, >> Shawn >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
