Re: Tomcat embedded with Apache Solr

[Shawn Heisey]

On 10/15/2018 2:15 AM, Jäkel, Guido wrote:

I have no experience with embedded tomcat, but it should be also straight 
forward. Said that, I can't imagine the advantage of such an approach against 
the currently used, which just start the Web Application Server (Jetty, Tomcat 
or whatever) with the preinstalled Solr application.


Probably the top reason for embedding the network layer (currently 
Jetty) is to have all of the global config (both for the 
network/container layer and for the Solr node itself) live in one place.


Right now, when running in cloud mode, a node could register itself with 
the cluster using completely invalid information -- wrong host/address, 
wrong port, wrong context path (normally /solr -- changing it causes big 
problems with 5.0 and later).  Changing to embedded would allow us to 
ensure that the info used in node registration is the same info used to 
initialize the node.  It would be overall much cleaner, and we would be 
able to finally say that the end user is starting Solr -- not Jetty or 
any other container.


Here's the info about why things are as they are currently, with a 
little bit of info about where we want things to end up:


https://wiki.apache.org/solr/WhyNoWar

Christopher already shared the issue I filed for the effort in setting 
Solr up as a standalone application.  It is an umbrella issue with one 
child issue currently:


https://issues.apache.org/jira/browse/SOLR-6733

Another point in Jetty's favor:  We are in the process of switching from 
Apache httpclient to Jetty httpclient, for http/2 support.  The new 
Apache client with http/2 support is only recently into beta status.  It 
was in alpha state for a REALLY long time, and we expect the beta state 
to last for another several months, possibly a year or longer.  The 
jetty client with http/2 support has been available in a stable version 
almost as long as the http/2 RFC has been published, and has had all 
that time with heavy usage for the showstopper bugs to be worked out.  I 
personally think it's tragic that we're switching away from Apache for 
our httpclient, but I'm in favor of the switch for the reasons 
outlined.  Compatibility with the server is expected to be better if 
both are from the same development team.


Thanks,
Shawn


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

Re: JVM keystores and CA

[Igor Cicimov]

Hi Chris,

On Fri, Oct 19, 2018 at 2:14 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Igor,
>
> On 10/16/18 17:03, Igor Cicimov wrote:
> > On Tue, Oct 16, 2018 at 8:56 PM Igor Cicimov 
> > wrote:
> >
> >> Hi Jose,
> >>
> >> On Tue, Oct 16, 2018 at 5:52 PM Jose María Zaragoza
> >>  wrote:
> >>
> >>> Hi
> >>>
> >>> El mar., 16 oct. 2018 a las 1:49, Igor Cicimov
> >>> () escribió:
> 
>  Hi all,
> 
>  I just want to clarify something that I've been seeing
>  behave
> >>> differently
>  on various Java versions during the years. In case we have
>  the following setting:
> 
>  -Djavax.net.ssl.trustStore=/keystore/truststore.jks"
> 
>  in Tomcat's default config file, is JVM suppose to fall back
>  to the
> >>> global
>  CA store on the server under /etc/ssl/certs for verification
>  in case
> >>> *any*
>  of the certificates returned by a trusted domain are not
>  present in the above JKS store? By any I mean, all the certs
>  in the chain returned by
> >>> the
>  SSL handshake.
> 
>  For example, lets say we have a situation like this:
> 
>  DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 ->
>  CN=*.mydomain.com
> 
>  Lets say I have imported the *CN=*.mydomain.com
>  * certificate in the truststore.jks, the
>  question is is JVM going to look under /etc/ssl/certs for
>  RapidSSL in order to validate the CN signature
> >>> and
>  then for DigiCert to validate the RapidSSL cert?
> 
>  As I said I had a mixed luck with this over the years,
>  sometimes it
> >>> works
>  as (I) expect it to work i.e. verify the certs by looking at
>  the system
> >>> CA
>  store and sometimes this is not the case.
> >>>
> >>> My experience is that if you store a server certificate in the
> >>> truststore.jks , don't search anyone more.
> >>>
> >>
> >> That's my experience too ... most of the time. But what happens
> >> when lets say the domain returns multiple certificates in the
> >> handshake, like the intermediate and the domain certificate? For
> >> the example above I gave:
> >>
> >> DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 ->
> >> CN=*.mydomain.com
> >>
> >> what if what is sent back are the Intermediate (RapidSSL TLS RSA
> >> CA G1) and the domain one (*.mydomain.com) cert in the chain? Is
> >> Java going to need to validate the Intermediate cert now too?
> >> There is only the domain cert in the truststore so how is it
> >> going to validate the Intermediate in this case? Is the
> >> Intermediate ignored maybe since the domain one validates
> >> anyway?
> >>
> >> This behaviour makes sense for me because you are saying that
> >> you
> >>> trust in that certificate because you verified ( by other means
> >>> ) it before Even if certificate is expired ( and server send it
> >>> expired too, obviously ) , I think that is validated as
> >>> trusted
> >>>
> >>> Regards
> >>>
> >>>
> > To make it more clear, with a custom trusted keystore how do the
> > certs that are not trusted get validated? Now Java needs to
> > validate the whole chain so where does it look for the CAs? In its
> > own keystore $JAVA_HOME/jre/lib/security/cacerts or under
> > /etc/ssl/certs ?
>
> Java has no notion of CAs, nor does any trust store, really.


Correct, but by loading all CAs in the trust store it kinda does,
indirectly.

A
> certificate is trusted if it is present in the trust store, full stop.
> It not need be a "CA". The oly thing being a CA gets you is ... in
> everyone's default trust stores.
>

> The system property javax.net.ssl.trustStore only sets the default
> trust store for the JVM and any components which choose to use it. For
> example, if you use HttpURLConnection without any explicit
> configuration, it will use that. Same with Apache httpclient.
>
> But both of those can be configured to use a different trust store,
> which case they will *not* fall-back to the built-in trust store (the
> one in JAVA_HOME/lib/security/cacerts.
>
>
Well I see couple of issues with this approach of the trsutstore being the
only source of truth. First is the obvious one, when using a custom trust
store
I have to load *all* CA certificates that already exist somewhere else on
the
server (and in multiple places) in the trust store too otherwise no
certificate will
ever get validated.


> When overriding the default trust store for the JVM, the trust store
> you specify should be the ONLY trust store consulted. It should not
> fall back. I can confirm this is the case on Java 8 - 11, at least the
> ones I happen to be using. Any other behavior would be a security proble
> m.
>
>
Not sure I can agree with this reasoning too. All apps on the server use
the default
system CA store so should we consider them insecure? I see no harm of Java
looking
in the default location(s) on the server when a cert can not be 

Re: Separate threadpool for url patterns

[Mark Thomas]

On 18/10/18 21:39, Phil Clay wrote:



> So my questions are:
> 1) Is there another way of delegating processing of certain url patterns to a 
> separate threadpool?

No. Tomcat does not provide such a feature.

> 2) Is this a bug?  i.e. should filterChains still be usable after doFilter 
> returns if request.startAsync() has been called?

This is not a bug. It is the behaviour required by the Servlet
specification. I recommend you read section 2.3.3.3 of the Servlet spec
for further details.

Mark

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

HTTP2 vs. HTTP 1.1 Performance Demo

[Igal Sapir]

I published a video that shows the performance benefits of HTTP/2 vs 
HTTP/1.1


To see just the demo, skip to 1:39 - https://youtu.be/jhqrRT4fvOA?t=99

To watch from the beginning where there is some more information about 
the h2 protocol, visit https://youtu.be/jhqrRT4fvOA


h/t Jean-Frederic Clere and Simone Bordet for inspiring the demo

Best,

Igal



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

Separate threadpool for url patterns

[Phil Clay]

Hi,

On Tomcat 9.0.12, what is the recommended way of having HTTP requests sent to a 
certain URL pattern be processed on a separate threadpool from all other 
requests?


I have found that the HTTP Connectors can only be configured with one executor, 
therefore all requests always get processed on that single executor.


I tried to implement a Filter that takes advantage of Servlet 3.0 async 
processing to delegate processing the remaining filterChain to a separate 
executor, but have found that the filterChain is released after the main thread 
finishes, and therefore is not usable on the downstream thread pool.

For example:

public class SeparateThreadPoolFilter implements Filter {
    
    private static final Logger logger = 
LoggerFactory.getLogger(SeparateThreadPoolFilter.class);
    
    private final Executor executor;

    public SeparateThreadPoolFilter(Executor executor) {
        this.executor = executor;
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain chain)
            throws IOException, ServletException {
        
        AsyncContext asyncContext = request.startAsync();
        
        executor.execute(() -> {
            try {
                // This chain is no longer usable, because it is released in 
the main thread after doFilter returns
                chain.doFilter(request, response);
            } catch (IOException | ServletException e) {
                logger.error("Exception occurred while executing HTTP request 
on separate threadpool" + e);
            } finally {
                asyncContext.complete();
            }
        });
    }

}

I have configured this as the first filter in the chain for the the desired url 
patterns.  I create and register this filter programmatically, and pass the 
desired Executor into the constructor.

What I have observed is that after doFilter returns, Tomcat will release the 
filterChain here...

https://github.com/apache/tomcat/blob/acaeccf3df95b24904c5f0ca9dd0f553d8f43289/java/org/apache/catalina/core/StandardWrapperValve.java#L254

Releasing the filter chain makes it unusable, since it removes all the filters, 
and the servlet...

https://github.com/apache/tomcat/blob/acaeccf3df95b24904c5f0ca9dd0f553d8f43289/java/org/apache/catalina/core/ApplicationFilterChain.java#L295-L306

Therefore, a NullPointerException occurs within ApplicationFilterChain when it 
tries to invoke the servlet (which is now null)...

Exception in thread "worker-11" java.lang.NullPointerException
    at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
    at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
    at 
com.example.SeparateThreadPoolFilter.lambda$0(SeparateThreadPoolFilter.java:34)


So my questions are:
1) Is there another way of delegating processing of certain url patterns to a 
separate threadpool?
2) Is this a bug?  i.e. should filterChains still be usable after doFilter 
returns if request.startAsync() has been called?

Thank you,

Phil

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

Re: [OT] Oracle Java 11 discussion?

[Johan Compagner]

>
>
> > There is no jre at all any more also from openjdk
>
> There is little difference between a JRE and a JDK. One just comes
> with a compiler.
>

not really,
until java 10 we had also desktop integration

like java -jar assignments and jnlp association for starting a webstart
application

so for windows it really integrated also into the registry.

but thats pretty much all gone now, maybe if you pay oracle?


> > Java on the desktop is really dead now (and we have quite a few
> > customers using that through webstart)
>
> Webstart is also dead. But let's be honest, Java on the desktop was
> never really alive in the first place.


Not for us!
we have a lot of customers that all use our webstart client to run there
own created applications in it..

Those users are end users like crm systems and so on. Not developers

Besides that also a lot of companies have i think in house stuff that run
like that.

Yes applets are dead for a long time, but Webstart applications are fine
and is a good way to get desktop applications that are auto updateable
But thats pretty much killed now
The weird thing is people say now use jlink that is the replacement for
it.. Huh?? what??

Re: Error Regarding RFC 7230 and RC 3986

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/18/18 09:09, Mark H. Wood wrote:
> On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
>> Thanks a bunch Mark.
>> 
>> "The correct fix is to ensure that the user agents are sending 
>> specification compliant requests." - Do you mean at browser level
>> ? If so, is there any specific browser/update we can use? We've
>> checked a few browsers so far (Firefox, Edge, Chrome) and none of
>> them seem to have this option (or we might've missed it).
> 
> [snip]
> 
 The URI we have for this problem has the following param (did
 work with 8.5.28)
 
 defaultMessageType=true=en_US=[key:label.edit]
> 
> The browser did not actually *compose* that parameter, did it?
> 
> If I had this problem, given only what I know from this thread, I 
> would suppose that the page which contained an href having such a 
> parameter is the source of the problem.  Some link is improperly 
> encoded.

Nope. Because if the application %-encodes those bracket characters,
the browser will double-%-encode them. There is literally no way to
get a browser to send the proper RFC-compliant character string, which
is why these hacks are necessary.

> I would say it is debatable whether browsers should be
> "correcting" hrefs which are handed to them by some site.

They are required to do so by the HTML specification. Well... the
HTML/HTTP spec also require them to do other things which they aren't
doing, so I suppose it's all the wild west out there. Did I mention
that ignoring standards hurts everybody?

IMO, HTTP/2 should have done-away with all of this and 100% required
clients and servers to implement the spec TO THE LETTER. Basically a
lot of "servers RFC-MUST cause the client to catch fire if the
encoding is incorrect" or something similar. But we all missed an
opportunity, there.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqsYACgkQHPApP6U8
pFi8zA/+KtWKJrOPn85xsW59lGBvZrxRP49DoLT7Smjkolpni99zCnHbR/QYfEqP
4iAo/GS1v11OtgJythTc26Ywy70Tm4KRWyrLwb+b4NfiChBaqzcg2k1mPL3N+spp
XDC7lfjzEHRtECuO9C/P1BJZ1+yQPaqBtZlczwanCLps7rveOc2z2Tysfo8AaFAy
2aURDpn/BsUrcS08FJMHaqBBsrBbQnvQ2fOjgV1v7umE21C/oZSEZ2/DMKfw+Tx4
92TwszW+cJloWRpSYVI0GA7ydSpw8GAfBbhci9VTc4PqHTxgUVkTQcem+8D90RtR
sa8aHy1CC6VILdtunApjcJCztnKn+6+XKqNEb5gHnI7uaEcU/I/hiGxqvfGv3fDh
o+gXD3YDwyJiG3v5ldJtP5GyIlmST0ihhDS8B1PyTHaYhEabU9flZ5Ul+pibU35X
aTPfBuN3+zHqAuNCZDSekHWTOHhwCHxeMhEBSYKe/8BxSXkfDpf+n1xGQWPtI/u2
gRQeI1BsqN+PAZDPXbeSMc2ArZoqHVxQ5WCUAQfdD37PC2L4s/t72jonRXNplRLt
X7EmwuaowURf7tJMetsWLmkWxbxaHQG0Cb4BwEOl3pST2vbNg9eZ4L6yW8+VCojx
WsvwSBrbZl6k55A19ZnRnoEdCTyWZh+8cObB8HZPrCGHgTsws4E=
=2/qX
-END PGP SIGNATURE-

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

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

[Alex O'Ree]

Roger that,  thanks

On Thu, Oct 18, 2018, 9:38 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alex,
>
> On 10/18/18 11:08, Alex O'Ree wrote:
> > Basically. I start with the tomcat distro, apply my changes,  then
> > zip it up and distribute. I'm at a situation when patches are
> > preferable over a complete reinstall of my product thus the
> > inquiry.  I can probably just replace all the tomcat bits and be
> > done with it.
>
> Tomcat only ships with .jar files and configuration. Feel free to just
> overwrite all the JAR files with the newer Tomcat ones. It's just as
> easy to replace all two-dozen of them as it would be to replace a
> single one, right?
>
> - -chris
>
> > On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Alex,
> >
> > On 10/14/18 18:06, Alex O'Ree wrote:
>  Is there perhaps a patch that can be applied or better yet, a
>  list of jars that are were affected by this? (I'm just trying
>  to find a simple way to patch a large volume of servers)
> >
> > There is nothing official. Nobody has individually identified
> > which svn revisions fix this issue, so your only options really
> > are:
> >
> > 1. Grab the previous version from source, apply all patches and
> > deploy (this is the same as just grabbing the new binaries,
> > assuming you trust ASF distros)
> >
> > 2. Grab the new binaries, determine which JARs are different
> > (which may not be super-easy), then copy those to each server. But
> > then you have a server which reports x.y.z but is actually x.y.z+∂
> > :(
> >
> > 3. Look at all the commits in ∂ and try to guess the problem.
> > Then, mitigate it at e.g. reverse-proxy of WAF level. One way would
> > be to prevent redirects to sites other than your own (which is
> > really the big danger for open-redirects). Just look for
> > sketchy-looking Location response headers. :)
> >
> > I'm curious how you handle upgrades in general. This certainly
> > isn't the first security issue inn Tomcat that requires an update
> > in your environment. How do you usually handle updates?
> >
> > -chris
> >
>  On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  Mark and Michael,
> 
>  On 10/10/18 05:15, Mark Thomas wrote:
> >>> On 08/10/18 21:55, Michael Yoder wrote:
>  On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas
>   wrote:
> > CVE-2018-11784 Apache Tomcat - Open Redirect
> 
>  Is it possible to get more information on the
>  "specially crafted URL"? I'd like more information so
>  that I can test if some of our apps are vulnerable.
> >>>
> >>> Generally, there is a balance to strike here between
> >>> making it easy for the less technically competent
> >>> attackers to construct an attack and making it easy for
> >>> end users to figure out if they are vulnerable. The way
> >>> we typically do this is by describing the conditions
> >>> necessary for an attack to be possible as completely as
> >>> possible but not providing details of how to perform an
> >>> attack.
> >>>
> >>> We also provide references to the commit that fixed
> >>> the issue. For someone with the right skills, there is
> >>> usually enough information in the description and the
> >>> commit for a successful attack to be reverse
> >>> engineered.
> 
>  It doesn't look like Sergey has posted anything (that I can
>  find) that might be called a full disclosure. If he had, I'd
>  point it out.
> 
>  If I were you, I'd just make sure that you either (a) upgrade
>  or (b) use the existing settings to mitigate the potential
>  problem, as described in the announcement.
> 
>  -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
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqP0ACgkQHPApP6U8
> pFgc9A//Qw9voOII2A/tOhYKSlyAK4psc5Cmq0Yf0DDtDYJzWYNrIHg50gXYB/lh
> HnaPEYWLuhIcOHYVI/37FXiOpBLA502U4U/shY5kncA7aNvOYMM7wRd+BM5FJEOK
> b6W6P2oFqc+vuJXfGknoT7Ff7CCRkRE7vBRvZH9FHxMXqrpCInl3n5/NAvgjkuHn
> pA1rhCsu1+n7y6kDUhiL7HvY2SwYKfqx0WrhDfCyc9bzqPN9urP0uWZm4lJ1LP4V
> +PdbtEegTLrBXUA0A5IMXmTHItmACqdDh/K9XDIkfh2201igLFLAnXjFPM72dMUx
> wz0jEX/4x/cgy0GEgDG5DURyuHIP8OzuD2xPM3PdB88/DQhN8pnd7nZ6gBPEere8
> 

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex,

On 10/18/18 11:08, Alex O'Ree wrote:
> Basically. I start with the tomcat distro, apply my changes,  then
> zip it up and distribute. I'm at a situation when patches are
> preferable over a complete reinstall of my product thus the
> inquiry.  I can probably just replace all the tomcat bits and be
> done with it.

Tomcat only ships with .jar files and configuration. Feel free to just
overwrite all the JAR files with the newer Tomcat ones. It's just as
easy to replace all two-dozen of them as it would be to replace a
single one, right?

- -chris

> On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Alex,
> 
> On 10/14/18 18:06, Alex O'Ree wrote:
 Is there perhaps a patch that can be applied or better yet, a
 list of jars that are were affected by this? (I'm just trying
 to find a simple way to patch a large volume of servers)
> 
> There is nothing official. Nobody has individually identified
> which svn revisions fix this issue, so your only options really
> are:
> 
> 1. Grab the previous version from source, apply all patches and
> deploy (this is the same as just grabbing the new binaries,
> assuming you trust ASF distros)
> 
> 2. Grab the new binaries, determine which JARs are different
> (which may not be super-easy), then copy those to each server. But
> then you have a server which reports x.y.z but is actually x.y.z+∂
> :(
> 
> 3. Look at all the commits in ∂ and try to guess the problem.
> Then, mitigate it at e.g. reverse-proxy of WAF level. One way would
> be to prevent redirects to sites other than your own (which is
> really the big danger for open-redirects). Just look for
> sketchy-looking Location response headers. :)
> 
> I'm curious how you handle upgrades in general. This certainly
> isn't the first security issue inn Tomcat that requires an update
> in your environment. How do you usually handle updates?
> 
> -chris
> 
 On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 Mark and Michael,
 
 On 10/10/18 05:15, Mark Thomas wrote:
>>> On 08/10/18 21:55, Michael Yoder wrote:
 On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas 
  wrote:
> CVE-2018-11784 Apache Tomcat - Open Redirect
 
 Is it possible to get more information on the
 "specially crafted URL"? I'd like more information so
 that I can test if some of our apps are vulnerable.
>>> 
>>> Generally, there is a balance to strike here between
>>> making it easy for the less technically competent
>>> attackers to construct an attack and making it easy for
>>> end users to figure out if they are vulnerable. The way
>>> we typically do this is by describing the conditions
>>> necessary for an attack to be possible as completely as
>>> possible but not providing details of how to perform an
>>> attack.
>>> 
>>> We also provide references to the commit that fixed
>>> the issue. For someone with the right skills, there is
>>> usually enough information in the description and the
>>> commit for a successful attack to be reverse
>>> engineered.
 
 It doesn't look like Sergey has posted anything (that I can
 find) that might be called a full disclosure. If he had, I'd
 point it out.
 
 If I were you, I'd just make sure that you either (a) upgrade
 or (b) use the existing settings to mitigate the potential
 problem, as described in the announcement.
 
 -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
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqP0ACgkQHPApP6U8
pFgc9A//Qw9voOII2A/tOhYKSlyAK4psc5Cmq0Yf0DDtDYJzWYNrIHg50gXYB/lh
HnaPEYWLuhIcOHYVI/37FXiOpBLA502U4U/shY5kncA7aNvOYMM7wRd+BM5FJEOK
b6W6P2oFqc+vuJXfGknoT7Ff7CCRkRE7vBRvZH9FHxMXqrpCInl3n5/NAvgjkuHn
pA1rhCsu1+n7y6kDUhiL7HvY2SwYKfqx0WrhDfCyc9bzqPN9urP0uWZm4lJ1LP4V
+PdbtEegTLrBXUA0A5IMXmTHItmACqdDh/K9XDIkfh2201igLFLAnXjFPM72dMUx
wz0jEX/4x/cgy0GEgDG5DURyuHIP8OzuD2xPM3PdB88/DQhN8pnd7nZ6gBPEere8
OAX+nrYNpI6MhHet6zeRAf0HBOXHDrgj86nxB9iPV02JQn5Y8tLIaVKeJ5JbH6L0
rzlDw+0CHXxnaz+p1ZzcxDjUckZQJsAHVZa7SqSfY54Oe4keSX5dihlyi7iT7JEd
On74o+sYd2F2fhEd1QgWT3kxjhdCcgsfOAwZRX+PYCVPfx/L4vv2IyUnotzxXaoM
u267+lUkD1e6/A7pLRRcNreW8TT/C39LphdjaGmShkJzKgixr6py8j/9OmakOY8S
8t0s/xkk3PFUGnKL7gFi/+rfTobbEM3TARRxqhmgkaqJcDB4Gg8=
=AYwn
-END PGP SIGNATURE-

Re: [OT] Oracle Java 11 discussion?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 10/17/18 12:28, Berneburg, Cris J. - US wrote:
> Thanks Mark
> 
> mt> The argument for a JRE vs a JDK is that the JDK includes mt> a
> compiler. The only reason Tomcat can run on a JRE and mt> still
> support JSPs (which require compilation) is that mt> Tomcat
> includes a Java compiler. I don't think the mt> security argument
> holds much water.
> 
> I had not thought of that, and you're right (literally technically
> speaking).
> 
> RAMBLE: However, if I try to look at it from a point of view of a
> large bureaucracy, of which I am largely ignorant, I would not be
> surprised if there is a policy against dev kits and IDE's on
> production servers for security sake.  Tomcat (whisper: with
> built-in compiler) is approved, but is the JDK allowed?  Guess I
> can ask.  Yeah, it's potentially a "distinction without a
> difference".  Well, unless there are other tools in the JDK that
> can pose security risks in addition to the Java compiler.

Hard and fast rule: no compilers.

Well, except for EJC, Perl, Python, PHP, *sh, and a host of other
things capable of running code.

It's a checkbox security "feature" that is all of meaningless,
ineffective, and inconvenient. These days, most servers have all the
code you'd already ever need to "compile" and run an exploit even if
there were no compiler there. All you need is a nice, vulnerable
pre-existing binary.

https://crypto.stanford.edu/~blynn/rop/

> mt> OpenJDK is very close to the Oracle JDK these days. I mt>
> regularly run Tomcat's unit tests with the latest OpenJDK mt> and
> have yet to find an issue that is OpenJDK specific. mt> mt> Tomcat
> runs happily (and is supported) on a JRE. mt> mt> If the JRE has
> passed the Java TCK then Tomcat should run mt> on it. I don't think
> there is an official Tomcat position mt> but my expectation is if a
> Tomcat bug (as opposed to a mt> Java bug) appears when running on
> any Java implementation mt> that has passed the TCK then the Tomcat
> team would treat mt> that as a Tomcat bug and fix it.
> 
> All good to know.
> 
> cjb> I am imagining spending all my time being taken up by cjb>
> Java upgrades with subsequent builds, regression testing, cjb> red
> tape, and deployments
> 
> mt> I'd plan to stick to the LTS releases.
> 
> Meh, not my call.  Whatever the Powers That Be decide for the 
> production environment, I'll probably match that in dev.  If they 
> decide LT$ is the way to go, using the JDK will cost nothing for
> my dev environment anyway.  But if OpenJDK and frequent updates
> are selected ... phooey.
They will decide to stick with Java 8, even though it's EOL. The
decision will be made because (a) "there are some incompatibilities
with Java 11 which are hairy to untangle" and (b) "Java 8 hasn't
caused a breach, yet, so we'll probably be fine".

Good luck!

I'm having trouble convincing a partner vendor to move from Java *6*
up to Java 8. *facepalm*

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIqB0ACgkQHPApP6U8
pFjKkg//QQ+ewAy0pyGGFvYtTeqQszqp1/ovQf5d1Tbv4NsDUH9iUtssW2PMb0Sa
/4NnBgtef9og0o4idn6ZH/2+I+bNx9/9Sp3Hpurosi7IKAuVCDo0IO97ccUqpaBd
OEy0giHx8ook91UOxHyCF9XFoAkJn1+DU41qw0pSSqIhAjPNXarRN3Fq3LzG3JEw
6q5yx3/chKuSpGw5ERhda7l7Sevlph0WGqz96Im7lW1Jmz+MQb/4Cigk9pmrhvw9
spJYE75Mp53CN2EWD2Z5k+Br60yL/XecT1VxXgMpVj8azMUMPtPCEUiwEJEy839A
vdeN6DDWbcjwNcyo9EOWt4yVI5t2cx7uc9eGtqrQTEREKHcrn+7ltKkr8bwRE7nz
EUiTC3uamhdCu6nRfiniSefCL3JXPZOXyeD0zUZBSK2HqWNEpWbFP8cAIHOhHHgY
w0qAOl52wDY+VeIw75raGk4AmjP/z4OpShLjp7Z6QD+mHhVkqQXQTuEmh6qptjQ7
SYEoOqqNurPK+T4R2pvYxQtydBqNi5dOQQ2G2dz7Wogq8imFEGYp+h0M2KDkXGyi
bLWv+AXQhJ+kdydbwbk1e7pH6zsxdGXwNCnU09bUhFSg4QoHqi3ngEkL5yL0mXz9
WQPYOnJcWgUrnEXwGhj3NKPMw2ivIAhz8ZvFEOsyOVwuWdEpjhg=
=lc0c
-END PGP SIGNATURE-

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

Re: [OT] Oracle Java 11 discussion?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 10/17/18 12:43, Berneburg, Cris J. - US wrote:
> Thanks Igal
> 
> mt> OpenJDK is very close to the Oracle JDK these days. I regularly
> run mt> Tomcat's unit tests with the latest OpenJDK and have yet to
> find an mt> issue that is OpenJDK specific.
> 
> is> I asked Gil Tene about this a couple of weeks ago.  Gil is a
> co- is> founder of Azul Systems, an OpenJDK committer, and on the
> Executive is> Committee of the JCP.  My understanding from him is
> that there is no is> JDK development outside of the OpenJDK.  The
> Oracle developers that is> work on the JDK commit directly to
> OpenJDK.  Oracle might add some is> other things when they package
> their edition of the JDK for is> distribution, but the JDK itself
> is the same one from OpenJDK.
> 
> Good to know.
> 
> is> The main problem with the rapid release cycle and six month
> support is> is that due to late adoption, many of the bugs in a
> given Java is> release are only discovered after more than six
> months of the release is> date.  That means that the free support
> will end while bugs and is> vulnerabilities are being discovered,
> forcing many organizations to is> pay for support.
> 
> Or frequent Java installations.
> 
> RAMBLE: Too bad there can't be an Apache OpenJRE umbrella project,
> with specific Apache OpenJRE [version X] sub-projects, that
> maintain JRE [version X]'s indefinitely.  One source (Apache) for
> all the different JRE's for the Java community at large, rather
> than depending on a bunch of different companies.  The OpenJRE
> source code could pull from the OpenJDK repository.  A potential
> issue could be back-porting bug fixes from later versions into
> earlier ones when the source code base has shifted drastically,
> making merges difficult.

I know it's not exactly what you meant, but...

http://harmony.apache.org/

You could always resurrect that project :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIpsAACgkQHPApP6U8
pFioUw/9FjG/PEHYjQq7e47Z0DOUQQBmtkepPKaeCaFSIUVMkE2nIFeqBmbGfSpu
iiXgYh4WfjBgoOGd8ZrFmfUNpHRuSK8g1OVM9iteJ9kCIOB0lXpjuQ3Z7i9Y0i9r
4z1b/KA+jzfDnG0AiBDyusio45Lcn2ztMsZA9ITJRvUUDHsjAZkGKhnmeSx5wBl1
RPdQJm4f4AicMJNuVxLedUbra0D2mXxOJtlAmMc05q9l2wvHi7hv1oHYKbJrn2zo
9cu4kjhkAAylJZ2bV3TN7M2cWuoQubdbDzmdRcKYGyEEpryRwOUHENPrOWXbi4xn
UHsXZQw9IIVt/TsruqbpFAbqffTHsIfBg34tfLCabXQA6J5vXf7yvQEt5NskyhVp
qNj+q1E6lYhAt0WGjR5GS70q5Mt/lMNVuwwGrV15/o1rbxyV96KIelIqdv9XMB6F
CCH73KFtdXV0yOPewWszwVRo9VF+IF6TOH5Mg0jefb2ECj2i3op+M0s486Gonhzb
wV9+NFHzEyZnCKGnijZdbrNYrQM3Deiq6ykGwcELewRUk164VYRVDY1L7NdUta/A
YCcgGLardkmrr6xwkP1P8BnT0t5b9bIxNA+d2JHyKvS4uUmNX7L+zc4xfoTgMAg8
MgTH9pYfl6KfLylKBD709kKm3SSx+eQY7pkDkwTjpN0XMawzvW8=
=NliJ
-END PGP SIGNATURE-

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

Re: [OT] Oracle Java 11 discussion?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Johan,

On 10/15/18 17:04, Johan Compagner wrote:
> Op ma 15 okt. 2018 20:37 schreef Mark Thomas :
> 
>> 
>> 
>> I'd be more concerned that Oracle are starting to charge for
>> production usage. That alone would be enough for me to switch to
>> OpenJDK.
>> 
> 
> Isnt that already the case?

Umm... yes.

> You can't download any installer of java 11 from Oracle that can be
> used in production, only for development and demos

Sure you can. You just have to pay them.

> There is no jre at all any more also from openjdk

There is little difference between a JRE and a JDK. One just comes
with a compiler.

> And open jdk doesnt have an installer at all, so it is all up to
> the package managers to get it (rpm/yum) so good luck on Windows
> with that (There is really just unzipping and setting paths
> you're self)

I've never installed Java any other way, so that's not really an issue
for me. Only recently have package-managers bothered to support
versions that are not insanely old. Now that I'll be switching to
OpenJDK, using a package-manager is going to look more attractive to me.

> Java on the desktop is really dead now (and we have quite a few
> customers using that through webstart)

Webstart is also dead. But let's be honest, Java on the desktop was
never really alive in the first place. The only tools I can think of
written in Java are mostly for developers. Yeah, there are a few
specialty things but mostly they come with their own JVMs, now (e.g.
Eclipse... which is also a developer tool). It's a huge waste of a
download, but what are you gonna do?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIpbIACgkQHPApP6U8
pFj0YA/7Btq4+JoBkqajBov98cAKsD1ld531HDc4VGRZJFuIjPXBZaWHCr/lQROk
tDBGE7VSA29KdzUk3zH/411vY8aaSFHYR4qDBAyVjHOz6lSvXkLmz/NP8WUu49q5
GCi2oZOjzZAaHzZGScwARED31XSI8Lxx4Qsz1LTIGXqoiDTSFMIpcVCGNagoe3SG
4k8YLUUm4ywIJfweLA9uZmf5yFayQg8xcAyiUfWVe961IeTMbKVspusZi7jq6Vk7
P5a5x6+0hQkV5OyNFRTDMX8Fa0ffewB8tEJi/EhIoKmKk4q5Y77S8TrSGI3C7TWr
ecsNtO0ijqPNQtBxcusnrRGTmJ/86VU+lar0UuMnz2a6NGk+vYcfs4bzcxb18jBN
cRqFkb6ziovgjqY30j1b3/S25PmUAVI8tuoki+NFap0XeysXahQTiEIhq6XH8ycg
Vib/0GvBb2lJW7YnLlzK7Rd5Ow/flCgyaiS9YxRBQDnQTUm27RS0GVB0+rPZEJbf
rU+XBFGnK+x6QDFJ3MOdKLrVFbXVrv0gRr1MVTDOC0eJkbqHX0iw9wob5rym1UzN
fUSaZh3O8rcmHsvBrs43SuA2cJSGqtQmLomrZTGUF0pNl/tCLl6ClaX5RewDSLng
jf3Yihlp82YSkjn/K1Vrd9u6RDrCYyLgYAbV9FIHx44NtlkQhYY=
=Y2Tj
-END PGP SIGNATURE-

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

Re: JVM keystores and CA

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Igor,

On 10/16/18 17:03, Igor Cicimov wrote:
> On Tue, Oct 16, 2018 at 8:56 PM Igor Cicimov 
> wrote:
> 
>> Hi Jose,
>> 
>> On Tue, Oct 16, 2018 at 5:52 PM Jose María Zaragoza
>>  wrote:
>> 
>>> Hi
>>> 
>>> El mar., 16 oct. 2018 a las 1:49, Igor Cicimov
>>> () escribió:
 
 Hi all,
 
 I just want to clarify something that I've been seeing
 behave
>>> differently
 on various Java versions during the years. In case we have
 the following setting:
 
 -Djavax.net.ssl.trustStore=/keystore/truststore.jks"
 
 in Tomcat's default config file, is JVM suppose to fall back
 to the
>>> global
 CA store on the server under /etc/ssl/certs for verification
 in case
>>> *any*
 of the certificates returned by a trusted domain are not
 present in the above JKS store? By any I mean, all the certs
 in the chain returned by
>>> the
 SSL handshake.
 
 For example, lets say we have a situation like this:
 
 DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 ->
 CN=*.mydomain.com
 
 Lets say I have imported the *CN=*.mydomain.com
 * certificate in the truststore.jks, the
 question is is JVM going to look under /etc/ssl/certs for
 RapidSSL in order to validate the CN signature
>>> and
 then for DigiCert to validate the RapidSSL cert?
 
 As I said I had a mixed luck with this over the years,
 sometimes it
>>> works
 as (I) expect it to work i.e. verify the certs by looking at
 the system
>>> CA
 store and sometimes this is not the case.
>>> 
>>> My experience is that if you store a server certificate in the 
>>> truststore.jks , don't search anyone more.
>>> 
>> 
>> That's my experience too ... most of the time. But what happens
>> when lets say the domain returns multiple certificates in the
>> handshake, like the intermediate and the domain certificate? For
>> the example above I gave:
>> 
>> DigiCert Global Root G2 -> RapidSSL TLS RSA CA G1 ->
>> CN=*.mydomain.com
>> 
>> what if what is sent back are the Intermediate (RapidSSL TLS RSA
>> CA G1) and the domain one (*.mydomain.com) cert in the chain? Is
>> Java going to need to validate the Intermediate cert now too?
>> There is only the domain cert in the truststore so how is it
>> going to validate the Intermediate in this case? Is the
>> Intermediate ignored maybe since the domain one validates 
>> anyway?
>> 
>> This behaviour makes sense for me because you are saying that
>> you
>>> trust in that certificate because you verified ( by other means
>>> ) it before Even if certificate is expired ( and server send it
>>> expired too, obviously ) , I think that is validated as
>>> trusted
>>> 
>>> Regards
>>> 
>>> 
> To make it more clear, with a custom trusted keystore how do the
> certs that are not trusted get validated? Now Java needs to
> validate the whole chain so where does it look for the CAs? In its
> own keystore $JAVA_HOME/jre/lib/security/cacerts or under
> /etc/ssl/certs ?

Java has no notion of CAs, nor does any trust store, really. A
certificate is trusted if it is present in the trust store, full stop.
It not need be a "CA". The oly thing being a CA gets you is ... in
everyone's default trust stores.

The system property javax.net.ssl.trustStore only sets the default
trust store for the JVM and any components which choose to use it. For
example, if you use HttpURLConnection without any explicit
configuration, it will use that. Same with Apache httpclient.

But both of those can be configured to use a different trust store,
which case they will *not* fall-back to the built-in trust store (the
one in JAVA_HOME/lib/security/cacerts.

When overriding the default trust store for the JVM, the trust store
you specify should be the ONLY trust store consulted. It should not
fall back. I can confirm this is the case on Java 8 - 11, at least the
ones I happen to be using. Any other behavior would be a security proble
m.

The proper way to validate a certificate chain is to perform the
following algorithm:

0. Start with the server's certificate (the leaf)
1. Is the certificate in the trust store?
   Yes: chain is valid; stop
2. Is the certificate signed by a cert in the trust store?
   Yes: chain is valid; stop
3. Is the certificate signed by the next cert in the chain?
   No: chain is invalid; stop
4. Move to the next cert in the chain
5. Go to step 1

So if you use an empty trust store and try to connect to
https://www.google.com, you should find that you get an exception
thrown. Something like this:

Exception in thread "main" javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

[Alex O'Ree]

Basically. I start with the tomcat distro, apply my changes,  then zip it
up and distribute. I'm at a situation when patches are preferable over a
complete reinstall of my product thus the inquiry.  I can probably just
replace all the tomcat bits and be done with it.


On Thu, Oct 18, 2018, 8:52 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alex,
>
> On 10/14/18 18:06, Alex O'Ree wrote:
> > Is there perhaps a patch that can be applied or better yet, a list
> > of jars that are were affected by this? (I'm just trying to find a
> > simple way to patch a large volume of servers)
>
> There is nothing official. Nobody has individually identified which
> svn revisions fix this issue, so your only options really are:
>
> 1. Grab the previous version from source, apply all patches and deploy
>(this is the same as just grabbing the new binaries, assuming you
> trust ASF distros)
>
> 2. Grab the new binaries, determine which JARs are different (which
> may not be super-easy), then copy those to each server. But then you
> have a server which reports x.y.z but is actually x.y.z+∂ :(
>
> 3. Look at all the commits in ∂ and try to guess the problem. Then,
> mitigate it at e.g. reverse-proxy of WAF level. One way would be to
> prevent redirects to sites other than your own (which is really the
> big danger for open-redirects). Just look for sketchy-looking Location
> response headers. :)
>
> I'm curious how you handle upgrades in general. This certainly isn't
> the first security issue inn Tomcat that requires an update in your
> environment. How do you usually handle updates?
>
> - -chris
>
> > On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Mark and Michael,
> >
> > On 10/10/18 05:15, Mark Thomas wrote:
>  On 08/10/18 21:55, Michael Yoder wrote:
> > On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas
> >  wrote:
> >> CVE-2018-11784 Apache Tomcat - Open Redirect
> >
> > Is it possible to get more information on the "specially
> > crafted URL"? I'd like more information so that I can test
> > if some of our apps are vulnerable.
> 
>  Generally, there is a balance to strike here between making
>  it easy for the less technically competent attackers to
>  construct an attack and making it easy for end users to
>  figure out if they are vulnerable. The way we typically do
>  this is by describing the conditions necessary for an attack
>  to be possible as completely as possible but not providing
>  details of how to perform an attack.
> 
>  We also provide references to the commit that fixed the
>  issue. For someone with the right skills, there is usually
>  enough information in the description and the commit for a
>  successful attack to be reverse engineered.
> >
> > It doesn't look like Sergey has posted anything (that I can find)
> > that might be called a full disclosure. If he had, I'd point it
> > out.
> >
> > If I were you, I'd just make sure that you either (a) upgrade or
> > (b) use the existing settings to mitigate the potential problem,
> > as described in the announcement.
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInigACgkQHPApP6U8
> pFhgDw/+L0SpWHz4IACgy7xB4ekyHpIt/5wbOEbqTfyZAh0m+LrSZgI73zPJuHtt
> pLnpwgx3lqwCiWTTFFpK8CqhiQ+a+2dKtSTeDlKRJuU4QZLDMSrgYpcWlGJ3h6w/
> LiM2KlnJ1i/jI95NVvoW8HFh/6wHCJLJV+czZJja3Uh/xQz/MTWhmh5dx3eVEIY6
> 7WTB/JNO02wzM8EudqHypypXmwI0pMLbsMsjTSikIHf8m41Qyd+XrY60DKZul8dv
> L6bolXxH23vGnxiv4fnN+tGzIaT1ptXmJ6u/MWFUODtD3PVR3CdjIp2JrXFd3GVN
> wGEow0tPRa3tsUvL/frllk22xhzbtxzu1M0Rf9U02TLB4nolyBIdJ5e3OyAnmS/Q
> ap3aAPVnFWz2twBxUbuXkk4aZ39YziziWqyFO36y5BFNKI5EQlI3GryDbmBZ6SeT
> vOJnMDwLy8o6kRcChNh1LmpjnbZMTYPmSkKEhfzf1tocDdBHZmd5yTIjBNrS0++V
> n572zrrTWiBbca39QKFqEgmB5iy4fWpkVYHPKqmOVT7JLhI74WRnKap9dqrSDGrP
> n1F4AjfuUjmG8H5Vo01bHWBav4aJuMDrLQ+Sr+sUl6uWPu5DDsG+1W9t2JAyC2Vq
> tfP9XLMNBDV+f0BUaYt2aPXmBmLe5IP8FNVAzO1W/2VJG7c1UrM=
> =E/P3
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: WebSockets and JSPs

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shawn,

On 10/16/18 00:00, Shawn Heisey wrote:
> On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
>> I have several webapps that do a significant amount of recursive
>> loads of snippits of HTML utilizing XHR/http/ajax requests. These
>> apps are all debugged and in production.   The server has no
>> problem whatsoever in keeping up with the multiple concurrent
>> requests.  However, the open-connection limits on the browsers
>> that block more than 6 concurrent connections to a server is
>> killing me in performance.
> 
> I know pretty much nothing about the things you asked about after
> this paragraph.  But I do know about one thing that might help you
> -- HTTP/2.  It can execute many HTTP requests simultaneously over a
> single TCP connection.

+1

h2 will improve your performance with basically zero other changes to
your environment or to your application.

> I really have no idea how to enable HTTP/2 in Tomcat, but I know
> that it can be done if you have a new enough version.

It's configured by default in Tomcat 8.5.x and later. Basically, you
just have to add this inside your  element in
conf/server.xml if it isn't already there:

  

> Another possibility is to put your web services behind a load
> balancer that supports HTTP/2 on the front end.  Haproxy is one
> that I am aware of with that support.

Basically everyone[1] supports h2. Hmm... no Squid. :(

Jerry, switching to Websocket basically requires you to rewrite your
application using a different protocol. I don't think you really want
to do that.

- -chris

[1] https://en.wikipedia.org/wiki/HTTP/2#Server_software
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvIoG4ACgkQHPApP6U8
pFgq8g//bU2tji+UM7j68ZRQIUazDTVlaQePwNLw5JicBuF+kkadBiSsKjp9qytO
P18JiuBTHm6AJZ/PrCvPrG4ceJbT7QzdMD1daj6hD5MkdOyPSiK0QTuqV5r+V7Dm
cjWGZ2F8WRIKN8w9BX3XNPZ3aLyf4pAd68EGow9R4Cm9FoMJ17kT1a1ALs/Iw0pX
5Ditcsl1SbnSyk+CxwgehLRkc7mub0c7Wk7bI6uYCzZrZt2ddNTmNON2Eqgzd+UB
R+6NoOpIiQV/mvP8jFaqBy+OcVIzbuzM/otBzkmgbNDimTrLsT790vOcDLD3BxtB
sZCVk1aC+7wO1Elq+104l/E/bFCPn8bFDspZdMpvp/wxrt80Co36Nw/4Jkg7QoGn
h1l8JI8R/bt5/jOQhcqQH2/4peilP0Zs6ASTB+U0tV0M6J6n/qDLjqo68ueMzgmN
Bo4cYATzO92G55T0WuGlQOynlPhrVS2s4u2mTVuaeMc8m863VdMiGhQh2anEqpJN
MumeH4JKFSsj78lzjWOenjE9/N0Gm00eeO1O0hYsnIOEyftv7osaXxBO0gJoKFHV
ZF1SkX7ogHfutt8Yzga7I6VK8184rt7EYohl6zf7QU4mdQIkVKBHQrlKRxddqIoQ
HIDmUOUPMuiq6V0i0E4QDxpvnG+1Ax1DvRrj20BJ1DuwII0odZY=
=FDC4
-END PGP SIGNATURE-

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

Re: Tomcat embedded with Apache Solr

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guido,

On 10/15/18 04:15, Jäkel, Guido wrote:
> Dear Christopher,
> 
> my 5ct on that: We're using Solr for years like (and together with)
> all other Webapps on Tomcat (and since some month on Wildfly) in a
> "classic" (non-cloud) setup without any the need for special
> tweaks.
> 
> There is no official support for an webapp artifact since some
> Versions, but one just have to extract the web application tree
> from the release.
> 
> I have no experience with embedded tomcat, but it should be also
> straight forward. Said that, I can't imagine the advantage of such
> an approach against the currently used, which just start the Web
> Application Server (Jetty, Tomcat or whatever) with the
> preinstalled Solr application.
> 
> We even have used it in the other way round: We used an embedded
> Solr Server as a SolrMaster instead of a SolrClient within an
> Ingest application to avoid the "serialization/network overhead" of
> big Solr documents. This Application was also hosted together with
> others on our Tomcat plattform

Thanks for the reply.

Actually, my goal was to convince the Solr team that switching from
Jetty to Tomcat was (a) possible and (b) possibly attractive. I agree
that "solr.sh start" is the right model for users. I'm just working on
getting them to consider Tomcat as the hosting container instead of
Jetty. Right now, "solr.sh start" launches Jetty with Solr configured
as a web application. They are considering using "real embedding" and
so Tomcat has an opportunity to be considered as the container for
that effort.

- -chris

>> -Original Message- From: Christopher Schultz
>> [mailto:ch...@christopherschultz.net] Sent: Sunday, October 14,
>> 2018 3:41 AM To: Tomcat Users List  
>> Subject: Tomcat embedded with Apache Solr
>> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> All,
>> 
>> I've posted a question to the Solr mailing list[1] about why
>> Jetty is being used instead of Tomcat, and it seems that it's
>> just "always the way it's been" for the most part.
>> 
>> These seems to be some interest in moving from their existing
>> model (Jetty launches, then hosts Solr as a web application) to
>> an embedded model where a Solr-agent launches and then launches
>> the app server (e.g. tc) hosting itself.
>> 
>> Is anyone familiar enough with Solr to whip-up a quick-and-dirty
>> POC for Tomcat-embedded-hosting-Solr?
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInvUACgkQHPApP6U8
pFgokQ/+IDJIEWrvtXg8WMGsnyikBwLpVafyNlje+nnNZDJ46bdL/5eAOeO0ef06
TidVZlbHtucP3gParlyDFAZE5+R5PLQw3Kb+aH5eZLShrUlF0/aBruG4sdAXt8b6
tN8eu9WmULz78AfX9wA5EvIKfKkps+ubYhbmZgMBnzHcARkMbG3FqKpIrEG36D3l
ixpPNrY/Ig7WDse20/+xbPVLpfkvYIlZuD1ks4ChRoUiMxSBUdTBcecI7b7ktzrT
OY6wxrrBPX4Ca37aA83oLw4EChPFy5bvR21P4wXFaA9yrT3GdvPNG0Rs7DiGR3PN
RSADf8dJ0Mle2azPB56+n2CPck5CLZllk8kbvyy1RV+9AQFDV0ytFPnS/34IbZf/
Q2lSgGyVLB3GAic3RzCqIAtRnUmJW6BSXtq8B8YGL5sy9HATTMj9f00xzDqTC38i
H22fnJohfTrsVj4VBklDEvE2V+9NEyj+guw/v0jKRlfiX8S98tHQuQD8kefTP4X2
vHkKaU0V5rNmO/Ix8jA9i9CVqNe5UX+nZThWe5gBHKxdFVpZ9VFWwTYgX9+eZiYc
+I1D6j1oQS+qEWw3RlPkTUei6GHVCrTsXlHxEN89k6mTOZi1x9xaq5G6th5AOa5B
VL3qxoVz/lWdSFaZLcN2kHwG/gBlSgqBa8V4m7kt83IDoUsGg2w=
=A9vT
-END PGP SIGNATURE-

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

Re: Tomcat/manager/ disable redirect from HTTPS to HTTP

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hans,

On 10/15/18 03:17, Hans Schou wrote:
> On Fri, 12 Oct 2018 at 14:12, Mark Thomas 
> wrote:
> 
>> 
>> For the HTTP connector processing proxied traffic originally
>> received over HTTPS you want: SSLEnabled="false" scheme="https" 
>> secure="true"
>> 
> 
> Thanks, this one is working exactly as expected:
> 
>  connectionTimeout="2" SSLEnabled="false" scheme="https" 
> secure="true" />
> 
> A bonus is that I now got forced use of SSL.

Note that port 8080 being TLS might be "surprising" to some clients.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInk4ACgkQHPApP6U8
pFjJhQ/9Em7SIjQY1EYUHdQQJHJlDKpF6leMw9eRgTZBsQm6KpjN7mHPxWSjnM6/
mlagtyAkKbC43k+a5oqn/NIPsCSGoLCT3aHR/ZkAktxc8D4Fckl9nzBvjAyKq3+E
w2bfE6DrNeLefRNEyAYLoEXq4A/GlAP9MudZELtW9M+U1dzN9BdKfMVmE7qznESG
kxg3cvoMb/cmn4jRjHvPfd9wN6bDT02JUOrQzxqMyqQXvdDbrn7iWVYE9R5Q6Tc4
21ZtqIglwO8p1GUll2hz1amnMLSl1nWdwQ0Li1Iy5q3nSZ4at+Q5EYHlSagAtd0h
Vj4dAIDZZeONrHi3368cI2BFYtlo4SReczpAtubZ1CJaucHQ/evJ5AT1XPvXymav
KaoFSzl8k5a8b+rYjRC0YOgcZRWCm89aqPGeps6fABHfe+86CNGIXH4l4whSyOJm
+ObdbSiYDKmGeokuJYnh4RRrThZf7EbQTJya6dJE7za4JRZ6Qh7Ayah7X1MZzcZC
x/wxKkORjhBYxIJUIjX0DBv/MsSzzkS1OH76mZXSu91hVKnpr5QDBxMvEFuJ7Tv5
oJGk/Y1JWsLaQTQN9Jj6alQTTqxnusHoguVMcm1NqAwC3D+bO1XXBq+CURcbKx6x
Sfu/KOzHMedQiZOVBSDVNF1k0k5UsyVfM5+T9rZCR0lsHcRqCz4=
=8bbY
-END PGP SIGNATURE-

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

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex,

On 10/14/18 18:06, Alex O'Ree wrote:
> Is there perhaps a patch that can be applied or better yet, a list
> of jars that are were affected by this? (I'm just trying to find a
> simple way to patch a large volume of servers)

There is nothing official. Nobody has individually identified which
svn revisions fix this issue, so your only options really are:

1. Grab the previous version from source, apply all patches and deploy
   (this is the same as just grabbing the new binaries, assuming you
trust ASF distros)

2. Grab the new binaries, determine which JARs are different (which
may not be super-easy), then copy those to each server. But then you
have a server which reports x.y.z but is actually x.y.z+∂ :(

3. Look at all the commits in ∂ and try to guess the problem. Then,
mitigate it at e.g. reverse-proxy of WAF level. One way would be to
prevent redirects to sites other than your own (which is really the
big danger for open-redirects). Just look for sketchy-looking Location
response headers. :)

I'm curious how you handle upgrades in general. This certainly isn't
the first security issue inn Tomcat that requires an update in your
environment. How do you usually handle updates?

- -chris

> On Wed, Oct 10, 2018 at 10:23 AM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Mark and Michael,
> 
> On 10/10/18 05:15, Mark Thomas wrote:
 On 08/10/18 21:55, Michael Yoder wrote:
> On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas
>  wrote:
>> CVE-2018-11784 Apache Tomcat - Open Redirect
> 
> Is it possible to get more information on the "specially
> crafted URL"? I'd like more information so that I can test
> if some of our apps are vulnerable.
 
 Generally, there is a balance to strike here between making
 it easy for the less technically competent attackers to
 construct an attack and making it easy for end users to
 figure out if they are vulnerable. The way we typically do
 this is by describing the conditions necessary for an attack
 to be possible as completely as possible but not providing
 details of how to perform an attack.
 
 We also provide references to the commit that fixed the
 issue. For someone with the right skills, there is usually
 enough information in the description and the commit for a
 successful attack to be reverse engineered.
> 
> It doesn't look like Sergey has posted anything (that I can find)
> that might be called a full disclosure. If he had, I'd point it
> out.
> 
> If I were you, I'd just make sure that you either (a) upgrade or
> (b) use the existing settings to mitigate the potential problem,
> as described in the announcement.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvInigACgkQHPApP6U8
pFhgDw/+L0SpWHz4IACgy7xB4ekyHpIt/5wbOEbqTfyZAh0m+LrSZgI73zPJuHtt
pLnpwgx3lqwCiWTTFFpK8CqhiQ+a+2dKtSTeDlKRJuU4QZLDMSrgYpcWlGJ3h6w/
LiM2KlnJ1i/jI95NVvoW8HFh/6wHCJLJV+czZJja3Uh/xQz/MTWhmh5dx3eVEIY6
7WTB/JNO02wzM8EudqHypypXmwI0pMLbsMsjTSikIHf8m41Qyd+XrY60DKZul8dv
L6bolXxH23vGnxiv4fnN+tGzIaT1ptXmJ6u/MWFUODtD3PVR3CdjIp2JrXFd3GVN
wGEow0tPRa3tsUvL/frllk22xhzbtxzu1M0Rf9U02TLB4nolyBIdJ5e3OyAnmS/Q
ap3aAPVnFWz2twBxUbuXkk4aZ39YziziWqyFO36y5BFNKI5EQlI3GryDbmBZ6SeT
vOJnMDwLy8o6kRcChNh1LmpjnbZMTYPmSkKEhfzf1tocDdBHZmd5yTIjBNrS0++V
n572zrrTWiBbca39QKFqEgmB5iy4fWpkVYHPKqmOVT7JLhI74WRnKap9dqrSDGrP
n1F4AjfuUjmG8H5Vo01bHWBav4aJuMDrLQ+Sr+sUl6uWPu5DDsG+1W9t2JAyC2Vq
tfP9XLMNBDV+f0BUaYt2aPXmBmLe5IP8FNVAzO1W/2VJG7c1UrM=
=E/P3
-END PGP SIGNATURE-

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

Re: Error Regarding RFC 7230 and RC 3986

[Johan Compagner]

On Thu, 18 Oct 2018 at 13:38, Mark Thomas  wrote:

> On 18/10/18 12:17, Johan Compagner wrote:
> > how is the browser to blame for "
> > defaultMessageType=true=en_US=[key:label.edit]"
> >
> > that url is not generated by a browser but by some software that uses a
> > browser...
>
> Browsers these days try to be helpful and show the user the un-encoded
> URI in the address bar but send the encoded version to the server.
>
>
If this is really the case that you have a webpage where we have a href
with the right url (so the above url is encoded)
and when you click on it, the browser loads it (and i guess that should be
fine then)

But then in the browser you see the un-encoded version (as a bove) and when
you do then a refresh it goes wrong?
That would be bad...
That something the browser really needs to fix...
So yes if the browser really sets the un-encoded version in the url bar
that would be quite annoying
(bookmarking it and so on)

Re: Error Regarding RFC 7230 and RC 3986

[M. Manna]

We already know that the parameter is the issue. Having to change all the
parameter i.e. refactoring code is always the answer.
The question was more about the recommended way of handling this issue
without exposing application to any specific vulnerability. I believe Mark
T has answered this already.

Thanks,


On Thu, 18 Oct 2018 at 14:09, Mark H. Wood  wrote:

> On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix is to ensure that the user agents are sending
> > specification compliant requests." - Do you mean at browser level ? If
> so,
> > is there any specific browser/update we can use? We've checked a few
> > browsers so far (Firefox, Edge, Chrome) and none of them seem to have
> this
> > option (or we might've missed it).
>
> [snip]
>
> > > > The URI we have for this problem has the following param (did work
> with
> > > > 8.5.28)
> > > >
> > > > defaultMessageType=true=en_US=[key:label.edit]
>
> The browser did not actually *compose* that parameter, did it?
>
> If I had this problem, given only what I know from this thread, I
> would suppose that the page which contained an href having such a
> parameter is the source of the problem.  Some link is improperly
> encoded.
>
> I would say it is debatable whether browsers should be "correcting"
> hrefs which are handed to them by some site.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>

Re: Error Regarding RFC 7230 and RC 3986

[Mark H. Wood]

On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
> Thanks a bunch Mark.
> 
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
> browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
> option (or we might've missed it).

[snip]

> > > The URI we have for this problem has the following param (did work with
> > > 8.5.28)
> > >
> > > defaultMessageType=true=en_US=[key:label.edit]

The browser did not actually *compose* that parameter, did it?

If I had this problem, given only what I know from this thread, I
would suppose that the page which contained an href having such a
parameter is the source of the problem.  Some link is improperly
encoded.

I would say it is debatable whether browsers should be "correcting"
hrefs which are handed to them by some site.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Error Regarding RFC 7230 and RC 3986

[Mark Thomas]

On 18/10/18 12:17, Johan Compagner wrote:
> how is the browser to blame for "
> defaultMessageType=true=en_US=[key:label.edit]"
> 
> that url is not generated by a browser but by some software that uses a
> browser...

Browsers these days try to be helpful and show the user the un-encoded
URI in the address bar but send the encoded version to the server.

Personally, that sort of behaviour bugs me as I like to know exactly
what is going on - not have the technology perform 'magic' for me under
the covers to get stuff to work. But I suspect that is just me. And that
is why I do a lot of my testing in this area with telnet.

In this instance, the browser should encode the '[' and the ']' but it
does not.

See this link for how browsers should (as per the RFC) encode characters
in the path and query string compared to how they actually behave.

https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs

Mark


> 
> 
> On Thu, 18 Oct 2018 at 12:55, M. Manna  wrote:
> 
>> Thanks a bunch Mark.
>>
>> "The correct fix is to ensure that the user agents are sending
>> specification compliant requests." - Do you mean at browser level ? If so,
>> is there any specific browser/update we can use? We've checked a few
>> browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
>> option (or we might've missed it).
>>
>> We are using relaxedQueryChars for now - but would like to understand the
>> fix you've proposed above.
>>
>> On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:
>>
>>> On 18/10/18 09:52, M. Manna wrote:
 Hello,

 We received in error in our application after we have upgraded to
>> 8.5.34

 INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged
>> at
 DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in the
>>> request
 target. The valid characters are defined in RFC 7230 and RFC 3986


 The URI we have for this problem has the following param (did work with
 8.5.28)

 defaultMessageType=true=en_US=[key:label.edit]

 The issue is the action parameter value. Could someone help me
>> understand
 the following?

 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
 triggered this change to be in place. I am just trying to confirm if
>> this
 is CVE-2016-681 ? If not, could you please let me know which one that
>> is?
>>>
>>> The change in request parsing was prompted by CVE-2016-6816. There
>>> wasn't a specific attack that prompted this particular change.
>>> CVE-2016-6816 was caused by not parsing the request line as per the
>>> spec. Therefore, to reduce the risk of future vulnerabilities, we have
>>> been tightening up the parsing of the request line.
>>>
 2) Apart from refactoring code, is there any recommended corrective
>>> action?
>>>
>>> The correct fix is to ensure that the user agents are sending
>>> specification compliant requests.
>>>
>>> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
>>> the Connector.
>>>
>>> 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: Error Regarding RFC 7230 and RC 3986

[M. Manna]

I understand. We will use the connector patch for now. But thanks again for
sharing your thoughts. And the link to apache Confluence is really helpful!

Thanks,

On Thu, 18 Oct 2018 at 12:12, Mark Thomas  wrote:

> On 18/10/18 11:55, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix is to ensure that the user agents are sending
> > specification compliant requests." - Do you mean at browser level ? If
> so,
> > is there any specific browser/update we can use? We've checked a few
> > browsers so far (Firefox, Edge, Chrome) and none of them seem to have
> this
> > option (or we might've missed it).
>
> The browsers should fix it but I doubt they will. I've seen at least one
> browser vendor refuse to accept the current behaviour is a bug and claim
> that the browsers are working to their own, different spec.
>
> Investigations show that each browser has slightly different behaviour.
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs
>
> So even if the browsers are following a different spec, they aren't
> implementing that one correctly either.
>
> Sigh.
>
> Mark
>
> >
> > We are using relaxedQueryChars for now - but would like to understand the
> > fix you've proposed above.
> >
> > On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:
> >
> >> On 18/10/18 09:52, M. Manna wrote:
> >>> Hello,
> >>>
> >>> We received in error in our application after we have upgraded to
> 8.5.34
> >>>
> >>> INFO: Error parsing HTTP request header
> >>> Note: further occurrences of HTTP header parsing errors will be logged
> at
> >>> DEBUG level.
> >>> java.lang.IllegalArgumentException: Invalid character found in the
> >> request
> >>> target. The valid characters are defined in RFC 7230 and RFC 3986
> >>>
> >>>
> >>> The URI we have for this problem has the following param (did work with
> >>> 8.5.28)
> >>>
> >>> defaultMessageType=true=en_US=[key:label.edit]
> >>>
> >>> The issue is the action parameter value. Could someone help me
> understand
> >>> the following?
> >>>
> >>> 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> >>> triggered this change to be in place. I am just trying to confirm if
> this
> >>> is CVE-2016-681 ? If not, could you please let me know which one that
> is?
> >>
> >> The change in request parsing was prompted by CVE-2016-6816. There
> >> wasn't a specific attack that prompted this particular change.
> >> CVE-2016-6816 was caused by not parsing the request line as per the
> >> spec. Therefore, to reduce the risk of future vulnerabilities, we have
> >> been tightening up the parsing of the request line.
> >>
> >>> 2) Apart from refactoring code, is there any recommended corrective
> >> action?
> >>
> >> The correct fix is to ensure that the user agents are sending
> >> specification compliant requests.
> >>
> >> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
> >> the Connector.
> >>
> >> 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: Error Regarding RFC 7230 and RC 3986

[Johan Compagner]

how is the browser to blame for "
defaultMessageType=true=en_US=[key:label.edit]"

that url is not generated by a browser but by some software that uses a
browser...


On Thu, 18 Oct 2018 at 12:55, M. Manna  wrote:

> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
> browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
> option (or we might've missed it).
>
> We are using relaxedQueryChars for now - but would like to understand the
> fix you've proposed above.
>
> On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:
>
> > On 18/10/18 09:52, M. Manna wrote:
> > > Hello,
> > >
> > > We received in error in our application after we have upgraded to
> 8.5.34
> > >
> > > INFO: Error parsing HTTP request header
> > > Note: further occurrences of HTTP header parsing errors will be logged
> at
> > > DEBUG level.
> > > java.lang.IllegalArgumentException: Invalid character found in the
> > request
> > > target. The valid characters are defined in RFC 7230 and RFC 3986
> > >
> > >
> > > The URI we have for this problem has the following param (did work with
> > > 8.5.28)
> > >
> > > defaultMessageType=true=en_US=[key:label.edit]
> > >
> > > The issue is the action parameter value. Could someone help me
> understand
> > > the following?
> > >
> > > 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> > > triggered this change to be in place. I am just trying to confirm if
> this
> > > is CVE-2016-681 ? If not, could you please let me know which one that
> is?
> >
> > The change in request parsing was prompted by CVE-2016-6816. There
> > wasn't a specific attack that prompted this particular change.
> > CVE-2016-6816 was caused by not parsing the request line as per the
> > spec. Therefore, to reduce the risk of future vulnerabilities, we have
> > been tightening up the parsing of the request line.
> >
> > > 2) Apart from refactoring code, is there any recommended corrective
> > action?
> >
> > The correct fix is to ensure that the user agents are sending
> > specification compliant requests.
> >
> > The work-around is to use relaxedPathChars and/or relaxedQueryChars on
> > the Connector.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>


-- 
Johan Compagner
Servoy

Re: Error Regarding RFC 7230 and RC 3986

[Mark Thomas]

On 18/10/18 11:55, M. Manna wrote:
> Thanks a bunch Mark.
> 
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
> browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
> option (or we might've missed it).

The browsers should fix it but I doubt they will. I've seen at least one
browser vendor refuse to accept the current behaviour is a bug and claim
that the browsers are working to their own, different spec.

Investigations show that each browser has slightly different behaviour.

https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs

So even if the browsers are following a different spec, they aren't
implementing that one correctly either.

Sigh.

Mark

> 
> We are using relaxedQueryChars for now - but would like to understand the
> fix you've proposed above.
> 
> On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:
> 
>> On 18/10/18 09:52, M. Manna wrote:
>>> Hello,
>>>
>>> We received in error in our application after we have upgraded to 8.5.34
>>>
>>> INFO: Error parsing HTTP request header
>>> Note: further occurrences of HTTP header parsing errors will be logged at
>>> DEBUG level.
>>> java.lang.IllegalArgumentException: Invalid character found in the
>> request
>>> target. The valid characters are defined in RFC 7230 and RFC 3986
>>>
>>>
>>> The URI we have for this problem has the following param (did work with
>>> 8.5.28)
>>>
>>> defaultMessageType=true=en_US=[key:label.edit]
>>>
>>> The issue is the action parameter value. Could someone help me understand
>>> the following?
>>>
>>> 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
>>> triggered this change to be in place. I am just trying to confirm if this
>>> is CVE-2016-681 ? If not, could you please let me know which one that is?
>>
>> The change in request parsing was prompted by CVE-2016-6816. There
>> wasn't a specific attack that prompted this particular change.
>> CVE-2016-6816 was caused by not parsing the request line as per the
>> spec. Therefore, to reduce the risk of future vulnerabilities, we have
>> been tightening up the parsing of the request line.
>>
>>> 2) Apart from refactoring code, is there any recommended corrective
>> action?
>>
>> The correct fix is to ensure that the user agents are sending
>> specification compliant requests.
>>
>> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
>> the Connector.
>>
>> 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: Error Regarding RFC 7230 and RC 3986

[M. Manna]

Thanks a bunch Mark.

"The correct fix is to ensure that the user agents are sending
specification compliant requests." - Do you mean at browser level ? If so,
is there any specific browser/update we can use? We've checked a few
browsers so far (Firefox, Edge, Chrome) and none of them seem to have this
option (or we might've missed it).

We are using relaxedQueryChars for now - but would like to understand the
fix you've proposed above.

On Thu, 18 Oct 2018 at 10:39, Mark Thomas  wrote:

> On 18/10/18 09:52, M. Manna wrote:
> > Hello,
> >
> > We received in error in our application after we have upgraded to 8.5.34
> >
> > INFO: Error parsing HTTP request header
> > Note: further occurrences of HTTP header parsing errors will be logged at
> > DEBUG level.
> > java.lang.IllegalArgumentException: Invalid character found in the
> request
> > target. The valid characters are defined in RFC 7230 and RFC 3986
> >
> >
> > The URI we have for this problem has the following param (did work with
> > 8.5.28)
> >
> > defaultMessageType=true=en_US=[key:label.edit]
> >
> > The issue is the action parameter value. Could someone help me understand
> > the following?
> >
> > 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> > triggered this change to be in place. I am just trying to confirm if this
> > is CVE-2016-681 ? If not, could you please let me know which one that is?
>
> The change in request parsing was prompted by CVE-2016-6816. There
> wasn't a specific attack that prompted this particular change.
> CVE-2016-6816 was caused by not parsing the request line as per the
> spec. Therefore, to reduce the risk of future vulnerabilities, we have
> been tightening up the parsing of the request line.
>
> > 2) Apart from refactoring code, is there any recommended corrective
> action?
>
> The correct fix is to ensure that the user agents are sending
> specification compliant requests.
>
> The work-around is to use relaxedPathChars and/or relaxedQueryChars on
> the Connector.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Issue while configuring keystore/SSL for Tomcat 8.5.33

[manjesh]

can you share the full debug log ?  what is the client for this SSL service
? browser or some other standalone programs
what version of JDK is being used?

On Thu, Oct 18, 2018 at 2:20 PM Sashidharan Ramamurthy <
sashidharan.ramamur...@ericsson.com> wrote:

> Any updates users of tomcat on this issue!!!
>
> -Original Message-
> From: Sashidharan Ramamurthy 
> Sent: Wednesday, October 17, 2018 4:22 PM
> To: users@tomcat.apache.org
> Subject: FW: Issue while configuring keystore/SSL for Tomcat 8.5.33
>
> Hi Tomcat user group,
>
> We have installed and deployed Tomcat Version: 8.5.33 in our machine.
>
> Software: AIX
>
> We configured SSL at 8443 port using below command for creating keystore.
>
> $JAVA_HOME/bin/keytool -genkey -alias iscpkey -keystore
> $outputfile -keyalg RSA -dname "CN=${site}, OU=Network Solutions, O=ISCP,
> L=Piscataway, C=US" -storepass "changeit" -keypass "changeit" -validity
> 1
>
> Though 8443 port no has started, we are unable to connect from SSL client.
> We are getting SSLException in our client.
>
> We enabled java.net.debug with SSL logs.
>
> Client Hello and Server Hello is done but fails soon afterwards in SSL
> with internal_error.
>
> *** ServerHelloDone
> https-jsse-nio-8443-exec-4, WRITE: TLSv1 Handshake, length = 1736
> https-jsse-nio-8443-exec-5, READ: TLSv1 Alert, length = 2
> https-jsse-nio-8443-exec-5, RECV TLSv1 ALERT:  fatal, internal_error
> https-jsse-nio-8443-exec-5, fatal: engine already closed.  Rethrowing
> javax.net.ssl.SSLException: Received fatal alert: internal_error
> https-jsse-nio-8443-exec-5, fatal: engine already closed.  Rethrowing
> javax.net.ssl.SSLException: Received fatal alert: internal_error
> https-jsse-nio-8443-exec-5, called closeOutbound()
> https-jsse-nio-8443-exec-5, closeOutboundInternal()
> https-jsse-nio-8443-exec-5, SEND TLSv1 ALERT:  warning, description =
> close_notify https-jsse-nio-8443-exec-5, WRITE: TLSv1 Alert, length = 2
>
> We are unable to proceed further.
>
> Can you let me know what could be the reason?
>
> Also, if this is not the correct tomcat group, can you point me to correct
> group?
>
> Thanks and Regards,
> Sashi
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Error Regarding RFC 7230 and RC 3986

[Mark Thomas]

On 18/10/18 09:52, M. Manna wrote:
> Hello,
> 
> We received in error in our application after we have upgraded to 8.5.34
> 
> INFO: Error parsing HTTP request header
> Note: further occurrences of HTTP header parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: Invalid character found in the request
> target. The valid characters are defined in RFC 7230 and RFC 3986
> 
> 
> The URI we have for this problem has the following param (did work with
> 8.5.28)
> 
> defaultMessageType=true=en_US=[key:label.edit]
> 
> The issue is the action parameter value. Could someone help me understand
> the following?
> 
> 1) Since the issue didn't happen for 8.5.28 - this means some CVE has
> triggered this change to be in place. I am just trying to confirm if this
> is CVE-2016-681 ? If not, could you please let me know which one that is?

The change in request parsing was prompted by CVE-2016-6816. There
wasn't a specific attack that prompted this particular change.
CVE-2016-6816 was caused by not parsing the request line as per the
spec. Therefore, to reduce the risk of future vulnerabilities, we have
been tightening up the parsing of the request line.

> 2) Apart from refactoring code, is there any recommended corrective action?

The correct fix is to ensure that the user agents are sending
specification compliant requests.

The work-around is to use relaxedPathChars and/or relaxedQueryChars on
the Connector.

Mark

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

Error Regarding RFC 7230 and RC 3986

[M. Manna]

Hello,

We received in error in our application after we have upgraded to 8.5.34

INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986


The URI we have for this problem has the following param (did work with
8.5.28)

defaultMessageType=true=en_US=[key:label.edit]

The issue is the action parameter value. Could someone help me understand
the following?

1) Since the issue didn't happen for 8.5.28 - this means some CVE has
triggered this change to be in place. I am just trying to confirm if this
is CVE-2016-681 ? If not, could you please let me know which one that is?

2) Apart from refactoring code, is there any recommended corrective action?

Thanks,

RE: Issue while configuring keystore/SSL for Tomcat 8.5.33

[Sashidharan Ramamurthy]

Any updates users of tomcat on this issue!!!

-Original Message-
From: Sashidharan Ramamurthy  
Sent: Wednesday, October 17, 2018 4:22 PM
To: users@tomcat.apache.org
Subject: FW: Issue while configuring keystore/SSL for Tomcat 8.5.33

Hi Tomcat user group,

We have installed and deployed Tomcat Version: 8.5.33 in our machine.

Software: AIX

We configured SSL at 8443 port using below command for creating keystore.

$JAVA_HOME/bin/keytool -genkey -alias iscpkey -keystore $outputfile 
-keyalg RSA -dname "CN=${site}, OU=Network Solutions, O=ISCP, L=Piscataway, 
C=US" -storepass "changeit" -keypass "changeit" -validity 1

Though 8443 port no has started, we are unable to connect from SSL client. We 
are getting SSLException in our client.

We enabled java.net.debug with SSL logs.

Client Hello and Server Hello is done but fails soon afterwards in SSL with 
internal_error.

*** ServerHelloDone
https-jsse-nio-8443-exec-4, WRITE: TLSv1 Handshake, length = 1736 
https-jsse-nio-8443-exec-5, READ: TLSv1 Alert, length = 2 
https-jsse-nio-8443-exec-5, RECV TLSv1 ALERT:  fatal, internal_error 
https-jsse-nio-8443-exec-5, fatal: engine already closed.  Rethrowing 
javax.net.ssl.SSLException: Received fatal alert: internal_error 
https-jsse-nio-8443-exec-5, fatal: engine already closed.  Rethrowing 
javax.net.ssl.SSLException: Received fatal alert: internal_error 
https-jsse-nio-8443-exec-5, called closeOutbound() https-jsse-nio-8443-exec-5, 
closeOutboundInternal() https-jsse-nio-8443-exec-5, SEND TLSv1 ALERT:  warning, 
description = close_notify https-jsse-nio-8443-exec-5, WRITE: TLSv1 Alert, 
length = 2

We are unable to proceed further.

Can you let me know what could be the reason?

Also, if this is not the correct tomcat group, can you point me to correct 
group?

Thanks and Regards,
Sashi

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