You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Garratt, Dave" <DG...@logopak.net> on 2016/10/04 07:38:36 UTC
Tomcat 8 HTTPS issue with old browser
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.
Many thanks
Dave G
AW: Tomcat 8 HTTPS issue with old browser
Posted by "Kreuser, Peter" <pk...@airplus.com>.
Objections Chris,
> André,
>
> On 10/4/16 7:59 AM, André Warnier (tomcat) wrote:
> > On 04.10.2016 12:43, Garratt, Dave wrote:
> >> 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.
> >
> > Maybe you cannot argue with the customer, that is for your
> > commercial environment to decide. But on the professional ethics
> > side of thing, I would disagree with you on the previous item. A
> > weak encryption can be worse than none, because it gives a false
> > sense of security. It may lead the customer to think that he is
> > protected, when in reality he is not. And it may be your duty as a
> > technical adviser, to point this out.
>
> +1
>
> Weak encryption is *worse* than no encryption IMO. You can argue about
> the definition of "weak", of course.
>
> SSLv2 is definitely weak. A NULL symmetric cipher is definitely weak.
> Is RSA key negotiation weak? I think reasonable people can disagree
> over that, but I won't deploy it on any production machine unless
> there are no alternatives.
>
> Since this is a barcode reader, it's unlikely that there are any
> problems with *confidentiality* of the data being transmitted. If you
> have to login to a "secure" server before reading barcodes, then you
> may have to consider the secrecy of the credentials for authentication
> even when the majority of the traffic will be non-private.
>
> Assuming the confidentiality isn't a problem, then the only reasons to
> use encryption are authentication (of the server by the client) and
> integrity (to prove that nobody has meddled with the message).
>
> If RSA authentication is good enough (and for most people, it is) and
> there are no issues with the authentication protocol (none that I can
> think of off the top of my head), then the differences between e.g.
> SSLv3 and TLSv1.2 are not that great.
>
> That's a lot of "ifs".
>
> It's also possible to use RSA authentication in a weak way. For some
> reason, Microsoft servers seem to be plagued by these issues in
> particular. 1024-bit RSA keys (and thus the certificates produced with
> them) have been deemed insecure for quite some time and I won't
> personally use a 2048-bit key for anything anymore. If the MC9090
> can't support keys of a certain length (I know of no SSL
> implementation that complains about "large" RSA keys) then you may not
> be able to get authentication (that the server is trusted by the
> client, that is) that is trustworthy.
>
> If you are covered by PCI-DSS then you MUST NOT use anything less than
> TLSv1.1 by ... wow, it's still 2 years away. [0] At least NIST
> deprecated the use of TLSv1 and earlier effective *immediately*. Of
> course, it just says "you shouldn't use these", it doesn't say you
> MUST NOT use these. Oh, well. At least Google has the temerity to
> force changes on the Internet even if standards bodies won't keep
> pace. It doesn't matter if it's not a regulatory requirement if none
> of your users will visit your site unless you get serious about security
> .
>
> Just some food for thought.
>
> -chris
>
> [0] Nice job, PCI-DSS... you were going to drive the industry forward
> until the industry cried like a bunch of babies about how they had
> large investments in crappy products and they didn't want to pay
> actual money to upgrade them. Better to swap fictional assets at
> ever-increasing margins pretending to make money to drive the stock
> price up. Heaven forbid you actually do something to protect
> yourselves, your shareholders, and your customers. </soapbox>
>
PCI requires you to use TLS > 1.0 for new implementations starting last year with PCI 3.0.
So if you add TLS because of PCI now (well too late IMO), you MUST NOT use TLS1.0 anymore .
I do agree with you on the weakening of the requirements in 3.1 and 3.2, but of course there are also customers out there with devices that do not support TLS1.2. So if you want to be customer friendly and not block them before you even can get a message across, you may be content that the final call is only in 2018.
My 2cts
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Andr�,
On 10/4/16 7:59 AM, Andr� Warnier (tomcat) wrote:
> On 04.10.2016 12:43, Garratt, Dave wrote:
>> 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\u2019s 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 \u201ctick the box\u201d exercise when
>> it comes to security - HTTPS - yes/no.
>>
>> On the assumption that a weak encryption is better than none then
>> I can\u2019t really argue with the customer.
>
> Maybe you cannot argue with the customer, that is for your
> commercial environment to decide. But on the professional ethics
> side of thing, I would disagree with you on the previous item. A
> weak encryption can be worse than none, because it gives a false
> sense of security. It may lead the customer to think that he is
> protected, when in reality he is not. And it may be your duty as a
> technical adviser, to point this out.
+1
Weak encryption is *worse* than no encryption IMO. You can argue about
the definition of "weak", of course.
SSLv2 is definitely weak. A NULL symmetric cipher is definitely weak.
Is RSA key negotiation weak? I think reasonable people can disagree
over that, but I won't deploy it on any production machine unless
there are no alternatives.
Since this is a barcode reader, it's unlikely that there are any
problems with *confidentiality* of the data being transmitted. If you
have to login to a "secure" server before reading barcodes, then you
may have to consider the secrecy of the credentials for authentication
even when the majority of the traffic will be non-private.
Assuming the confidentiality isn't a problem, then the only reasons to
use encryption are authentication (of the server by the client) and
integrity (to prove that nobody has meddled with the message).
If RSA authentication is good enough (and for most people, it is) and
there are no issues with the authentication protocol (none that I can
think of off the top of my head), then the differences between e.g.
SSLv3 and TLSv1.2 are not that great.
That's a lot of "ifs".
It's also possible to use RSA authentication in a weak way. For some
reason, Microsoft servers seem to be plagued by these issues in
particular. 1024-bit RSA keys (and thus the certificates produced with
them) have been deemed insecure for quite some time and I won't
personally use a 2048-bit key for anything anymore. If the MC9090
can't support keys of a certain length (I know of no SSL
implementation that complains about "large" RSA keys) then you may not
be able to get authentication (that the server is trusted by the
client, that is) that is trustworthy.
If you are covered by PCI-DSS then you MUST NOT use anything less than
TLSv1.1 by ... wow, it's still 2 years away. [0] At least NIST
deprecated the use of TLSv1 and earlier effective *immediately*. Of
course, it just says "you shouldn't use these", it doesn't say you
MUST NOT use these. Oh, well. At least Google has the temerity to
force changes on the Internet even if standards bodies won't keep
pace. It doesn't matter if it's not a regulatory requirement if none
of your users will visit your site unless you get serious about security
.
Just some food for thought.
- -chris
[0] Nice job, PCI-DSS... you were going to drive the industry forward
until the industry cried like a bunch of babies about how they had
large investments in crappy products and they didn't want to pay
actual money to upgrade them. Better to swap fictional assets at
ever-increasing margins pretending to make money to drive the stock
price up. Heaven forbid you actually do something to protect
yourselves, your shareholders, and your customers. </soapbox>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJX9BIbAAoJEBzwKT+lPKRYF9sQAJTiF+Z/2sHEdJ8cVtgyxsd1
CLDkS5Sulk+oRqera8lvdc5jyBOv/FuopCXIzoj3Rk1TLGLWpXsR3rj59iOjtjTk
KSCtzBFpk8ACBGI4/A0sj8MQkbKIr4K2oCfNNIU1Lj9dGduSRbGsTY7lOYDYJRA3
r6cEpV80Z0V9uu5zO8ISYBo1ljiAkjtC/InK5EAFC5tw8ObTZ+11q2rWlDgJ1wVz
fuVMnmWgwzVEt7z4QH+dcUpGQyA+hbrXEDgzF20ZHUFQt+usNohhMnsfcxWMYs+V
e4UNr2e+OHkPCk0Rc37itGg1pk5HwxbNElAXgzR9GJxxZBOyh1pcuDsF+qyDqZFz
8MQ2lcckbGGNzvh16CahXR1LBYNvhovzfqfl8ZS2YdQVf3y0El7P38kbt1ZdcWFg
8D7zD3LtcLMjeq0pPEBZY4mZopVKWFhvTLRQrGnGydAk4NE0eVLNLqQvGqQPCsFl
dCeFv0fIo9wO7NsL0cv3gMtMFc3pJsUHu/uJ+ewnO9zW5+18gJRiqb4tF4u9fNGB
NN9T/xzLwQegEYYYwOPmsFGTRDF5rI4/UNRpqEy8txfg5HD7lt4cXHTeUqulJETW
oVdXcivTLnrTsyvypQfFQeVwUr3O5F9fZseS0Lt0IyBYgI3N/4venig8UZSZ8oW1
1m1quXMayFH/BSXd5kRB
=i0YL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 04.10.2016 12:43, Garratt, Dave wrote:
> 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\u2019s 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 \u201ctick the box\u201d exercise when it comes to security - HTTPS - yes/no.
>
> On the assumption that a weak encryption is better than none then I can\u2019t really argue with the customer.
Maybe you cannot argue with the customer, that is for your commercial environment to
decide. But on the professional ethics side of thing, I would disagree with you on the
previous item. A weak encryption can be worse than none, because it gives a false sense
of security. It may lead the customer to think that he is protected, when in reality he is
not. And it may be your duty as a technical adviser, to point this out.
And just to rub it in : if there is any question of potential future legal liability in
this, I would seriously think about it. What if in 6 months, someone breaks into the
server and causes a lot of damage, taking advantage of one of the long-time known bugs of
the old HTTPS algorithm ? If this is really a major international corporation, do you
think that their legal department would hesitate for a minute before starting to look if
you have adequately warned them, and you have written proof of ditto ?
At least I would make sure that the correspondence shows something like "HTTPS encryption
according to the best method available, taking into account the well-known limitations of
the client device & software, as per our memo of ... ".
In other words, it may be a "tick the box" exercise for them; but that does not mean that
it is one for you, or for your employer.
>
> Someone did suggest using Apache HTTP server to do the comms - maybe and IIS connector to Tomcat would accomplish the same ?
>
Yes. Basically, the schema is like
client device <- HTTPS -> IIS <-- (choice) --> Tomcat <- internal -> webapp
+ connector
Assuming that IIS and Tomcat are running on the same host, the communication between IIS
and Tomcat does not need to be encrypted (assuming the basic premise that the host itself
is not accessible to potential miscreants).
This kind of configuration is usually described as "terminating HTTPS at the front-end
level", because the only place where HTTPS (and encryption) takes place, is between the
client and the front-end IIS server. In this kind of configuration, it is still possible
to know, for the Tomcat webapp, that the original client<->server communication /is/ using
HTTPS, and to react appropriately.
The (choice) element above, is because there are various methods/protocols available to do
the job. With IIS, you could use
- a simple proxying through HTTP, which would require some standard setup in IIS (I am not
familiar with it, so I don't really know how to do that)
- or an AJP connection. This requires an IIS add-on module available on the Tomcat
website, and the corresponding setup.
See : http://tomcat.apache.org/connectors-doc/,
and the "ISAPI redirector" would be the one you need.
AJP is not HTTP, it is another specific protocol, but it carries the same information as
the HTTP protocol. To "talk AJP" between IIS and Tomcat, you need
- on the IIS side, the ISAPI redirector module
- on the Tomcat side, a <Connector> of the AJP kind.
(see : http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html)
> As I mentioned before I\u2019m a bit of a novice with the server config.
By the time you're done with this, you'll have become an expert.
But please before you do, heed the advice given by several contributors here, about this
potentially weak HTTPS setup.
>
> 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 \u201cexpert\u201d 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\u2019t 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by Daniel Savard <da...@gmail.com>.
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 <DG...@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
> >
>
>
Re: Tomcat 8 HTTPS issue with old browser
Posted by Olaf Kock <to...@olafkock.de>.
Am 04.10.2016 um 12:43 schrieb Garratt, Dave:
> 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\u2019s a huge international organisation and making a upgrade to their entire line of devices is likely to take some time.
IMHO you should point out that weakening encryption server-side is
nothing but a workaround, valid until the problem has been solved at its
root: The barcode scanners need to be upgraded.
If you rely on trusted CA certs instead of self-signing them, you might
be out of luck when the current certs need to be extended: *None* of the
OS's trusted root CAs will issue any SHA-1 certificate any more as of
this year. Doublecheck if the scanners can operate on a currently issued
cert. Alternatively you will need to roll out your own CA with - more or
less - self-signed certificates. Any one of these solutions will do, but
they might bite you if they come unsuspected and at an inconvenient time.
> However silly it may seem this is a \u201ctick the box\u201d exercise when it comes to security - HTTPS - yes/no.
>
> On the assumption that a weak encryption is better than none then I can\u2019t really argue with the customer.
well... at least you can mention it - make an impression by pointing to
an insecure requirement that has been made under the assumption of
adding security.
> Someone did suggest using Apache HTTP server to do the comms - maybe and IIS connector to Tomcat would accomplish the same ?
I've mentioned "Apache httpd (or equivalent webserver of your choice)".
In this case IIS seems to be the webserver of your choice.
>
> As I mentioned before I\u2019m a bit of a novice with the server config.
>
> Dave
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by "Garratt, Dave" <DG...@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
>
Re: Tomcat 8 HTTPS issue with old browser
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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 \u201cexpert\u201d 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\u2019t 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
Re: Tomcat 8 HTTPS issue with old browser
Posted by "Garratt, Dave" <DG...@logopak.net>.
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 <to...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat 8 HTTPS issue with old browser
Posted by Olaf Kock <to...@olafkock.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Tomcat 8 HTTPS issue with old browser
Posted by "Kreuser, Peter" <pk...@airplus.com>.
Dave,
> 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.
>
> Thanks for the suggestion though.
>
> Dave
>
> > 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 ?
> >
> >
> >
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.
Best regards
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by "Garratt, Dave" <DG...@logopak.net>.
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.
Thanks for the suggestion though.
Dave
> 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 ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat 8 HTTPS issue with old browser
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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 \u201cexpert\u201d 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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8 HTTPS issue with old browser
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dave,
On 10/4/16 3:38 AM, 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 \u201cexpert\u201d 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.
The user manual for the MC9090 doesn't say what support that model has
for SSL or TLS. It does mention both SSL and TLS, which is a good sign.
But it might not support certain versions e.g. TLSv1.1 or TLSv1.2. It
might also require the use of an "SSLv2 Hello" handshake which uses
the SSLv2 protocol only for the handshake but won't negotiate SSLv2
for example.
If your server and client cannot agree on a protocol, you won't be
able to communicate. Can you reconfigure the mobile device to use a
different URL? If so, you might be able to set up a web server that is
very locked-down and expected to only be used by that particular
device. If that device can only make insecure web requests, you might
want to decide if you should really still be using it for anything
that requires actual security.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJX88iwAAoJEBzwKT+lPKRYYmQP/A827s+M9eS74SR5vvchDHEp
dlcMIg06G31rkgQjbYl8Zuwx3q8q8/MZwo9gg5bjDBL5+sdQ0aepB804X26907fY
XmYOF+l+XW/9m7D/CZxrvkky6AqBe16VHDpvzSV2i3hisHDJdb9LoAPPMXNSg/Wl
f3o9mUQyqP3SixomI4C5eiK1y4kkt1g36bfo+fTWzXEHdQ+CNQZTrXCRBEBKYhcB
jXu8YoM6pCVm/625ro3gi9P+MQwxrb2kMIWI5m2AClVLJZKa8PtG5rASNtaINb8J
IHnhRceOOTAbtCedmYC5YiM6oxweU3yCv2o6hD2pBrpHZ/VG1R0TmGyPcBHhq72S
qMwKAPdg2v+saunIwJg7FZ8RLnos24iY4/7NK3CoQriNC5rdIFrIp6OhH6gdW02H
j6SFdrNHk8lgEhlvV7kWNRBT/lzyD7AVyRjWPGuQcRqEPhHO1ZAQb5DVVAnyjiLB
D/rcmW+hIn57ihkw08hopJ4BcXlULzswsM+lT396u3Uy0M9uW6ln2RYIx00VpqEo
GLT5B3jb/H2rDrwgFI3nhvxJHcWHtd8XvV007AfA264v/dVaSh9rat7fEB965HLY
ULQ8pM28qMZrWioCv8DsxVkzhQE8Nmj9LifcLArmdtNbEHXY4tMr8+O2TexfUWNh
leDCI7B30HQEI7LSeVAF
=ObJT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org