When connecting to a non-existent HTTPS service, the "req" is not null
but the "evhttp_request_get_response_code(req)" is zero.
Closes: #822 (cherry-picked)
LibreSSL 2.7 implements OpenSSL 1.1 API except for BIO_get_init()
See also: https://bugs.freebsd.org/226900
Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>
Closes: #617 (cherry-pick)
This reverts commit c4e9d9bd662de7f575f2172c160795d452ebe709
("sample/https-client: check for ERR_remove_thread_state() existence").
Calling AC_SEARCH_LIBS() modifies LIBS - -lcrypto incorrectly
ends up in LIBS, and thus linked to by libevent_core.so.
Checking for ERR_remove_thread_state should no longer be needed
because it was introduced in openssl 1.0.0, and the previous line
0.9.8 had support discontinued at the end of 2015.
Fixes: #473
Currently a static (Debian) certificate path is used by default, which
can be overridden using the -crt parameter. This commit changes the
default behaviour such that the openssl default certificate store is
used, unless overridden by -crt.
Signed-off-by: David Disseldorp <ddiss@suse.de>
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..."
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 :(
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.
