331.2 X.509 Certificates for Encryption, Signing and Authentication
Weight: 4
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:
httpd.conf
mod_ssl
openssl (including relevant subcommands)
SSL, TLS and common Transport Security Threats
SSL and TLS
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.
stands for Secure Sockets Layer
stands for Transport Layer Security
originally the protocol used to secure web traffic
The TLS protocol is the successor to SSL beginning with TLS 1.0 which replaced SSLv3
The latest version of SSL is SSLV3, which has been deprecated
The current standard is TLS 1.2; however, TLS 1.3 has been purposed as an Internet Standard
Due to the deprecated nature of SSL, it should not be used.
Transport Layer Seurity
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.
Man-in-the-Middle Attack
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
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
With each TLS update, vulnerabilities such as POODLE and BEAST are patched, and weak ciphers are de-supported.
Working with Apache's mod_ssl
ssl.conf
It is located inside /etc/httpd/conf.d/
directory .Key directives for HTTPS configuration:
Enhancing cipher strength:
Configuring server-side certificates:
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:
SSLCACertificateFile
: CA certificate to check againstSSLVerifyClient
: Instructs server to verify client certificateSSLVerifyDepth
: Number of intermediaries (1 for local CA signed)
OCSP Stapling
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.
OCSP Stapling doesn't exit in ssl.conf file and should be added in the global section not in the Virtual Host section.
SNI
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
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
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).
HSTS
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.
Configure Apache in the appropriate context to send appropriate header information:
The Max-age
directive is required and specifies the number of seconds the site should be regarded as a known HSTS host
When implementing HSTS, start with a lower max-age and work up to a 2-year max-age over a few weeks This will allow fixes to be issued if needed during the transition to HSTS
includeSubDomains
is only needed if the domain has sub-domains A wild-card SSL certificate is necessary to support sub-domains
The preload directive
tells browsers to treat the host as a known HSTS host and to not make non- HTTPS requests The preload directive should only be added after a successful testing period with HSTS .
Configure Redirect to force HTTPS when HTTP request is made:
Troubleshooting using openssl
There are more usefull openssl commands:
that's all.
.
.
.
resources:
..
Last updated