You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/04/15 04:20:00 UTC
[Bug 57815] New: Successful build against old OpenSSL leads to
runtime error when parsing SSLProtocol
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
Bug ID: 57815
Summary: Successful build against old OpenSSL leads to runtime
error when parsing SSLProtocol
Product: Tomcat Native
Version: 1.1.33
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Library
Assignee: dev@tomcat.apache.org
Reporter: crynax@yahoo.com
Tomcat Native builds against older versions of OpenSSL, but then throws a
runtime error when parsing SSLProtocol. In my case, building Tomcat Native
1.1.33 on CentOS 6.2 against openssl-1.0.0-20.el6.x86_64 leads to the following
exception when parsing SSLProtocol="TLSv1+TLSv1.1+TLSv1.2" in server.xml, even
on latest CentOS 6.6 when linking openssl-1.0.1e-30.el6.8.x86_64.
java.lang.Exception: Unable to create SSLContext. Check that SSLEngine is
enabled in the AprLifecycleListener, the AprLifecycleListener has initialised
correctly and that a valid SSLProtocol has been specified
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:532)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:730)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:456)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:960)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:567)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:842)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:576)
at org.apache.catalina.startup.Catalina.load(Catalina.java:599)
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:497)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484)
Caused by: java.lang.Exception: Invalid Server SSL Protocol
(error:00000000:lib(0):func(0):reason(0))
at org.apache.tomcat.jni.SSLContext.make(Native Method)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:527)
... 16 more
I suspect this same circumstance was reported here:
https://mail-archives.apache.org/mod_mbox/tomcat-users/201412.mbox/%3cCAPvtZefZzW9L73D0s4B7rGq8DTxzcJkv8OO9SMdQOx+awxfYBA@mail.gmail.com%3e
Tomcat Native should probably have either configure or compile checks for
OpenSSL version or for supported protocols, it should dynamically support these
protocols as it dynamically links OpenSSL, or it should have better runtime
error logging.
No such error or exception occurs if I build and run against OpenSSL 1.0.1m on
CentOS 6.2.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Justin from comment #2)
> (In reply to Christopher Schultz from comment #1)
> > when it comes to discovering available functions
>
> Seems to me there are many ways to do this. OpenSSL's own "ciphers" command
> tells you what ciphers are supported.
Ciphers are s different story: you give a list of ciphers to OpenSSL and tell
it to use those. Any that it doesn't support, it will ignore, and there are
(usually) plenty of others to choose from. For protocols, you're pretty much
limited to 3 useful ones, and some versions of the library only support one. If
you choose one it doesn't support, it simply will not support it, no matter
what version you built against.
> These are standard names which also indicate which SSL protocols are
> supported.
While true, the mechanism for configuring OpenSSL for a protocol is
fundamentally different from the way that ciphers are specified and selected.
The Java analogy would be that I have to know at build-time the exact name of
the class I want to instantiate in order to get an engine that supports e.g.
TLS1.2. If it's not available at built time, I simply can't guarantee it will
be available at runtime, so I can't compile-in the usage of that class (it's a
function that returns a complex structure in C) or you'll get runtime failures
that will usually bring-down the process.
Bringing-down the process is much worse than downgrading to the features
available in the build-time version of OpenSSL.
> > 14-Apr-2015 17:30:50.069 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully
> initialized (OpenSSL 1.0.1e 11 Feb 2013)
>
> I'm a little bothered that you'll log the runtime library, but not the build
> time library that you are restricting users to.
Bothered? Well, feel free to ask for that information to be added. I'm the one
who added the version information to that log message, and it didn't occur to
be to log the version of OpenSSL we built-against. If you think that's useful,
I'm happy to add it.
Back to "doing the right thing". I'm not sure it's possible to make tcnative
forward-compatible with as-yet-unseen versions of OpenSSL; the best we can do
is build against the version we have at hand.
On the other hand, we could be better about picking a protocol given the
protocol(s) requested by the caller and those supported by the build-time
library. I can review the code in there, which I thought was a little funny at
the time. I can also fix the error message so that it makes more sense.
> This obviously isn't a problem on Windows where most use the pre-built
> Tomcat Native where OpenSSL is statically linked. They must wait for a new
> build of Tomcat Native.
Windows users can certainly build their own; they just aren't used to compiling
their own software like most UNIX admins are.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #6 from Mark Thomas <ma...@apache.org> ---
This is handled in Tomcat.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
--- Comment #4 from Justin <cr...@yahoo.com> ---
Thanks for your time and contributions. I would definitely find both the
compile time and run time versions of OpenSSL helpful, at least while such
static restrictions exist.
Sadly Tomcat Native is not actively maintained in many distributions, e.g.
pulled from Fedora EPEL 6, at 1.1.30 in Fedora EPEL 7 (as of April 16, 2015).
OpenSSL will be more actively maintained, particularly for security concerns.
Might help many to support future protocols and ciphers.
Slightly off topic: have you or others considered alternatives to
OpenSSL/LibreSSL? Maybe GnuTLS, NSS, Botan?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Successful build against |Improve error message when
|old OpenSSL leads to |OpenSSL does not support
|runtime error when parsing |the requested highest
|SSLProtocol |SSLProtocol
Severity|normal |enhancement
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> ---
I'm inclined to simply improve the error message, though it's already telling
you what is wrong: you are requesting a protocol it can't support. (Here, you
are requesting TLS1.2 which wasn't supported in your 1.0.0 version of OpenSSL
and so support wasn't compiled-in to the native library; the fact that you are
running it on 1.0.1 is unfortunately not relevant).
When configuring OpenSSL, we must try to instantiate a server "method" object
that implements the highest-allowed protocol. If there isn't any protocol match
between what you chose for your highest-level protocol version (TLS1.2 in this
case) and what the current library-version can support, then we will throw this
error.
Of course, we are essentially reporting that the error is "0" (no error),
probably because you built against 1.0.0 (max TLSv1.1) and you are requesting
TLS1.2, which isn't available, so we fall-through and choose no server method.
The null-check for the created-context fails and we assume there was an OpenSSL
error and throw an exception.
The behavior should still be the same (throw an exception), but we should give
the proper reason: we couldn't support your requested protocol and so we chose
*nothing*, rather than OpenSSL actually failing to initialize a particular
protocol.
> Tomcat Native should probably have either configure or compile checks for
> OpenSSL version
We have these checks in both configure (checks for an acceptable OpenSSL
version) and the pre-processor (to conditionally-compile support for various
supported protocols, etc.).
> or for supported protocols, it should dynamically support these protocols
> as it dynamically links OpenSSL
This is not possible in C. While the library is dynamically loaded at runtime,
the actual linking step is performed along with the compiler. Native libraries
aren't as flexible as Java is when it comes to discovering available functions
in library code.
> or it should have better runtime error logging.
This seems like a reasonable request. Marking as "enhancement" since the
behavior won't change.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
--- Comment #2 from Justin <cr...@yahoo.com> ---
(In reply to Christopher Schultz from comment #1)
> when it comes to discovering available functions
Seems to me there are many ways to do this. OpenSSL's own "ciphers" command
tells you what ciphers are supported. These are standard names which also
indicate which SSL protocols are supported.
> 14-Apr-2015 17:30:50.069 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully
initialized (OpenSSL 1.0.1e 11 Feb 2013)
I'm a little bothered that you'll log the runtime library, but not the build
time library that you are restricting users to.
This obviously isn't a problem on Windows where most use the pre-built Tomcat
Native where OpenSSL is statically linked. They must wait for a new build of
Tomcat Native.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57815] Improve error message when OpenSSL does not support the
requested highest SSLProtocol
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57815
--- Comment #5 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Justin from comment #4)
> Thanks for your time and contributions. I would definitely find both the
> compile time and run time versions of OpenSSL helpful, at least while such
> static restrictions exist.
Okay.
> Sadly Tomcat Native is not actively maintained in many distributions, e.g.
> pulled from Fedora EPEL 6, at 1.1.30 in Fedora EPEL 7 (as of April 16,
> 2015). OpenSSL will be more actively maintained, particularly for security
> concerns. Might help many to support future protocols and ciphers.
Please lobby your distribution for updates. Generally-speaking, Linux distros
try to maintain stability and will only back-port security patches, so many
improvements are ignored. There may not be a way to change that policy.
> Slightly off topic: have you or others considered alternatives to
> OpenSSL/LibreSSL? Maybe GnuTLS, NSS, Botan?
If you look at the TLS-related tcnative code, you'll notice that is is *very*
tightly coupled with the OpenSSL API. Even the Java binding exposes OpenSSL API
calls (I'm specifically thinking of the "hasOp" method).
LibreSSL's initial goal is library-compatibility, so using that library ought
to be relatively easy to do. The others, not so much.
If you'd be interested in taking a look at how to implement some of the native
functions that are currently implemented as OpenSSL-only, except with GnuTLS,
etc., I'd certainly be interested in seeing them.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org