On Fri, Jan 3, 2014 at 6:17 PM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 03/01/2014 19:31, Jeff Trawick wrote:
Support for ServerInfoFile still isn't in
SSL_CONF_cmd()/SSL_CONF_cmd_value_type() in OpenSSL master or the 1.0.2
branch,
right? (IOW, SSLOpenSSLConfCmd
On Tue, Oct 22, 2013 at 4:04 PM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 22/10/2013 20:14, Trevor Perrin wrote:
On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 21/10/2013 05:09, Trevor Perrin wrote:
BTW I've just added
On 03/01/2014 19:31, Jeff Trawick wrote:
Support for ServerInfoFile still isn't in
SSL_CONF_cmd()/SSL_CONF_cmd_value_type() in OpenSSL master or the 1.0.2
branch,
right? (IOW, SSLOpenSSLConfCmd ServerInfoFile info1.pem is the planned
interface in mod_ssl but not yet workable?) Or maybe
On 13/11/2013 14:06, Kaspar Brand wrote:
I'm not proposing to drop support for encrypted private keys from 2.4.x
(yet), to be clear - I guess we need to keep this for quite some while
for backwards compatibility. I suggest, however, to only support
unencrypted private keys with the
On 23.10.2013 16:09, Kaspar Brand wrote:
On 21.10.2013 06:09, Trevor Perrin wrote:
I looked at your patch. Besides lack of passphrase-handling, it
breaks compatibility with existing config files (which assume
certs/keys are matched by type, not order).
I don't think that random order of
On 13/11/2013 14:06, Kaspar Brand wrote:
Taking a step back, however, I wonder what problem we're really solving
with the support for encrypted private keys. SSLPassPhraseDialog and its
three incarnations (builtin, pipe and exec) have been in mod_ssl ever
since 2.0, sure, but what do they
On 21.10.2013 06:09, Trevor Perrin wrote:
I looked at your patch. Besides lack of passphrase-handling, it
breaks compatibility with existing config files (which assume
certs/keys are matched by type, not order).
I don't think that random order of multiple SSLCertificateFile and
On 22.10.2013 22:04, Dr Stephen Henson wrote:
Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
structure
in modssl_ctx_t. It's done that way to avoid having to keep creating and
destroying the SSL_CONF_CTX for each directive but a quick test showed it was
creating
On 23/10/2013 15:30, Kaspar Brand wrote:
On 22.10.2013 22:04, Dr Stephen Henson wrote:
Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
structure
in modssl_ctx_t. It's done that way to avoid having to keep creating and
destroying the SSL_CONF_CTX for each directive but a
On 23.10.2013 16:48, Dr Stephen Henson wrote:
Well the handling remains in ssl_init_ctx_protocol but now an SSL_CONF_CTX
with
appropriate flags is created in moddssl_ctx_init. That is done because a valid
SSL_CONF_CTX is needed to call SSL_CONF_cmd_value_type in
ssl_cmd_SSLOpenSSLConfCmd.
On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 21/10/2013 05:09, Trevor Perrin wrote:
Seems like a lot of work. For example, how would the generic
SSLConfCmd commands get hooked-up with passphrase handling for the key
files?
BTW I've just added
On 22/10/2013 20:14, Trevor Perrin wrote:
On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 21/10/2013 05:09, Trevor Perrin wrote:
BTW I've just added some experimental code to the OpenSSL master branch. It
adds
key/certificate support to SSL_CONF
On 21/10/2013 05:09, Trevor Perrin wrote:
Seems like a lot of work. For example, how would the generic
SSLConfCmd commands get hooked-up with passphrase handling for the key
files?
BTW I've just added some experimental code to the OpenSSL master branch. It adds
key/certificate support to
On Sun, Oct 13, 2013 at 2:24 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 13.10.2013 00:43, Trevor Perrin wrote:
But maybe the easiest way to handle this is to create another hash
table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd).
This table could be populated in
On 14/10/13 17:28, Kaspar Brand wrote:
On 14.10.13 10:51, Rob Stradling wrote:
Kaspar, I don't think data from 2010 (or even data from today) should be
assumed to be a reliable indicator of future use of non-RSA certs on
public sites.
Past performance is not indicative of future performance,
On 13/10/13 10:29, Kaspar Brand wrote:
On 11.10.2013 13:53, Dr Stephen Henson wrote:
IMHO though there needs to be a way to be able to tie a directive to a
certificate in mod_ssl anyway though. I'm surprised no one has needed to do that
before.
I'm not sure we really need this for mod_ssl, as
AFAICT, interest (amongst the commercial CAs) in ECC certs continues to
grow. Since a significant proportion (I estimate ~20%) of deployed clients
will accept RSA server certs but not ECC server certs, I think that
configuring both an ECC cert and an RSA cert on a single vhost may yet
become
On 14.10.13 10:51, Rob Stradling wrote:
Kaspar, I don't think data from 2010 (or even data from today) should be
assumed to be a reliable indicator of future use of non-RSA certs on
public sites.
Past performance is not indicative of future performance, as they use
to say in other
On 13.10.2013 00:43, Trevor Perrin wrote:
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
I *think* you then have to delve into ssl_pphrase_Handle() [note the comment
on
the way in] and somehow link the ServerInfo index with something you can use
to
recognise it later. The algorithm
On 11.10.2013 13:53, Dr Stephen Henson wrote:
IMHO though there needs to be a way to be able to tie a directive to a
certificate in mod_ssl anyway though. I'm surprised no one has needed to do
that
before.
I'm not sure we really need this for mod_ssl, as configuring more than
one cert per
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 10/10/2013 23:18, Trevor Perrin wrote:
How would you expect the code to track the Cert - ServerInfo
relationship between these points?
AFAICS the certificate and key files both go through the function
On 02/10/2013 08:35, Kaspar Brand wrote:
An overhaul of ssl_engine_pphrase.c:ssl_pphrase_Handle() - and its use
of the tVHostKeys and tPublicCert hashes - would probably be welcomed by
quite a few devs, though (see e.g. https://svn.apache.org/r1069765).
Hmm.. I had a look at
On 11/10/2013 05:14, Kaspar Brand wrote:
On 09.10.2013 15:52, Dr Stephen Henson wrote:
It's tempting to just add a directive but after some thought I think
expanding
Apache SSL_CONF handling is the way to go. This would add some future
proofing
so we don't have to go through this all again
On Wed, Oct 9, 2013 at 6:52 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
Technically the current certificate concept doesn't need exposing at all.
You
just have to make sure you set all the relevant parameters *after* you set the
certificate they apply to and *before* you set
On 10/10/2013 23:18, Trevor Perrin wrote:
How would you expect the code to track the Cert - ServerInfo
relationship between these points?
Disclaimer: it's been a while since I looked at that code and someone else might
have a better idea. It didn't quite work in the way I recalled.
It may
On 09.10.2013 15:52, Dr Stephen Henson wrote:
It's tempting to just add a directive but after some thought I think expanding
Apache SSL_CONF handling is the way to go. This would add some future proofing
so we don't have to go through this all again in future.
Yes, please. Let's not perpetuate
On 09/10/2013 02:22, Trevor Perrin wrote:
Hi Kaspar, Stephen,
So I think where things stand is that the OpenSSL 1.0.2 branch is
capable of handling ServerInfo on a per-algorithm basis, but it's not
clear how to expose this through Apache.
(My previous email was naive, I was thinking maybe
On 02/10/2013 08:35, Kaspar Brand wrote:
On 01.10.2013 12:15, Dr Stephen Henson wrote:
That's just OpenSSL internals though. To handle ServerInfo properly in
mod_ssl
IMHO you would need a new directive as there's no support for per-certificate
SSL_CONF commands: it wasn't intended to be used
Hi Kaspar, Stephen,
So I think where things stand is that the OpenSSL 1.0.2 branch is
capable of handling ServerInfo on a per-algorithm basis, but it's not
clear how to expose this through Apache.
(My previous email was naive, I was thinking maybe Stephen was saying
the current certificate /
On Tue, Oct 1, 2013 at 3:15 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
OpenSSL has the concept of the current certificate. That is the last
certificate set. So you set certificate foo and then any parameters you
set
are associated with it until another certificate is set.
On 01.10.2013 12:15, Dr Stephen Henson wrote:
That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl
IMHO you would need a new directive as there's no support for per-certificate
SSL_CONF commands: it wasn't intended to be used like that in its current
form.
This
On 01/10/2013 05:53, Trevor Perrin wrote:
On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 28.09.2013 18:34, Dr Stephen Henson wrote:
How about something like:
int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
which can return things like...
On 01/10/2013 11:15, Dr Stephen Henson wrote:
To handle ServerInfo properly in mod_ssl
IMHO you would need a new directive as there's no support for per-certificate
SSL_CONF commands: it wasn't intended to be used like that in its current
form.
Though thinking about this some more there
On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 28.09.2013 18:34, Dr Stephen Henson wrote:
How about something like:
int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
which can return things like...
SSL_CONF_TYPE_INVALID:unrecognised name.
On 28.09.2013 18:34, Dr Stephen Henson wrote:
How about something like:
int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
which can return things like...
SSL_CONF_TYPE_INVALID:unrecognised name.
SSL_CONF_TYPE_FILE: file name.
SSL_CONF_TYPE_DIR:directory name.
On 27.09.2013 20:58, Trevor Perrin wrote:
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile.
If we're adding specific
On 28/09/2013 14:42, Kaspar Brand wrote:
If the ability to specify relative path names with SSLOpenSSLConfCmd is
considered an absolutely essential feature, then OpenSSL could perhaps
standardize its option names somewhat - e.g. by always naming those
which take a file name argument with
On 28/09/2013 14:56, Dr Stephen Henson wrote:
On 28/09/2013 14:42, Kaspar Brand wrote:
If the ability to specify relative path names with SSLOpenSSLConfCmd is
considered an absolutely essential feature, then OpenSSL could perhaps
standardize its option names somewhat - e.g. by always naming
On 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm not sure how you'd do that with
SSLOpenSSLConfCmd?
It could probably be
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm
On Tue, Sep 24, 2013 at 10:39 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?),
Since you mentioned RFC 5878, I've attached a patch to issue 55467 which allows
third party modules to send and receive custom TLS extensions or supplemental
data (which can be used to implement support for RFC 5878), and adds reneg
support as well (as some folks only want to send the
On 25/09/2013 06:39, Kaspar Brand wrote:
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways,
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways, is this something Apache is interested
44 matches
Mail list logo
