summaryrefslogtreecommitdiff
path: root/ssl.adoci
diff options
context:
space:
mode:
authorOlivier Gayot <duskcoder@gmail.com>2015-01-16 23:56:37 +0100
committerOlivier Gayot <duskcoder@gmail.com>2015-01-16 23:56:37 +0100
commit0ad40b88ba4e2f00da0e3b861dd535516b3597cc (patch)
tree42c98ce23557bbcf709f2debe7050ee5ed827767 /ssl.adoci
parent0f0eb74c5cf637ed92b6db5c5b1127f4994115e4 (diff)
added content for the SSL practical
Signed-off-by: Olivier Gayot <duskcoder@gmail.com>
Diffstat (limited to 'ssl.adoci')
-rw-r--r--ssl.adoci101
1 files changed, 101 insertions, 0 deletions
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!
+