Use --dh-param-file option to specify a file including DH parameters
in PEM format.
For example, you can create DH parameters with 1024 bit key using
following command:
$ openssl dhparam -outform PEM -out dhparam.pem 1024
shrpx:
* Added an option to set the TLS SNI extension between shrpx and the
origin on the command line
spdycat:
* If the user set an explicit host header ( using --headers ) use that
name for the TLS SNI extension.
* Added the handshake completion time to the verbose output
* The gettimeofday call in get_time was using the incorrect structure
( I believe )
* In update_html_parser it was submitting the request regardless of
the return value of add_request.
Patch from Stephen Ludin
Specify proxy URI in the form http://[USER:PASS]PROXY:PORT. USER and
PASS are optional and if they exist they must be properly
percent-encoded. This proxy is used when the backend connection is
SPDY. First, make a CONNECT request to the proxy and it connects to
the backend on behalf of shrpx. This forms tunnel. After that, shrpx
performs SSL/TLS handshake with the downstream through the tunnel. The
timeouts when connecting and making CONNECT request can be specified
by --backend-read-timeout and --backend-write-timeout options.
With --spdy-bridge option, it listens SPDY/HTTPS connections from
front end and forwards them to the backend in SPDY. The usage will be
written later. This change fixes the crash when more than 2
outstanding SpdyDownstreamConnection objects are added to SpdySession
and establishing connection to SPDY backend is failed.
This option specifies additional certificate and private key
file. Shrpx will choose certificates based on the hostname indicated
by client using TLS SNI extension. This option can be used multiple
times.
INFO log and its surrounding code are now guarded by
LOG_ENABLED(SEVERITY) macro so that they don't run if log level
threshold is higher. This increases performance because log formatting
is somewhat expensive.
This avoids the need to provide the password for your
private key interactively.
It can be used via --private-key-passwd-file or private-key-passwd-file
in the given config file. The first line in the file
(without \n) will be treated as the passwd. There isn't
any validation and all lines after the first one (if any)
are ignored.
The security model behind this is a bit simplistic so I
am open to better ideas. Basically your password file
should be root:root (700) and you *should* drop root
and run as an unprivileged user.
If the file exists and a line can be read then a callback
will be set for the SSL ctxt and it'll feed the passwd
when the private key is read (if password is needed).
If the file exists with the wrong permisions it'll be
logged and ignored.
The -k, --insecure option is added to skip this verification. The
system wide trusted CA certificates will be loaded at startup. The
--cacert option is added to specify the trusted CA certificate file.