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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to