From 0d0e3b3c05b5e3004f526bf0ace02885c36ce2d5 Mon Sep 17 00:00:00 2001
From: Olivier Gayot <duskcoder@gmail.com>
Date: Sun, 10 May 2015 20:36:08 +0100
Subject: use *.asciidoc(i) extension instead of *.adoc(i)

Signed-off-by: Olivier Gayot <duskcoder@gmail.com>
---
 ssl.asciidoci | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 ssl.asciidoci

(limited to 'ssl.asciidoci')

diff --git a/ssl.asciidoci b/ssl.asciidoci
new file mode 100644
index 0000000..87c9ef1
--- /dev/null
+++ b/ssl.asciidoci
@@ -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!
+
-- 
cgit v1.2.3