RE: [External] Re: SSL Handshake Failure - Logging Level
Thank you, Mark.
I agree changing the log level to error could cause problems you mentioned.
But option like logHandshakeFailuresAtError will be useful to
troubleshooting/debugging assuming DoS attacks are handled differently.
Thinking if this could be a connector level attribute or attribute at SSL host
config level in "server.xml".
Thanks,
Amit
-Original Message-
From: Mark Thomas
Sent: Friday, June 3, 2022 12:24 PM
To: users@tomcat.apache.org
Subject: [External] Re: SSL Handshake Failure - Logging Level
On 03/06/2022 15:33, Amit Pande wrote:
> Hello,
>
> First, thank you to Mark for adding the access logs in case of SSL handshake
> failures
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23&data=05%7C01%7CAmit.Pande%40veritas.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eVNkn8ZtEi6l1IZ5N8tdmVZ%2B0xj%2FeOFC7G2YdBQxZ0Y%3D&reserved=0).
> Really useful enhancement.
>
> On a related note, I am trying to understand if we can log the SSL handshake
> failure at ERROR level instead of current DEBUG level.
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat%
> 2Futil%2Fnet%2FNio2Endpoint.java&data=05%7C01%7CAmit.Pande%40verit
> as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318e
> 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7C&sdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3D&rese
> rved=0
>
> if (log.isDebugEnabled()) {
>
> log.debug(sm.getString("endpoint.err.handshake"), x); }
>
> Are there any issues logging this at error level?
Yes. We generally don't log user triggerable exceptions above debug level as
that can expose the server to a potential DoS - either by filling the disk with
log messages or the performance impact of triggering the exceptions.
I guess we could make the log level for that message configurable.
logHandshakeFailuresAtError or something.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL]
Thank you as always Mark and all! Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Mark Thomas > Sent: Friday, June 3, 2022 4:19 AM > To: users@tomcat.apache.org > Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over > SSL [EXTERNAL] > > Jon, > > If you want to secure the httpd <-> Tomcat link with mutually authenticated > TLS then I believe it is possible based on reading the docs but a) haven't > tested it and b) you are going to need to be careful to ensure Tomcat doesn't > get confused about whether it is the actual client or the reverse proxy that > is > authenticated. > > The following are some pointers that should help. This is how I would go > about things if I was doing this. > > 1. Set up mod_proxy_http and get it working over http. > > 2. Create and configure a server certificate for Tomcat. > > 3. Switch to proxy over https. > > 4. Use SSLProxyCACertifcate[File|Path] to configure httpd to authenticate > Tomcat. > > 5. Check you got 4 right by changing the Tomcat cert to a self-signed one and > looking for the proxy connection to fail. > > 6. Create a client cert for httpd. > > 7. Configure Tomcat to require client cert authentication. > > 8. Configure httpd using SSLProxyMachineCertificate[File|Path] to provide > the certificate. > > 9. Check you got 8 right by: > a) using a JSP to view the presented certificate > b) changing httpd to use a self-signed cert and check it fails > > > The problem you have now is that Tomcat sees httpd as a TLS authenticated > client and you really want Tomcat to see the authentication status of the real > client. > > I've looked at the SSLValve and it only sets request attributes if the > relevant > headers from httpd are present. You would need to write an additional Valve > that ran earlier in the pipeline and cleared those headers. > > HTH, > > Mark > > > On 03/06/2022 00:13, jonmcalexan...@wellsfargo.com.INVALID wrote: > > Ok, so in short ots not possible to mutually authenticate the > > mod-proxy and a tomcat connector, correct? > > > > I'm needing to convert an ajp configuration to mod-proxy, but a security > architect wants the other as well. > > > > > > Thanks, > > > > > > Sent with BlackBerry Work > > > (https://urldefense.com/v3/__http://www.blackberry.com__;!!F9svGWnIa > VP > > GSwU!oOENK5nJ9Bjo27NDwzO08hd73vpTk3jdwxUjQI6v10Xcd3-p- > MGYhMB5ZZjpooe5o > > iwCi-AthWdFVKAJcCg8cQ$ ) > > From: Christopher Schultz > > Sent: Jun 2, 2022 5:05 PM > > To: users@tomcat.apache.org > > Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy > over > > SSL [EXTERNAL] > > > > On 6/2/22 14:38, Beard, Shawn wrote: > > > I've never done this. But I think it would go something like this: > > > To make tomcat take advantages of Client Authentication, require three > > > certificates. i.e A Server Certificate for Tomcat, Client Certificate > > > for the browser/Apache and Certificate of the CA which will sign both > > > the above mentioned certificates. > > > > Stop. John: if you aren't using client TLS certs with your end-users, > > then this is a rathole you don't want to go down. > > > > If you *do* need to use client-TLS-auth, then this is correct. > > > > -chris > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Handshake Failure - Logging Level
On 03/06/2022 15:33, Amit Pande wrote:
Hello,
First, thank you to Mark for adding the access logs in case of SSL handshake
failures
(https://github.com/apache/tomcat/commit/acf6076d7118571ebc881984b96792f861b72bb2#).
Really useful enhancement.
On a related note, I am trying to understand if we can log the SSL handshake
failure at ERROR level instead of current DEBUG level.
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/Nio2Endpoint.java
if (log.isDebugEnabled()) {
log.debug(sm.getString("endpoint.err.handshake"), x);
}
Are there any issues logging this at error level?
Yes. We generally don't log user triggerable exceptions above debug
level as that can expose the server to a potential DoS - either by
filling the disk with log messages or the performance impact of
triggering the exceptions.
I guess we could make the log level for that message configurable.
logHandshakeFailuresAtError or something.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Memory Realm documentation issue?
On 03/06/2022 16:31, Mark Wick wrote: The Tomcat 8.5 documentation states for the Memory Realm: MemoryRealm operates according to the following rules: . When Tomcat first starts up, it loads all defined users and their associated information from the users file. Changes to the data in this file will not be recognized until Tomcat is restarted. However, we are seeing a different behavior (8.5.54), and see indications in the log that the system is trying to reload the database from the tomcat-users.xml file. If I look at the MemoryUserDatabase source, the watchSource member variable is set to true by default. I also do not see the "watchSource" parameter listed as a Realm parameter in the documentation. I am happy to file a bug against the doc, but wanted to confirm that I wasn't missing something first. No you aren't missing anything. It looks like we forgot to update the docs when we enabled the file watching feature by default. That is a documentation bug. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Memory Realm documentation issue?
The Tomcat 8.5 documentation states for the Memory Realm: MemoryRealm operates according to the following rules: . When Tomcat first starts up, it loads all defined users and their associated information from the users file. Changes to the data in this file will not be recognized until Tomcat is restarted. However, we are seeing a different behavior (8.5.54), and see indications in the log that the system is trying to reload the database from the tomcat-users.xml file. If I look at the MemoryUserDatabase source, the watchSource member variable is set to true by default. I also do not see the "watchSource" parameter listed as a Realm parameter in the documentation. I am happy to file a bug against the doc, but wanted to confirm that I wasn't missing something first. Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL Handshake Failure - Logging Level
Hello,
First, thank you to Mark for adding the access logs in case of SSL handshake
failures
(https://github.com/apache/tomcat/commit/acf6076d7118571ebc881984b96792f861b72bb2#).
Really useful enhancement.
On a related note, I am trying to understand if we can log the SSL handshake
failure at ERROR level instead of current DEBUG level.
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/Nio2Endpoint.java
if (log.isDebugEnabled()) {
log.debug(sm.getString("endpoint.err.handshake"), x);
}
Are there any issues logging this at error level?
Thanks,
Amit
RE: [External] Re: Maximum header size in Tomcat 9
Thank you, Mark! -Original Message- From: Mark Thomas Sent: Thursday, May 26, 2022 6:10 AM To: users@tomcat.apache.org Subject: Re: [External] Re: Maximum header size in Tomcat 9 On 25/05/2022 16:21, Amit Pande wrote: > Hello Mark, > > Could we slightly update the description - to say that this size is total > size (in bytes)of all the request (and response) headers combined (including > the header name and values)? > In the past, I incorrectly assumed that this size limit applies for one > header value. > > maxHttpHeaderSize > The maximum size of the request and response HTTP header, specified in bytes. > If not specified, this attribute is set to 8192 (8 KB). Done. Mark > > Thanks, > Amit > > -Original Message- > From: Mark Thomas > Sent: Wednesday, May 25, 2022 6:16 AM > To: users@tomcat.apache.org > Subject: [External] Re: Maximum header size in Tomcat 9 > > On 25/05/2022 12:08, Aditya Kumar wrote: >> Thanks! Sorry I misread that article. >> >> So I suppose it's the same for maxHttpRequestHeaderSize and >> maxHttpResponseHeaderSize? > > Correct. > > Mark > > >> >> >> >> On Wed, May 25, 2022 at 10:45 AM Mark Thomas wrote: >> >>> On 25/05/2022 10:33, Aditya Kumar wrote: I'm sorry I'm not sure what you mean by Integer.MAX_VALUE? >>> >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdo >>> c >>> s.oracle.com%2Fjavase%2F8%2Fdocs%2Fapi%2Fjava%2Flang%2FInteger.html% >>> 2 >>> 3MAX_VALUE&data=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152bff >>> 0 >>> 402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63 >>> 7 >>> 890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi >>> V >>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pfV4 >>> K >>> ul5InBqXlyW958TnV57bbZbe6F%2FrurIJqJ70xg%3D&reserved=0 >>> Looking at https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft o mcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fhttp.html&data=05%7 C 01%7CAmit.Pande%40veritas.com%7Ce18ae152bff0402dad6908da3e3ff7e3%7C f c8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637890741724402644%7CUnkn o wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW w iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VXFY%2Bew8f1HxXiUYsyCmgiV D B%2FqQUJr4rhbB8LbZmkA%3D&reserved=0 >>> all I see is this:- "maxHttpHeaderSize The maximum size of the request and response HTTP header, specified in bytes. If not specified, this attribute is set to 8192 (8 KB)." This does not explain possible values. Can you give me an actual number >>> for the maximum? >>> >>> See above. >>> >>> The theoretical maximum is so far above any sensible value there is >>> not much point documenting it. >>> Also I saw in this article: >>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fco >>> m >>> munity.jaspersoft.com%2Fwiki%2Fhow-pass-big-number-values-apache-tom >>> c >>> at-url-string&data=05%7C01%7CAmit.Pande%40veritas.com%7Ce18ae152 >>> b >>> ff0402dad6908da3e3ff7e3%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7 >>> C >>> 637890741724402644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI >>> j >>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I >>> 6 >>> %2FHM6WSIVucDyEU17ENL0NGNbBDqtAEZ2snU6FFUF4%3D&reserved=0 " A value of less than 0 means no limit." >>> >>> That text is copied directly from the Tomcat documentation and is >>> part of the description for maxParameterCount, not maxHttpHeaderSize. >>> What makes you think it might apply to maxHttpHeaderSize? >>> >>> Mark >>> >>> On Wed, May 25, 2022 at 10:19 AM Mark Thomas wrote: > On 25/05/2022 09:51, Aditya Kumar wrote: >> Hi >> >> I'm using Tomcat 9.0.46 and I want to know what is the maximum >> possible value for maxHttpHeaderSize > > Integer.MAX_VALUE > >> I have Tomcat setup using kerberos authentication and for some >> users >>> the >> Authorisation header is too large (too many AD groups). >> >> I have seen various articles when googling but I want something >> from official documentation to state what the possible values for >> this field are. Is it true that setting a value of "-1" causes a >> limitless maximum header size value? > > Where did you read that? I don't see that in the documentation. > > Mark > > -- > - > -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > >>> >>> >>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> > > -
Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL]
Jon, If you want to secure the httpd <-> Tomcat link with mutually authenticated TLS then I believe it is possible based on reading the docs but a) haven't tested it and b) you are going to need to be careful to ensure Tomcat doesn't get confused about whether it is the actual client or the reverse proxy that is authenticated. The following are some pointers that should help. This is how I would go about things if I was doing this. 1. Set up mod_proxy_http and get it working over http. 2. Create and configure a server certificate for Tomcat. 3. Switch to proxy over https. 4. Use SSLProxyCACertifcate[File|Path] to configure httpd to authenticate Tomcat. 5. Check you got 4 right by changing the Tomcat cert to a self-signed one and looking for the proxy connection to fail. 6. Create a client cert for httpd. 7. Configure Tomcat to require client cert authentication. 8. Configure httpd using SSLProxyMachineCertificate[File|Path] to provide the certificate. 9. Check you got 8 right by: a) using a JSP to view the presented certificate b) changing httpd to use a self-signed cert and check it fails The problem you have now is that Tomcat sees httpd as a TLS authenticated client and you really want Tomcat to see the authentication status of the real client. I've looked at the SSLValve and it only sets request attributes if the relevant headers from httpd are present. You would need to write an additional Valve that ran earlier in the pipeline and cleared those headers. HTH, Mark On 03/06/2022 00:13, jonmcalexan...@wellsfargo.com.INVALID wrote: Ok, so in short ots not possible to mutually authenticate the mod-proxy and a tomcat connector, correct? I'm needing to convert an ajp configuration to mod-proxy, but a security architect wants the other as well. Thanks, Sent with BlackBerry Work (www.blackberry.com) From: Christopher Schultz Sent: Jun 2, 2022 5:05 PM To: users@tomcat.apache.org Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] On 6/2/22 14:38, Beard, Shawn wrote: > I've never done this. But I think it would go something like this: > To make tomcat take advantages of Client Authentication, require three > certificates. i.e A Server Certificate for Tomcat, Client Certificate > for the browser/Apache and Certificate of the CA which will sign both > the above mentioned certificates. Stop. John: if you aren't using client TLS certs with your end-users, then this is a rathole you don't want to go down. If you *do* need to use client-TLS-auth, then this is correct. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
