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