tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Savard <daniel.sav...@gmail.com>
Subject Re: Tomcat 8 HTTPS issue with old browser
Date Tue, 04 Oct 2016 11:30:40 GMT
Your challenge is much more with Java 8 as already mentioned above if you
use a non-APR connector and with OpenSSL otherwise than with Tomcat itself.

-----------------
Daniel Savard

2016-10-04 6:43 GMT-04:00 Garratt, Dave <DGarratt@logopak.net>:

> To elaborate, there is only this single application running on the server.
> All other web applications use Windows IIS.
>
> I have mentioned that the problem is down to the old software on the
> scanner but it’s a huge international organisation and making a upgrade to
> their entire line of devices is likely to take some time.
>
> However silly it may seem this is a “tick the box” exercise when it comes
> to security - HTTPS - yes/no.
>
> On the assumption that a weak encryption is better than none then I can’t
> really argue with the customer.
>
> Someone did suggest using Apache HTTP server to do the comms - maybe and
> IIS connector to Tomcat would accomplish the same ?
>
> As I mentioned before I’m a bit of a novice with the server config.
>
> Dave
>
>
> > On 4 Oct 2016, at 11:29, André Warnier (tomcat) <aw@ice-sa.com> wrote:
> >
> > On 04.10.2016 09:53, Garratt, Dave wrote:
> >
> >>> On 4 Oct 2016, at 08:48, André Warnier (tomcat) <aw@ice-sa.com> wrote:
> >>>
> >>> On 04.10.2016 09:38, Garratt, Dave wrote:
> >>>> I have Apache Tomcat 8 working ok with https when I connect to my web
> page using a recent browser (desktop) or iPhone for example. However this
> specific application is designed to run on a Motorola MC9090 hand held
> wireless barcode scanner running a relatively old version of Windows
> Mobile. The browser on that device can only load the HTTP page and not the
> HTTPS page, giving a unable to open page message. Speaking to a “expert” on
> these scanners the consensus of opinion is that the type of encryption used
> by Apache Tomcat 8 is more up to date than the mobile devices browser can
> support. As it does not appear likely that the mobile devices are going to
> be updated any time soon I was wondering if its possible to force Tomcat to
> accept deprecated protocols rather than be forced to revert to plain HTTP.
> >>>>
> >>>> Any ideas or ideally an example of how this might look in a config
> file would be most appreciated.
> >>>>
> >>>>
> >>>
> >>> Naive question : if you are dealing anyway with old devices that
> cannot be replaced by new devices, then why do you not just keep using the
> correspondingly old version of tomcat and of the JVM ?
> >>>
> >>>
> >
> >> The requirement for HTTPS is only a recent requirement and the
> application is now heavily dependent on Java 8. At this point I don’t know
> just how old a version of Tomcat I would need to make it work and I would
> have to make significant changes to the code in order to make it Java 6/7
> compliant.
> >>
> >
> > I was just wondering, basically because the reason for retiring an old
> SSL protocol is usually that it has been proven insecure and/or buggy. So,
> there might be a way to do what you are requesting, but it does not seem to
> make sense that the requirement for HTTPS is recent (and presumably linked
> to a wish for increased security), yet for these old devices the only way
> to do it, would be by enabling and old/buggy SSL protocol (and thus
> potentially weaken other applications running on the same host). There
> seems to be a bit of a logical thinking contradiction in this, no ?
> >
> > To dig a bit deeper : there are two families of "connectors" which can
> be used by Tomcat :
> > - the ones based on the underlying Java JVM's SSL
> > - the one based on the underlying APR (Apache Portable Runtime), which
> use OpenSSL-based logic
> >
> > If you wanted to enable an old deprecated protocol under the Java 8 JVM,
> you'd have to look if this old protocol is even still supported by the Java
> 8 JVM. If not, though luck, because the chances of persuading the vendor of
> this JVM to change their ways are probably slim to say the least.
> > If you wanted to enable an old deprecated protocol in the APR-based
> connectors, your chances may be a bit better (but not guaranteed), to find
> a working combination of Tomcat/APR/OpenSSL which allows this and still
> works. But as time goes on, these things will eventually get upgraded, and
> your old devices may get the problem again at some unexpected moment.
> > You may also be facing issues then, if some security team scans your
> server, and finds out that it is allowing a deprecated HTTPS protocol
> (which would show up even for accesses having nothing to do with this
> application or these devices).
> >
> > So if I was looking at this in a top-down way, I would tend to say that
> if really these old devices need this "functionality", then whenever the
> server detects that it is talking to one of these devices, it should
> redirect these calls to some other specific host or service, where the
> HTTPS protocol has been intentionally weakened to support them, and that
> this is well-documented and approved.
> > And the initial work to set this up, and its support after that, would
> then be clearly identified and clearly attributable to the support of these
> old devices, without interference with the new stuff.
> > That may also help the decision-makers to determine if the cost of
> supporting these old devices is worth it or not.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message