sample/openssl_hostname_validation.c: In function 'matches_common_name':
sample/openssl_hostname_validation.c:80: warning: comparison between signed and unsigned integer expressions
sample/openssl_hostname_validation.c: In function 'matches_subject_alternative_name':
sample/openssl_hostname_validation.c:124: warning: comparison between signed and unsigned integer expressions
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.
This made the difference between segfaulting and not segfaulting for
me when I run https-client, when I've built libevent using an OpenSSL
in a non-standard location.
In the same spirit as 1d9d5110a4aebf5833f6fd78bd0252affde0f4d0 and
d70af27d0152d0a87a25127faf215604beb8ffe0.
Before this patch socket created before domain was resolved, and it
always create with AF_INET (ipv4), but we must create socket only after
domain was resolved to understad which protocol family have domain
address.
Thank to Patrick Pelletier, who found this bug.
There's no way to retrieve an fd from an evconnlistener whose
callback has been cleared, so we had better close any such fd.
Found by coverity; CID 739725.
