Apache HTTPD with mod_ssl: Exploring configuration options

This is yet another blog post related to LPIC-3 Exam 303: Security. Knowing Apache configuration options is an important topic for Security Engineers. Apache web server is often serving web interfaces or acting as reverse proxy (for example for Splunk or Kibana). TLS configuration is an important step for securing these interfaces from eavesdropping and man-in-the-middle attacks. Let's examine Apache web server configuration with mod_ssl.

TLS configuration

SSL/TLS configuration file resides under /etc/httpd/conf.d/ssl.conf.

SSLCertificateFile and SSLCertificateKeyFile mod_ssl directives are used to enable https. 

SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"

 

Mutual TLS authentication

To enable client authentication with certificate we need the following three directives:

  • SSLVerifyClient: set to require, so client has to present a valid certificate
  • SSLVerifyDepth: the maximum number of intermediate certificate issuers, default: 1
  • SSLCACertificateFile: CA certificate for client authentication
SSLVerifyClient require
SSLVerifyDepth 10
SSLCACertificateFile "/etc/apache2/conf/root_cert.pem"

 

Online Certificate Status Protocol (OCSP) stapling

OCSP is a standard for checking the revocation status of X.509 digital certificates. It contrary to Certificate Revocation Lists (CRL), OCSP allows to check the certificate status in real time.

SSLStaplingCache directive specifies cache location and size (bytes). 

SSLUseStapling on 
SSLStaplingCache "shmcb:/tmp/stapling_cache(128000)"

 

Server Name Indication (SNI)

SNI allows a server to present multiple certificates on the same IP address and port number, which enables the name-based virtual hosts with unique certificates. This way, multiple websites can be hosted on a single web server. 

If SSLStrictSNIVHostCheck is enabled, SNI unaware clients won't be able to connect. All modern browsers support SNI. 

SSLStrictSNIVHostCheck on

 

HTTP Strict Transport Security (HSTS)

As  RFC 6797 describes, HSTS is "a mechanism enabling web sites to declare themselves accessible only via secure connections [...]". By sending Strict-Transport-Security header, the server instructs browser to always access the page via HTTPS. 

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

max-age (at least 1 year), includeSubDomains and preload directives must be specified to leverage HSTS preloading mechanism (which basically ensures that a site will be never visited using unsecured connection).

Comments

Post a Comment

Popular posts from this blog

Splunk: Authentication with Discord? Wht not! (OAuth 2.0)

Image
As some of you may already know, thanks to OAuth standard (which stands for Open Authorization) we don't need a separate account for every single website. It allows us to share information about our Google account with a third party, such as our name and e-mail address. On many sites we are free to use that "Login with Google/Facebook/other" button to sign up and/or login. Thanks to OAuth we don't have to give our password to the app/website. Upon login we are redirected to the OAuth provider site to login there (for instance to our Google account). And now the best part - if we are already logged on the provider site, this is likely to result in instant login on a third party site (sometimes interrupted by a pop up to confirm OAuth scope).  Here is a list of well-known OAuth providers (Wikipedia): https://en.wikipedia.org/wiki/List_of_OAuth_providers To get better understanding of OAuth 2.0 I would recommend reading these docs for developers: Using OAuth 2.0 to Acces...
Read more

Study notes: Understanding DNSSEC

Image
DNSSEC Recently I have been researching materials covering DNSSEC as it is an important subject for LPIC-3 Exam 303. DNSSEC has been developed to address security issues of the DNS protocol, in particular preventing DNS cache poisoning attacks . Below I post DNSSEC description from Internet Corporation for Assigned Names and Numbers (ICANN), which I find useful and included in my study notes.  "DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it's not DNS queries and responses themselves that are cryptographically signed, but rather DNS data itself is signed by the owner of the data. Every DNS zone has a public/private key pair. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures over that data. As the name "private key" implies, this key material is kept secret by the zone owner. The zone's public key, however, is published in the zone itself ...
Read more

Linux: auditd fundamentals

Image
auditd stands for the audit daemon and it can be used to log events happening on a Linux host. It is a very powerful tool that can enable Threat Detection and/or - as the name suggests - create audit records. It writes to /var/log/audit/audit.log and collects such information as timestamp, PID, UID, Audit UID (auid), session info (ses), SELinux info (subj) and message (msg). Installation auditd is installed by default on most of the Linux distributions. In my case, I'm using RHEL 8 for the test purpose. The package is called audit .  Rules auditd is rule-based software and it support the following three types of rules: control : to configure general settings of the audit system, such as event rate limit, etc. file : file rules or watches can monitor files or directories and are using the following syntax: -w path-to-file -p permissions -k keyname syscall : these rules are loaded into the matching engine that intercepts every single syscall on the system and for this reason they ...
Read more