331.2 X.509 Certificates for Encryption, Signing and Authentication
Description: Candidates should be able to use X.509 certificates for both server and client authentication. This includes implementing user and server authentication for Apache HTTPD. The version of Apache HTTPD covered is 2.4 or higher.
Key Knowledge Areas:
- Understand SSL, TLS, including protocol versions and ciphers
- Configure Apache HTTPD with mod_ssl to provide HTTPS service, including SNI and HSTS
- Configure Apache HTTPD with mod_ssl to serve certificate chains and adjust the cipher configuration (no cipher-specific knowledge)
- Configure Apache HTTPD with mod_ssl to authenticate users using certificates
- Configure Apache HTTPD with mod_ssl to provide OCSP stapling
- Use OpenSSL for SSL/TLS client and server tests
Partial list of the used files, terms and utilities:
- openssl (including relevant subcommands)
SSL and TLS were developed primarily to protect Web transactions, but they can be used to protect any type network traffic that utilizes TCP at the transport layer. Both SSL and TLS are located above TCP in the protocol stack. Applications that interface with TCP when security is not required interface with SSL or TLS when security is required.
SSL and TLS both are solutions to answer security issues exists in a public network communication. The protocols meet the following needs:
• Securely encrypt exchanged data
• Authenticate at least one party
• Ensure data integrity
• Prevent replay attacks
Transport layer security achieves this through the use of PKI as well as general encryption practice.
A man-in-the-middle attack is a type of eavesdropping attack, where attackers interrupt an existing conversation or data transfer. After inserting themselves in the "middle" of the transfer, the attackers pretend to be both legitimate participants. This enables an attacker to intercept information and data from either party while also sending malicious links or other information to both legitimate participants in a way that might not be detected until it is too late.
You can think of this type of attack as similar to the game of telephone where one person's words are carried along from participant to participant until it has changed by the time it reaches the final person. In a man-in-the-middle attack, the middle participant manipulates the conversation unknown to either of the two legitimate participants, acting to retrieve confidential information and otherwise cause damage.
Common abbreviations for a man-in-the-middle attack including MITM, MitM, MiM, and MIM.
There are different types of Man in the Middle Attacks, one of them is SSL Hijackting:
This is what it is critically important to use TLS 1.3 or newer as soon as feasible. It is also important to encrypt all traffic.
POODLE attack vulnerability
The POODLE attack (which stands for "Padding Oracle On Downgraded Legacy Encryption", CVE-2014-3566) is a man-in-the-middle (MITM) exploit which allows a hacker to decrypt select content within the SSL session.
Variations of the POODLE vulnerability affects TLS because an active MITM attacker can force a browser to downgrade the session down to SSLv3, which can then be exploited.
BEAST attack vulnerability
The BEAST attack, reported as CVE-2011-3389, exploits a weakness in SSL/TLS cipher-block chaining (CBC), allowing a man-in-the-middle attacker to recover certain session information, such as cookie data, from what should be a secure connection.
With each TLS update, vulnerabilities such as POODLE and BEAST are patched, and weak ciphers are de-supported.
It is located inside
/etc/httpd/conf.d/directory .Key directives for HTTPS configuration:
Enhancing cipher strength:
## Configure Cipher Usage:
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
# The OpenSSL system profile is configured by default. See
# update-crypto-policies(8) for more details.
# User agents such as web browsers are not configured for the user's
# own preference of either security or performance, therefore this
# must be the prerogative of the web server administrator who manages
# cpu load versus confidentiality, so enforce the server's cipher order.
Configuring server-side certificates:
## Secure http traffic with PKI:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that restarting httpd will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
# Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
# require an ECC certificate which can also be configured in
## Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
# ECC keys, when in use, can also be configured in parallel
#Server Certificate Chain:
- SSLCertificateFile: Public key certificate given to users
Note: As of httpd 2.4.8, the intermediate CA certificates may also be included in this file The Certificates should be provided from root to leaf (highest level CA at the bottom) This new functionality obsoletes SSLCertificateChainFile
- SSLCertificateKeyFile: Private key for a webserver
Configure client certificate authentication:
## Authenticate with a client certificate:
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
- SSLCACertificateFile: CA certificate to check against
- SSLVerifyClient: Instructs server to verify client certificate
- SSLVerifyDepth: Number of intermediaries (1 for local CA signed)
OCSP Stapling is one of the many new features introduced with httpd 2.4. It allows client software using SSL to communicate with your server to efficiently check that your server certificate has not been revoked.
SSLStaplingCache "shmcb:logs/ssl_stapling(32 768)"
OCSP Stapling doesn't exit in ssl.conf file and should be added in the global section not in the Virtual Host section.
Server Name Identification (SNI) is an extension of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocol that enables you to host multiple SSL certificates on a single unique Internet Protocol (IP) address.
The problem with using named virtual hosts over SSL is that named virtual hosts rely on knowing what hostname is being requested, and the request can't be read until the SSL connection is established. The ordinary behavior, then, is that the SSL connection is set up using the configuration in the default virtual host for the address where the connection was received.
While Apache can renegotiate the SSL connection later after seeing the hostname in the request (and does), that's too late to pick the right server certificate to use to match the request hostname during the initial handshake, resulting in browser warnings/errors about certificates having the wrong hostname in them.
And while it's possible to put multiple hostnames in a modern certificate and just use that one certificate in the default vhost, there are many hosting providers who are hosting far too many sites on a single address for that to be practical for them.
The solution is an extension to the SSL protocol called Server Name Indication (RFC 4366), which allows the client to include the requested hostname in the first message of its SSL handshake (connection setup). This allows the server to determine the correct named virtual host for the request and set the connection up accordingly from the start.
With SNI, you can have many virtual hosts sharing the same IP address and port, and each one can have its own unique certificate (and the rest of the configuration).
HTTP Strict Transport Security (HSTS) is a web security policy mechanism used for securing HTTPS websites against downgrade attacks. HSTS prevents your web browser from accessing the website over non-HTTPS connections.
To enable HSTS for Service Manager , you only need to enable HSTS in the web server (Apache or IIS) or the web application server (Tomcat or WebSphere) so that an HTTP header named Strict-Transport-Security is added when an HTTPS session has already been established.
There are more usefull openssl commands:
## Establish a secure connection:
openssl s_client -connect <host>:<port>
## Validate a trust chain:
openssl verify -verbose <certificate>
## Show all certificates in the certificate chain
openssl s_client -connect <host>:<port> -showcerts
## Forces a specific cipher. Useful for testing enabled SSL ciphers
openssl s_client -connect <host>:<port> -cipher DHE-RSA-AES256-SHA
## View Certificate details:
openssl x509 —text <cert_file>