On 10/13/25 9:02 AM, Olaf Kock wrote:
Do you have any question about this, that is missing in your original post?
HSTS can still help you, as even in case of a breach, or a MITM attack,
no browser (that has seen your site's HSTS header before) will ever even
try to access port 80, but automatically rewrite URLs to https.
The only drawback (if I remember correctly) is that it doesn't play
well with non-default ports, e.g. 8080, if it's exposed publically.
Thanks. Basically, when the subject first came up (late Friday
afternoon), I took a brief look through the docs, but really didn't get
a whole lot of practical information. (As it stands, with the
anti-clickjacking parameters, I'm only doing what our web development
team said to do, and they're currently hip-deep in other projects that
I'd rather not interrupt).
One of the things that scares me the most about this is that I got the
impression that browsers will remember that a site has HSTS turned on,
even if it's subsequently turned off, making it difficult to "unscrew"
something that is screwed up.
The most convenient "guinea pig" Tomcat server (because it isn't
normally used for anything else) would make a lousy candidate for
testing this functionality with our webapps, because (as a guinea pig
environment) its cert is long out-of-date (among other things),
requiring me to override several browser complaints. And the only other
one suitable for use as a guinea pig isn't doing its own HTTPS; it's
sitting behind something else (not sure whether it's the httpd server on
the same box, or something between the box and the rest of the world)
that's doing it.
So it should come as no surprise that I'm reluctant to do anything with
it, without a lot of guidance, in case it breaks our webapp (using the
wrong anti-clickjacking parameters will do that), and breaks it in a way
that might have lasting effects that would be difficult to undo.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
