|
462e6b60
|
2014-03-12T12:45:41
|
|
add a cast to https-client.c
|
|
d7be7887
|
2014-01-22T11:15:17
|
|
Fix https-client compilation on Windows.
ssize_t is not defined. But using ssize_t for s in this context makes no
sense, since fread returns size_t.
|
|
|
4cb44fdf
|
2014-01-21T14:26:01
|
|
Merge remote-tracking branch 'joakimsoderberg/new_cmake'
Conflicts:
sample/https-client.c
|
|
|
4e143958
|
2014-01-21T11:30:27
|
|
Change all uses of WIN32 to _WIN32
|
|
|
88ecda3b
|
2013-12-24T14:37:30
|
|
Fix a couple of "#ifdef WIN32" instances
|
|
|
d1976f8e
|
2013-12-24T14:05:44
|
|
Sample HTTPS Client: Set hostname for SNI extension (by f69m)
Patch from f69m on SourceForge
|
|
|
90786eb0
|
2013-12-24T12:59:36
|
|
Small tweaks to https-client.c
|
|
|
0ef1d04e
|
2013-12-17T14:32:07
|
|
Get rid of unknown pragma warnings.
|
|
|
69c3516b
|
2013-12-17T13:28:23
|
|
Get rid of deprecation warnings for OpenSSL on OSX 10.7+
|
|
|
19222e52
|
2013-12-13T17:00:23
|
|
Added some GCC specific options.
- Added sample applications.
- Fixed the https-client to work on Windows kind of (No cert validation).
|
|
29af65eb
|
2013-04-14T15:41:44
|
|
https-client: code cleanup
|
|
|
902bf21e
|
2013-04-14T15:12:22
|
|
Merge branch 'master' of https://github.com/libevent/libevent into https
|
|
|
95acdaa3
|
2013-04-10T17:56:54
|
|
Another tweak to https-client.c
|
|
|
8a90a850
|
2013-04-10T13:53:44
|
|
Remove http_struct.h usage in sample/https-client.c
|
|
|
c5887f73
|
2013-03-11T18:31:19
|
|
POST supported, args supported
|
|
64d9f161
|
2013-02-27T17:16:27
|
|
use iSECPartners code to validate hostname in certificate
The problem is that if you go to a website whose certificate does not
match its hostname, it should fail. Try this in a web browser for
https://www.kegel.com/ for example. Your web browser will say the
certificate is for *.pair.com, not for www.kegel.com, and won't let
you visit it without clicking through a bunch of scary warnings.
However, prior to this commit, https-client was happy to fetch
https://www.kegel.com/ without complaining. That is bad. Now, with
this commit, it will properly complain, which is good:
pelletier@chives:~/src/libevent/sample$ ./https-client https://www.kegel.com/
Got 'MatchNotFound' for hostname 'www.kegel.com' and certificate:
/C=US/postalCode=15203/ST=Pennsylvania/L=Pittsburgh/street=Suite 210/street=2403 Sidney Street/O=pair Networks, Inc./OU=Provided by pair Networks, Inc./OU=PairWildcardSSL $250,000/CN=*.pair.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$
It will still succeed for sites with an exactly-matching certificate,
such as https://github.com/ and that is also good!
However, the problem is that the iSECPartners code doesn't handle
wildcards, which means we reject https://ip.appspot.com/ even though
it is perfectly legitimate, because we don't understand the wildcard:
ppelletier@chives:~/src/libevent/sample$ ./https-client https://ip.appspot.com/
Got 'MatchNotFound' for hostname 'ip.appspot.com' and certificate:
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$
So, we need to fix this. In other words, "to be continued..."
|
|
|
aacd674c
|
2013-02-26T00:06:50
|
|
use Debian's default root certificate location
as suggested here:
http://archives.seul.org/libevent/users/Feb-2013/msg00034.html
although curl's acinclude.m4 reveals many other possibilities:
dnl /etc/ssl/certs/ca-certificates.crt Debian systems
dnl /etc/pki/tls/certs/ca-bundle.crt Redhat and Mandriva
dnl /usr/share/ssl/certs/ca-bundle.crt old(er) Redhat
dnl /usr/local/share/certs/ca-root.crt FreeBSD
dnl /etc/ssl/cert.pem OpenBSD
dnl /etc/ssl/certs/ (ca path) SUSE
And none of these cover Windows :(
|
|
|
5754d96a
|
2013-02-25T23:43:05
|
|
better handling of OpenSSL errors
|
|
|
42d7441a
|
2013-02-25T23:14:26
|
|
https-client was putting newlines at 256-byte boundaries
presumably this was meant to put a ">" before every line, but that
isn't what it does, since evbuffer_remove is simply returning
fixed-size chunks. So, when retrieving a document of more than 256
bytes (e. g. any nontrivial document), we got "> " and newlines thrown
in at very arbitrary places.
|
|
be46c99b
|
2013-02-19T12:22:31
|
|
Add sample/https-client.c, an example of stacking evhttp as a client on top of bufferevent_ssl.
Signed-off-by: Catalin Patulea <catalinp@google.com>
|