Am 16.08.2017 um 23:38 schrieb Rainer Jung:
Am 16.08.2017 um 14:45 schrieb Rainer Jung:
Am 13.08.2017 um 19:37 schrieb Mark Thomas:
On 13/08/17 16:42, Rainer Jung wrote:
Hi,
OpenSSl has an API named SSL_CONF_cmd. Te API allows application using
OpenSSL to no longer implement an application specific configuration
option per OpenSSL config feature the app wants to support, but instead
use a more generic approach. The API can be seen here (it was added in
1.0.2, but also exists in 1.1.0):
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html
mod_ssl in httpd already supports that API:
http://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html#sslopensslconfcmd
The API can be fed with pairs of command names and values. If we would
like to support this, we would have to find an appropriate approach of
supporting name/value pairs in our config. I'd say server.xml (and
every
xml based file) isn't appropriate.
Is there any interest in supporting SSL_CONF_cmd?
If so, should we
a) create a new file, e.g. conf/openssl.properties
or
b) pack new properties into catalina.properties, probably with a common
prefix "openssl.conf.cmd."?
And if catalina.properties, should we add the properties also to java
system properties or filter them?
Or maybe the other way round: extract all system properties named
openssl.conf.cmd.* and use them?
If we would want to support different setting per connector or
SSLHostConfig, we would instead need a properties file per connector or
SSLHostConfig, so probably an xml attribute opensslConfCmdFile="..."
and
read the properties form there.
Any opinion?
I like the idea of not having to replicate openssl setters and gettes in
Java and C.
I think the configuration needs to be per SSLHostConfig.
I was thinking of something along the line of IntrosepctionUtils that
was passed the attribute name and value from the XML and then called the
appropriate API. If the attributes had a common prefix (openssl.cmd...)
then ID'ing the name/value pairs should be fairly easy.
Haven't thought about how this might integrate with the current code.
I think implementation of handling the specific SSL_CONF_cmd attributes
would be easier (and cleaner), if we introduce another SSLHostConfig sub
element (analogous to <Certificate>), e.g. named <OpenSSLConfCmd>, and
each attribute there gets set by calling a generic method using key and
value as args instead of a key-specific attribute setter. That's most
likely easier to implement with digester and produces less config magic
plus we no longer need such an attribute name prefix. It kind of is
implicit in the new sub element.
I'll try to do a prototype later and if it works already include the
needed native calls in the tcnative, so that we'll have something in
1.2.13 that we can build upon.
Since at config parsing time we do not already have the SSL context
available that needs to be passed when calling SSL_CONF_cmd(), we would
need to store the list of key/values during config parse time and then
later when creating the ssl context we need to apply them. That is quite
similar to what happens in mod_ssl. Storing the list would be easier in
the Java world and keep the native part simpler. In addition to the
SSL_CONF_cmd() calls when actually setting up the ssl context, we could
do some checks for the key/value pairs already during config parse time
using SSL_CONF_cmd_value_type() and code similar to mod_ssl
(ssl_cmd_SSLOpenSSLConfCmd).
There seems to be a conceptual problem. The order of attributes seems to
not be well-defined, but the order of SSL_CONF_cmd executions can be
relevant, so we should aim at getting the commands in the order they
have been put into the config file. I guess we need the more ugly config
style (beneath SSLHostConfig):
<OpenSSLConf>
<Command name="..." args="...">
...
<Command name="..." args="...">
</OpenSSLConf>
since elements should already get processed in an ordered way.
I added the functionality today to tcnative and TC 9. Currently when you
try to use it it checks for UnsatisfiedLinkError because we can't yet
assume a tcnative version is present, that already contains that
functionality. You need to build it from tcnative trunk to get it.
An example would be
<SSLHostConfig>
<OpenSSLConf>
<OpenSSLConfCmd name="Protocol"
value="-SSLv3,-TLSv1,TLSv1.1,TLSv1.2"/>
<OpenSSLConfCmd name="CipherString"
value="ECDHE-RSA-AES128-SHA"/>
<OpenSSLConfCmd name="Options"
value="-SessionTicket,-Compression,ServerPreference"/>
</OpenSSLConf>
</SSLHostConfig>
(it is just meant to show the principles).
Docs for the supported names (varying by OpenSSL version):
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_CONF_cmd.html
https://www.openssl.org/docs/manmaster/man3/SSL_CONF_cmd.html
Look for "SUPPORTED CONFIGURATION FILE COMMANDS"
Some remarks:
- storeconfig support is still missing
- docs are missing; simple example and warning that if your "normal"
attributes and OpenSSLConf are in conflict you might get unexpected
results (although in general OpenSSLConf since applied later simply
overrides)
- tests are missing
- I had to make two method in SSLHostConfig public,
see the log for r1805529
- during testing I observed that we continuously reconfigure the
SSL objects when using a Java connector with OpenSSL. Since they
are all created based on a configured SSL_CTX, a reconfig isn't
needed and I removed it. With JSSE TLS impl it still is needed.
Concerning tcnative 1.2.13: it would be useful if we could have a
release soon. I do plan another tcnative feature - debug flags similar
to what you can do e.g. in "openssl s_server", but that will take some
time and can come post 1.2.13.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
