librelist archives

HTTPS support in Mongrel2 and configuration schema changes

From:

Alex Gartrell

Date:

2010-09-23 @ 02:06

Hey guys,

We're looking to get HTTPS out of the gate soon, and it's already
wired into the internals.  The only thing left to do is wire it up to
the config and then we're good to go.  So why the email, over
something so trivial?

Well, it's kinda not.

For the uninitiated, HTTPS is just like good ol' vanilla HTTP.  The
only difference is, rather than send the bytes over a regular TCP
socket, you send it over SSL (Secure Socket Layer).  Really, once
you've found a decent library (we're using axTLS), it's a pretty
straightforward undertaking.  As users of the library, all we have to
do is wait for the handshake to complete (which is helpfully
abstracted away by the library) and then it's business as usual.  This
involves, among other things, providing your certificate to the client
so that they can make sure that you are who they think you are
(SeriousBankBusiness.com, etc.).

Now, as you can guess, one of the quirks here is that you have to know
which host the client thinks it's connecting to, which basically
eliminates virtual hosting (that is, multiple Hosts from the same
port) altogether.

Anyway, long story short, this begs the question, how should we add
this stuff to the config system?  Should we just do one cert per
server (which is the practical thing) or should we do something closer
to the way people view it (maybe one cert per host and only one host
per ssl server?).  I figure this is a moderately sized schema change,
so getting this right is important.

Also, do we have a process for updating the config schema?  Now that
we're releasing snapshots and actively going after users, it might be
worthwhile to formalize this (even if it's just "mention it in the
release notes" or equiv.)

Thanks

Alex

On Wed, Sep 22, 2010 at 9:06 PM, Alex Gartrell <alexgartrell@gmail.com> wrote:
> Anyway, long story short, this begs the question, how should we add
> this stuff to the config system?  Should we just do one cert per
> server (which is the practical thing) or should we do something closer
> to the way people view it (maybe one cert per host and only one host
> per ssl server?).  I figure this is a moderately sized schema change,
> so getting this right is important.

Sorry I'm probably responding too late to this, but I think it would
be great if you could have a different cert for each "domain". (That
is, "company.com" and "nonprofit.org" are separate domains even if
they're on the same box, but "sub.company.com" is also a separate
domain, if you've set your certs up that way.)  How you map this into
the mongrel2 schema we already have and that which you've already
planned might be more flexible.  Is it more "natural" to think of the
domain as a "Host" rather than a "Server"?  Even if it is, there's a
trade-off here: making it easier for a person with a bunch of domains
who wants to use different certs for each might make it harder for a
person with a bunch of domains and one cert.  It isn't clear which of
these two hypothetical users has the stronger claim.  Would it
undermine the hierarchy to just say you can put a cert at either level
and the finer-grained (Host) cert will win if both exist, but if only
the Server cert exists then the Hosts will inherit that?  That may be
more complication than you'd like to build in, since options are the
enemies of security.

cheers,
Jess

Just a few thoughts on the subject:

You can do ssl virtual host by using SNI (
http://en.wikipedia.org/wiki/Server_Name_Indication#Libraries) but probably
you already knew this.

Also as well we should have a "listen" option in the host/server config
(which we would need even if we weren't doing ssl) to be able to have more
than one mongrel2 instance in a machine.

I read about the "ssl dir" that Zed mentioned and I do not quite like it,
because it can become tricky with the cert chain.
One feature of ssl that is important (imho) is to be able to do client cert
authentication.

Plus also one thing that is important (not absolutely related to ssl but it
affects its implementation) is to be able to require ssl on a directory
scope. Since currently we do not have rewrite to force SSL, you could want
to give out a 403 in case somebody tries to access a sensitive resource over
plain text http.



On Wed, Sep 22, 2010 at 9:06 PM, Alex Gartrell <alexgartrell@gmail.com>wrote:

> Hey guys,
>
> We're looking to get HTTPS out of the gate soon, and it's already
> wired into the internals.  The only thing left to do is wire it up to
> the config and then we're good to go.  So why the email, over
> something so trivial?
>
> Well, it's kinda not.
>
> For the uninitiated, HTTPS is just like good ol' vanilla HTTP.  The
> only difference is, rather than send the bytes over a regular TCP
> socket, you send it over SSL (Secure Socket Layer).  Really, once
> you've found a decent library (we're using axTLS), it's a pretty
> straightforward undertaking.  As users of the library, all we have to
> do is wait for the handshake to complete (which is helpfully
> abstracted away by the library) and then it's business as usual.  This
> involves, among other things, providing your certificate to the client
> so that they can make sure that you are who they think you are
> (SeriousBankBusiness.com, etc.).
>
> Now, as you can guess, one of the quirks here is that you have to know
> which host the client thinks it's connecting to, which basically
> eliminates virtual hosting (that is, multiple Hosts from the same
> port) altogether.
>
> Anyway, long story short, this begs the question, how should we add
> this stuff to the config system?  Should we just do one cert per
> server (which is the practical thing) or should we do something closer
> to the way people view it (maybe one cert per host and only one host
> per ssl server?).  I figure this is a moderately sized schema change,
> so getting this right is important.
>
> Also, do we have a process for updating the config schema?  Now that
> we're releasing snapshots and actively going after users, it might be
> worthwhile to formalize this (even if it's just "mention it in the
> release notes" or equiv.)
>
> Thanks
>
> Alex
>



-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.