You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID> on 2023/09/11 16:30:43 UTC
Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Ladies and Gentlemen of Both Lists:
Last Friday evening, I ran into a problem updating SSL/TLS keystores on
two customer boxes, and spent three hours yesterday, finding the cause,
doping out a way to salvage the certs they'd paid for, and doping out a
solution to keep it from happening in the future.
It seems that with the new keystores (generated on my Mac, initially
created with Keytool, and then maintained with Keystore Explorer), they
were getting:
> Throwable occurred: java.io.IOException: Invalid keystore format
> at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> at java.security.KeyStore.load(KeyStore.java:414)
I put them back on their old keystores, and cycled Tomcat again, to get
them back up, and then spent three hours working the problem yesterday
(Sunday) afternoon.
It turns out that the default keytool on my new Mac is the one from Java
17. And the customer boxes are running Tomcat under much older JVMs,
because there's always a significant time lag before any given JVM makes
it to an IBM Midrange box.
So I was able to salvage one of the certs (and its CA reply, and its
chain) by moving the cert to a keystore generated on my *old* Mac (with
Java 8 as the default JVM), and then re-signing and re-chaining it in
KSE. And I tested the KS on our V6 box, to make *sure* it worked.
I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just
not the default), to conveniently use that JVM's Keytool, and came up
with a wrapper BASH script to do the job. I tested the wrapper script by
using it to generate their new keystore.
Key takeaway (no pun intended) here: if you get an "Invalid keystore
format" in Tomcat (or presumably anything else that uses Java
Keystores), when generating a keystore on one box for use on another,
*look for a difference in JVM.*
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Michael Osipov <mi...@apache.org>.
On 2023/09/12 07:06:52 "Thomas Hoffmann (Speed4Trade GmbH)" wrote:
> Hallo James,
>
> > -----Ursprüngliche Nachricht-----
> > Von: James H. H. Lampert <ja...@touchtonecorp.com.INVALID>
> > Gesendet: Montag, 11. September 2023 18:31
> > An: Java 400 List <ja...@lists.midrange.com>; Tomcat Users List
> > <us...@tomcat.apache.org>
> > Betreff: Solution to "Invalid keystore format" (cross-posted to Tomcat Users
> > List at Apache, and Java 400 List at Midrange)
> >
> > Ladies and Gentlemen of Both Lists:
> >
> > Last Friday evening, I ran into a problem updating SSL/TLS keystores on two
> > customer boxes, and spent three hours yesterday, finding the cause, doping
> > out a way to salvage the certs they'd paid for, and doping out a solution to
> > keep it from happening in the future.
> >
> > It seems that with the new keystores (generated on my Mac, initially created
> > with Keytool, and then maintained with Keystore Explorer), they were
> > getting:
> >
> > > Throwable occurred: java.io.IOException: Invalid keystore format
> > > at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> > > at java.security.KeyStore.load(KeyStore.java:414)
> >
> > I put them back on their old keystores, and cycled Tomcat again, to get them
> > back up, and then spent three hours working the problem yesterday
> > (Sunday) afternoon.
> >
> > It turns out that the default keytool on my new Mac is the one from Java 17.
> > And the customer boxes are running Tomcat under much older JVMs,
> > because there's always a significant time lag before any given JVM makes it
> > to an IBM Midrange box.
> >
> > So I was able to salvage one of the certs (and its CA reply, and its
> > chain) by moving the cert to a keystore generated on my *old* Mac (with
> > Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. And I
> > tested the KS on our V6 box, to make *sure* it worked.
> >
> > I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not
> > the default), to conveniently use that JVM's Keytool, and came up with a
> > wrapper BASH script to do the job. I tested the wrapper script by using it to
> > generate their new keystore.
> >
> > Key takeaway (no pun intended) here: if you get an "Invalid keystore
> > format" in Tomcat (or presumably anything else that uses Java Keystores),
> > when generating a keystore on one box for use on another, *look for a
> > difference in JVM.*
> >
> > --
> > JHHL
> >
>
> I moved away from using the proprietary java keystore format.
> I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer.
> No need to convert it into Java format any more and you can also open it with any text editor.
This is exactly the same what I have been doing for the past 10 years. No pointless fiddling with Java keystores.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello,
> -----Ursprüngliche Nachricht-----
> Von: Shawn Heisey <ap...@elyograg.org>
> Gesendet: Mittwoch, 13. September 2023 15:00
> An: users@tomcat.apache.org
> Betreff: Re: AW: Solution to "Invalid keystore format" (cross-posted to
> Tomcat Users List at Apache, and Java 400 List at Midrange)
>
> On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > I moved away from using the proprietary java keystore format.
> > I switched to using Base64 PEM format. This is usually also the format you
> get from the certificate issuer.
> > No need to convert it into Java format any more and you can also open it
> with any text editor.
>
> I have never been able to get a Java program to accept a certificate/key in
> PEM format. The closest I've been able to come is creating a PKCS12 file with
> openssl. Annoying because all the other software I use accepts PEM with no
> problem, and as you have said, PEM is the format generally produced by a
> CA.
>
> How did you get it to take a PEM cert?
>
> Thanks,
> Shawn
>
If you want to use it for SSL / https, my server.xml snippet looks like:
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
....
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
<SSLHostConfig ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
disableSessionTickets="true"
honorCipherOrder="false"
protocols="+TLSv1.2,+TLSv1.3">
<Certificate certificateKeyFile="<pathto>\localhost.key"
certificateFile="<pathto>\localhost.pem"
type="RSA" />
</SSLHostConfig>
</Connector>
Greetings, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Brian,
On 9/13/23 23:25, Brian Wolfe wrote:
> The PKCS12 is the industry standard keystore format. Your mac should be
> creating it in that version. You should get familiar using the pkcs12. Its
> not difficult to set it up. keytool and openssl support pkcs12 and have for
> some time now. Its possible your older keystores are of the storetype JKS
> or JCEKS, JKS used to be the default I think back in Java 6. Anything newer
> should throw a warning telling you the industry standard is pkcs12. But you
> can still open older formats by specifying the "--storetype" option. Your
> getting that error because you probably didn't tell it what kind it is and
> its default assumption is wrong.
>
> Using a keystore is much better for managing your keys than using PEM
> files.
Why?
> It's best practice to have seperate stores for keys and for trust.
+1, and using files in PEM format do not preclude this.
> by default java has the "cacerts" file for establishing trust.
True, but not terribly relevant.
-chris
> On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert
> <ja...@touchtonecorp.com.invalid> wrote:
>
>> Java Keystores work. And I don't find them especially difficult to work
>> with (other than new formats not being backward-compatible with older
>> JVMs, and as one who has made a comfortable living banging out code for
>> IBM Midrange boxes for over a quarter century, I am quite familiar with
>> a much worse variation on that theme, namely, unless you explicitly set
>> the TGTRLS parameter (and have the appropriate previous version compiler
>> installed, and don't need to go back more than it will let you), your
>> programs will not even *restore* onto a prior release system.
>>
>> And the one time I attempted to get anything other than a Java Keystore
>> to work in Tomcat, on an IBM Midrange box, I failed miserably.
>>
>> Putting shell-script wrappers around two different versions of keytool
>> on my work Mac, so that "keytool" launches the Java 8 version, and
>> "keytool-default" launches the default version (in the unlikely event
>> that I'd ever need it) was a relatively simple exercise.
>>
>> --
>> JHHL
>>
>> ---------------------------------------------------------------------
>> 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
AW: AW: HSTS on 401 / error pages
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello Shawn,
> -----Ursprüngliche Nachricht-----
> Von: Shawn Heisey <ap...@elyograg.org>
> Gesendet: Freitag, 15. September 2023 03:56
> An: Tomcat Users List <us...@tomcat.apache.org>
> Betreff: Re: AW: HSTS on 401 / error pages
>
> On 9/14/23 08:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Sorry, I thought removing all content and subject is sufficient. Maybe
> > the message-id header is used internally(?)
>
> TL;DR: technical details about message threading. Not about Tomcat.
>
> This is what happens when you reply to an existing message for a new topic
> rather than starting a brand new message:
>
> https://www.dropbox.com/scl/fi/6f6xqoj9ndznr1pwnluuk/bad-threading-
> tomcat-user.png?rlkey=q6385e4fqyd2ngp97qgj4bj3y&dl=0
>
> There are headers in the message that facilitate threading that you can't
> normally see. These are the relevant headers in the message you replied to:
>
> References: <9ebb0e5d-1794-92f6-9c9f-
> 47a235a4eb2b@touchtonecorp.com>
> <05...@speed4trade.com>
> <5f...@elyograg.org>
> <80...@apache.org>
> <40...@christopherschultz.net>
> <c6...@touchtonecorp.com>
> In-Reply-To: <c668d2c4-f475-5303-9cba-
> 802edd43815c@touchtonecorp.com>
> Message-ID:
>
> <CANQXucfXnysDtn1kmK320AF6uYjrp=nCnmCUVsjbK9zvELan1Q@mail.gmail
> .com>
>
> And these are the relevant headers in your reply:
>
> Message-ID: <62...@speed4trade.com>
> References: <9ebb0e5d-1794-92f6-9c9f-
> 47a235a4eb2b@touchtonecorp.com>
> <05...@speed4trade.com>
> <5f...@elyograg.org>
> <80...@apache.org>
> <40...@christopherschultz.net>
> <c6...@touchtonecorp.com>
>
> <CANQXucfXnysDtn1kmK320AF6uYjrp=nCnmCUVsjbK9zvELan1Q@mail.gmail
> .com>
> In-Reply-To:
>
> <CANQXucfXnysDtn1kmK320AF6uYjrp=nCnmCUVsjbK9zvELan1Q@mail.gmail
> .com>
>
> While some mail clients will create threads on the message subject, these
> headers are the strictly correct way to show threads. We also see messages
> where people send a reply to a thread by writing a new message with the
> same subject. Clients that do threading properly will not show those
> messages as part of the thread.
>
> Thanks,
> Shawn
>
>
Thanks for your explanation and I see that pressing "reply" causes issues.
I already assumed that the mail headers are related to this.
I will stick to "new message" in future!
Have a nice day!
Thomas
Re: AW: HSTS on 401 / error pages
Posted by Shawn Heisey <ap...@elyograg.org>.
On 9/14/23 08:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Sorry, I thought removing all content and subject is sufficient. Maybe the message-id header is used internally(?)
TL;DR: technical details about message threading. Not about Tomcat.
This is what happens when you reply to an existing message for a new
topic rather than starting a brand new message:
https://www.dropbox.com/scl/fi/6f6xqoj9ndznr1pwnluuk/bad-threading-tomcat-user.png?rlkey=q6385e4fqyd2ngp97qgj4bj3y&dl=0
There are headers in the message that facilitate threading that you
can't normally see. These are the relevant headers in the message you
replied to:
References: <9e...@touchtonecorp.com>
<05...@speed4trade.com>
<5f...@elyograg.org>
<80...@apache.org>
<40...@christopherschultz.net>
<c6...@touchtonecorp.com>
In-Reply-To: <c6...@touchtonecorp.com>
Message-ID:
<CA...@mail.gmail.com>
And these are the relevant headers in your reply:
Message-ID: <62...@speed4trade.com>
References: <9e...@touchtonecorp.com>
<05...@speed4trade.com>
<5f...@elyograg.org>
<80...@apache.org>
<40...@christopherschultz.net>
<c6...@touchtonecorp.com>
<CA...@mail.gmail.com>
In-Reply-To:
<CA...@mail.gmail.com>
While some mail clients will create threads on the message subject,
these headers are the strictly correct way to show threads. We also see
messages where people send a reply to a thread by writing a new message
with the same subject. Clients that do threading properly will not show
those messages as part of the thread.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: HSTS on 401 / error pages
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello,
thanks for all your suggestions and input and also Chris for digging into the underlying reason.
As tomcat is running standalone I think I will leave it as it is.
Setting up a reverse proxy or containerization for this reason sounds like overdoing it in this case.
I will take it as a "cosmetic imperfection" and maybe ask also the burpsuite-team if this finding is justified.
I wish all a nice weekend!
Thomas
> -----Ursprüngliche Nachricht-----
> Von: Roberto Benedetti <ro...@dedalus.eu>
> Gesendet: Samstag, 16. September 2023 11:46
> An: Tomcat Users List <us...@tomcat.apache.org>
> Betreff: R: HSTS on 401 / error pages
>
> If you have a fronting reverse proxy/load balancer (HAProxy, NGINX,
> Apache) you can use them to set HSTS and let Tomcat set the other security
> headers.
> If your application is running in a container (Kubernetes, Openshift, OKD),
> they all have the option to add HSTS in Ingress/Route. Again, the other
> security options are left to Tomcat.
>
> We had the same issue and that's how we passed the pen-test.
>
> Roberto
>
> -----Messaggio originale-----
> Da: Peter Kreuser <lo...@kreuser.name>
> Inviato: venerdì 15 settembre 2023 21:34
> A: Tomcat Users List <us...@tomcat.apache.org>
> Oggetto: Re: HSTS on 401 / error pages
>
> CAUTION - This e-mail originates outside of Dedalus. Be vigilant with
> content, links and attachments!
>
> d) !!!
>
> BTW: HSTS needs to be evaluated only once and then sticks in the browser!
> So unless the 401 is the first page ever, this change would not be really
> necessary.
>
> Peter
>
> > Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH)
> <Th...@speed4trade.com.invalid>:
> >
> > Hello Christ,
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Christopher Schultz <ch...@christopherschultz.net>
> >> Gesendet: Freitag, 15. September 2023 17:15
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: HSTS on 401 / error pages
> >>
> >> Thomas,
> >>
> >>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello Chris,
> >>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: Christopher Schultz <ch...@christopherschultz.net>
> >>>> Gesendet: Donnerstag, 14. September 2023 15:26
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: HSTS on 401 / error pages
> >>>>
> >>>> Thomas,
> >>>>
> >>>> Please start a new thread next time.
> >>>
> >>> Sorry, I thought removing all content and subject is sufficient.
> >>> Maybe the message-id header is used internally(?)
> >>
> >> Absolutely. That's what "reply" does on a mailing list...
> >>
> >>>
> >>>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>>> Hello everyone,
> >>>>>
> >>>>> I would like to get your opinion about the
> >>>>> HttpHeaderSecurityFilter in
> >>>> Tomcat.
> >>>>> I configured HSTS in Tomcat and it works well.
> >>>>> When I do a pen-test with burpsuite it complains that HSTS header
> >>>>> is
> >>>> missing on 401 responses.
> >>>>> I couldn’t find much information about whether HSTS makes sense
> >>>>> for
> >>>> error pages.
> >>>>>
> >>>>> It seems that Tomcat doesn’t send HSTS on 401 pages but
> >>>>> burpsuite
> >>>> expects the header.
> >>>>> Are there any pros and cons about sending HSTS on 401 response?
> >>>>
> >>>> You should always return an HSTS header.
> >>>>
> >>>> How have you configured your HttpHeaderSecurityFilter? What is
> >>>> causing the
> >>>> 401 response? Which application is responding with that status?
> >>>>
> >>>> -chris
> >>>>
> >>>
> >>> Here are the requested details:
> >>>
> >>> SecurityFilter is set in the web.xml of the application:
> >>> <filter>
> >>> <filter-name>httpHeaderSecurity</filter-name>
> >>> <filter-
> >> class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-cl
> >> class>ass>
> >>> <async-supported>true</async-supported>
> >>> <init-param>
> >>> <param-name>hstsEnabled</param-name>
> >>> <param-value>true</param-value>
> >>> </init-param>
> >>> ...
> >>>
> >>> Further down in the web.xml is a constraint:
> >>> <security-constraint>
> >>> <web-resource-collection>
> >>> <web-resource-name>xxx</web-resource-name>
> >>> <url-pattern>/*</url-pattern>
> >>> </web-resource-collection>
> >>>
> >>> <auth-constraint>
> >>> <role-name>yyy</role-name>
> >>> </auth-constraint>
> >>>
> >>> <user-data-constraint>
> >>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> >>> </user-data-constraint>
> >>> </security-constraint>
> >>>
> >>>
> >>> There is no frontend-server, tomcat is directly accessed from the
> browser.
> >>> It seems that burpsuite didn’t send authentication in the first
> >>> place and this
> >> resulted in 401.
> >>>
> >>> If I use curl https://<domain>/ I get similar result:
> >>> < HTTP/1.1 401
> >>> < WWW-Authenticate: Negotiate
> >>> < Content-Type: text/html;charset=utf-8 < Content-Language: de <
> >>> Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
> >>>
> >>> When providing credentials to curl, the following headers are also
> included:
> >>> < Strict-Transport-Security: max-age=31536000;includeSubDomains
> >>> < X-Frame-Options: DENY
> >>> < X-Content-Type-Options: nosniff
> >>> < X-XSS-Protection: 1; mode=block
> >>>
> >>> I hope this information helps.
> >>
> >> Authentication is checked before any filters run, because
> >> authentication is performed by a Valve, all of which run before any Filters
> run.
> >>
> >> I'm not sure there is a way around this without
> >>
> >> a. Using a fronting server of some kind b. Getting a change of some
> >> kind made to Tomcat c. Hacking this yourself
> >>
> >> (b) is probably the best option, though I'm not sure what the best
> >> form of server-support for this would be.
> >>
> >> Making HttpHeaderSecurity available in a Valve-packaging would do the
> >> trick, but maybe this makes sense to add at a more fundamental level to
> Tomcat.
> >> The problem is that HSTS is only one of many security-related headers
> >> and maybe it's potential lifetime isn't that long. My guess is that
> >> sometime in the near future, TLS will simply be required for all web
> >> traffic. If we bake that kind of thing into core-Tomcat, it becomes
> >> something we will need to un- bake in the future, and chefs can tell
> >> you that un-baking things rarely works out well.
> >>
> >> -chris
> >>
> >> ---------------------------------------------------------------------
> >
> > Thanks for your elaboration!
> > The security headers change from time to time, true.
> > Maybe it would be possible to provide a kind of "http-header-valve" which
> can be configured which headers to add?
> > Then you wouldn’t have a tight coupling and when headers change, you
> can adjust the configuration without changing code.
> > It would not be as comfortable as the HttpHeaderSecurityFilter but more
> flexible.
> >
> > Option d) would be to ignore the reported finding of the pen-testing
> > tool 😉
> >
> > Greetings,
> > Thomas
> >
> >
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KKKKKKKKKKK
> > KCB•È [œÝXœØÜšX™KK[XZ[
> ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ]
> > ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[
> ˆ \Ù\œËZ[ ÛXØ]
> > ˜\XÚK›Ü™ÃBƒ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> B
> KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KKKKKKKKKKCB [ X ܚX KK[XZ[
>
> \ \ ][ X ܚX P X ]
> \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
>
> \ \ Z[ X ]
> \X K ܙ B
R: HSTS on 401 / error pages
Posted by Roberto Benedetti <ro...@dedalus.eu>.
If you have a fronting reverse proxy/load balancer (HAProxy, NGINX, Apache) you can use them to set HSTS and let Tomcat set the other security headers.
If your application is running in a container (Kubernetes, Openshift, OKD), they all have the option to add HSTS in Ingress/Route. Again, the other security options are left to Tomcat.
We had the same issue and that's how we passed the pen-test.
Roberto
-----Messaggio originale-----
Da: Peter Kreuser <lo...@kreuser.name>
Inviato: venerdì 15 settembre 2023 21:34
A: Tomcat Users List <us...@tomcat.apache.org>
Oggetto: Re: HSTS on 401 / error pages
CAUTION - This e-mail originates outside of Dedalus. Be vigilant with content, links and attachments!
d) !!!
BTW: HSTS needs to be evaluated only once and then sticks in the browser!
So unless the 401 is the first page ever, this change would not be really necessary.
Peter
> Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.invalid>:
>
> Hello Christ,
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Schultz <ch...@christopherschultz.net>
>> Gesendet: Freitag, 15. September 2023 17:15
>> An: users@tomcat.apache.org
>> Betreff: Re: AW: HSTS on 401 / error pages
>>
>> Thomas,
>>
>>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello Chris,
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Christopher Schultz <ch...@christopherschultz.net>
>>>> Gesendet: Donnerstag, 14. September 2023 15:26
>>>> An: users@tomcat.apache.org
>>>> Betreff: Re: HSTS on 401 / error pages
>>>>
>>>> Thomas,
>>>>
>>>> Please start a new thread next time.
>>>
>>> Sorry, I thought removing all content and subject is sufficient.
>>> Maybe the message-id header is used internally(?)
>>
>> Absolutely. That's what "reply" does on a mailing list...
>>
>>>
>>>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I would like to get your opinion about the
>>>>> HttpHeaderSecurityFilter in
>>>> Tomcat.
>>>>> I configured HSTS in Tomcat and it works well.
>>>>> When I do a pen-test with burpsuite it complains that HSTS header
>>>>> is
>>>> missing on 401 responses.
>>>>> I couldn’t find much information about whether HSTS makes sense
>>>>> for
>>>> error pages.
>>>>>
>>>>> It seems that Tomcat doesn’t send HSTS on 401 pages but
>>>>> burpsuite
>>>> expects the header.
>>>>> Are there any pros and cons about sending HSTS on 401 response?
>>>>
>>>> You should always return an HSTS header.
>>>>
>>>> How have you configured your HttpHeaderSecurityFilter? What is
>>>> causing the
>>>> 401 response? Which application is responding with that status?
>>>>
>>>> -chris
>>>>
>>>
>>> Here are the requested details:
>>>
>>> SecurityFilter is set in the web.xml of the application:
>>> <filter>
>>> <filter-name>httpHeaderSecurity</filter-name>
>>> <filter-
>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-cl
>> class>ass>
>>> <async-supported>true</async-supported>
>>> <init-param>
>>> <param-name>hstsEnabled</param-name>
>>> <param-value>true</param-value>
>>> </init-param>
>>> ...
>>>
>>> Further down in the web.xml is a constraint:
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>xxx</web-resource-name>
>>> <url-pattern>/*</url-pattern>
>>> </web-resource-collection>
>>>
>>> <auth-constraint>
>>> <role-name>yyy</role-name>
>>> </auth-constraint>
>>>
>>> <user-data-constraint>
>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>> </user-data-constraint>
>>> </security-constraint>
>>>
>>>
>>> There is no frontend-server, tomcat is directly accessed from the browser.
>>> It seems that burpsuite didn’t send authentication in the first
>>> place and this
>> resulted in 401.
>>>
>>> If I use curl https://<domain>/ I get similar result:
>>> < HTTP/1.1 401
>>> < WWW-Authenticate: Negotiate
>>> < Content-Type: text/html;charset=utf-8 < Content-Language: de <
>>> Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
>>>
>>> When providing credentials to curl, the following headers are also included:
>>> < Strict-Transport-Security: max-age=31536000;includeSubDomains
>>> < X-Frame-Options: DENY
>>> < X-Content-Type-Options: nosniff
>>> < X-XSS-Protection: 1; mode=block
>>>
>>> I hope this information helps.
>>
>> Authentication is checked before any filters run, because
>> authentication is performed by a Valve, all of which run before any Filters run.
>>
>> I'm not sure there is a way around this without
>>
>> a. Using a fronting server of some kind b. Getting a change of some
>> kind made to Tomcat c. Hacking this yourself
>>
>> (b) is probably the best option, though I'm not sure what the best
>> form of server-support for this would be.
>>
>> Making HttpHeaderSecurity available in a Valve-packaging would do the
>> trick, but maybe this makes sense to add at a more fundamental level to Tomcat.
>> The problem is that HSTS is only one of many security-related headers
>> and maybe it's potential lifetime isn't that long. My guess is that
>> sometime in the near future, TLS will simply be required for all web
>> traffic. If we bake that kind of thing into core-Tomcat, it becomes
>> something we will need to un- bake in the future, and chefs can tell
>> you that un-baking things rarely works out well.
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>
> Thanks for your elaboration!
> The security headers change from time to time, true.
> Maybe it would be possible to provide a kind of "http-header-valve" which can be configured which headers to add?
> Then you wouldn’t have a tight coupling and when headers change, you can adjust the configuration without changing code.
> It would not be as comfortable as the HttpHeaderSecurityFilter but more flexible.
>
> Option d) would be to ignore the reported finding of the pen-testing
> tool 😉
>
> Greetings,
> Thomas
>
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KCB•È [œÝXœØÜšX™KK[XZ[
ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ]
> ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[
ˆ \Ù\œËZ[ ÛXØ]
> ˜\XÚK›Ü™ÃBƒ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HSTS on 401 / error pages
Posted by Peter Kreuser <lo...@kreuser.name>.
d) !!!
BTW: HSTS needs to be evaluated only once and then sticks in the browser!
So unless the 401 is the first page ever, this change would not be really necessary.
Peter
> Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.invalid>:
>
> Hello Christ,
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Schultz <ch...@christopherschultz.net>
>> Gesendet: Freitag, 15. September 2023 17:15
>> An: users@tomcat.apache.org
>> Betreff: Re: AW: HSTS on 401 / error pages
>>
>> Thomas,
>>
>>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello Chris,
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Christopher Schultz <ch...@christopherschultz.net>
>>>> Gesendet: Donnerstag, 14. September 2023 15:26
>>>> An: users@tomcat.apache.org
>>>> Betreff: Re: HSTS on 401 / error pages
>>>>
>>>> Thomas,
>>>>
>>>> Please start a new thread next time.
>>>
>>> Sorry, I thought removing all content and subject is sufficient. Maybe
>>> the message-id header is used internally(?)
>>
>> Absolutely. That's what "reply" does on a mailing list...
>>
>>>
>>>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I would like to get your opinion about the HttpHeaderSecurityFilter
>>>>> in
>>>> Tomcat.
>>>>> I configured HSTS in Tomcat and it works well.
>>>>> When I do a pen-test with burpsuite it complains that HSTS header is
>>>> missing on 401 responses.
>>>>> I couldn’t find much information about whether HSTS makes sense for
>>>> error pages.
>>>>>
>>>>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
>>>> expects the header.
>>>>> Are there any pros and cons about sending HSTS on 401 response?
>>>>
>>>> You should always return an HSTS header.
>>>>
>>>> How have you configured your HttpHeaderSecurityFilter? What is
>>>> causing the
>>>> 401 response? Which application is responding with that status?
>>>>
>>>> -chris
>>>>
>>>
>>> Here are the requested details:
>>>
>>> SecurityFilter is set in the web.xml of the application:
>>> <filter>
>>> <filter-name>httpHeaderSecurity</filter-name>
>>> <filter-
>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
>>> <async-supported>true</async-supported>
>>> <init-param>
>>> <param-name>hstsEnabled</param-name>
>>> <param-value>true</param-value>
>>> </init-param>
>>> ...
>>>
>>> Further down in the web.xml is a constraint:
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>xxx</web-resource-name>
>>> <url-pattern>/*</url-pattern>
>>> </web-resource-collection>
>>>
>>> <auth-constraint>
>>> <role-name>yyy</role-name>
>>> </auth-constraint>
>>>
>>> <user-data-constraint>
>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>> </user-data-constraint>
>>> </security-constraint>
>>>
>>>
>>> There is no frontend-server, tomcat is directly accessed from the browser.
>>> It seems that burpsuite didn’t send authentication in the first place and this
>> resulted in 401.
>>>
>>> If I use curl https://<domain>/ I get similar result:
>>> < HTTP/1.1 401
>>> < WWW-Authenticate: Negotiate
>>> < Content-Type: text/html;charset=utf-8 < Content-Language: de <
>>> Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
>>>
>>> When providing credentials to curl, the following headers are also included:
>>> < Strict-Transport-Security: max-age=31536000;includeSubDomains
>>> < X-Frame-Options: DENY
>>> < X-Content-Type-Options: nosniff
>>> < X-XSS-Protection: 1; mode=block
>>>
>>> I hope this information helps.
>>
>> Authentication is checked before any filters run, because authentication is
>> performed by a Valve, all of which run before any Filters run.
>>
>> I'm not sure there is a way around this without
>>
>> a. Using a fronting server of some kind
>> b. Getting a change of some kind made to Tomcat c. Hacking this yourself
>>
>> (b) is probably the best option, though I'm not sure what the best form of
>> server-support for this would be.
>>
>> Making HttpHeaderSecurity available in a Valve-packaging would do the trick,
>> but maybe this makes sense to add at a more fundamental level to Tomcat.
>> The problem is that HSTS is only one of many security-related headers and
>> maybe it's potential lifetime isn't that long. My guess is that sometime in the
>> near future, TLS will simply be required for all web traffic. If we bake that
>> kind of thing into core-Tomcat, it becomes something we will need to un-
>> bake in the future, and chefs can tell you that un-baking things rarely works
>> out well.
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>
> Thanks for your elaboration!
> The security headers change from time to time, true.
> Maybe it would be possible to provide a kind of "http-header-valve" which can be configured which headers to add?
> Then you wouldn’t have a tight coupling and when headers change, you can adjust the configuration without changing code.
> It would not be as comfortable as the HttpHeaderSecurityFilter but more flexible.
>
> Option d) would be to ignore the reported finding of the pen-testing tool 😉
>
> Greetings,
> Thomas
>
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ] ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ \Ù\œËZ[ ÛXØ] ˜\XÚK›Ü™ÃBƒ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: AW: HSTS on 401 / error pages
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello Christ,
> -----Ursprüngliche Nachricht-----
> Von: Christopher Schultz <ch...@christopherschultz.net>
> Gesendet: Freitag, 15. September 2023 17:15
> An: users@tomcat.apache.org
> Betreff: Re: AW: HSTS on 401 / error pages
>
> Thomas,
>
> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Chris,
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Christopher Schultz <ch...@christopherschultz.net>
> >> Gesendet: Donnerstag, 14. September 2023 15:26
> >> An: users@tomcat.apache.org
> >> Betreff: Re: HSTS on 401 / error pages
> >>
> >> Thomas,
> >>
> >> Please start a new thread next time.
> >
> > Sorry, I thought removing all content and subject is sufficient. Maybe
> > the message-id header is used internally(?)
>
> Absolutely. That's what "reply" does on a mailing list...
>
> >
> >> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello everyone,
> >>>
> >>> I would like to get your opinion about the HttpHeaderSecurityFilter
> >>> in
> >> Tomcat.
> >>> I configured HSTS in Tomcat and it works well.
> >>> When I do a pen-test with burpsuite it complains that HSTS header is
> >> missing on 401 responses.
> >>> I couldn’t find much information about whether HSTS makes sense for
> >> error pages.
> >>>
> >>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
> >> expects the header.
> >>> Are there any pros and cons about sending HSTS on 401 response?
> >>
> >> You should always return an HSTS header.
> >>
> >> How have you configured your HttpHeaderSecurityFilter? What is
> >> causing the
> >> 401 response? Which application is responding with that status?
> >>
> >> -chris
> >>
> >
> > Here are the requested details:
> >
> > SecurityFilter is set in the web.xml of the application:
> > <filter>
> > <filter-name>httpHeaderSecurity</filter-name>
> > <filter-
> class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> > <async-supported>true</async-supported>
> > <init-param>
> > <param-name>hstsEnabled</param-name>
> > <param-value>true</param-value>
> > </init-param>
> > ...
> >
> > Further down in the web.xml is a constraint:
> > <security-constraint>
> > <web-resource-collection>
> > <web-resource-name>xxx</web-resource-name>
> > <url-pattern>/*</url-pattern>
> > </web-resource-collection>
> >
> > <auth-constraint>
> > <role-name>yyy</role-name>
> > </auth-constraint>
> >
> > <user-data-constraint>
> > <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> > </user-data-constraint>
> > </security-constraint>
> >
> >
> > There is no frontend-server, tomcat is directly accessed from the browser.
> > It seems that burpsuite didn’t send authentication in the first place and this
> resulted in 401.
> >
> > If I use curl https://<domain>/ I get similar result:
> > < HTTP/1.1 401
> > < WWW-Authenticate: Negotiate
> > < Content-Type: text/html;charset=utf-8 < Content-Language: de <
> > Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
> >
> > When providing credentials to curl, the following headers are also included:
> > < Strict-Transport-Security: max-age=31536000;includeSubDomains
> > < X-Frame-Options: DENY
> > < X-Content-Type-Options: nosniff
> > < X-XSS-Protection: 1; mode=block
> >
> > I hope this information helps.
>
> Authentication is checked before any filters run, because authentication is
> performed by a Valve, all of which run before any Filters run.
>
> I'm not sure there is a way around this without
>
> a. Using a fronting server of some kind
> b. Getting a change of some kind made to Tomcat c. Hacking this yourself
>
> (b) is probably the best option, though I'm not sure what the best form of
> server-support for this would be.
>
> Making HttpHeaderSecurity available in a Valve-packaging would do the trick,
> but maybe this makes sense to add at a more fundamental level to Tomcat.
> The problem is that HSTS is only one of many security-related headers and
> maybe it's potential lifetime isn't that long. My guess is that sometime in the
> near future, TLS will simply be required for all web traffic. If we bake that
> kind of thing into core-Tomcat, it becomes something we will need to un-
> bake in the future, and chefs can tell you that un-baking things rarely works
> out well.
>
> -chris
>
> ---------------------------------------------------------------------
Thanks for your elaboration!
The security headers change from time to time, true.
Maybe it would be possible to provide a kind of "http-header-valve" which can be configured which headers to add?
Then you wouldn’t have a tight coupling and when headers change, you can adjust the configuration without changing code.
It would not be as comfortable as the HttpHeaderSecurityFilter but more flexible.
Option d) would be to ignore the reported finding of the pen-testing tool 😉
Greetings,
Thomas
Re: AW: HSTS on 401 / error pages
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Thomas,
On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello Chris,
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Schultz <ch...@christopherschultz.net>
>> Gesendet: Donnerstag, 14. September 2023 15:26
>> An: users@tomcat.apache.org
>> Betreff: Re: HSTS on 401 / error pages
>>
>> Thomas,
>>
>> Please start a new thread next time.
>
> Sorry, I thought removing all content and subject is sufficient. Maybe the message-id header is used internally(?)
Absolutely. That's what "reply" does on a mailing list...
>
>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello everyone,
>>>
>>> I would like to get your opinion about the HttpHeaderSecurityFilter in
>> Tomcat.
>>> I configured HSTS in Tomcat and it works well.
>>> When I do a pen-test with burpsuite it complains that HSTS header is
>> missing on 401 responses.
>>> I couldn’t find much information about whether HSTS makes sense for
>> error pages.
>>>
>>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
>> expects the header.
>>> Are there any pros and cons about sending HSTS on 401 response?
>>
>> You should always return an HSTS header.
>>
>> How have you configured your HttpHeaderSecurityFilter? What is causing the
>> 401 response? Which application is responding with that status?
>>
>> -chris
>>
>
> Here are the requested details:
>
> SecurityFilter is set in the web.xml of the application:
> <filter>
> <filter-name>httpHeaderSecurity</filter-name>
> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> <async-supported>true</async-supported>
> <init-param>
> <param-name>hstsEnabled</param-name>
> <param-value>true</param-value>
> </init-param>
> ...
>
> Further down in the web.xml is a constraint:
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>xxx</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
>
> <auth-constraint>
> <role-name>yyy</role-name>
> </auth-constraint>
>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
>
> There is no frontend-server, tomcat is directly accessed from the browser.
> It seems that burpsuite didn’t send authentication in the first place and this resulted in 401.
>
> If I use curl https://<domain>/ I get similar result:
> < HTTP/1.1 401
> < WWW-Authenticate: Negotiate
> < Content-Type: text/html;charset=utf-8
> < Content-Language: de
> < Content-Length: 439
> < Date: Thu, 14 Sep 2023 13:58:10 GMT
>
> When providing credentials to curl, the following headers are also included:
> < Strict-Transport-Security: max-age=31536000;includeSubDomains
> < X-Frame-Options: DENY
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
>
> I hope this information helps.
Authentication is checked before any filters run, because authentication
is performed by a Valve, all of which run before any Filters run.
I'm not sure there is a way around this without
a. Using a fronting server of some kind
b. Getting a change of some kind made to Tomcat
c. Hacking this yourself
(b) is probably the best option, though I'm not sure what the best form
of server-support for this would be.
Making HttpHeaderSecurity available in a Valve-packaging would do the
trick, but maybe this makes sense to add at a more fundamental level to
Tomcat. The problem is that HSTS is only one of many security-related
headers and maybe it's potential lifetime isn't that long. My guess is
that sometime in the near future, TLS will simply be required for all
web traffic. If we bake that kind of thing into core-Tomcat, it becomes
something we will need to un-bake in the future, and chefs can tell you
that un-baking things rarely works out well.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HSTS on 401 / error pages
Posted by lo...@kreuser.name.
Chris,
this is what's happening with the globally configured HttpHeaderSecurityFilter:
curl -ik "https://localhost:8443/manager/"
HTTP/2 302
x-frame-options: DENY
x-content-type-options: nosniff
strict-transport-security: max-age=31536000
x-xss-protection: 1; mode=block
location: /manager/html
content-type: text/html
content-length: 0
date: Thu, 14 Sep 2023 20:31:50 GMT
curl -ik "https://localhost:8443/manager/html/"
HTTP/2 401
cache-control: private
www-authenticate: Basic realm="Tomcat Manager Application"
vary: accept-encoding
content-type: text/html;charset=ISO-8859-1
content-length: 2499
date: Thu, 14 Sep 2023 20:32:00 GMT
curl -ik "https://localhost:8443/xxx"
HTTP/2 404
strict-transport-security: max-age=31536000
x-frame-options: DENY
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
content-type: text/html;charset=utf-8
content-language: en
content-length: 41
date: Thu, 14 Sep 2023 20:31:35
I assume it's the order of the filters? Authentication before HeaderSecurity maybe? It's not HSTS only....
What do you think?
Peter
> Am 14.09.2023 um 16:03 schrieb Thomas Hoffmann (Speed4Trade GmbH) <Th...@speed4trade.com.INVALID>:
>
> Hello Chris,
>
>> -----Ursprüngliche Nachricht-----
>> Von: Christopher Schultz <ch...@christopherschultz.net>
>> Gesendet: Donnerstag, 14. September 2023 15:26
>> An: users@tomcat.apache.org
>> Betreff: Re: HSTS on 401 / error pages
>>
>> Thomas,
>>
>> Please start a new thread next time.
>
> Sorry, I thought removing all content and subject is sufficient. Maybe the message-id header is used internally(?)
>
>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> Hello everyone,
>>>
>>> I would like to get your opinion about the HttpHeaderSecurityFilter in
>> Tomcat.
>>> I configured HSTS in Tomcat and it works well.
>>> When I do a pen-test with burpsuite it complains that HSTS header is
>> missing on 401 responses.
>>> I couldn’t find much information about whether HSTS makes sense for
>> error pages.
>>>
>>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
>> expects the header.
>>> Are there any pros and cons about sending HSTS on 401 response?
>>
>> You should always return an HSTS header.
>>
>> How have you configured your HttpHeaderSecurityFilter? What is causing the
>> 401 response? Which application is responding with that status?
>>
>> -chris
>>
>
> Here are the requested details:
>
> SecurityFilter is set in the web.xml of the application:
> <filter>
> <filter-name>httpHeaderSecurity</filter-name>
> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
> <async-supported>true</async-supported>
> <init-param>
> <param-name>hstsEnabled</param-name>
> <param-value>true</param-value>
> </init-param>
> ...
>
> Further down in the web.xml is a constraint:
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>xxx</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
>
> <auth-constraint>
> <role-name>yyy</role-name>
> </auth-constraint>
>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
>
> There is no frontend-server, tomcat is directly accessed from the browser.
> It seems that burpsuite didn’t send authentication in the first place and this resulted in 401.
>
> If I use curl https://<domain>/ I get similar result:
> < HTTP/1.1 401
> < WWW-Authenticate: Negotiate
> < Content-Type: text/html;charset=utf-8
> < Content-Language: de
> < Content-Length: 439
> < Date: Thu, 14 Sep 2023 13:58:10 GMT
>
> When providing credentials to curl, the following headers are also included:
> < Strict-Transport-Security: max-age=31536000;includeSubDomains
> < X-Frame-Options: DENY
> < X-Content-Type-Options: nosniff
> < X-XSS-Protection: 1; mode=block
>
> I hope this information helps.
>
> Thanks in advance!
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
AW: HSTS on 401 / error pages
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello Chris,
> -----Ursprüngliche Nachricht-----
> Von: Christopher Schultz <ch...@christopherschultz.net>
> Gesendet: Donnerstag, 14. September 2023 15:26
> An: users@tomcat.apache.org
> Betreff: Re: HSTS on 401 / error pages
>
> Thomas,
>
> Please start a new thread next time.
Sorry, I thought removing all content and subject is sufficient. Maybe the message-id header is used internally(?)
> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello everyone,
> >
> > I would like to get your opinion about the HttpHeaderSecurityFilter in
> Tomcat.
> > I configured HSTS in Tomcat and it works well.
> > When I do a pen-test with burpsuite it complains that HSTS header is
> missing on 401 responses.
> > I couldn’t find much information about whether HSTS makes sense for
> error pages.
> >
> > It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
> expects the header.
> > Are there any pros and cons about sending HSTS on 401 response?
>
> You should always return an HSTS header.
>
> How have you configured your HttpHeaderSecurityFilter? What is causing the
> 401 response? Which application is responding with that status?
>
> -chris
>
Here are the requested details:
SecurityFilter is set in the web.xml of the application:
<filter>
<filter-name>httpHeaderSecurity</filter-name>
<filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>hstsEnabled</param-name>
<param-value>true</param-value>
</init-param>
...
Further down in the web.xml is a constraint:
<security-constraint>
<web-resource-collection>
<web-resource-name>xxx</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>yyy</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
There is no frontend-server, tomcat is directly accessed from the browser.
It seems that burpsuite didn’t send authentication in the first place and this resulted in 401.
If I use curl https://<domain>/ I get similar result:
< HTTP/1.1 401
< WWW-Authenticate: Negotiate
< Content-Type: text/html;charset=utf-8
< Content-Language: de
< Content-Length: 439
< Date: Thu, 14 Sep 2023 13:58:10 GMT
When providing credentials to curl, the following headers are also included:
< Strict-Transport-Security: max-age=31536000;includeSubDomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
I hope this information helps.
Thanks in advance!
Thomas
Re: HSTS on 401 / error pages
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Thomas,
Please start a new thread next time.
On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello everyone,
>
> I would like to get your opinion about the HttpHeaderSecurityFilter in Tomcat.
> I configured HSTS in Tomcat and it works well.
> When I do a pen-test with burpsuite it complains that HSTS header is missing on 401 responses.
> I couldn’t find much information about whether HSTS makes sense for error pages.
>
> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite expects the header.
> Are there any pros and cons about sending HSTS on 401 response?
You should always return an HSTS header.
How have you configured your HttpHeaderSecurityFilter? What is causing
the 401 response? Which application is responding with that status?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
HSTS on 401 / error pages
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hello everyone,
I would like to get your opinion about the HttpHeaderSecurityFilter in Tomcat.
I configured HSTS in Tomcat and it works well.
When I do a pen-test with burpsuite it complains that HSTS header is missing on 401 responses.
I couldn’t find much information about whether HSTS makes sense for error pages.
It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite expects the header.
Are there any pros and cons about sending HSTS on 401 response?
Thanks in advance!
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Brian Wolfe <wo...@gmail.com>.
The PKCS12 is the industry standard keystore format. Your mac should be
creating it in that version. You should get familiar using the pkcs12. Its
not difficult to set it up. keytool and openssl support pkcs12 and have for
some time now. Its possible your older keystores are of the storetype JKS
or JCEKS, JKS used to be the default I think back in Java 6. Anything newer
should throw a warning telling you the industry standard is pkcs12. But you
can still open older formats by specifying the "--storetype" option. Your
getting that error because you probably didn't tell it what kind it is and
its default assumption is wrong.
Using a keystore is much better for managing your keys than using PEM
files. It's best practice to have seperate stores for keys and for trust.
by default java has the "cacerts" file for establishing trust.
On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert
<ja...@touchtonecorp.com.invalid> wrote:
> Java Keystores work. And I don't find them especially difficult to work
> with (other than new formats not being backward-compatible with older
> JVMs, and as one who has made a comfortable living banging out code for
> IBM Midrange boxes for over a quarter century, I am quite familiar with
> a much worse variation on that theme, namely, unless you explicitly set
> the TGTRLS parameter (and have the appropriate previous version compiler
> installed, and don't need to go back more than it will let you), your
> programs will not even *restore* onto a prior release system.
>
> And the one time I attempted to get anything other than a Java Keystore
> to work in Tomcat, on an IBM Midrange box, I failed miserably.
>
> Putting shell-script wrappers around two different versions of keytool
> on my work Mac, so that "keytool" launches the Java 8 version, and
> "keytool-default" launches the default version (in the unlikely event
> that I'd ever need it) was a relatively simple exercise.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Thanks,
Brian Wolfe
https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
Java Keystores work. And I don't find them especially difficult to work
with (other than new formats not being backward-compatible with older
JVMs, and as one who has made a comfortable living banging out code for
IBM Midrange boxes for over a quarter century, I am quite familiar with
a much worse variation on that theme, namely, unless you explicitly set
the TGTRLS parameter (and have the appropriate previous version compiler
installed, and don't need to go back more than it will let you), your
programs will not even *restore* onto a prior release system.
And the one time I attempted to get anything other than a Java Keystore
to work in Tomcat, on an IBM Midrange box, I failed miserably.
Putting shell-script wrappers around two different versions of keytool
on my work Mac, so that "keytool" launches the Java 8 version, and
"keytool-default" launches the default version (in the unlikely event
that I'd ever need it) was a relatively simple exercise.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Shawn and Mark,
On 9/13/23 09:30, Mark Thomas wrote:
> On 13/09/2023 14:00, Shawn Heisey wrote:
>> On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>>> I moved away from using the proprietary java keystore format.
>>> I switched to using Base64 PEM format. This is usually also the
>>> format you get from the certificate issuer.
>>> No need to convert it into Java format any more and you can also open
>>> it with any text editor.
>>
>> I have never been able to get a Java program to accept a
>> certificate/key in PEM format. The closest I've been able to come is
>> creating a PKCS12 file with openssl. Annoying because all the other
>> software I use accepts PEM with no problem, and as you have said, PEM
>> is the format generally produced by a CA.
>>
>> How did you get it to take a PEM cert?
>
> Tomcat has supported this for a while. The bulk of th ecode can be found
> in:
>
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/jsse/PEMFile.java
I also have code on GitHub that is very similar.
https://github.com/ChristopherSchultz/pem-utils
The hard part is the wide variety of "private key" formats that are out
there in the wild. Reading a certificate in PEM format from Java is
pretty much a one-liner. But reading a private key in one of the many
possible formats, encodings, encryption strategies, etc. requires miles
and miles of code.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Mark Thomas <ma...@apache.org>.
On 13/09/2023 14:00, Shawn Heisey wrote:
> On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>> I moved away from using the proprietary java keystore format.
>> I switched to using Base64 PEM format. This is usually also the format
>> you get from the certificate issuer.
>> No need to convert it into Java format any more and you can also open
>> it with any text editor.
>
> I have never been able to get a Java program to accept a certificate/key
> in PEM format. The closest I've been able to come is creating a PKCS12
> file with openssl. Annoying because all the other software I use
> accepts PEM with no problem, and as you have said, PEM is the format
> generally produced by a CA.
>
> How did you get it to take a PEM cert?
Tomcat has supported this for a while. The bulk of th ecode can be found in:
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/jsse/PEMFile.java
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by Shawn Heisey <ap...@elyograg.org>.
On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> I moved away from using the proprietary java keystore format.
> I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer.
> No need to convert it into Java format any more and you can also open it with any text editor.
I have never been able to get a Java program to accept a certificate/key
in PEM format. The closest I've been able to come is creating a PKCS12
file with openssl. Annoying because all the other software I use
accepts PEM with no problem, and as you have said, PEM is the format
generally produced by a CA.
How did you get it to take a PEM cert?
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Posted by "Thomas Hoffmann (Speed4Trade GmbH)" <Th...@speed4trade.com.INVALID>.
Hallo James,
> -----Ursprüngliche Nachricht-----
> Von: James H. H. Lampert <ja...@touchtonecorp.com.INVALID>
> Gesendet: Montag, 11. September 2023 18:31
> An: Java 400 List <ja...@lists.midrange.com>; Tomcat Users List
> <us...@tomcat.apache.org>
> Betreff: Solution to "Invalid keystore format" (cross-posted to Tomcat Users
> List at Apache, and Java 400 List at Midrange)
>
> Ladies and Gentlemen of Both Lists:
>
> Last Friday evening, I ran into a problem updating SSL/TLS keystores on two
> customer boxes, and spent three hours yesterday, finding the cause, doping
> out a way to salvage the certs they'd paid for, and doping out a solution to
> keep it from happening in the future.
>
> It seems that with the new keystores (generated on my Mac, initially created
> with Keytool, and then maintained with Keystore Explorer), they were
> getting:
>
> > Throwable occurred: java.io.IOException: Invalid keystore format
> > at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> > at java.security.KeyStore.load(KeyStore.java:414)
>
> I put them back on their old keystores, and cycled Tomcat again, to get them
> back up, and then spent three hours working the problem yesterday
> (Sunday) afternoon.
>
> It turns out that the default keytool on my new Mac is the one from Java 17.
> And the customer boxes are running Tomcat under much older JVMs,
> because there's always a significant time lag before any given JVM makes it
> to an IBM Midrange box.
>
> So I was able to salvage one of the certs (and its CA reply, and its
> chain) by moving the cert to a keystore generated on my *old* Mac (with
> Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. And I
> tested the KS on our V6 box, to make *sure* it worked.
>
> I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not
> the default), to conveniently use that JVM's Keytool, and came up with a
> wrapper BASH script to do the job. I tested the wrapper script by using it to
> generate their new keystore.
>
> Key takeaway (no pun intended) here: if you get an "Invalid keystore
> format" in Tomcat (or presumably anything else that uses Java Keystores),
> when generating a keystore on one box for use on another, *look for a
> difference in JVM.*
>
> --
> JHHL
>
I moved away from using the proprietary java keystore format.
I switched to using Base64 PEM format. This is usually also the format you get from the certificate issuer.
No need to convert it into Java format any more and you can also open it with any text editor.
Greetings,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org