added content for the SSL practical

Signed-off-by: Olivier Gayot <duskcoder@gmail.com>

2 files changed, 102 insertions, 0 deletions

diff --git a/practicals.adoc b/practicals.adoc
index b92e289..2d1bde3 100644
--- a/practicals.adoc
+++ b/practicals.adoc
@@ -3,3 +3,4 @@ include::apache.adoci[]
 include::ldap1.adoci[]
 include::ldap2.adoci[]
 include::dns.adoci[]
+include::ssl.adoci[]
diff --git a/ssl.adoci b/ssl.adoci
new file mode 100644
index 0000000..87c9ef1
--- /dev/null
+++ b/ssl.adoci
@@ -0,0 +1,101 @@
+== SSL Practical, Week 9 ==
+
+The purpose of this practical is to provide a secure way to communicate with
+our website. We will use SSL over HTTP for this purpose.
+
+At this end of the practical, we should be able to avoid any attempt of
+intercepting or altering our communications with our website when using the
+SSL layer.
+
+=== Problem 1: Passing the certificate out of band ===
+
+Using HTTP in order to send our certificate seems to be a very bad idea.
+Indeed, if a user is tampering our connection at the time the certificate is
+sent, he will be able to send to replace our certificate with a rogue crafted
+one.
+
+Since the purpose of using SSL over HTTP is exactly to avoid this king of
+attack, it seems very important to use a secure channel to send our
+certificate.
+
+==== Resolution ====
+
+Instead of using HTTP to send our certificate, we will use a trusted channel.
+Since we use SSH to access our virtual machine, we will use it to retrieve the
+certificate as well.
+
+    $ rsync csvm2c4e.kent.ac.uk:rootCA.crt .
+    > rootCA.crt
+    >       1,415 100%    1.35MB/s    0:00:00 (xfr#1, to-chk=0/1)
+
+Now we can add our 'rootCA.crt' file to the list of trusted CA of our web
+browser.
+
+Otherwise, we can use 'curl' directly:
+
+.trying to access the secure website without giving the CA certificate
+======
+
+    $ curl https://csvm2c4e.kent.ac.uk
+    > curl: (60) SSL certificate problem: self signed certificate
+
+======
+
+.trying to access the secure website using the CA certificate
+======
+
+    $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt
+    > <h1>It works!</h1
+
+======
+
+=== Problem 2: The certificate is only valid for Olivier Gayot ===
+
+When browsing our secure website with 'Firefox', it complains about the
+certificate being only valid for Olivier Gayot.
+
+It is actually the 'Common Name' field that 'openssl' was asking when signing
+our certificate with our private key.
+
+==== Resolution ====
+
+Although 'openssl' prompts:
+
+    > Common Name (e.g. server FQDN or YOUR name) []:
+
+we actually need to enter our FQDN (Fully Qualified Domain Name) so that
+'Firefox' stops complaining. We can figure our what our FQDN is by issuing the
+following command on our virtual machine.
+
+    $ hostname --fqdn
+    > csvm2C4E.kent.ac.uk
+
+Then, by regenerating our certificate with 'csvm2C4E.kent.ac.uk' as 'Common
+Name', 'Firefox' feels better.
+
+=== Problem 3: Testing our security ===
+
+What we would like to know now is what would happen if someones is altering our
+connection and trying to redirect our traffic to a rogue web server.
+
+==== Resolution ====
+
+We will use the file '/etc/hosts' to override the IP address of our web server.
+By adding the following line inside, we force our resolver to assume that the
+IP address of 'csvm2c4e.kent.ac.uk' is '104.130.219.184' (which is in fact the
+IP address of 'httpd.apache.org').
+
+    104.130.219.184 csvm2c4e.kent.ac.uk
+
+We can check that our entry has been taken into account:
+
+    $ resolveip csvm2c4e.kent.ac.uk
+    > IP address of csvm2c4e.kent.ac.uk is 104.130.219.184
+
+So now, we try to access the website using our CA certificate:
+
+   $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt
+   > curl: (60) SSL certificate problem: unable to get local issuer certificate
+
+Our security layer seems to work!
+