[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] [PATCH] Add sample/https-client.c, an example of stacking evhttp as a client on top of bufferevent_ssl.

On Wed, Feb 20, 2013 at 9:03 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
On Wed, Feb 20, 2013 at 12:42 PM, Catalin Patulea <catalinp@xxxxxxxxxx> wrote:
> On Tue, Feb 19, 2013 at 9:40 PM, Jardel Weyrich <jweyrich@xxxxxxxxx> wrote:
>> 2) Call SSL_CTX_load_verify_locations passing the path of the CA
>> certificates installed by the aforementioned package - generally
>> /etc/ssl/certs/ca-certificates.crt
> Nick, does this seem like a reasonable solution?
> SSL_CTX_load_verify_locations(ssl_ctx,
> "/etc/ssl/certs/ca-certificates.crt", NULL);

Seems like it could work fine for an initial attempt. ÂOf course, it
needs to check for errors and report them if they occur.

Even thoughÂlibevent cannot assume that file exists - it would have to ship it, or an alternative to it.
Are we talking about the test case? If yes, another option would be to generate some certificates - 2 CAs, plus 2 certs per CA (1 valid, 1 expired), and 2 extra self-signed certs. It's likely that more certs are needed to cover all possible scenarios. Lengthy work, but can be done.

With this in mind, will libevent try to cover all possibilities in a test case?

Also, in addition to this and SSL_verify, I think you may need to call
SSL_get_certificate_status() [or whatever it's called] and
SSL_get_peer_certificate() in some combination,

By SSL_get_certificate_status, do you mean checking whether the certificate is valid (not expired, not revoked, etc)?
and check that the
hostname in the cert matches the hostname you're trying to connect to
-- unless *think* openssl does this for you?

There's X509_check_host for that, but I'm really not sure whether it's enough or not.
Might be a good idea to check how Chromium does that.

BTW, have a look at http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf ,
for information/entertainment value. ÂA lot of software gets this
stuff wrong, and makes it easy to get it wrong. ÂI'd like to make sure
we test this pretty hard, to make sure that:
 * a self-signed certificate doesn't get accepted
 * a CA-signed certificate for the wrong hostname doesn't get accepted
 * whatever else we'd be likely to overlook if we forgot to test the
failing cases

> Anything more than this feels, to me, outside the scope of a libevent sample.
> In a related vein, is it possible to get OpenSSL to immediately dump
> errors to stderr? The only API I can find (ERR_*) let you inspect
> errors after the fact (ERR_get_error, ERR_print_error, etc.) but I
> would prefer not to clutter the sample with those calls unless
> necessary?

I don't know of an API like that in openssl. Â(Anybody?)

AFAIK, it has no callback support for this kind of "automatic error reporting", except for SSL_set_info_callback, which sets a callback to report errors and state changes for a given SSL connection. FWIW, Tor uses it (see src/common/tortls.c).

You could still wrap the OpenSSL functions and have your wrappers call a custom callback in case of error, or just print directly. Boring task, I know.

- jw