[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 02/27/2013 08:06 PM, Jardel Weyrich wrote:


It seems that you're right. The next feature release will be 1.0.2
though, but I don't see an ETA - http://www.openssl.org/news/state.html
But from looking at the CHANGES file, it looks like the host checking is slated for 1.1.0, rather than 1.0.2, unless I'm misreading it or they change their minds. So, if we don't even know when 1.0.2 will be, 1.1.0 could be a while. 


libcurl is a good candidate. The still-not-released OpenSSL function
seems to support wildcard in any subdomain label. Libevent could ship a
copy of it, but only use it when the host version of OpenSSL is <=
1.<something>. That would require including the proper license, I guess.

Thoughts?


I guess there are two axes to consider here.  One axis is license:
a) the iSECPartners code is MIT licensed, and cURL is licensed under a license which seems to be somewhere in the neighborhood of MIT and BSD3, although not quite either. So both of these seem compatible in spirit with libevent's BSD3 license, although technically they are different licenses.
b) Taking the code directly out of the unreleased OpenSSL would ensure maximum compatibility with the future OpenSSL release, but would be covered under OpenSSL's funny 6-clause license with the dreaded "advertising clause", which makes it more restrictive than libevent's BSD3. 

The other axis is where to put this code.  I see three possibilities:
1) In libevent itself (or technically, in libevent_openssl, which is already a separate library), which seems to be implied by your suggestion "libevent could ship a copy"
2) As part of the https-client example in libevent's "samples" directory. Although I guess this still technically "ships with" libevent, it isn't part of libevent proper. (This is the approach I've taken on the branch I've put together; see below.) So if someone was basing their code on https-client, they'd copy the relevant files (hostcheck.[ch] and openssl_hostname_validation.[ch]) into their own program. This would be slightly less convenient for the user, but would avoid bloating libevent or exposing it to more licenses.
3) Create a new library. I've expressed before (on the randombit cryptography mailing list) that OpenSSL isn't a "batteries included" experience, so it could benefit from a helper library. (Something developed entirely separately from OpenSSL, perhaps led by me and hosted on github, so there wouldn't be the same barrier to entry as getting code into OpenSSL proper.) Since OpenSSL itself is split into libcrypto and libssl, the helper library would probably be split into libcrypto_extra and libssl_extra, or something like that. Stuff like this hostname validation code would go in libssl_extra, while stuff like threading callbacks (which I think it's almost criminal that OpenSSL doesn't provide built-in defaults for pthreads and Windows threads, the way libraries like libevent or GnuTLS do) would go in libcrypto_extra. I'm curious if there's any interest in a "helper library" like this, which could "fill the gap" between OpenSSL itself, and applications or libraries which consume OpenSSL.
Anyway, food for thought. But now, without further ado, here is my branch which takes Catalin's original https-client.c, fixes a few small issues (or things which I considered issues in my opinion), and finally adds the hostname checking. I structured it as a number of separate commits, to hopefully make it clear each change I was making and why.
I don't consider this a pull request, exactly, since I think it needs further discussion and study from the folks on this list. So, it's more of a "review request". But I'll go ahead and provide the output of "git request-pull" here, to make it clear where it is (it's the "https" branch of my ppelleti/libevent repo on github). I'd welcome any feedback, or if anyone wants to take this branch and take a stab at refining it further.
So far, I've only tested this code on Ubuntu 10.04 (albeit with OpenSSL 1.0.1c, not the system's OpenSSL). In particular, I haven't tested it on Windows. (Although since the "sample" directory doesn't seem to have a Makefile.nmake at all, Windows has bigger problems before it can build this sample. I may have to look into that at a later date.) 

The following changes since commit 87c56727b61e48c102d21f1bb6477de8ec001869:
  Nick Mathewson (1):
        Merge pull request #41 from ppelleti/winsock-errs

are available in the git repository at:

  git@xxxxxxxxxx:ppelleti/libevent.git https

Catalin Patulea (1):
Add sample/https-client.c, an example of stacking evhttp as a client on top of bufferevent_ssl. 

Patrick Pelletier (7):
      use ${OPENSSL_LIBS} instead of -lssl -lcrypto
      https-client was putting newlines at 256-byte boundaries
      better handling of OpenSSL errors
      use Debian's default root certificate location
      use iSECPartners code to validate hostname in certificate
      avoid sign mismatch warning in openssl_hostname_validation.c
      pull in wildcard matching code from cURL

 .gitignore                           |    1 +
 sample/hostcheck.c                   |  217 ++++++++++++++++++++++
 sample/hostcheck.h                   |   30 +++
sample/https-client.c | 332 ++++++++++++++++++++++++++++++++++ 
 sample/include.am                    |   13 ++-
 sample/openssl_hostname_validation.c |  168 +++++++++++++++++
 sample/openssl_hostname_validation.h |   56 ++++++
 7 files changed, 816 insertions(+), 1 deletions(-)
 create mode 100644 sample/hostcheck.c
 create mode 100644 sample/hostcheck.h
 create mode 100644 sample/https-client.c
 create mode 100644 sample/openssl_hostname_validation.c
 create mode 100644 sample/openssl_hostname_validation.h

--Patrick

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.