This commit is relatively major refactoring of the `openssl-sys` crate as well
as the `openssl` crate itself. The end goal here was to support OpenSSL 1.1.0,
and lots of other various tweaks happened along the way. The major new features
are:
* OpenSSL 1.1.0 is supported
* OpenSSL 0.9.8 is no longer supported (aka all OSX users by default)
* All FFI bindings are verified with the `ctest` crate (same way as the `libc`
crate)
* CI matrixes are vastly expanded to include 32/64 of all platforms, more
OpenSSL version coverage, as well as ARM coverage on Linux
* The `c_helpers` module is completely removed along with the `gcc` dependency.
* The `openssl-sys` build script was completely rewritten
* Now uses `OPENSSL_DIR` to find the installation, not include/lib env vars.
* Better error messages for mismatched versions.
* Better error messages for failing to find OpenSSL on a platform (more can be
done here)
* Probing of OpenSSL build-time configuration to inform the API of the `*-sys`
crate.
* Many Cargo features have been removed as they're now enabled by default.
As this is a breaking change to both the `openssl` and `openssl-sys` crates this
will necessitate a major version bump of both. There's still a few more API
questions remaining but let's hash that out on a PR!
Closes#452
SSL_CTX_add_extra_chain_cert assumes ownership of the certificate, so
the method really needs to take an X509 by value. Work around this by
manually cloning the cert.
This method has been around for over a year but I'm guessing nobody
actually used it since it produces a nice double free into segfault!
Allows recognizing when a stream is still in handshake mode and can gracefully
transition when ready. The blocking usage of the API should still be the same,
just helps nonblocking implementations!
Fix error caused by mismatched types while building crate
openssl for Raspberry Pi 2 and other ARM devices.
Signed-off-by: Leon Anavi <leon.anavi@konsulko.com>
Additionally impl Clone for SslContext to both allow us to use it &
allow external users to take advantage of SslContext's internal
refcount.
Maintain the existing signature for set_ssl_context(), but
add inline comments recommending changing it.
Fixes#333
SslStream::{clone,try_clone} are inherently broken since the Ssl object
shared by both streams is only going to be talking to one stream. Stuff
like hyper depends on try_clone, so we'll leave it here for now but
minimize the brokenness to "no worse than what it used to be like".
They'll be removed in 0.8.
cc #325
A new nonblocking socket may not have finished connecting yet, so reads
and writes can return ENOTCONNECTED which we should reinterpret into a
WantRead or WantWrite
Closes#323
SSL_CTX_use_certificate_chain_file() is preferred over
SSL_CTX_use_certificate_file().
It allows the use of complete certificate chains instead of loading
only the first certificate in a PEM file.
LibreSSL has deprecated SSLv3_method, so this commit makes that a compile-time
feature.
It also removes a test referencing SSL_OP_CISCO_ANYCONNECT, as the LibreSSL
header says it is amongst "Obsolete flags kept for compatibility. No sane code
should use them."
In OpenSSL world, the SSLv23 option is a poorly name method that will
negotiate what version of TLS or SSL to use. It starts with the best
version the library supports and then precedes to keep trying all the
way down to SSL 2.0.
The current behavior causes a server written using rust-openssl to (if
it cannot negotiate a protocol) fallback to the first protocol it has
avaliable.
This makes it impossible to detect protocol mismatches.
This updates our selection to be more similar to how openssl's
s_server behaves: non-matching protocols are not supplied with a
fallback.
Note that some setups may actually want a fallback protocol supplied
via ALPN. To support those cases, we should consider adding a generic
callback that allows protocol selection to be entirely controlled by
the programmer.
For the purposes of having a sane default, however, not supplying a
default (and mimicing s_server's behavior) is the best choice.
rust-openssl didn't support forward secrecy at all.
This adds support for DHE, by exposing set_tmp_dh() as well as the RFC5114
parameters, which are conveniently exposed since OpenSSL 1.0.2.
With OpenSSL >= 1.0.2, and the rfc5114 feature gate, enabling DHE is as simple
as (here for 2048-bit MODP group with 256-bit prime order subgroup):
use openssl::dh::DH;
let dh = DH::get_2048_256().unwrap();
ctx.set_tmp_dh(dh).unwrap();
With OpenSSL < 1.0.2, DH::from_params() can be used to manually specify the
DH parameters (here for 2048-bit MODP group with 256-bit prime order subgroup):
use openssl::bn::BigNum;
use openssl::dh::DH;
let p = BigNum::from_hex_str("87A8E61DB4B6663CFFBBD19C651959998CEEF608660DD0F25D2CEED4435E3B00E00DF8F1D61957D4FAF7DF4561B2AA3016C3D91134096FAA3BF4296D830E9A7C209E0C6497517ABD5A8A9D306BCF67ED91F9E6725B4758C022E0B1EF4275BF7B6C5BFC11D45F9088B941F54EB1E59BB8BC39A0BF12307F5C4FDB70C581B23F76B63ACAE1CAA6B7902D52526735488A0EF13C6D9A51BFA4AB3AD8347796524D8EF6A167B5A41825D967E144E5140564251CCACB83E6B486F6B3CA3F7971506026C0B857F689962856DED4010ABD0BE621C3A3960A54E710C375F26375D7014103A4B54330C198AF126116D2276E11715F693877FAD7EF09CADB094AE91E1A1597").unwrap();
let g = BigNum::from_hex_str("3FB32C9B73134D0B2E77506660EDBD484CA7B18F21EF205407F4793A1A0BA12510DBC15077BE463FFF4FED4AAC0BB555BE3A6C1B0C6B47B1BC3773BF7E8C6F62901228F8C28CBB18A55AE31341000A650196F931C77A57F2DDF463E5E9EC144B777DE62AAAB8A8628AC376D282D6ED3864E67982428EBC831D14348F6F2F9193B5045AF2767164E1DFC967C1FB3F2E55A4BD1BFFE83B9C80D052B985D182EA0ADB2A3B7313D3FE14C8484B1E052588B9B7D2BBD2DF016199ECD06E1557CD0915B3353BBB64E0EC377FD028370DF92B52C7891428CDC67EB6184B523D1DB246C32F63078490F00EF8D647D148D47954515E2327CFEF98C582664B4C0F6CC41659").unwrap();
let q = BigNum::from_hex_str("8CF83642A709A097B447997640129DA299B1A47D1EB3750BA308B0FE64F5FBD3").unwrap();
let dh = DH::from_params(p, g, q).unwrap();
ctx.set_tmp_dh(dh).unwrap();
When using DTLS you might run into the situation where no packets
are pending, so SSL_read returns len=0. On a TLS connection this
means that the connection was closed, but on DTLS it does not
(a DTLS connection cannot be closed in the usual sense).
This commit fixes a bug introduced by c8d23f3.
Conflicts:
openssl/src/ssl/mod.rs
The OpenSSL "SSL_OP_*" flags are in constant flux between different OpenSSL
versions. To avoid having to change the Rust definitions, we implement our
own numbering system in Rust, and use an automatically-generated C shim to
convert the bitflags at runtime.
Heavily based on the existing NPN wrapping code. Naming of public
functions is identical to the NPN ones with `s/npn/alpn/` applied to
prevent devs from needing to remember 2 names (and to let my copy the
npn tests and perform the subistution to generate the apln tests).
It might make sense to (at some point) use macros or a trait to cut down
the duplication.
Rather than having the verification data idx generation and NPN use
there own (similar) impls to generate indexes with destructors, unify
them.
Make NPNs use of indexes more idomatic by storing the index in a
lazyref rather than having a function with static data members.
Turns out this is called with a null pointer if you never set the data
which didn't end up doing anything until the recent zeroing drop
changes.
Also use a map of indexes since statics in generic functions don't
monomorphize
If a server socket is created with a context on which the
`set_npn_protocols` method has been called, during TLS connection
establishment, the server will advertise the list of protocols given to
the method, in case the client indicates that it supports the NPN TLS
extension.
The method is added to the `Ssl` struct, since this is how the native
OpenSSL API works. It is also added to the `SslStream` convenience
struct, since the `Ssl` instance that it wraps is not public and clients
may want to check which protocol is in use on a particular SSL stream.
After the `set_npn_protocols` method of the `SslContext` struct is
called, any future TLS connections established with this context will
perform NPN negotiation.
The chosen protocol is the one with the highest priority in the
server's protocol list that is also in the client's protocol list.
(This is the default behavior provided by OpenSSL's
`SSL_select_next_proto` function.)
If there is no overlap between the two lists, no error is raised.
A new method `set_npn_protocols` is added to the `SslContext` struct,
when the `npn` feature is enabled.
The method takes a list of protocols that are supported by the peer.
These protocols will be used during Next Protocol Negotiation.
The method saves the given list within the extra data of the OpenSSL
Context structure, so that the list can be referred to later on by the
callbacks invoked during TLS connection establishment.
Steven Fackler