Am 13.10.25 um 19:43 schrieb James H. H. Lampert:
On 10/13/25 9:02 AM, Olaf Kock wrote:
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.
...
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.
You have almost no chance to screw it up (provided you use standard
ports 80 and 443):
* As you say in your initial message, you're not serving any http
traffic anyway, so there can't be anything hidden that needs to be
served through http instead of https
* The most you can do is to force browsers to replace any http with
https in any links (or in user input). And that already works for you
* If you screw something up, it'll be because you suddenly stop serving
https. Which, these days, would trigger all kind of browser warnings and
render your site unusable anyway. HSTS is /not/ tied to any certificate.
It's literally just the single "s" that's added to URLs. The rest of the
handling is 100% standard no matter any HSTS setting
* if you don't use the "includeSubdomains" option, there's no impact
outside of the current host name
* And if you are still fearful: /You/ are in control of the duration
that is flagged to the browser. I typically set it to 1 year (if I
remember correctly: in seconds), but you can certainly start with
testing it for 1 hour or 1 day. Not too useful in practice, but good for
testing the impact.
Yes, other configuration options can be much more impactful. But if you
don't serve https these days, you're screwed to begin with. So there is,
IMHO, no risk to enforce it.
Best,
Olaf
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
