[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: [External] Re: SSL Handshake Failure - Logging Level
From:       Mark Thomas <markt () apache ! org>
Date:       2022-06-10 13:17:46
Message-ID: d5f8a6a4-8def-06b6-a46c-b26957831ae0 () apache ! org
[Download RAW message or body]

I've thinking about this further and also noticed this enhancement request:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65401

I think a better solution is to provide a dedicated logger for TLS 
handshake failures and then that logger can be configured to provide the 
desired level of detail without impacting the configuration of any other 
loggers.

Mark


On 06/06/2022 15:50, Amit Pande wrote:
> I mean this log is helpful troubleshooting issues in production systems. We can't \
> have Tomcat log level set to DEBUG in this case. And debugging on local/development \
> environments. Agree, in this case, we could change the Tomcat logging configuration \
> and get this log. 
> Thanks,
> Amit
> 
> -----Original Message-----
> From: Mark Thomas <markt@apache.org>
> Sent: Saturday, June 4, 2022 6:13 AM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: SSL Handshake Failure - Logging Level
> 
> On 03/06/2022 21:29, Amit Pande wrote:
> > 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.
> 
> If the purpose of this is debugging / troubleshooting they why not just enable \
> debug logging when needed? 
> Why does this need to be separately configurable?
> 
> Mark
> 
> 
> > 
> > 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 <markt@apache.org>
> > 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%2Fgith \
> > > ub.com%2Fapache%2Ftomcat%2Fcommit%2Facf6076d7118571ebc881984b96792f861b72bb2%23& \
> > > amp;data=05%7C01%7CAmit.Pande%40veritas.com%7C4a3b22cfe34644c1530508da461b3fe9%7 \
> > > Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637899380101620149%7CUnknown%7CTWFpb \
> > > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 \
> > > %7C%7C%7C&amp;sdata=ZUT9Z1PWQBYpJPWZgAgVX93SJkhDnq%2BQxXJv8BanV9o%3D&amp;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%2Fgit
> > > h
> > > ub.com%2Fapache%2Ftomcat%2Fblob%2Fmain%2Fjava%2Forg%2Fapache%2Ftomcat
> > > %
> > > 2Futil%2Fnet%2FNio2Endpoint.java&amp;data=05%7C01%7CAmit.Pande%40veri
> > > t
> > > as.com%7Cc90c525c37304f89d53e08da4586d120%7Cfc8e13c0422c4c55b3eaca318
> > > e
> > > 6cac32%7C0%7C0%7C637898742608266230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > C
> > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> > > %
> > > 7C&amp;sdata=beoiMNczfYunL9CN7I8mJCLwNsyXr%2FjlGRzDy1ZHEmg%3D&amp;res
> > > e
> > > 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-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
> > 
> 
> ---------------------------------------------------------------------
> 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
> 

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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic