Category Archives: Website

Connect to OpenLDAP server with PHP5 (CentOS 7)

Here is a short PHP sample script of how to connect to an OpenLDAP server using the secure LDAPS protocol (port 636).

PHP uses the LDAP settings from the LDAP base packages. in the case of CentOS 7 they are configured in /etc/openldap/ldap.conf . Following two entries are the only ones that are important:

TLS_CACERTDIR   /etc/openldap/certs
TLS_REQCERT     demand

The first line gives the location of the public CA certificate that was used to sign the LDAP server certificate. The second line rejects all invalid certificates. To make the first line work, we need to import the public CA certificate into the local NSS database. For that we use the certutil command line utility (root privileges required):

certutil -A -n ldap -t "C,," -d dbm:/etc/openldap/certs -i /etc/ssl/certs/ldap-ca.pem
certutil -L -d dbm:/etc/openldap/certs

The first line imports an existing CA certificate into the database (with the nickname "ldap" which should be unique). The certificate database uses the old Berkeley DB format, so we need to prefix the location with "dbm:". There are 2 files that make up the certificate database:

  • cert8.db
  • key3.db

The second line of the code example merely lists all existing database entries. It should now include our new CA certificate for LDAP connections:

[root@centos7]# certutil -L -d dbm:/etc/openldap/certs 
Certificate Nickname                                         Trust Attributes 
                                                             SSL,S/MIME,JAR/XPI 
 
ldap                                                         C,,

Notice the 3 trust attributes for our new CA certificate. In our case the first field needs to include the trust "C". For a description of all possible values, see "man certutil".

Now that we installed the CA certificate for LDAPS connections, we can actually try to make a connection to the LDAP server with PHP5.

<?php 
$server = "ldaps://ldap.example.org"; 
 
echo "Connecting to $server ...\n"; 

#ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7); 
 
$ldapconn = ldap_connect($server, 636) 
        or die("ERROR: Unable to connect to $server\n"); 
 
ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3); 
 
$ldapbind = ldap_bind($ldapconn) 
        or die("ERROR: Unable to bind to $server\n"); 
 
echo "Ok, now connected to $server\n"; 
 
ldap_unbind($ldapconn); 
?>

Here we make an anonymous connection to the LDAP server. You can also provide a username and password for the ldap_bind() function call. Now call this script from the command line (needs yum package "php-cli"):

$ php php-test.php
Connecting to ldaps://ldap.example.org ... 
Ok, now connected to ldaps://ldap.example.org

Important things to note:

  • Call ldap_set_option() to activate debug output.
  • ldap_connect() does not actually connect to the LDAP server. It only initializes internal data structures and variables. The network connection to port 636 will be made by ldap_bind().
  • You need to explicitly set the LDAP protocol version to 3. Otherwise version 2 will be used, which will not work with contemporary OpenLDAP servers.
Share

Certificate Authorities (CA) in Google Chrome / Chromium and Firefox on Linux

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is the list of all root CAs included in Firefox along with their fingerprints:
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Builtin root CAs are hardcoded in /usr/lib/firefox/libnssckbi.so . You can see a list of all CAs in Firefox preferences (advanced settings).

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d $HOME/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:
https://www.chromium.org/Home/chromium-security/root-ca-policy

In Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so which is part of the package "libnss3". You should therefore update this package as soon as there is an update available to keep your builtin CA list up-to-date.

CAs that are not builtin and that you installed manually are stored in your home directory:
certutil -d sql:$HOME/.pki/nssdb -L

Important things to note:

  • The security of SSL encrypted websites (https://...) depends on the root CA which is used to sign the website certificate. These CAs are stored locally on your device in different locations based on the browser you are using.
  • There are 2 kinds of CAs:
    1. Builtin CAs that ship with your browser or linux installation. They are stored in shared object files. There is probably no easy way to edit this list unless you change the source files and recompile the package. Nevertheless in both browsers you can remove all trust from a builtin certificate which is basically the same as deleting it.
    2. Manually added CAs are stored in your home directory. You can easily edit that list within the settings of the browser or on the command line.
  • Both Firefox and Chromium / Google Chrome use NSS certificate databases to store manually added CAs that are not builtin. But they use different directories. Maybe you could use symbolic links to point both directories to the same database. That way both browsers would be using the same manual CA list.Currently Firefox uses by default the legacy dbm database version (cert8.db, key3.db) and Chromium / Google Chrome uses by default the new SQLite database version (cert9.db, key4.db). There seems to be an environment variable NSS_DEFAULT_DB_TYPE that makes Firefox use the new SQLite database version as well (s. https://wiki.mozilla.org/NSS_Shared_DB_Howto).
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".
Share

HSTS with Apache and Chrome

  • HSTS (HTTP Strict Transport Security) prevents your browser from visiting a website over an unencrypted "http://..." url. Instead you have to use the encrypted "https://..." url, otherwise your browser refuses to load the website.
    Either the webserver of the website you are visiting suggests the use of HSTS to your browser by sending an additional HTTP header, or you manually configure a certain website yourself in your browser.
  • Apache requires the module mod_headers to make the necessary changes to the HTTP headers.
  • Add this to your Apache vhost configuration:
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    For a description of all options see RFC: https://tools.ietf.org/html/rfc6797#section-6
    The "preload" option is not part of the RFC. It just signals that you want your site to be added to the browser builtin list of HSTS sites (see below). If you do not plan to get listed, you may omit this option.
  • Visit the site at least once using HTTPS in your Chrome browser ("trust on first use"). The HSTS configuration of the site (provided by the Apache STS header) will be added to an internal Chrome list. HSTS really depends on this internal browser list. Webservers only send an additional HTTP header that webbrowsers may or may not honor.
  • Add, delete or check websites in your Chrome browser:
    chrome://net-internals/#hsts
    Changes take place immediately without having to restart Chrome.
    You can add sites even if they don't send the special STS header.
    You can combine those entries with PKP (Public Key Pinning) by providing fingerprints for all accepted public keys of a website.
  • Chrome ships with a builtin list of sites that require HSTS. If you run a large public website, you might want to get included in that list: https://hstspreload.appspot.com/
    These builtin sites get listed as "static_..." in your internal Chrome browser list. All other sites (added manually or by honoring the STS header) get listed as "dynamic_...".
  • You cannot delete site entries from the builtin list (assuming that you use the official Chrome browser and that it has not been manipulated).
  • This is the message you get in Chrome when HSTS is violated on a website (in this case the certificate of www.rolandschnabel.de has expired and therefore Chrome refuses to establish the HTTPS connection):
You cannot visit www.rolandschnabel.de right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

Important things to note:

  • Even for HSTS enabled sites, you may still be able to type in the "http://..." URL in the browser address bar. Chrome automatically recognizes the URL and redirects you to the corresponding "https://..." URL.
    This is different from traditional HTTP redirects, because no unencrypted traffic is sent over the network. The redirection already takes place in the browser.
    The downside of this behaviour is that it makes it hard for people to identify if a website is using HSTS or simply redirects all traffic from HTTP/port 80 to HTTPS/port 443 (HTTP status codes 3xx).
  • Many browser plugins now offer the same functionality (redirect some or all website addresses to HTTPS URLs).
  • Maybe some day HTTPS URLs become the default in webbrowsers. If you type a URL in the address bar, or select a URL without the leading "http(s)://", the browser first redirects you automatically to the HTTPS URL. Only if there is no connection possible, you will receive a warning message and get redirected to the HTTP URL. Let's make HTTPS the default in browsers and accept HTTP only for a small number of exceptions.
    No green lock icon for SSL encrypted websites, just red unlock icons for unencrypted websites.

 

Share

Security check for Apache 2.4 webserver (TLS)

You can use nmap to show what kind of ciphers your webserver is supporting.

List all supported protocols and ciphers of a webserver:
nmap --script=ssl-enum-ciphers -Pn -p 443 www.local.example

Set the following configuration options in you Apache server config:

SSLEngine on
SSLOptions +StrictRequire
SSLHonorCipherOrder on
SSLProtocol all -SSLv3

SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache "shmcb:/..."   (requires mod_socache_shmcb)
SSLSessionTickets off

SSLStrictSNIVHostCheck on

To get a list of all protocols and ciphers that your webserver supports you can use nmap:
$ nmap --script=ssl-enum-ciphers -Pn -p 443 mailserver.local.example

Share

Browser blank page / white page with php script (WordPress, etc.)

I recently had a completely white / blank browser page when I tried to reset my WordPress password. It was from a local WordPress installation on my Debian 8 Jessie server. I was resetting my password for the admin login. It turned out that there was a problem with my php.ini settings. I had to add the following paths to the open_basedir variable:

open_basedir = /usr/share/php:/usr/share/php5

When resetting the WordPress password, WordPress includes some php files to send a reset email in wp-includes/pluggable.php:

require_once ABSPATH . WPINC . '/class-phpmailer.php';
require_once ABSPATH . WPINC . '/class-smtp.php';

The problem is that with the standard wordpress package on Debian 8 Jessie, class-phpmailer.php and class-smtp.php are symbolic links to /usr/share/php/... . If this path is not included in open_basedir, the php script just terminates without sending any error messages. I couldn't find anything in the apache logs either. The browser showed a blank page.

This might also be a problem with other php web applications. So if you experience a similar situation (no output of php script, blank page) you might want to check the open_basedir variable in you php.ini and make sure that all required / included php files and symbolic links are part of it.

If you have any ideas how to find out if a php script is trying to include a file outside of open_basedir, please leave a comment.

Share

Make imdb work with Google Chrome browser (blank black video)

Recently Google Chrome introduced the ability to activate plugins only after user confirmation. While this is a very good setting to increase your security level (especially for flash plugin), it prevents certain sites to display their content, e.g. imdb.com.

The video window on imdb.com will stay black, no error message, no way to activate the flash plugin. If you want to make it work, add an exception to the plugin content settings.

Within chrome, go to "Settings" -> "Privacy" -> "Content settings..." -> "Plugins" -> "Manage exceptions..." and add the following to the list of plugin exceptions:

[*.]imdb.com              allow
Share