- 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.
Daniel Lowrey [Tue, 4 Mar 2014 01:57:33 +0000 (18:57 -0700)]
Refactor + reorganize openssl files
- 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
Nikita Popov [Sat, 1 Mar 2014 22:51:03 +0000 (23:51 +0100)]
Abort on invalid key size
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.
Nikita Popov [Sat, 1 Mar 2014 14:42:07 +0000 (15:42 +0100)]
Abort on missing IV if the enc_mode requires it
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).
Nikita Popov [Sat, 1 Mar 2014 14:29:20 +0000 (15:29 +0100)]
Abort on invalid IV size
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.
Andrey Hristov [Wed, 5 Mar 2014 14:22:23 +0000 (16:22 +0200)]
Refactor the result set data structures. Move more to the buffered and unbuffered
substructures. Add methods to these too. Preparing for pluggable interface for
returning data to the engine (zvals, c-style, something else)
Remi Collet [Wed, 5 Mar 2014 09:40:36 +0000 (10:40 +0100)]
Fixed Bug #66815 imagecrop(): insufficient fix for NULL defer CVE-2013-7327
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).
Daniel Lowrey [Sun, 2 Mar 2014 14:03:39 +0000 (07:03 -0700)]
Capture peer cert even if verify fails
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.
Chris Wright [Sun, 2 Mar 2014 01:57:20 +0000 (01:57 +0000)]
Windows cert verify improvements + leak fixes
- 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
The reason behind this change is a stack allocation issue pointed
out by Dmitry: As of PHP 5.5 the stack necessary for pushing
arguments is precomputed and preallocated, as such the individual
SEND opcodes no longer verify that there is enough stack space.
The unpacked arguments will occupy some of that preallocated
space and as such following positional arguments could write past
a stack page boundary.
An alternative resolution for this issue is to ensure that there
is enough space for the remaining arguments in the UNPACK opcode.
However making this allocation precise (rather than using a
conversative over-estimate) would require some effort. Given that
this particular aspect of the feature wasn't very popular in the
first place, it doesn't seem worth the effort.
Nikita Popov [Tue, 25 Feb 2014 23:14:50 +0000 (00:14 +0100)]
Store arg_num in fcall entry
Instead of storing the argument number in the znode of the parameter
list, store it in fcall->arg_num. This mainly cleans up the parameter
parsing code, which previously had to duplicate all rules (this
becomes more excessive as more features are added, e.g. named params
would already require a minimum of 14 rules...)
Nikita Popov [Tue, 25 Feb 2014 22:39:50 +0000 (23:39 +0100)]
Introduce zend_function_call_entry structure
Instead of directly pushing the zend_function* onto the
function_call_stack, push this structure. This allows us to store
additional data on this stack.
Ferenc Kovacs [Wed, 26 Feb 2014 14:13:40 +0000 (15:13 +0100)]
Merge branch 'PHP-5.5' into PHP-5.6
* PHP-5.5:
add news entry
add news entry
add clear_env option to FPM config
add clear_env option to FPM config
Reduce test noise on cross Oracle client <-> server version tests. This fix is already in PHP 5.6+
Reduce test noise in cross Oracle client <-> server version testing. This change is already in PHP 5.6+
projects / php / log