Dear all,
This mail is a warning, that after an upgrade to the newest version from git,
some of your configuration files/applications might need adjustments,
The newest commit to the main repository brings more security, by validating in
ns_http client requests always the server certificate. While this is common for
browsers, this is not necessarily the case for automated web operations (web
services etc.), opening a large attack vector for man-in-the-middle attacks
(see below). So far, checking the certificates was per default deactivated,
which has the consequence, that in practice, many (most?) application
developers just used with the defaults, leading to an unpleasant situation.
Now, certificated checking is activated, it can be deactivated by adding the
parameter “-insecure” to an “ns_http” request (there are other means, see
below).
The regression test (including self-signed certificates for HTTPS, revproxy, …)
works fine.
Next steps for me:
- check consequences for letsencrypt
- add similar changes to “ns_connchan open|connect"
- documentation of certificate management in detail (covering ns_http,
ns_connchan, admin-config)
We are getting closer to the release candiate...
all the best
-gn
Security by default for HTTP client requests (ns_http)
Background: Authenticating the peer is a critical part of SSL connection setup
when a client connects to a server. In this process, the server presents its
public-key certificate. If the results of this authentication is missing, a
server might be vulnerable to man-in-the-middle attacks. Protection against
this is one of the intentions of HTTPS, and becomes more important when backend
transactions are performed via HTTPS (administration of servers, cloud
infrastructure, payments, ...), establishing secure network tunnels, or when
sending confidential information via HTTPs
As the paper mentioned below points out, the validation of peer certificates is
usually in place for web communication over the browser, but it is often not
active for web service interactions. One reason for this is that application
developers choose very often the default setup.
The key instrument of NaviServer for performing HTTP client operations is
ns_http, which certainly has the ability for certificate validation, but so far
it was per default deactivated. This changes now with NaviServer 5, where the
default is now including validation.
One of the consequences of validating peer certificates is that the
administrator has to care about certificates (what certificates are accepted),
including management of self-signed certificates.
We try to make the transition as smooth a possible by providing a reasonable
default setup including established root certificates (ca-bundle.crt),
providing simple means to add your own trusted certificates (including
self-signed certificates). This default setup can be altered for a server via
the configuration file, or for every single request via parameters.
The most important changes are:
- new parameter "-insecure" for "ns_http run" and "ns_http queue"
This parameter turns off certificate validation for the target HTTPS server.
The name follows the naming convention of curl.
- The old parameter "-validate" is a now a no-op.
Per default, all ns_http requests to HTTPS servers are now validated
- Store certificates in directory ${NSHOME}/certificates instead of
${NSHOME}/etc
- New configuration parameter "CApath" and "CAfile" for the "httpclient"
section of a server to specify default locations for certificate validation. It
is possible to override these values via parameters to "ns_http run" and
"ns_http queue".
Default configuration:
ns/${server}/httpclient {
ns_param CAfile ... ;# default ${NSHOME}/ca-bundle.crt
ns_param CApath ... ;# default ${NSHOME}/certificates
}
* "CAfile" points to a .pem file containing established root certificates,
often named "ca-bundle.crt". This file contains multiple of these certificates.
The version shipped with NaviServer is based on Mozilla's root certificates.
Also, many operating systems provide these certificates (e.g., on Ubuntu
/etc/ssl/certs/ca-certificates.crt). One can certainly use various sources,
e.g. via symbolic links or configuration parameters. The file can be manually
updated e.g. via
curl https://curl.se/ca/cacert.pem -o /usr/local/ns/ca-bundle.crt
* "CApath" points to a directory containing CA certificates in PEM
format. Each of the files must contain exactly one CA certificate (OpenSSL
requirement).
It is possible to add self-signed certificates to this directory to
connect via ns_http with an HTTPS URL to this server, after running
openssl rehash ${NSHOME}/certificates
The rehash operation is performed automatically in the installation
process.
- New configuration parameter "insecure" for the "httpclient" section of a
server
The Most Dangerous Code in the World: Validating SSL Certificates in
Non-Browser Software
https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
- Added certificate settings to sample configuration files nsd-config.tcl and
openacs-config.tcl
- Minor cleanup of Makefiles (improve consistency and configurability)
- similar changes for "ns_connchan connect|open" will follow
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
