Thanks for that very comprehensive answer. I had not considered that but it sounds like it should give me the flexibility I need. I’m a Java programmer by profession rather then a web guru so it will no doubt take a fair bit of trial an error but that’s for pointing me in the right direction.
Dave > On 4 Oct 2016, at 10:58, Olaf Kock <tom...@olafkock.de> wrote: > > > Am 04.10.2016 um 11:23 schrieb Kreuser, Peter: >> In my opinion weakening the security of the majority of users (there are >> seemingly others) is a pretty bad thing to do. My suggestion would be a >> different connector on a separate port for the handhelds. Configure this >> either on HTTP or a specific supported SSL protocol and ciphers. It would >> probably mean to reconfigure the handhelds, to add a hole into the firewall >> for the new port, but that could be restricted to the location/subnet of the >> handhelds. >> You will need to get an exemption from the https-requirement for the >> handhelds anyways, so that may be a way to get a compensating control. > > Given the situation described, I'd opt for adding an Apache httpd (or > equivalent webserver of your choice) to the game to handle encryption. > As Peter suggests, preferably on a different host/port/firewalled > section. Given that OpenSSL/mod_ssl come with the kitchensink of > algorithms, it should be straightforward to configure the best algorithm > that the barcode scanners support. > > This way you can continue to run tomcat8 in a non-weakened configuration > and totally ignore encryption on that end. > > Personally I prefer this setup anyway: My tomcat installations never > deal with https, it's always a frontend-webserver. If only because > mod_rewrite has helped me quickfix an issue in seconds instead of hours. > And on my installations there's typically no need to encrypt the > Apache->tomcat traffic (on small installations: because it's localhost > traffic to begin) > > Sooner or later OP should push for updates to the barcode scanners - > especially if HTTPS is mandatory. The old algorithms are deprecated for > a reason and won't protect the data in transit as you expect when just > seeing https:// on a URL. And the older Windows desktop&server versions > do not support the newer algorithms. I'm expecting the same for Windows > Mobile. > > And I can't go without ranting: When "only" HTTPS is a requirement, not > "data protection according to the latest findings": There's a NULL > cipher that you could select. It's disabled by default for obvious > reasons, but it does exactly what you'd expect: Talk https without > encrypting or signing any of the traffic. ;) (Of course: Use this only > to question the requirements: If customer wants *proper* encryption > instead of bandaid, the barcode scanners will need to be *up*graded to > support proper encryption, rather than the server to be *down*graded) > > Olaf > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
