- New "SNI_server_certs" context option maps host names to
appropriate certs should client handshakes advertise the
SNI extension:
$ctx = stream_context_create(["ssl" => [
"local_cert" => "/path/to/cert.pem",
"SNI_server_certs" => [
"domain1.com" => "/path/to/domain1.pem",
"*.domain2.com" => "/path/to/domain2.pem",
"domain3.com" => "/path/to/domain3.pem"
]
]]);
- Prefixing a "*." will utilize the matching cert if a client
requests the primary host name or any subdomain thereof. So
in the above example our "domain2.pem" will be used for both
requests to "domain2.com" -and- "subdomain.domain2.com"
- The "SNI_server_certs" ctx option has no effect for client
streams.
- SNI support is enabled by default as of 5.6 for both servers
and clients. Servers must specify the "SNI_server_certs" array
to actually use the SNI extension, though.
- If the `"SNI_enabled" => false` ctx option is also passed then
"SNI_server_certs" has no effect.
- While supporting SNI by itself is enough to successfully
negotiate the TLS handshake with many clients, servers MUST
still specify a "local_cert" ctx option or run the risk of
connection failures from clients that do not support the SNI
extension.
- All streams-related code now lives in xp_ssl.c. Previously
stream code was split across both openssl.c and xp_ssl.c
- Folded superfluous php_openssl_structs.h into xp_ssl.c
- Server-specific options now set on SSL_CTX instead of SSL
- Deprecate SNI_server_name ctx option
- Miscellaneous refactoring
Previously an incorrectly sized key was either silently padded
with NUL bytes or truncated. Especially the silent nature of this
behavior makes it extremely easy to use weak encryption. A common
mistake - which has also been extensively made in our tests - is
to use a password instead of a key.
Incorrectly sized keys will now be rejected.
Previously the code fell back on using a NUL IV if no IV was
passed and the encryption mode required it. This is dangerous and
makes no sense from a practical point of view (as you could just
as well use ECB then).
Previously, if the size of the IV did not match the block size
mcrypt would throw a warning and fall back to a NUL IV. This
behavior is both dangerous and makes no practical sense.
mcrypt_encrypt etc. will now return false if the IV has an incorrect
size.
This amends commit 8f4a537, which aimed to correct NULL dereference because of
missing check of gdImageCreateTrueColor() / gdImageCreate() return value. That
commit checks for negative crop rectangle width and height, but
gdImageCreate*() can also return NULL when width * height overflows. Hence
NULL deref is still possible, as gdImageSaveAlpha() and gdImagePaletteCopy()
is called before dst == NULL check.
This moves NULL check to happen right after gdImageCreate*(). It also removes
width and height check before gdImageCreate*(), as the same check is done by
image create functions (with an extra warning).
From thoger redhat com
Previously the "capture_peer_cert" SSL context option only
captured the peer's certificate if the verification routine
succeeded.
By also capturing the on verify failure applications have the
ability to parse the cert and ask users whether they wish to
proceed given the information presented by the peer.
- Clean up properly at all fail points in native Windows peer
verification routine
- Bring certificate usages and chain flags into line with chromium
implementation in windows environments
