Lab4 - P-2 (4).pdf

TNE30024 Deploying Secure Engineering Applications Online Portfolio Task – Lab 4 Modifying existing HTTP Website to use HTTPS and encryption Pass Task 1 Introduction In earlier labs you have learnt how to create and validate certificates, in the nex...

TNE30024 Deploying Secure Engineering Applications Online Portfolio Task – Lab 4 Modifying existing HTTP Website to use HTTPS and encryption Pass Task 1 Introduction In earlier labs you have learnt how to create and validate certificates, in the next two labs you will be learning how to create and deploy certificates on an existing server-based applications to secure communications. In this lab, you will modify an existing HTTP web site to use HTTPS and encrypt all communications. Your rule host has been built with four functioning web sites; you will be converting one of these web sites to use a self-signed certificate. In this deployment, HTTPS will use TLS as the underlying communications channel, TLS will only: 1. Validate the server – the client can be sure that it is communicating with an authorised entity 2. Secure Communications – no other Internet user, or system administrator, will be able to read communications from the web browser to the web site or from the web site to the browser. In the subsequent lab we will look at creating HTTPS web sites that use certificates signed by a certificate authority. 2 Purpose Often, we only need to secure communications, and ensure that when we connect to and communicate with a server, we are talking to the correct server. In these cases, the client applications typically do not need to verify themselves to the server. If this is needed, you can often use a username/password combination between the client and the server after the encrypted channel is established. But, do keep in mind, for all HTTPS solutions, the client is not validated. This means any client can connect to your sever application. If it is important to validate the client, and you choose to use this approach, then part of the 1 communications between the client and the server after the TLS handshake is complete is for the client to authenticate itself with the server using some password or password-hash approach. The contents of this authentication will be encrypted during transport and cannot be decoded by others, but is required prior to allowing open comms with the server 3 Preparation There are some initial steps that you need to configure on your rule host before you are ready to actually complete the lab. The four web sites have all been set up for rule201.caia.swin.edu.au. So, you will need to modify some configuration files to ensure that everything is correctly established for your actual rule host (ie ruleXX). 3.1.1 DNS The DNS server is used in the Internet to translate from URLs to IP addresses. For example, when you type http://www.swin.edu.au into your browser, the system will query the DNS system to locate the IP address of www.swin.edu.au, and ultimately return. The DNS system is a distributed set of servers on the Internet that provide these mappings. Your rule host is already setup to run its own DNS server. On your personal DNS server, the system is configured to automatically query the Swinburne DNS server for all unknown names, and to create a new top-level URL called tne30024. Within this domain a number of URLs are created: ns1.tne30024 (DNS name server for the tne30024 domain) rule201.tne30024 (your rule host within the tne30024 domain) selfsigned.tne30024 (web site for this lab – lab 4) trusted.tne30024 (web site for the next lab – lab 5) chained.tne30024 (web site for the next lab – lab 5) You can query the DNS server for these names by executing the following command (where XX is your rule host number): nslookup 136.186.230.XX 2 Example: Root# nslookup rule201.tne30024 136.186.230.XX Server: 136.186.230.XX Address: 136.186.230.XX#53 trusted.tne30024 canonical name = rule201.tne30024. Name: rule201.tne30024 Address: 136.186.230.201 You can repeat the above with the other names. We will need to modify the DNS server to both change the name of rule201.tne30024 to ruleXX.tne30024, and to make all five of these names map to the IP address of your rule host. There are two configuration files for the DNS server that you need to edit. Before you make any changes, make backup copies of these files in case you make a mistake. 1. The first of these files to edit is: /usr/local/etc/namedb/working/tne30024 In this file change (where XX is your rule host): 1. Change the name rule201 on line 14 to ruleXX 2. Change the mappings for ns1 and rule201 on lines 14 and 15 to 136.186.230.XX 3. Change the CNAME values for selfsigned, trusted, and chained on lines 17, 18 and 19 from rule201 to ruleXX 2. The second file to edit is: /usr/local/etc/namedb/working/230.186.136.in- addr.arpa. In this file change (where XX is your rule host): 1. Change number 201 on line 14 to XX 2. Change the PTR value rule201.tne30024. to ruleXX.tne30024. 3  NOTE: The first file is responsible for mapping names to IP addresses, the second file is responsible for mapping IP addresses back to names. 3. Once you have made these changes, you will need to restart the DNS server by executing: /usr/local/etc/rc.d/named restart 4. Once this is done, confirm you have correctly made all the changes by performing a DNS lookup on ALL five names listed above. All names should now resolve to 136.186.230.XX 3.1.2 Web Server The web server has also been configured for rule201.tne30024, you will need to modify this for your own rule host. There are two relevant Web server configuration files. 1. The first of these is: /usr/local/etc/apache24/httpd.conf You will not need to modify this file at this stage, but you will need to do so later in order to complete the lab. This file contains generic configuration information for the web server. 2. The second file is: /usr/local/etc/apache24/extra/httpd-vhosts.conf This file contains the configuration for the four web sites on your rule host. The file contains four configuration blocks called , each block defines one web site. You will need to modify the first virtual host which defines the web site http://rule201.tne30024. In this file block you will need to modify the four instances of rule201 to ruleXX. Each of these configuration items defines: 1. ServerName – The full URL of the website 2. ServerAlias – Alternate URLs that can be used to access the web site 3. ErrorLog – The file where error messages from the web server when people try to access the web site are placed. This will be very useful to debug your lab 4  4. CustomLog – The file where all successful attempts to access the web server will be logged. Also useful for debugging 3. Once you have made these changes, you will need to restart the web server by executing: /usr/local/etc/rc.d/apache24 restart NOTE 1: You will need to restart the web server every time you modify the configuration. NOTE 2: Starting the web server will also check your configuration for syntax errors. Information will be printed to the screen and more detailed messages to /var/log/httpd-error.log 3.1.3 Testing the Web Server Your rule host is now hosting four unique web sites. You should start by using a web browser to browse to http://ruleXX.caia.swin.edu.au To test the other web sites, you will need to configure your system to use your RULE host as a DNS server. If you have your own device, you can do so by temporarily modifying the system configuration. There are two options: 1. Modify your system to use your rule host as a DNS server. Please see your windows, Mac, or Linux configuration guide to learn how to do so 2. Add the four relevant rule hosts to your systems hosts file. On Mac and Linux, this file can be found in /etc/hosts. This file is formatted as an IP address, followed by a tab, followed by a space separated list of all names that map to this IP address. On Windows, the file can be found in c:\Windows\System32\Drivers\hosts You will not be able to use any of the above options on a Swinburne PC, in this case there may be an addon for the browser that can accomplish the same output You should be able to browse to each of the four tne30024 web sites (ruleXX.tne30024, selfsigned.tne30024, trusted.tne30024, and chained.tne30024) once these changes are made. 5 4 Methodology To implement the Pass Task, you must correctly change https://selfsigned.tne30024 to a HTTPS web site protected with a self-signed certificate. You should verify that communications are encrypted via Wireshark. 4.1 Create the Certificate Please refer back to previous labs to create a self-signed certificate for this lab. You will need both the generated private key file and the signed certificate for your programs to function. Also consider the lectures about using certificates in real use. The server application needs to use the private key to encrypt communications with the browser, this key needs to be kept private. Similarly, the server also needs to have a certificate which includes details about the server, and the server public key to allow the browser to establish a secret channel with the server. NOTE 1: The browser will generate a temporary public/private key pair to establish communications NOTE 2: The private/public key pairs are used to establish an encrypted channel using an adaptation of the Diffie-Helman algorithm. The actual channel is encrypted using a randomly selected symmetric key. For a long time, it was expected the web site URL would be contained within the commonName field of the certificate. However, modern browsers no longer accept certificates where the site name is encoded within the commonName. Instead, the site name needs to be encoded within the subjectAltName as a DNS entry. When creating your certificates for web servers and other applications, you should include the server name in both the commonName and subjectAltName fields. When connecting, the browser TLS implementation will check that the subjectAltName in the certificate matches the name of the server connected to prior to allowing connection. When setting the subjectAltName, you should set this field to DNS:selfsigned.tne30024, this is equal to the name of the web site without the https:// field. 6 As you are no longer a 1st or 2nd year student, some of these tasks will need to be done using self exploration. Use online research tools to learn how to: 1. Create a self-signed certificate and corresponding private key 2. Incorporate the appropriate URL into the certificate within both the commonName and subjectAltName fields. 4.2 Installing the Certificate and Private Key The two files need to be copied or installed somewhere on your rule host in a directory with general access permissions. The web server runs as the user www, therefore if you place these files in a folder that only root (or student) can access, then the web server will not be able to open and use these files. NOTE 1: You should never install the private key in the directory that hosts the actual web site. All files in this directory are typically accessible via the browser and the private key needs to be protected. NOTE 2: The certificate is public and could be stored on the actual web site, but it is considered best practice to host this in another directory. 4.3 Modifying the Web Site 1. The first task is to re-configure the Apache web server to load the SSL module. The Apache SSL module provides all https:// functionality. This change should be made within the following file: /usr/local/etc/apache24/httpd.conf You will need to investigate the appropriate changes to make to this file to enable the SSL module. 2. The next task is to re-configure the selfsigned.tne30024 web site in the /usr/local/etc/apache24/extra/httpd- vhosts.conf file. All further changes need only be made to this file. a) The first change to make to this file is to tell Apache to accept connections on port 443 (the default https:// port). You will need to figure out the appropriate command to add to this file. b) The next task is to modify the selfsigned.tne30024 VirtualHost block to run over port 443, and to configure the certificate and private key information. Again, you will need to research appropriate steps to do so. 7  NOTE: This handout clearly describes what tasks you are supposed to accomplish, but not necessarily how to do them. This should give you the appropriate information to research. 3. Previous information explained many of the items within the VirtualHost block, the remaining items are: ServerAdmin – email address of server administrator DocumentRoot – The directory which hosts the web site files block – information about what is allowed on the web site, basically this block provides access to all files in DocumentRoot AND will automatically load the index.html file IF the basic URL is provided You will need to add extra configuration items in the VirtualHost block to enable SSL for this site, and to tell Apache the location of the Certificate and Private Key files 4. When finished, don’t forget to restart the Apache Server (see earlier in this document for the command) 4.4 Testing your Solution If you are able to modify your laptop or PC to use your rule host as a DNS server (or able to modify the hosts file), you should test your solution by browsing to your new web site – https://selfsigned.tne30024 The browser should complain about an un-trusted certificate, you will need to accept the risk and continue to actually see the web site in the browser. The web site should display, but with a red broken padlock to say that the site is untrusted. You can click on the padlock to review the certificate details and confirm it is the certificate you created earlier. You should also reload the web site while Wireshark is running to confirm that communications between the browser and your rule host are encrypted. If you are unable to use the browser due to using a Swinburne PC, you can use the automated marking script at http://ruleprimary1.caia.swin.edu.au/tne30024.php 8 At this web site, select the appropriate lab and your rule host, then choose to assess your work. The web site will: 1. Confirm that the DNS server on your rule host is appropriately resolving the URL selfsigned.tne30024 2. Try to access the https://selfsigned.tne30024 web site, this should fail as it is using an untrusted certificate 3. Try to access the https://selfsigned.tne30024 web site trusting the provided certificate, this should succeed 4. Compare the web site with the page as initially provided If all these tests are OK, the web site will report that you have successfully completed the lab. This concludes the lab task. 5 Assessment You will not need to demonstrate successful completion for this lab. Instead, when you have completed it, access the marking web site as listed above, mark your rule host, and download the output as a PDF file. This is evidence of successful completion of the lab which you will need to show to your lab supervisor Upon demonstration of the PDF file, you will also need to answer the lab supervisor’s interview questions about how you completed the lab. 9