Dear all, A stable version of the certificate validation management for outgoing HTTPS requests (ns_http, ns_connchan) for NaviServer 5 is now in the NaviServer repository on GitHub. The current documentation is also online:
https://naviserver.sourceforge.io/5.0/manual/files/admin-config.html#subsection13 Let me know, if you have additional requirements in this regard. The newest version of NaviServer runs since this morning on openacs.org <http://openacs.org/>. All the best -gn > On 23.01.2025, at 18:43, Gustaf Neumann (sslmail) <neum...@wu.ac.at> wrote: > > 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
