This adds an openssl dependency that is required. Future versions (0.9.1+) will make this optional. No openssl location is available in the configure command, so I had to hack it with C_INCLUDE_PATH during make. Hopefully it is fixed in future versions.
Closes#467.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
Patch has been accepted into upstream master, but the old link now 404s.
Originally added in Homebrew/legacy-homebrew#20759.
2753e70013/
Closes#899.
Closes#1101.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
Due to the more or less blind trust external tools place in the PEM generated and
stored in `/usr/local/etc/openssl` (Presuming your Homebrew is in the normal place)
it's possible for self-signed or explicitly not trusted certificates to be treated
as perfectly valid and safe.
This results in some potentially unexpected differences between system-provided tools
and Homebrew-provided tools linked against different crypto libraries.
By default both the system curl (Since Mountain Lion) and Homebrew's curl (For ML and above)
are linked to Apple's Secure Transport, which handles self-signed certificates in
the Keychain as invalid unless they are explicitly trusted and throws the following
error on connection: `* SSL certificate problem: Invalid certificate chain`.
If you mark the certificate in the Keychain as explicitly trusted both the system
and default Homebrew curl respect that and will permit the connection to be established:
```
Connected to abc.def (xxx.xxx.xxx.xx) port 443 (#0)
TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Server certificate: abc.def
...
Connection #0 to host abc.def left intact
```
This is also the situation for at least Safari and Google Chrome on OS X, where
Keychain trust status guides whether or not the self-signed certificate should be
trusted.
Where things are potentially more dicey is where you have built Homebrew's curl
against OpenSSL or LibreSSL, which is a fairly common configuration, and you have
a self-signed certificate in the Keychain when OpenSSL/LibreSSL is installed/upgraded/etc.
That self-signed cert is folded into the PEM and treated as perfectly valid, even
if it was marked explicitly not trusted in the Keychain at time of PEM creation.
This enables self-signed cert connections to go ahead without notification of the
potential issue. It's mildly easier to spot on verbose curl connections, but no obvious
warning is included that you're using a self-signed certificate for the connection.
The example below was explicitly generated as a test cert and tagged as such:
```
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=GB; O=TEST.ORG; OU=TESTING; CN=abc.def; emailAddress=test@abc.def
* start date: May 9 20:28:52 2016 GMT
* expire date: June 9 20:28:52 2016 GMT
* common name: abc.def (matched)
* issuer: C=GB; O=TEST.ORG; OU=TESTING; CN=abc.def; emailAddress=test@abc.def
* SSL certificate verify ok.
```
Although curl is used for testing here, wget and other utilities that trust
OpenSSL's PEM file are impacted as well.
This change results in the PEM file only containing system root certificates, which
is a more secure default position to take.
If you relied on the previous behaviour you can re-enable it by copying PEM files
into `/usr/local/etc/openssl/certs` & running `$(brew --prefix openssl)/bin/c_rehash`.
You may need to pass the directory to specific tools or by setting the SSL_CERT_DIR
variable.
Credit to Geoff Nixon for the original report. Extra testing done by me against
an Ubuntu server running the latest nginx release.
Closes#1072.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
