Form based auth does not provide the option to show error reason in the error page
I know it has been asked dozens of times but the response is always "Cannot be done in a standard way". But why can't we change Tomcat to provide further details to the error page of why the login failed? I would have thought tomcat can support that easily without any backward compatibility issue: Everywhere the authenticate method is called, e.g. FormAuthenticator.doAuthenticate() catch throwables and add the exception details as parameter, as session variable, as ... to the redirect call, such that the error page has a place to read the actual issue. There are tons of reasons a login might fail and without providing the user with the reason he has no option to fix the problem. Only option is to call up the web server admin to scan the webserver logs. Examples: * password wrong * cannot connect to the user database due to network or database not up * login is fine but password expired, must be changed * connection to the user database is fine but SQL statement failed for whatever reason So why has this not been done? What am I missing? Does an enhancement request exist?? Thanks in advance
Re: Tomcat 9.0.x JDBC connection pool does not always remove abandoned connections
Gerhardt, On 10/12/21 13:27, Martin, Gerhardt A wrote: Running Tomcat 9.0.50 on Centos 7.9.x Linux and using Tomcat JDBC connection pool to connect to my application's databases. My app connects to about a dozen read only databases and one read/write database. Here is a typical resource definition with tuning configurations for the pool and the MSSQL server JDBC driver: Note that these are the only relevant attributes: > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" You are using tomcat-pool, not the default commons-dbcp. maxActive="20" initialSize="1" maxIdle="8" minIdle="1" maxWait="5000" testOnBorrow="false" testWhileIdle="false" testOnConnect="false" testOnReturn="false" timeBetweenEvictionRunsMillis="1" removeAbandonedTimeout="15" removeAbandoned="true" logAbandoned="false" minEvictableIdleTimeMillis="90" maxAge="60" Important NOTE: the framework we employ does NOT execute more than one SQL statement per borrow from the connection pool. It's a constant cycle of getConnection(borrow) ->execute 1 SQL->closeConnection(return) That's kind of wasteful, but okay. Why are we configured this way: Ultimately we need to fail fast to avoid our APP going into death by stuck threads when we lose connectivity to the backend databases for a short period of time. ( for example a short 10 second period where the DB(s) is/are unreachable from the app servers). Is this common? -We want the evictor thread (Pool Cleaner) to run every 10 seconds -We are only using the Pool Cleaner to clobber busy connections that have been running 15 seconds or more NOTE: we rarely see SQL that takes longer than 2 seconds, most are sub 100ms and the avg is about 4ms Note that the connections aren't clobbered; they are simply dropped from the pool. The work they generated is still continuing... -We are not testing connections period -We want our connections replaced with new fresh connections after 10 mins of use hence we set maxAge=60 The connection pool settings work hand in hand with properties set on the SQL server JDBC driver in the URL: The driver will kill any SQL that takes longer than 10 seconds Ouch. -When everything else is OK, then the connection itself is returned intact back to the connection pool -When the DB is unreachable, there is another timer cancelQueryTimeout set to 10 seconds which is a safety valve for cases where the message to the DB server to cancel the SQL gracefully does not make it to the DB. After the cancleQueryTimeout, the client side of the driver gives up. This is problematic because it actually returns a bad connection back to the connection pool. The combination of the connection pool settings to run the Pool cleaner every 10 seconds and removeAbandoned of 15 seconds should work together to remove any connection whose SQL execution time went past 10 seconds before the cancelQueryTimeout kicks in. This should prevent returning bad connections to the pool when bad things happen like a network switch going offline temporarily and dropping all packets between the app server hosting tomcat and the database server. Sounds like you really just want to be validating connections, but you have explicitly disabled that feature. Why? NOTE that for the MSSQL server driver all their timeouts default to wait indefinitely. This is one of the prime reasons why even short outages can kill our APP with stuck threads. Our Web app hits tomcat about 2000 requests per minute and each request is going to fire on AVG ~6 SQL statements so we are running about 12K SQL hits per minute. If we lose connectivity to a database for even 15 seconds without a means to fail fast we could easily overcome the allotted number of threads which will create a "log jam" that can take a very long time to recover. Why doesn't your query-timeout handle this situation? So I am very sorry for all this lenghty background but I thought it might help for readers and potential responders to know a bit about why we do what we do in our connection pool. Finally now onto the problem: I was running a load test and simulating the temporary loss of connectivity to one or more of the databases used in the APP and I noticed a strange behavior that does not align with my understanding of how Tomcat JDBC removeAbandoned works. While most of my database connections coming from the pool did die shortly after the simulation started and "failed fast" there were a few connections that actually ran for up to 5 minutes before they terminated themselves. Given the configuration I explained I would have expected no database connection that was interacting with the database to live beyond 30 seconds. ( giving that there could be some forward/reverse lag in the evictor thread timing where there could be a slight chance that the first run of the evictor thread might not catch every connection that was at the 15 seconds mark.) Remember that the pool won't ki
[SECURITY] CVE-2021-42340 Apache Tomcat DoS
CVE-2021-42340 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.1.0-M1 to 10.1.0-M5 Apache Tomcat 10.0.0-M10 to 10.0.11 Apache Tomcat 9.0.40 to 9.0.53 Apache Tomcat 8.5.60 to 8.5.71 Description: The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.1.0-M6 or later - Upgrade to Apache Tomcat 10.0.12 or later - Upgrade to Apache Tomcat 9.0.54 or later - Upgrade to Apache Tomcat 8.5.72 or later History: 2021-10-14 Original advisory 2021-10-14 Correct CVE reference in body of advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2021-42340 Apache Tomcat DoS
CVE-2021-41079 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.1.0-M1 to 10.1.0-M5 Apache Tomcat 10.0.0-M10 to 10.0.11 Apache Tomcat 9.0.40 to 9.0.53 Apache Tomcat 8.5.60 to 8.5.71 Description: The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.1.0-M6 or later - Upgrade to Apache Tomcat 10.0.12 or later - Upgrade to Apache Tomcat 9.0.54 or later - Upgrade to Apache Tomcat 8.5.72 or later History: 2021-10-14 Original advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
On 14/10/2021 10:28, Natraj Thekkan wrote:
Hi,
We are using tomcat version 9.0.46.
Could you please provide suggestion to restrict the TLS version in HTTP2 over
HTTPS with OpenSSL implementation?.
The code below is sufficient, assuming that is then the connector that
is being used by the clients.
You should be able to remove to remove the
sslHostConfig.setSslProtocol("TLS");
line. It is only used with JSSE.
Mark
Regards,
Natraj
From: Natraj Thekkan
Sent: Wednesday, October 13, 2021 10:15 AM
To: 'users@tomcat.apache.org'
Subject: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Hi,
We have tried to restrict the TLS version in https connection establishment in
embedded tomcat for OpenSSL based implementation. With this part of the code,
TLSv1.0/TLSv1.1 client also able to connect with our https server. Please let
us know how we can restrict the TLS version in HTTP2 over HTTPS in OpenSSL
implementation.
Below code is used while creating connector.
private final String[] enabledProtocol = new String[] { "TLSv1.2" };
SSLHostConfig sslHostConfig = new SSLHostConfig();
sslHostConfig.setInsecureRenegotiation( false );
sslHostConfig.setCertificateFile( certLocation );
sslHostConfig.setCertificateKeyFile( certKeyLocation );
sslHostConfig.setCertificateKeyPassword( certKeyPassword );
if( isClientAuthreq && caCertificatePath != null &&
!caCertificatePath.isEmpty() )
{
sslHostConfig.setCertificateVerification(
CertificateVerification.REQUIRED.toString() );
sslHostConfig.setCaCertificateFile( caCertificatePath );
}
sslHostConfig.setSslProtocol("TLS");
sslHostConfig.setEnabledProtocols( enabledProtocol );
this.addSslHostConfig( sslHostConfig );
IntrospectionUtils.setProperty( this, "SSLEnabled", "true" );
IntrospectionUtils.setProperty( this, "sslImplementationName",
"org.apache.tomcat.util.net.openssl.OpenSSLImplementation" );
Regards,
Natraj
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Hi,
We are using tomcat version 9.0.46.
Could you please provide suggestion to restrict the TLS version in HTTP2 over
HTTPS with OpenSSL implementation?.
Regards,
Natraj
From: Natraj Thekkan
Sent: Wednesday, October 13, 2021 10:15 AM
To: 'users@tomcat.apache.org'
Subject: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL
Hi,
We have tried to restrict the TLS version in https connection establishment in
embedded tomcat for OpenSSL based implementation. With this part of the code,
TLSv1.0/TLSv1.1 client also able to connect with our https server. Please let
us know how we can restrict the TLS version in HTTP2 over HTTPS in OpenSSL
implementation.
Below code is used while creating connector.
private final String[] enabledProtocol = new String[] { "TLSv1.2" };
SSLHostConfig sslHostConfig = new SSLHostConfig();
sslHostConfig.setInsecureRenegotiation( false );
sslHostConfig.setCertificateFile( certLocation );
sslHostConfig.setCertificateKeyFile( certKeyLocation );
sslHostConfig.setCertificateKeyPassword( certKeyPassword );
if( isClientAuthreq && caCertificatePath != null &&
!caCertificatePath.isEmpty() )
{
sslHostConfig.setCertificateVerification(
CertificateVerification.REQUIRED.toString() );
sslHostConfig.setCaCertificateFile( caCertificatePath );
}
sslHostConfig.setSslProtocol("TLS");
sslHostConfig.setEnabledProtocols( enabledProtocol );
this.addSslHostConfig( sslHostConfig );
IntrospectionUtils.setProperty( this, "SSLEnabled", "true" );
IntrospectionUtils.setProperty( this, "sslImplementationName",
"org.apache.tomcat.util.net.openssl.OpenSSLImplementation" );
Regards,
Natraj
