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
