Java 9 support + HSTS for tomcat.apache.org

[Oliver Heister]

Hi all,

I have two suggestions:

1. The table on http://tomcat.apache.org/whichversion.html has a column
“Supported Java Versions” which has entries like “8 and later”. My
understanding from e.g.
https://marc.info/?l=tomcat-dev&m=150617891913261&w=2 is that currently no
stable tomcat release supports Java 9 yet.

IMO a remark regarding Java 9 should be added to
http://tomcat.apache.org/whichversion.html .


2. Currently MITM attacks by evil ISPs or WiFi networks are possible
against people downloading tomcat from
http://tomcat.apache.org/download-80.cgi . (The page has links to PGP, md5
and sha1 hashes for validation, but the links are on a http page that does
not redirect to https. This means they could be replaced in case of MITM.)

IMO a HTTP 301 redirect to the https version and HSTS headers should be
added to http://tomcat.apache.org/ .



Should I try to submit issues in Bugzilla for both?


Best Regards

Oliver

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Oliver,

Post by Oliver Heister
1. The table on http://tomcat.apache.org/whichversion.html has a
column “Supported Java Versions” which has entries like “8 and
later”. My understanding from e.g.
https://marc.info/?l=tomcat-dev&m=150617891913261&w=2 is that
currently no stable tomcat release supports Java 9 yet.
IMO a remark regarding Java 9 should be added to
http://tomcat.apache.org/whichversion.html .

Sounds good. I don't know of anything specific that does NOT work with
Java 9, but markt has been following the pre-releases of Java 9 pretty
closely, and has made adjustments (mostly disabling various
workarounds for bugs in previous JVMs) accordingly. There may be some
NEW items that may need to be worked-around -- those usually turn out
to be various ClassLoader-pinning memory-leaks -- but my guess is that
most Tomcat versions will work just find under Java 9 without any
special effort.

Could you try (the latest patch-level of) whatever version of Tomcat
you are currently using with Java 9 and let us know how things go?

Post by Oliver Heister
2. Currently MITM attacks by evil ISPs or WiFi networks are
possible against people downloading tomcat from
http://tomcat.apache.org/download-80.cgi . (The page has links to
PGP, md5 and sha1 hashes for validation, but the links are on a
http page that does not redirect to https. This means they could be
replaced in case of MITM.)
IMO a HTTP 301 redirect to the https version and HSTS headers
should be added to http://tomcat.apache.org/ .

Agreed about the redirect... not so sure about HSTS, as that affects
the whole domain.

Post by Oliver Heister
Should I try to submit issues in Bugzilla for both?

Yes, please. Post-back with URLs to the BZ issues you raise.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnLtH8ACgkQHPApP6U8
pFiODA//aTKgTuNYFZ+pLwZmweRXapD5lVfn2c9VWIh8DIaYuCa6LE1nGLNTrX9Z
p8WUj5gubOvjjtYYuoebZmrkLhS1l98tRqy6aUCnSgxkgUYJtoNGyKvMO0cceVg2
5mROW5B1fKhZdwonIWbpO6gGsrye5FC4elTPZE1B/iigPrK/sakhWCHPTARG5xHd
KJkimzppTewV/KExIyS4QeOPWn6RJPjGeZWDFNT5YDDsTEF3VKFqVnf2afLvs+Fp
mGjE47GsWjNJtKFkuQeAyI46zaRvbhW9g6XTtwGquNmZ+e4orJSKNfSjaM+CpkKk
UdmiddlsoyzyC6ZUvftUdLG35l4NPWHnuhTGdnuxAqm6xSRoB5M5zC7EYGoMzYGS
1HXQeqKqQtJG3NlPi7lOH+h7qJwMnGz8GvBlwtWTrxlzbXWKWu9UFwY2SceBEJOa
xavbUirNui5qyxbfWea8cnVVztDVbFEUJNv5G1i2tumQj7CuJjpgg/yr2m8MIU6M
c7sW1iKjrwmtUkr84Ha+C8CQO5zE1oRITCfKQHRcFNE+7xZq1LrNMVrnF9Oj5M++
pkoXh9wKlm+DT1h7Zx/icqOkRuSzgWaEob1Syx76+ixUJJCVd0sn9bUqx9g+URFv
x0bZpqzfMIQ8pO7ZYzhBcr8G/4t28TjZZybEmBPrDovy6kQVwyg=
=phJW
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Oliver Heister]

Post by Christopher Schultz

Post by Oliver Heister
IMO a remark regarding Java 9 should be added to
http://tomcat.apache.org/whichversion.html .

Sounds good. I don't know of anything specific that does NOT work with
Java 9, but markt has been following the pre-releases of Java 9 pretty
closely, and has made adjustments (mostly disabling various
workarounds for bugs in previous JVMs) accordingly. There may be some
NEW items that may need to be worked-around -- those usually turn out
to be various ClassLoader-pinning memory-leaks -- but my guess is that
most Tomcat versions will work just find under Java 9 without any
special effort.
Could you try (the latest patch-level of) whatever version of Tomcat
you are currently using with Java 9 and let us know how things go?

It looks like Tomcat 8.5.23 and Tomcat 9.0.1 Beta will be released
soon and they include the fix mentioned in
https://marc.info/?l=tomcat-dev&m=150617928913339&w=2 . So we will
test Tomcat 8.5.23.

Post by Christopher Schultz

Post by Oliver Heister
2. Currently MITM attacks by evil ISPs or WiFi networks are
possible against people downloading tomcat from
http://tomcat.apache.org/download-80.cgi . (The page has links to
PGP, md5 and sha1 hashes for validation, but the links are on a
http page that does not redirect to https. This means they could be
replaced in case of MITM.)
IMO a HTTP 301 redirect to the https version and HSTS headers
should be added to http://tomcat.apache.org/ .

Agreed about the redirect... not so sure about HSTS, as that affects
the whole domain.

HSTS (RFC 6797) would only affect http://tomcat.apache.org/ .
"HSTS preload" would affect the base domain and all subdomains.

Post by Christopher Schultz

Post by Oliver Heister
Should I try to submit issues in Bugzilla for both?

Yes, please. Post-back with URLs to the BZ issues you raise.

OK.

Regards
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Konstantin Kolinko]

Post by Oliver Heister
2. Currently MITM attacks by evil ISPs or WiFi networks are possible
against people downloading tomcat from
http://tomcat.apache.org/download-80.cgi . (The page has links to PGP, md5
and sha1 hashes for validation, but the links are on a http page that does
not redirect to https. This means they could be replaced in case of MITM.)
IMO a HTTP 301 redirect to the https version and HSTS headers should be
added to http://tomcat.apache.org/ .

The recommended way to validate releases it to check the PGP
signature, not the checksums.

It is not so easy to compromise a PGP signature. You cannot generate a
new signature without having a key.


I think that HSTS is an overkill.

Maybe update links to *.cgi pages (in menu and on the site) to use https:

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Konstantin Kolinko]

Post by Konstantin Kolinko

Post by Oliver Heister
2. Currently MITM attacks by evil ISPs or WiFi networks are possible
against people downloading tomcat from
http://tomcat.apache.org/download-80.cgi . (The page has links to PGP, md5
and sha1 hashes for validation, but the links are on a http page that does
not redirect to https. This means they could be replaced in case of MITM.)
IMO a HTTP 301 redirect to the https version and HSTS headers should be
added to http://tomcat.apache.org/ .

The recommended way to validate releases it to check the PGP
signature, not the checksums.
It is not so easy to compromise a PGP signature. You cannot generate a
new signature without having a key.
I think that HSTS is an overkill.

I updated XSLT stylesheet that is used to generate the tomcat.apache.org site
so that all links to *.cgi pages are automatically updated to use
https://tomcat.apache.org.

I also updated the links to archive.apache.org, blogs.apache.org,
wiki.apache.org
and ASF fundraising & sponsorship pages to use https.


Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org