Re: Tomcat log warnings for connection parameter limits?
Thanks, Mark. Submitted < https://bz.apache.org/bugzilla/show_bug.cgi?id=68934> On Tue, Apr 16, 2024 at 4:44 AM Mark Thomas wrote: > It would be worth creating an enhancement request for this in Bugzilla > to ensure the request doesn't get forgotten about. > > Mark > > > On 16/04/2024 01:06, Baron Fujimoto wrote: > > From our perspective, it needn't be super timely. It would be more for > > forensic confirmation that there's something we should consider. I think > a > > hysteresis behavior would be compatible with this. > > > > On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas wrote: > > > >> On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be > >> something that would be left on in a live> system. We can set these > >> parameters, so it would be useful to know if we > >>> were hitting the set limits. > >> > >> For the connection limit: > >> > >> How timely do you need the information to be? It is much easier to add a > >> check when the connection is closed since a) it returns the current > >> count and b) we are already checking the return value for mis-counting. > >> > >> For the thread limit: > >> > >> We have a couple of options here. (We use a custom queue which > >> effectively changes the way threads in the pool re used.) The simplest > >> is probably to add log in TaskQueue.offer() if all threads are currently > >> being used. > >> > >>> I'm not sure I fully grasp how this additional logging presents a > >>> significant incremental DOS risk. I mean, if an attacker is flooding > you > >>> with enough traffic or connections where this becomes an issue, aren't > >> you > >>> already logging various aspects of the attempts anyway (e.g., access > >> logs, > >>> etc)? At that point aren't your logs already being filled anyway? > >> > >> It is an area we need to be careful with. Log messages that include > >> exceptions are of greatest concern since they are relatively expensive > >> to generate. If an invalid HTTP message triggers a log message with an > >> exception (it does, but only when configured for debug logging) then > >> there is a degree of DoS risk there. > >> > >> Access logs are a special case and one that we have taken care to try > >> and optimise. Still, if you want to make a performance test look good > >> turning off access logging is one of the first things to do (and of > >> course results in totally meaningless results that don't reflect real > >> world usage). > >> > >> I think the concern Chris was trying to express (although I'm sure he'll > >> correct me if I am wrong) is that when these limits are reached there is > >> a risk of a lot of log messages being generated and that can cause > >> issues both from a performance issue and from just filling the logs with > >> the same message over and over again. > >> > >> I think what we would need is some form of hysteresis. Log a message > >> when the limit is reached, log another message when usage falls below > >> 80%? of the limit. That way, administrators see the peaks in usage but > >> aren't inundated with log messages. > >> > >> My only concern is that at least some this code is going to run for > >> every single request. It needs to be efficient. We should measure the > >> impact of adding this code before we decide on whether to include it. > >> > >> Mark > >> > >> > >>> > >>> On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz < > >>> ch...@christopherschultz.net> wrote: > >>> > >>>> Baron, > >>>> > >>>> On 4/9/24 16:33, Baron Fujimoto wrote: > >>>>> I'm investigating occasional 503 errors for our CAS service running > in > >> a > >>>>> Tomcat 10.1.x container. The 503s appear to correlate with some > traffic > >>>>> spikes at the same time. > >>>>> > >>>>> The connector is configured as follows: > >>>>> > >>>>> protocol="org.apache.coyote.http11.Http11NioProtocol" > >>>>> port="8443" > >>>>> maxThreads="2500" > >>>>> maxConnections="5" > >>>>> maxPostSize="10" > >>>&
Re: Tomcat log warnings for connection parameter limits?
>From our perspective, it needn't be super timely. It would be more for forensic confirmation that there's something we should consider. I think a hysteresis behavior would be compatible with this. On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas wrote: > On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be > something that would be left on in a live> system. We can set these > parameters, so it would be useful to know if we > > were hitting the set limits. > > For the connection limit: > > How timely do you need the information to be? It is much easier to add a > check when the connection is closed since a) it returns the current > count and b) we are already checking the return value for mis-counting. > > For the thread limit: > > We have a couple of options here. (We use a custom queue which > effectively changes the way threads in the pool re used.) The simplest > is probably to add log in TaskQueue.offer() if all threads are currently > being used. > > > I'm not sure I fully grasp how this additional logging presents a > > significant incremental DOS risk. I mean, if an attacker is flooding you > > with enough traffic or connections where this becomes an issue, aren't > you > > already logging various aspects of the attempts anyway (e.g., access > logs, > > etc)? At that point aren't your logs already being filled anyway? > > It is an area we need to be careful with. Log messages that include > exceptions are of greatest concern since they are relatively expensive > to generate. If an invalid HTTP message triggers a log message with an > exception (it does, but only when configured for debug logging) then > there is a degree of DoS risk there. > > Access logs are a special case and one that we have taken care to try > and optimise. Still, if you want to make a performance test look good > turning off access logging is one of the first things to do (and of > course results in totally meaningless results that don't reflect real > world usage). > > I think the concern Chris was trying to express (although I'm sure he'll > correct me if I am wrong) is that when these limits are reached there is > a risk of a lot of log messages being generated and that can cause > issues both from a performance issue and from just filling the logs with > the same message over and over again. > > I think what we would need is some form of hysteresis. Log a message > when the limit is reached, log another message when usage falls below > 80%? of the limit. That way, administrators see the peaks in usage but > aren't inundated with log messages. > > My only concern is that at least some this code is going to run for > every single request. It needs to be efficient. We should measure the > impact of adding this code before we decide on whether to include it. > > Mark > > > > > > On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> Baron, > >> > >> On 4/9/24 16:33, Baron Fujimoto wrote: > >>> I'm investigating occasional 503 errors for our CAS service running in > a > >>> Tomcat 10.1.x container. The 503s appear to correlate with some traffic > >>> spikes at the same time. > >>> > >>> The connector is configured as follows: > >>> > >>>>>> port="8443" > >>> maxThreads="2500" > >>> maxConnections="5" > >>> maxPostSize="10" > >>> maxParameterCount="1000" > >>> scheme="https" secure="true" > >>> SSLEnabled="true" > >>> > > >>> > >>> Can Tomcat log info such as when the maxThreads or maxConnections > limits > >>> are reached? I'm basically trying to see if there is a good way to > >>> more definitively determine what may have caused the 503s and what may > be > >>> feasible to mitigate them. > >> > >> Are you thinking of a debugging feature or something to be left-on for a > >> live production system? > >> > >> Such logging might be considered a DOS vector for a live system: you can > >> fill the logs by asking lots of trivial requests. > >> > >> -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 > > -- Baron Fujimoto ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
Re: Tomcat log warnings for connection parameter limits?
I was thinking it would be something that would be left on in a live system. We can set these parameters, so it would be useful to know if we were hitting the set limits. I'm not sure I fully grasp how this additional logging presents a significant incremental DOS risk. I mean, if an attacker is flooding you with enough traffic or connections where this becomes an issue, aren't you already logging various aspects of the attempts anyway (e.g., access logs, etc)? At that point aren't your logs already being filled anyway? On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Baron, > > On 4/9/24 16:33, Baron Fujimoto wrote: > > I'm investigating occasional 503 errors for our CAS service running in a > > Tomcat 10.1.x container. The 503s appear to correlate with some traffic > > spikes at the same time. > > > > The connector is configured as follows: > > > > > port="8443" > > maxThreads="2500" > > maxConnections="5" > > maxPostSize="10" > > maxParameterCount="1000" > > scheme="https" secure="true" > > SSLEnabled="true" > > > > > > > Can Tomcat log info such as when the maxThreads or maxConnections limits > > are reached? I'm basically trying to see if there is a good way to > > more definitively determine what may have caused the 503s and what may be > > feasible to mitigate them. > > Are you thinking of a debugging feature or something to be left-on for a > live production system? > > Such logging might be considered a DOS vector for a live system: you can > fill the logs by asking lots of trivial requests. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Baron Fujimoto ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
Tomcat log warnings for connection parameter limits?
I'm investigating occasional 503 errors for our CAS service running in a Tomcat 10.1.x container. The 503s appear to correlate with some traffic spikes at the same time. The connector is configured as follows: Can Tomcat log info such as when the maxThreads or maxConnections limits are reached? I'm basically trying to see if there is a good way to more definitively determine what may have caused the 503s and what may be feasible to mitigate them. -- Baron Fujimoto ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
Re: localhost log config?
Doh! Well, that was a dumb mistake. Mahalo for pointing out the obvious. On Sat, Sep 23, 2023 at 9:06 PM Konstantin Kolinko wrote: > пт, 22 сент. 2023 г. в 21:59, Baron Fujimoto : > > > >[...] > > > > I have the following defined in our logging.properties file: > > > > 1catalina.org.apache.juli.AsyncFileHandler.rotatable = false > > > > 2localhost.org.apache.juli.FileHandler.rotatable = false > > > > [...] > > I'm not sure why this works as expected with the catalina log files, but > not localhost. > > Note that "2localhost" setting has a typo: > s/FileHandler/AsyncFileHandler/ > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Baron Fujimoto ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
localhost log config?
I hope someone can help me with a Tomcat (10.1.x) logging configuration
question.
I'm perplexed trying to figure out the logging configuration for the
localhost log. I'm using an external logrotate utility to handle log
rotation. This is working well for other Tomcat logs such as catalina.out,
access.log, etc, but for our localhost log, Tomcat seems to be creating
them with the date Tomcat was started in the log filename, and I don't know
why or how to change this behavior. Our logrotate utility expects a
predictable logfile name, such as localhost.log, and the addition of the
date in the filename breaks that.
I have the following defined in our logging.properties file:
1catalina.org.apache.juli.AsyncFileHandler.level = FINE
1catalina.org.apache.juli.AsyncFileHandler.directory =
${catalina.base}/logs
1catalina.org.apache.juli.AsyncFileHandler.prefix = catalina
1catalina.org.apache.juli.AsyncFileHandler.encoding = UTF-8
1catalina.org.apache.juli.AsyncFileHandler.rotatable = false
2localhost.org.apache.juli.AsyncFileHandler.level = FINE
2localhost.org.apache.juli.AsyncFileHandler.directory =
${catalina.base}/logs
2localhost.org.apache.juli.AsyncFileHandler.prefix= localhost
2localhost.org.apache.juli.AsyncFileHandler.encoding = UTF-8
2localhost.org.apache.juli.FileHandler.rotatable = false
If I restart Tomcat today, for example, I wind up
with localhost2023-09-22.log
I'm not sure why this works as expected with the catalina log files, but
not localhost. Presumably I have a misconception about how this is supposed
to work or some other basic error?
--
Baron Fujimoto ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
Re: tomcat 8.5 TLS cipher strings
On Wed, Nov 18, 2020 at 04:45:05PM +, Mark Thomas wrote: On 18/11/2020 03:07, Baron Fujimoto wrote: On Mon, Nov 16, 2020 at 09:47:03AM +, Mark Thomas wrote: Have you tried adding ":-AES:+AESGCM" to the cipher string you are already using? I hadn't (did I miss where these were documented somewhere?). However it seems like once I add "":-AES", tomcat fails to start with the following error: Sorry, wrong information on my part. Try appending: ":-AES:AESGCM" See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html Tomcat aims to support the same set of options as the latest stable OpenSSl release and to return the same set of ciphers for the same input. Note that due to different defaults in different versions of OpenSSL as well as support for ciphers being added/removed in some versions we only aim to replicate the behaviour of the latest stable OpenSSL release (currently 1.1.1h). Mahalo, that did the trick! -- UH Information Technology Services : Identity & Access Mgmt, Middleware minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8.5 TLS cipher strings
On Mon, Nov 16, 2020 at 09:47:03AM +, Mark Thomas wrote: On 14/11/2020 00:41, Baron Fujimoto wrote: We're running Tomcat 8.5, currently configured with the following OpenSSL cipher strings in our SSLHostConfig: ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!PSK" However, SSLLabs' server test reports that the following available ciphers are weak: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Is there a cipher string that concisely includes these *_RSA_WITH_AES_*_CBC_SHA* ciphers that may be used to disallow them in the SSLHostConfig ciphers parameter? I didn't see one in the OpenSSL ciphers reference. Have you tried adding ":-AES:+AESGCM" to the cipher string you are already using? I hadn't (did I miss where these were documented somewhere?). However it seems like once I add "":-AES", tomcat fails to start with the following error: 17-Nov-2020 16:54:01.095 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1077) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:552) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:848) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:639) at org.apache.catalina.startup.Catalina.load(Catalina.java:662) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472) Caused by: java.lang.IllegalArgumentException: None of the [ciphers] specified are supported by the SSL engine : [[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_ CAMELLIA_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384, TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_DHE_RSA_WITH_CAMELLI A_256_CBC_SHA256, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256, TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256, TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA, TLS_DH_DSS_WITH_CAMELL IA_256_CBC_SHA, TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256, TLS_ DHE_DSS_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256, TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256, TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS _DHE_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA, TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA, TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256]] at org.apache.tomcat.util.net.SSLUtilBase.getEnabled(SSLUtilBase.java:149) at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:123) at org.apache.tomcat.util.net.jsse.JSSEUtil.(JSSEUtil.java:113) at org.apache.tomcat.util.net.jsse.JSSEUtil.(JSSEUtil.java:108) at org.apache.tomcat.util.net.jsse.JSSEImplementation.getSSLUtil(JSSEImplementation.java:50) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:89) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72) at org.apache.tomcat.util.net.Ni
tomcat 8.5 TLS cipher strings
We're running Tomcat 8.5, currently configured with the following OpenSSL cipher strings in our SSLHostConfig: ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!PSK" However, SSLLabs' server test reports that the following available ciphers are weak: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA Is there a cipher string that concisely includes these *_RSA_WITH_AES_*_CBC_SHA* ciphers that may be used to disallow them in the SSLHostConfig ciphers parameter? I didn't see one in the OpenSSL ciphers reference. SSLLabs reports only the following available ciphers as non-weak: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 Our ciphers are provided via Oracle's JDK 8. -- UH Information Technology Services : Identity & Access Mgmt, Middleware minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
web.xml mime-mappings
Apologies in advance if this is a dumb question. I usually base our config files off of the sample config files as a starting point. The sample web.xml contains many mime-mapping elements (1000+ I think). Is there any good reason to include these if your application isn't going to use the vast majority of these mime-types? I.e., is it recommended to edit it down to just those that the application is likely to use? It seems like it would be less unwieldy if I did this, but I just want to make sure there's no compelling downside to it. -- Baron Fujimoto :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: configuring ciphers for SSL Labs server test
Hmm, I'm now getting an A grade using: If I'm sufficiently motivated next week, I'll see if I can sort out exactly what the deal was. But for now, it's Friday and pau hana time... (yes, tomcat 8.5.x and Java 1.8_x) On Fri, May 11, 2018 at 07:39:25AM +0100, Mark Thomas wrote: >On 11/05/18 03:35, Baron Fujimoto wrote: >> Yes, the host is behind an F5 load balacer, but AFAIK it should be passing >> all the TLS/SSL directly to the real host to handle. > >You don't say which Tomcat version is being used. I assume one of the >8.5.x versions since the 8.5.x docs are referenced. > >8.5.x should get an A from SSLLabs with the default configuration: >https://wiki.apache.org/tomcat/Security/Ciphers > >I recently updated that page but 8.5.x was getting a A two years ago as >well. > >Are you sure Java 8 is being used? > >Mark > > >> >> On Thu, May 10, 2018 at 11:23:44PM +, Scott Hoenigman wrote: >>> Are you using a load balancer? >>> >>> >>> >>> Sent from my T-Mobile 4G LTE Device >>> >>> >>> Original message >>> From: David Wall <d.w...@computer.org> >>> Date: 5/10/18 6:15 PM (GMT-06:00) >>> To: users@tomcat.apache.org >>> Subject: Re: configuring ciphers for SSL Labs server test >>> >>> We're doing good with this: >>> >>> >> protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true" >>> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, >>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, >>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, >>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256" >>> > >>> >>> >>> On 5/10/18 2:45 PM, Baron Fujimoto wrote: >>>> I'm trying to improve our grade on SSL Labs SSL server test[1] for our >>>> Tomcat configuraton. Currently, their report caps our grade at B because, >>>> "This server does not support Authenticated encryption (AEAD) cipher >>>> suites". They report that we support the following cipher suites: >>>> >>>> # TLS 1.2 >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>>> >>>> # TLS 1.1 >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>>> >>>> I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are >>>> using Java 1.8.0_162, and I believe we have the Java Cryptography >>>> Extension (JCE) properly installed. I have the following connector >>>> defined (this version explicitly lists ciphers I think should satisfy the >>>> AEAD cipher requirement[2]): >>>> >>>> >>> address="0.0.0.0" >>>> port="8443" >>>> maxThreads="500" >>>> maxPostSize="10" >>>> scheme="https" secure="true" >>>> defaultSSLHostConfigName="foo.example.edu" >>>> SSLEnabled="true" > >>>> >>> protocols="TLSv1.1+TLSv1.2+TLS1.3" >>>> certificateVerification="none" >>>> honorCipherOrder="true" >>>> >>>> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK >>>> :!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA >>>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA >>>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 >>>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >>>> :!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >>>> :!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >
Re: configuring ciphers for SSL Labs server test
Yes, the host is behind an F5 load balacer, but AFAIK it should be passing all the TLS/SSL directly to the real host to handle. On Thu, May 10, 2018 at 11:23:44PM +, Scott Hoenigman wrote: > Are you using a load balancer? > > > >Sent from my T-Mobile 4G LTE Device > > > Original message >From: David Wall <d.w...@computer.org> >Date: 5/10/18 6:15 PM (GMT-06:00) >To: users@tomcat.apache.org >Subject: Re: configuring ciphers for SSL Labs server test > >We're doing good with this: > > protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true" >ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, >TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, >TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, >TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, >TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, >TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >TLS_DHE_RSA_WITH_AES_128_CBC_SHA, >TLS_DHE_RSA_WITH_AES_256_CBC_SHA, >TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, >TLS_DHE_RSA_WITH_AES_256_CBC_SHA256" > > > > >On 5/10/18 2:45 PM, Baron Fujimoto wrote: >> I'm trying to improve our grade on SSL Labs SSL server test[1] for our >> Tomcat configuraton. Currently, their report caps our grade at B because, >> "This server does not support Authenticated encryption (AEAD) cipher >> suites". They report that we support the following cipher suites: >> >> # TLS 1.2 >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >> >> # TLS 1.1 >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >> >> I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are >> using Java 1.8.0_162, and I believe we have the Java Cryptography >> Extension (JCE) properly installed. I have the following connector >> defined (this version explicitly lists ciphers I think should satisfy the >> AEAD cipher requirement[2]): >> >> > address="0.0.0.0" >> port="8443" >> maxThreads="500" >> maxPostSize="10" >> scheme="https" secure="true" >> defaultSSLHostConfigName="foo.example.edu" >> SSLEnabled="true" > >> > protocols="TLSv1.1+TLSv1.2+TLS1.3" >> certificateVerification="none" >> honorCipherOrder="true" >> >> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK >> :!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA >> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA >> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 >> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >> :!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >> :!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >> :!TLS_RSA_WITH_AES_128_CBC_SHA >> :!TLS_RSA_WITH_AES_256_CBC_SHA >> :!TLS_RSA_WITH_AES_128_CBC_SHA256 >> :!TLS_RSA_WITH_AES_256_CBC_SHA256 >> :!TLS_RSA_WITH_AES_128_GCM_SHA256 >> :!TLS_RSA_WITH_AES_256_GCM_SHA384 >> :!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> :!TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> :TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 >> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA >> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA >> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 >> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 >> :TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> :TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA >>
configuring ciphers for SSL Labs server test
I'm trying to improve our grade on SSL Labs SSL server test[1] for our Tomcat configuraton. Currently, their report caps our grade at B because, "This server does not support Authenticated encryption (AEAD) cipher suites". They report that we support the following cipher suites: # TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA # TLS 1.1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are using Java 1.8.0_162, and I believe we have the Java Cryptography Extension (JCE) properly installed. I have the following connector defined (this version explicitly lists ciphers I think should satisfy the AEAD cipher requirement[2]): I've mapped the cipher suite names using the OpenSSL cipher suite name list[3]. I originally started with ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK", but had the same result, so subsequently tried adding the specific ciphers shown above. The tomcat SSLHostConfig docs state that either the OpenSSL or JSSE cipher names may be used[4]. Any suggestions on what I may be doing wrong or for further troubleshooting? References: [1] <https://www.ssllabs.com/ssltest/analyze.html> [2] <https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites> [3] <https://www.openssl.org/docs/manmaster/man1/ciphers.html#CIPHER-SUITE-NAMES> [4] <https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig> -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: converting 8.0.x ssl Connector to 8.5.x sslHostConfig
On Thu, Apr 26, 2018 at 10:15:03AM +0100, Mark Thomas wrote: >On 26/04/18 02:37, Baron Fujimoto wrote: >> We're working on upgrading from 8.0.x to 8.5.x in preparation for 8.0's >> impending EOL. >> Our initial 8.5 deployment which essentially uses our legacy server.xml SSL >> connectors from 8.0 seems to work as expected. The HTTP Connector >> documentation suggests that the SSL configuration should now be handled by >> the nested SSLHostConfig and Certificate elements; is this the case? I've >> been running into snags trying to convert our lagacy config. Is there a >> migration guide I may have missed? > >What snags? > >What is the original 8.0.x configuration? > >What is the new 8.5.x configuration? Belay that. As expected, it was pilot error. Apparently I was mislocating Connector attributes relative to the closing ">" of the opening element. Closer examination of a working config revelaed my problem. Mea culpa. -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
converting 8.0.x ssl Connector to 8.5.x sslHostConfig
We're working on upgrading from 8.0.x to 8.5.x in preparation for 8.0's impending EOL. Our initial 8.5 deployment which essentially uses our legacy server.xml SSL connectors from 8.0 seems to work as expected. The HTTP Connector documentation suggests that the SSL configuration should now be handled by the nested SSLHostConfig and Certificate elements; is this the case? I've been running into snags trying to convert our lagacy config. Is there a migration guide I may have missed? -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload
On Tue, Oct 03, 2017 at 10:55:26AM +, Mark Thomas wrote: >CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP Upload > >Severity: Important > >Vendor: The Apache Software Foundation > >Versions Affected: >[...] >Apache Tomcat 8.0.0.RC1 to 8.0.46 >[...] > >Description: >When running with HTTP PUTs enabled (e.g. via setting the readonly >initialisation parameter of the Default servlet to false) it was >possible to upload a JSP file to the server via a specially crafted >request. This JSP could then be requested and any code it contained >would be executed by the server. > >Mitigation: >Users of the affected versions should apply one of the following >mitigations: >[...] >- Upgrade to Apache Tomcat 8.0.47 or later >[...] I haven't seen an announcement for 8.0.47, nor does the Apache Tomcat website seem to reference it yet, but it appears to be available in the distribution archive(s). E.g.: <http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.47/bin/> Is this 8.0.47 blessed for use? Aloha, -baron -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
On Tue, Dec 15, 2015 at 09:37:45AM +0200, Violeta Georgieva wrote:
>Hello,
>
>2015-12-15 4:35 GMT+02:00 Baron Fujimoto <ba...@hawaii.edu>:
>>
>> On Mon, Dec 14, 2015 at 09:12:20PM +, Mark Thomas wrote:
>> >On 14/12/2015 20:49, Baron Fujimoto wrote:
>> >> On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote:
>> >>> On Sat, Dec 12, 2015 at 12:16:01AM +, Mark Thomas wrote:
>> >
>> >
>> >
>> >>> I've confirmed that the problem begins with 8.0.29.
>> >
>> >Looking through the changelog it is hard to see how any of the changes
>> >not in the Catalina section could trigger this. So, focussing on that
>> >section...
>> >
>> >>>> If you can find out how the CSRF protection is adding the token then
>> >>>> that will also help since it gives an idea of what to look for in the
>> >>>> changelog.
>> >>>
>> >>> I believe it's done using the OWASP CSRFGuard Project, and I have the
>> >>> property files generated by the Grouper devs that define its
>> >>> configuration. I'll query the Grouper folks to confirm and see if they
>> >>> can provide a relevant and succinct explanation about this in
>particular.
>> >>
>> >> The Grouper devs explain, "Javascript sets an HTTP header called
>> >> OWASP_CSRFTOKEN: on requests (some excluded per properties file)".
>> >
>> >That doesn't explain how/where the token is generated or what component
>> >validates it server side. I'm guessing a Filter does the validation.
>> >
>> >> Per the properties file, I believe the following are excluded:
>> >>
>> >> org.owasp.csrfguard.unprotected.Default=%servletContext%/
>> >
>> >Hmm. This first one combined with the last entry in the Catalina section
>> >of the 8.0.29 changelog look like a possibility.
>> >
>> >Try each of the following (one at a time, not together) to see if they
>> >fix it:
>>
>> Neither of these, tried independently, appeared to have any effect.
>>
>> >a) Add the following (note the lack of trailing slash) to the properties
>> >file:
>> >
>> >org.owasp.csrfguard.unprotected.Upload=%servletContext%
>>
>> I tried this as described, but since I wasn't sure if you really meant the
>> .Default property I also tried that, just in case (separate tests,
>> performed independently). I tried both by adding the suggested definitions
>> after their original definitions (in case they superceded them) and by
>> replacing the original definitions.
>>
>>
>> >b) Set mapperContextRootRedirectEnabled="true" and
>> >mapperDirectoryRedirectEnabled="true" on the Context in
>> >$CATALINA_BASE/conf/context.xml
>>
>> The resulting $CATALINA_BASE/conf/context.xml was:
>>
>>
>> WEB-INF/web.xml
>> ${catalina.base}/conf/web.xml
>>
>> mapperContextRootRedirectEnabled="true"
>> mapperDirectoryRedirectEnabled="true"
>>
>
>mapperContextRootRedirectEnabled and
>mapperDirectoryRedirectEnabled
>
>are attributes of the Context so your context.xml should look like the one
>below:
>
>mapperDirectoryRedirectEnabled="true">
>WEB-INF/web.xml
>${catalina.base}/conf/web.xml
>
>
>Regards,
>Violeta
That works! Mahalo for correcting the context.xml syntax. This workaround
will allow us to stay current with the latest Tomcat release. Is this
expected to be the default behavior going forward?
Aloha,
-baron
>> >>
>> >> [...]
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
On Mon, Dec 14, 2015 at 09:12:20PM +, Mark Thomas wrote:
>On 14/12/2015 20:49, Baron Fujimoto wrote:
>> On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote:
>>> On Sat, Dec 12, 2015 at 12:16:01AM +, Mark Thomas wrote:
>
>
>
>>> I've confirmed that the problem begins with 8.0.29.
>
>Looking through the changelog it is hard to see how any of the changes
>not in the Catalina section could trigger this. So, focussing on that
>section...
>
>>>> If you can find out how the CSRF protection is adding the token then
>>>> that will also help since it gives an idea of what to look for in the
>>>> changelog.
>>>
>>> I believe it's done using the OWASP CSRFGuard Project, and I have the
>>> property files generated by the Grouper devs that define its
>>> configuration. I'll query the Grouper folks to confirm and see if they
>>> can provide a relevant and succinct explanation about this in particular.
>>
>> The Grouper devs explain, "Javascript sets an HTTP header called
>> OWASP_CSRFTOKEN: on requests (some excluded per properties file)".
>
>That doesn't explain how/where the token is generated or what component
>validates it server side. I'm guessing a Filter does the validation.
>
>> Per the properties file, I believe the following are excluded:
>>
>> org.owasp.csrfguard.unprotected.Default=%servletContext%/
>
>Hmm. This first one combined with the last entry in the Catalina section
>of the 8.0.29 changelog look like a possibility.
>
>Try each of the following (one at a time, not together) to see if they
>fix it:
Neither of these, tried independently, appeared to have any effect.
>a) Add the following (note the lack of trailing slash) to the properties
>file:
>
>org.owasp.csrfguard.unprotected.Upload=%servletContext%
I tried this as described, but since I wasn't sure if you really meant the
.Default property I also tried that, just in case (separate tests,
performed independently). I tried both by adding the suggested definitions
after their original definitions (in case they superceded them) and by
replacing the original definitions.
>b) Set mapperContextRootRedirectEnabled="true" and
>mapperDirectoryRedirectEnabled="true" on the Context in
>$CATALINA_BASE/conf/context.xml
The resulting $CATALINA_BASE/conf/context.xml was:
WEB-INF/web.xml
${catalina.base}/conf/web.xml
mapperContextRootRedirectEnabled="true"
mapperDirectoryRedirectEnabled="true"
Aloha,
-baron
>> org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html
>> org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
>> org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html
>> org.owasp.csrfguard.unprotected.Error=%servletContext%/error.html
>> org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html
>> org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html
>> org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
>> org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp
>> org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp
>> org.owasp.csrfguard.unprotected.Session=%servletContext%/session.jsp
>>
>> CSRFGuard defines the following actions for a detected attack:
>>
>> org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
>> org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery
>> (CSRF) attack thwarted (user:%user%, ip:%remote_ip%,
>> method:%request_method%, uri:%request_uri%, error:%exception_message%)
>> org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
>> org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html
>> org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
>>
>> Other misc CSRFGuard confs:
>>
>> org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
>> org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
>> org.owasp.csrfguard.TokenLength=32
>> org.owasp.csrfguard.PRNG=SHA1PRNG
>> org.owasp.csrfguard.PRNG.Provider=SUN
>>
>> org.owasp.csrfguard.JavascriptServlet.domainStrict = true
>> org.owasp.csrfguard.JavascriptServlet.cacheControl = private, maxage=28800
>> org.owasp.csrfguard.JavascriptServlet.refererPattern = .*
>> org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = true
>> org.owasp.csrfguard.JavascriptServlet.injectIntoForms = true
>> org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = true
>>
>> Here is an example of a resulting URL/token that results in the error.
>>
>> <https://foo.ex
Re: CSRF errors after upgrade of tomcat 8
On Fri, Dec 11, 2015 at 05:02:43PM -1000, Baron Fujimoto wrote: >On Sat, Dec 12, 2015 at 12:16:01AM +, Mark Thomas wrote: >>On 12/12/2015 00:01, Baron Fujimoto wrote: >>> >>> On Fri, Dec 11, 2015 at 09:25:12PM +, Mark Thomas wrote: >>>> On 11/12/2015 21:10, Baron Fujimoto wrote: >>>>> After upgrading Tomcat from 8.0.24 to 8.0.30, one of our applications >>>>> (Internet2's Grouper) "broke" with CSRF errors. Research turned up the >>>>> following in the Tomcat8 Changelog: >>>>> >>>>> "Add a new RestCsrfPreventionFilter that provides basic CSRF protection >>>>> for REST APIs." >>>> >>>> Apart from the fact that that entry includes "CSRF" and it is your CSRF >>>> protection that is broken, what evidence to you have that the two are >>>> related? >>>> >>>>> However, Grouper already incorporates CSRF protection using OWASP >>>>> CSRFGuard >>>>> <https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>. >>>>> >>>>> It appears that the new Tomcat RestCSRF feature interacts with OWASP >>>>> CSRFGuard poorly. The new Tomcat RestCSRF is apparently enabled by default >>>>> since I did not to anything to specifically enable it. >>>> >>>> What are you basing this assertion on? Evidence to back up the claim >>>> that Tomcat's RestCSRF protection is enabled by default is required. >>> >>> Ok, I'll concede your points. This is what I know: >>> >>> Upgrading Tomcat from 8.0.24 to 8.0.30 resulted in CSRF related failures. >>> I made no other changes to the existing Tomcat or application configs. >>> Therefore I concluded that the new failure mode is the result of some >>> difference between the Tomcat versions. Reverting back to 8.0.24 >>> eliminates the problem. >>> >>> The actual error logged is from the OWASP CSRFGuard package. >>> >>> ERROR CsrfGuardLogger.log(47) - - potential cross-site request forgery >>> (CSRF) attack thwarted (user:, ip:xxx.xxx.xxx.xxx, method:GET, >>> uri:/grouper/grouperUi, error:required token is missing from the request) >>> >>> So I, naively perhaps, looked for CSRF related changes that may have >>> accounted for that. It seemed reasonable, to me at least, that two >>> features purported to serve similar purposes could step on each other's >>> toes. >>> >>>>> How do I disable it? >>>> >>>> The same way you disable any Servlet Filter. >>>> >>>>> I didn't see any information on how to do this in the documentation at >>>>> <https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>. >>>> >>>> The Tomcat docs assume that users of Tomcat are familiar with the >>>> Servlet specification and therefore don't need to be told the details of >>>> how to enable/disable Filters, Servlets etc. >>> >>> I will also concede I have not waded through the 200+ page Servlet >>> specification doc. I have now looked over the filter section of the >>> specification, and based on section 6.2.4, "A filter is defined ... in the >>> deployment descriptor using the element" I'm inferring that a >>> filter is not enabled unless so defined. If this is in fact explicitly >>> stated somewhere, then I have overlooked it. I'll simply note though that >>> some sort of documentation to that effect would add a lot of clarity for >>> me. >>> >>>>> Since the app already provides CSRF protection that is carefully >>>>> configured it with which URLs need protection, etc., it seems redundant >>>>> for the container to do it. And actually, since it has now apparently >>>>> broken the app, I would like to turn it off Tomcat's version. >>>> >>>> Again, where is the evidence that Tomcat RestCSRF filter is responsible >>>> for the behaviour you are seeing? >>>> >>>> Hint: The root cause is not what you think it is. You need to do a >>>> little more research. >>> >>> As I've conceded, I may well have made an unwarranted assumption >>> about the probable root cause. Let me take a step back then and ask, >>> given the problems encountered as a result of the upgrade, what >>> can I do to identify the source of the probl
Re: CSRF errors after upgrade of tomcat 8
On Fri, Dec 11, 2015 at 09:25:12PM +, Mark Thomas wrote: >On 11/12/2015 21:10, Baron Fujimoto wrote: >> After upgrading Tomcat from 8.0.24 to 8.0.30, one of our applications >> (Internet2's Grouper) "broke" with CSRF errors. Research turned up the >> following in the Tomcat8 Changelog: >> >> "Add a new RestCsrfPreventionFilter that provides basic CSRF protection >> for REST APIs." > >Apart from the fact that that entry includes "CSRF" and it is your CSRF >protection that is broken, what evidence to you have that the two are >related? > >> However, Grouper already incorporates CSRF protection using OWASP CSRFGuard >> <https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>. >> >> It appears that the new Tomcat RestCSRF feature interacts with OWASP >> CSRFGuard poorly. The new Tomcat RestCSRF is apparently enabled by default >> since I did not to anything to specifically enable it. > >What are you basing this assertion on? Evidence to back up the claim >that Tomcat's RestCSRF protection is enabled by default is required. Ok, I'll concede your points. This is what I know: Upgrading Tomcat from 8.0.24 to 8.0.30 resulted in CSRF related failures. I made no other changes to the existing Tomcat or application configs. Therefore I concluded that the new failure mode is the result of some difference between the Tomcat versions. Reverting back to 8.0.24 eliminates the problem. The actual error logged is from the OWASP CSRFGuard package. ERROR CsrfGuardLogger.log(47) - - potential cross-site request forgery (CSRF) attack thwarted (user:, ip:xxx.xxx.xxx.xxx, method:GET, uri:/grouper/grouperUi, error:required token is missing from the request) So I, naively perhaps, looked for CSRF related changes that may have accounted for that. It seemed reasonable, to me at least, that two features purported to serve similar purposes could step on each other's toes. >> How do I disable it? > >The same way you disable any Servlet Filter. > >> I didn't see any information on how to do this in the documentation at >> <https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>. > >The Tomcat docs assume that users of Tomcat are familiar with the >Servlet specification and therefore don't need to be told the details of >how to enable/disable Filters, Servlets etc. I will also concede I have not waded through the 200+ page Servlet specification doc. I have now looked over the filter section of the specification, and based on section 6.2.4, "A filter is defined ... in the deployment descriptor using the element" I'm inferring that a filter is not enabled unless so defined. If this is in fact explicitly stated somewhere, then I have overlooked it. I'll simply note though that some sort of documentation to that effect would add a lot of clarity for me. >> Since the app already provides CSRF protection that is carefully >> configured it with which URLs need protection, etc., it seems redundant >> for the container to do it. And actually, since it has now apparently >> broken the app, I would like to turn it off Tomcat's version. > >Again, where is the evidence that Tomcat RestCSRF filter is responsible >for the behaviour you are seeing? > >Hint: The root cause is not what you think it is. You need to do a >little more research. As I've conceded, I may well have made an unwarranted assumption about the probable root cause. Let me take a step back then and ask, given the problems encountered as a result of the upgrade, what can I do to identify the source of the problem? Aloha, -baron -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CSRF errors after upgrade of tomcat 8
After upgrading Tomcat from 8.0.24 to 8.0.30, one of our applications (Internet2's Grouper) "broke" with CSRF errors. Research turned up the following in the Tomcat8 Changelog: "Add a new RestCsrfPreventionFilter that provides basic CSRF protection for REST APIs." However, Grouper already incorporates CSRF protection using OWASP CSRFGuard <https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>. It appears that the new Tomcat RestCSRF feature interacts with OWASP CSRFGuard poorly. The new Tomcat RestCSRF is apparently enabled by default since I did not to anything to specifically enable it. How do I disable it? I didn't see any information on how to do this in the documentation at <https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>. Since the app already provides CSRF protection that is carefully configured it with which URLs need protection, etc., it seems redundant for the container to do it. And actually, since it has now apparently broken the app, I would like to turn it off Tomcat's version. -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CSRF errors after upgrade of tomcat 8
On Sat, Dec 12, 2015 at 12:16:01AM +, Mark Thomas wrote: >On 12/12/2015 00:01, Baron Fujimoto wrote: >> >> On Fri, Dec 11, 2015 at 09:25:12PM +, Mark Thomas wrote: >>> On 11/12/2015 21:10, Baron Fujimoto wrote: >>>> After upgrading Tomcat from 8.0.24 to 8.0.30, one of our applications >>>> (Internet2's Grouper) "broke" with CSRF errors. Research turned up the >>>> following in the Tomcat8 Changelog: >>>> >>>> "Add a new RestCsrfPreventionFilter that provides basic CSRF protection >>>> for REST APIs." >>> >>> Apart from the fact that that entry includes "CSRF" and it is your CSRF >>> protection that is broken, what evidence to you have that the two are >>> related? >>> >>>> However, Grouper already incorporates CSRF protection using OWASP CSRFGuard >>>> <https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>. >>>> >>>> It appears that the new Tomcat RestCSRF feature interacts with OWASP >>>> CSRFGuard poorly. The new Tomcat RestCSRF is apparently enabled by default >>>> since I did not to anything to specifically enable it. >>> >>> What are you basing this assertion on? Evidence to back up the claim >>> that Tomcat's RestCSRF protection is enabled by default is required. >> >> Ok, I'll concede your points. This is what I know: >> >> Upgrading Tomcat from 8.0.24 to 8.0.30 resulted in CSRF related failures. >> I made no other changes to the existing Tomcat or application configs. >> Therefore I concluded that the new failure mode is the result of some >> difference between the Tomcat versions. Reverting back to 8.0.24 >> eliminates the problem. >> >> The actual error logged is from the OWASP CSRFGuard package. >> >> ERROR CsrfGuardLogger.log(47) - - potential cross-site request forgery >> (CSRF) attack thwarted (user:, ip:xxx.xxx.xxx.xxx, method:GET, >> uri:/grouper/grouperUi, error:required token is missing from the request) >> >> So I, naively perhaps, looked for CSRF related changes that may have >> accounted for that. It seemed reasonable, to me at least, that two >> features purported to serve similar purposes could step on each other's >> toes. >> >>>> How do I disable it? >>> >>> The same way you disable any Servlet Filter. >>> >>>> I didn't see any information on how to do this in the documentation at >>>> <https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>. >>> >>> The Tomcat docs assume that users of Tomcat are familiar with the >>> Servlet specification and therefore don't need to be told the details of >>> how to enable/disable Filters, Servlets etc. >> >> I will also concede I have not waded through the 200+ page Servlet >> specification doc. I have now looked over the filter section of the >> specification, and based on section 6.2.4, "A filter is defined ... in the >> deployment descriptor using the element" I'm inferring that a >> filter is not enabled unless so defined. If this is in fact explicitly >> stated somewhere, then I have overlooked it. I'll simply note though that >> some sort of documentation to that effect would add a lot of clarity for >> me. >> >>>> Since the app already provides CSRF protection that is carefully >>>> configured it with which URLs need protection, etc., it seems redundant >>>> for the container to do it. And actually, since it has now apparently >>>> broken the app, I would like to turn it off Tomcat's version. >>> >>> Again, where is the evidence that Tomcat RestCSRF filter is responsible >>> for the behaviour you are seeing? >>> >>> Hint: The root cause is not what you think it is. You need to do a >>> little more research. >> >> As I've conceded, I may well have made an unwarranted assumption >> about the probable root cause. Let me take a step back then and ask, >> given the problems encountered as a result of the upgrade, what >> can I do to identify the source of the problem? > >The first thing to do is to identify the Tomcat version that introduced >the problem. That makes reviewing the changelog easier. I've confirmed that the problem begins with 8.0.29. > >If you can find out how the CSRF protection is adding the token then >that will also help since it gives an idea of what to look for in the >changelog. I believe it's done using the OWASP CSRFGuard Project, and I have the property files generated by the Grouper devs that define its configuration. I'll query the Grouper folks to confirm and see if they can provide a relevant and succinct explanation about this in particular. -baron -- Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6-8 upgrade breaks logout script?
On Fri, Mar 20, 2015 at 05:46:42PM -0400, Christopher Schultz wrote: On 3/20/15 4:27 PM, Baron Fujimoto wrote: I hope someone may be able to provide some insight or a solution to a problem we encountered after I upgraded from Tomcat 6 to 8. We're using Tomcat as the servlet container for our Shibboleth IdP SSO, which we use to authenticate to Google Apps. Google allows you to configure a URL used for logout. We have this pointed at a logout.jsp page that basically does the following (excerpted code cribbed from the shibboleth-users list): https://groups.google.com/forum/#!msg/shibboleth-users/CFkau-FHCsA/yx7KRO9xMCoJ - - Cookie c; c = new Cookie(JSESSIONID, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); c = new Cookie(_idp_session, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); session.invalidate(); - This was working until I upgraded from Tomcat 6 to Tomcat 8. Since then, the cookies no longer seem to get wiped. Users are still logged in if they revist any of the Google Apps. Any suggestions or pointers on how to get this working again would be most appreciated. Try adding a trailing / onto the end of the path: c.setPath(/idp/); Ok, that seems to work. So mahalo for that! But I'd feel a lot better if I knew *why* that worked, and how I should have been able to figure that out myself. What I find even more confusing is that on one system, if revert to a version of the script that doesn't add the trailing /, it still works, but on another system, if I back out the change, it goes back to being broken. WAT? -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6-8 upgrade breaks logout script?
I hope someone may be able to provide some insight or a solution to a problem we encountered after I upgraded from Tomcat 6 to 8. We're using Tomcat as the servlet container for our Shibboleth IdP SSO, which we use to authenticate to Google Apps. Google allows you to configure a URL used for logout. We have this pointed at a logout.jsp page that basically does the following (excerpted code cribbed from the shibboleth-users list): https://groups.google.com/forum/#!msg/shibboleth-users/CFkau-FHCsA/yx7KRO9xMCoJ - Cookie c; c = new Cookie(JSESSIONID, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); c = new Cookie(_idp_session, null); c.setPath(/idp); c.setMaxAge(0); response.addCookie(c); session.invalidate(); - This was working until I upgraded from Tomcat 6 to Tomcat 8. Since then, the cookies no longer seem to get wiped. Users are still logged in if they revist any of the Google Apps. Any suggestions or pointers on how to get this working again would be most appreciated. Aloha, -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: 2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / However, when I test this by attempting connections with a script[*] that iterates through the set of ciphers available to openssl, it appears to successfully connect with the following set of ciphers: AES128-SHA DES-CBC-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-RC4-MD5 EXP-RC4-MD5 RC4-MD5 RC4-MD5 RC4-SHA [*] The script basically parses the output of the following command: openssl s_client -cipher $cipher -connect $SERVER Am I misunderstanding the use of the ciphers parameter? Or is there perhaps something in my testing methodology that accounts for these unexpected results? Any advice would be appreciated. As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Restricting ciphers
I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / However, when I test this by attempting connections with a script[*] that iterates through the set of ciphers available to openssl, it appears to successfully connect with the following set of ciphers: AES128-SHA DES-CBC-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-RC4-MD5 EXP-RC4-MD5 RC4-MD5 RC4-MD5 RC4-SHA [*] The script basically parses the output of the following command: openssl s_client -cipher $cipher -connect $SERVER Am I misunderstanding the use of the ciphers parameter? Or is there perhaps something in my testing methodology that accounts for these unexpected results? Any advice would be appreciated. Aloha, -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
