On 16/05/2013 14:23, Michael Martin wrote:
> Hello,
> 
> We're looking at a known issue with Tomcat 7.0.32's APR connector
> (which users OpenSSL), as documented here -
> http://tomcat.apache.org/security-7.html#Not_a_vulnerability_in_Tomcat
> (TLS SSL Man in Middle).

Are you sure there is a vulnerability here you need to avoid? What
version of APR/native are you using? What version of OpenSSL is it built
with? I'd expect just using the latest version would protect against this.

> A solution this offers is switching to the NIO connector. From what
> iv'e read, this should be as simple as amending the server.xml. This
> is what we now changed for the SSL:
> 
> <Connector executor="tomcatThreadPool" port="443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> SSLEnabled="true"
> 
> However, upon restarting out Tomcat with these setting, we get the
> following in our error log:
> 
> 2013-05-16 12:31:18,334 [main] INFO
> org.apache.catalina.core.AprLifecycleListener - Loaded APR based
> Apache Tomcat Native library 1.1.24 using APR version 1.4.6.

OK. You are definitely protected against client initiated renegotiations.

A later version of Tomcat would tell you the OpenSSL version as well.


> 2013-05-16 12:31:18,334 [main] INFO
> org.apache.catalina.core.AprLifecycleListener - APR capabilities:
> IPv6 [true], sendfile [true], accept filters [false], random [true]. 
> 2013-05-16 12:31:18,334 [main] ERROR
> org.apache.catalina.connector.Connector - Protocol handler
> instantiation failed java.lang.ClassNotFoundException:
> Http11NioProtocol at
> java.net.URLClassLoader$1.run(URLClassLoader.java:366) at
> java.net.URLClassLoader$1.run(URLClassLoader.java:355) at
> java.security.AccessController.doPrivileged(Native Method) at
> java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> 
> So looks like it can't be found, and still says its loading "APR
> based" Tomcat...anyone have any ideas on how to fix this, or what
> I've missed?

Loading the APR library does not mean that it will be used for a
connector. The logs will tell you which connector is being used once you
get past the CNFE problem.

Is there some more to that stack trace? It looks like the protocol
attribute in server.xml isn't the one you quoted but there might be
something else going on - that is why the full stack trace would be helpful.

Mark

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

Reply via email to