You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2014/04/12 15:00:08 UTC
[PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
http://people.apache.org/~trawick/httpd-ct.patch
Here is the documentation for the new hooks, annotated with an idea of what
mod_ssl_ct does with them:
/**
* init_server hook -- allow SSL_CTX-specific initialization to be
performed by
* a module for each SSL-enabled server (one at a time)
* @param s SSL-enabled [virtual] server
* @param p pconf pool
* @param is_proxy 1 if this server supports backend connections
* over SSL/TLS, 0 if it supports client connections over SSL/TLS
* @param ctx OpenSSL SSL Context for the server
*/
APR_DECLARE_EXTERNAL_HOOK(ssl, SSL, int, init_server,
(server_rec *s, apr_pool_t *p, int is_proxy,
SSL_CTX *ctx))
mod_ssl_ct:
For an SSL-enabled proxy backend, we need to set up TLS extension handling
to
ask for an SCT list in ClientHello and grab it from ServerHello. This
requires the SSL_CTX. (And similar for OCSP).
For an SSL-enabled server, we do the opposite (see if the client cares from
ClientHello,
provide it in ServerHello). Additionally, we take this opportunity to
query the SSL_CTX
for all the server certificates, for which we should be able to send SCTs.
/**
* pre_handshake hook
* @param c conn_rec for new connection from client or to backend server
* @param ssl OpenSSL SSL Connection for the client or backend server
*/
APR_DECLARE_EXTERNAL_HOOK(ssl, SSL, int, pre_handshake,
(conn_rec *c, SSL *ssl))
mod_ssl_ct:
Ask for the OCSP status extension to be sent.
Set TLS extension "debug" callbacks to find out if the peer is CT-aware when
resuming a session. (Not critical)
/**
* proxy_post_handshake hook -- allow module to abort after successful
* handshake with backend server and subsequent peer checks
* @param c conn_rec for connection to backend server
* @param ssl OpenSSL SSL Connection for the client or backend server
*/
APR_DECLARE_EXTERNAL_HOOK(ssl, SSL, int, proxy_post_handshake,
(conn_rec *c, SSL *ssl))
mod_ssl_ct:
Look at the server certificate for a SCT list (in a certificate extension).
This is also the point at which we've had the chance to potentially find
SCTs in ServerHello, cert extension, and/or stapled OCSP response, so we
proceed by checking the signature and
time in each SCT and, assuming all okay, queue it for further analysis
offline. If nothing
valid has been seen, depending on the configuration we may return an error
from the
hook, which will cause mod_ssl to abort.
--/--
I've been developing mod_ssl_ct here thus far but intend for this to be
part of the httpd distribution:
https://github.com/trawick/ct-httpd/tree/master/src/proto1
--/--
On the issue of mod_ssl APIs:
mod_ssl.h currently has nothing specific to OpenSSL, which has not been
necessary so far, and which is useful because other SSL/TLS providers also
implement the limited APIs that are described there.
Maybe trunk should define those provider-independent interfaces in
<TOP>/include/httpd.h or similar, since it is recommended (in practice if
not officially) that other SSL/TLS providers implement them on behalf of
mod_proxy and modules that look up variables.
Maybe these hooks that pass around OpenSSL structures should be private
anyway (mod_ssl_private.h), as it could be difficult to debug issues with
other modules that feel free to operate on the OpenSSL structures.
It was suggested that the toolkit features needed by mod_ssl_ct (handle TLS
and OCSP extensions, look at certificates, whatever else) be defined by
mod_ssl as generic APIs which could be implemented by other SSL/TLS
providers, probably on top of other toolkits. Scott Deboy's patch for TLS
extensions went a long way towards that. IMO somebody that actually cares
about that needs to invest in the considerable work, which would include
actually implementing it for another toolkit and making sure that it is
doable.
So... Concerns? Suggestions? Etc.? Speak up, or forever* ask me to fix
it after committing ;) (*Let's not be ridiculous though)
Thanks!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Apr 14, 2014 at 11:29 AM, Joe Orton <jo...@redhat.com> wrote:
> On Mon, Apr 14, 2014 at 08:32:18AM -0400, Jeff Trawick wrote:
> > FWIW, I think it is reasonable to say "This *is* a private mod_ssl
> > interface for the purposes of introducing some modularity within this
> > particular SSL/TLS implementation, and these interfaces aren't intended
> for
> > third-party modules." That's not how I coded it, but now that somebody
> has
> > actually looked I'm curious about your thoughts.
>
> Hmmm, I think the only distinction that matters is whether it's in a
> header installed by "make install". I don't think we can successfully
> hide private APIs in public headers, modules will use them regardless of
> the "here be dragons" comments - or e.g. CORE_PRIVATE!
>
> Regards, Joe
>
Well, yes ;) But punt for now. In the short term I need it to be easy to
build the CT module outside of httpd, so install it is.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2014 at 08:32:18AM -0400, Jeff Trawick wrote:
> FWIW, I think it is reasonable to say "This *is* a private mod_ssl
> interface for the purposes of introducing some modularity within this
> particular SSL/TLS implementation, and these interfaces aren't intended for
> third-party modules." That's not how I coded it, but now that somebody has
> actually looked I'm curious about your thoughts.
Hmmm, I think the only distinction that matters is whether it's in a
header installed by "make install". I don't think we can successfully
hide private APIs in public headers, modules will use them regardless of
the "here be dragons" comments - or e.g. CORE_PRIVATE!
Regards, Joe
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Apr 14, 2014 at 8:03 AM, Joe Orton <jo...@redhat.com> wrote:
> On Sat, Apr 12, 2014 at 09:00:08AM -0400, Jeff Trawick wrote:
> > So... Concerns? Suggestions? Etc.? Speak up, or forever* ask me to
> fix
> > it after committing ;) (*Let's not be ridiculous though)
>
> Interesting stuff!
>
> I do think it is preferable to keep mod_ssl.h toolkit-agnostic. Because
> the API you are adding is not indended to be "private", I'd suggest
> mod_ssl_openssl.h or something like that instead.
>
I'll do that.
FWIW, I think it is reasonable to say "This *is* a private mod_ssl
interface for the purposes of introducing some modularity within this
particular SSL/TLS implementation, and these interfaces aren't intended for
third-party modules." That's not how I coded it, but now that somebody has
actually looked I'm curious about your thoughts.
> Regards, Joe
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Apr 14, 2014 at 8:14 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 14 Apr 2014, at 2:03 PM, Joe Orton <jo...@redhat.com> wrote:
>
> > Interesting stuff!
> >
> > I do think it is preferable to keep mod_ssl.h toolkit-agnostic.
>
> +1.
>
> > Because
> > the API you are adding is not indended to be "private", I'd suggest
> > mod_ssl_openssl.h or something like that instead.
>
> Pass what you need as DER encoded structures, that way can can swap
> backends and they will still work.
>
Pragmatically, what I need is to make OpenSSL calls at certain points
(e.g., augment the type of setup that mod_ssl is doing). I'm not in a
position (i.e., many days with nothing to do) to create enough generic
interfaces to allow arbitrary mod_foo+FooSSL to implement CT.
The generic TLS extension APIs submitted earlier were just a start, and
even those needed additional work.
> Regards,
> Graham
> --
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate Transparency as a separate mod
Posted by Graham Leggett <mi...@sharp.fm>.
On 14 Apr 2014, at 2:03 PM, Joe Orton <jo...@redhat.com> wrote:
> Interesting stuff!
>
> I do think it is preferable to keep mod_ssl.h toolkit-agnostic.
+1.
> Because
> the API you are adding is not indended to be "private", I'd suggest
> mod_ssl_openssl.h or something like that instead.
Pass what you need as DER encoded structures, that way can can swap backends and they will still work.
Regards,
Graham
--
Re: [PATCH] mod_ssl APIs to allow implementation of Certificate
Transparency as a separate mod
Posted by Joe Orton <jo...@redhat.com>.
On Sat, Apr 12, 2014 at 09:00:08AM -0400, Jeff Trawick wrote:
> So... Concerns? Suggestions? Etc.? Speak up, or forever* ask me to fix
> it after committing ;) (*Let's not be ridiculous though)
Interesting stuff!
I do think it is preferable to keep mod_ssl.h toolkit-agnostic. Because
the API you are adding is not indended to be "private", I'd suggest
mod_ssl_openssl.h or something like that instead.
Regards, Joe