SYS 360 Lab 8 1: TLS for LAMP Stack - JadenGil/Jaden-Tech-Journal GitHub Wiki
Enable TLS on the server:
Note from lab: A self-signed certificate is acceptable for testing but not production. If you expose your self-signed certificate to the internet, visitors to your site are greeted by security warnings.
Note from lab: launch a free-tier EC2 Amazon Linux 2 (HVM) instance NOTE: NOT AMAZON LINUX 2023 - that will cause issues with the next lab!
Starting this lab is pretty simple. Much like our previous LAMP labs we will want to make a key pair, security group, and an instance that connects to them before we can then SSH into them.
Key Pair:
Sec Group:
Instance:
Once we SSH into the lab we can really get started. We will first want to check if httpd is enabled:
If it is not enabled enable it and if you can't enable it then make sure it is installed using sudo yum install httpd and enable it once installed.
Double check the service is started to be safe:
Run a quick update on the machine to make sure all the packages are up to date by using sudo yum update -y
Note from lab: The -y option installs the updates without asking for confirmation. If you would like to examine the updates before installing, you can omit this option.
We will then want to install mod_ssl using sudo yum install -y mod_ssl:
The instance now has the following files that we will use to configure the secure server and create a certificate for testing:
/etc/httpd/conf.d/ssl.conf and /etc/pki/tls/certs/make-dummy-cert
Note from lab: The configuration file for mod_ssl. It contains directives telling Apache where to find encryption keys and certificates, the TLS protocol versions to allow, and the encryption ciphers to accept.
Note from lab: A script to generate a self-signed X.509 certificate and private key for your server host. This certificate is useful for testing that Apache is properly set up to use TLS. Because it offers no proof of identity, it should not be used in production. If used in production, it triggers warnings in Web browsers.
Then run the commands in the screenshot:
The file we just made contains both a self-signed certificate and the certificate's private key. Apache requires the certificate and key to be in PEM format.
The file will look something like this:
We now want to open the /etc/httpd/conf.d/ssl.conf directory to comment out the SSLCertificateKeyFile /etc/pki/tls/private/localhost.key line. I will be using nano.
Make sure the changes are saved and restart Apache:
Note from lab: Make sure that TCP port 443 is accessible on your EC2 instance via your Inbound Security Group
Deliverable 1:
Test and harden your TLS Server;
On this website we will want to enter the public DNS IP from our instance https://www.ssllabs.com/ssltest/
Once the test is completed we will see this:
Notes from lab:
Though the overview shows that there are Trust issues as you used a self-signed certificate - the rest of the configuration is mostly sound. The detailed report may flag several potential problems, such as:
✗ The RC4 cipher is supported for use by certain older browsers. A cipher is the mathematical core of an encryption algorithm. RC4, a fast cipher used to encrypt TLS data-streams, is known to have several serious weaknessesLinks to an external site.. Unless you have very good reasons to support legacy browsers, you should disable this.
✗ Old TLS versions are supported. The configuration supports TLS 1.0 (already deprecated) and TLS 1.1 (on a path to deprecation). Only TLS 1.2 has been recommended since 2018.
✗ Forward secrecy is not fully supported. Forward secrecyLinks to an external site. is a feature of algorithms that encrypt using temporary (ephemeral) session keys derived from the private key. This means in practice that attackers cannot decrypt HTTPS data even if they possess a web server's long-term private key.
To fix the TLS config we will need to edit the file /etc/httpd/conf.d/ssl.conf and comment out the line SSLProtocol all -SSLv3 and add the directive SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 underneath:
Notes from lab:
This directive explicitly disables SSL versions 2 and 3, as well as TLS versions 1.0 and 1.1. The server now refuses to accept encrypted connections with clients using anything except TLS 1.2. The verbose wording in the directive conveys more clearly, to a human reader, what the server is configured to do.
Disabling TLS versions 1.0 and 1.1 in this manner blocks a small percentage of outdated web browsers from accessing your site.
Now we want to edit the file /etc/httpd/conf.d/ssl.conf and comment out the line SSLCipherSuite:
Using this website https://ssl-config.mozilla.org/#server=apache&version=2.4.62&config=intermediate&openssl=1.1.0&guideline=5.7 we want to enter the following information:
Once we hit the enter key it will provide us with a lot of information but we only want the SSLCipherSuite and we can copy it and put it into the file we just edited:
There is much more to that cipher but it gets cut off by the screen.
Just below that section in the file, we will want to uncomment the highlighted directive:
Note from lab: This directive forces the server to prefer high-ranking ciphers, including (in this case) those that support forward secrecy. With this directive turned on, the server tries to establish a strong secure connection before falling back to allowed ciphers with lesser security.
Now we want to save the changes and restart Apache and go back to https://www.ssllabs.com/ssltest/ and clear the cache before putting the DNS IP back into the website.
Deliverable 2: