Previously only one address was used by the listen directive handler even if host name resolved to multiple addresses. Now a separate listening socket is created for each address.
If ngx_pool_cleanup_add() fails, we have to clean just created SSL context manually, thus appropriate call added. Additionally, ngx_pool_cleanup_add() moved closer to ngx_ssl_create() in the ngx_http_ssl_module, to make sure there are no leaks due to intermediate code.
OpenSSL 1.1.1 does not save server name to the session if server name callback returns anything but SSL_TLSEXT_ERR_OK, thus breaking the $ssl_server_name variable in resumed sessions. Since $ssl_server_name can be used even if we've selected the default server and there are no other servers, it looks like the only viable solution is to always return SSL_TLSEXT_ERR_OK regardless of the actual result. To fix things in the stream module as well, added a dummy server name callback which always returns SSL_TLSEXT_ERR_OK.
A virtual server may have no SSL context if it does not have certificates defined, so we have to use config of the ngx_http_ssl_module from the SSL context in the certificate callback. To do so, it is now passed as the argument of the callback. The stream module doesn't really need any changes, but was modified as well to match http code.
Dynamic certificates re-introduce problem with incorrect session reuse (AKA "virtual host confusion", CVE-2014-3616), since there are no server certificates to generate session id context from. To prevent this, session id context is now generated from ssl_certificate directives as specified in the configuration. This approach prevents incorrect session reuse in most cases, while still allowing sharing sessions across multiple machines with ssl_session_ticket_key set as long as configurations are identical.
Previously, when using proxy_upload_rate and proxy_download_rate, the buffer size for reading from a socket could be reduced as a result of rate limiting. For connection-oriented protocols this behavior is normal since unread data will normally be read at the next iteration. But for datagram-oriented protocols this is not the case, and unread part of the datagram is lost. Now buffer size is not limited for datagrams. Rate limiting still works in this case by delaying the next reading event.
A shared connection does not own its file descriptor, which means that ngx_handle_read_event/ngx_handle_write_event calls should do nothing for it. Currently the c->shared flag is checked in several places in the stream proxy module prior to calling these functions. However it was not done everywhere. Missing checks could lead to calling ngx_handle_read_event/ngx_handle_write_event on shared connections. The problem manifested itself when using proxy_upload_rate and resulted in either duplicate file descriptor error (e.g. with epoll) or incorrect further udp packet processing (e.g. with kqueue). The fix is to set and reset the event active flag in a way that prevents ngx_handle_read_event/ngx_handle_write_event from scheduling socket events.
Previously, AF_UNIX client addresses were handled as AF_INET, leading to unexpected results.
In the past, there were several security issues which resulted in worker process memory disclosure due to buffers with negative size. It looks reasonable to check for such buffers in various places, much like we already check for zero size buffers. While here, removed "#if 1 / #endif" around zero size buffer checks. It looks highly unlikely that we'll disable these checks anytime soon.