From 0ad40b88ba4e2f00da0e3b861dd535516b3597cc Mon Sep 17 00:00:00 2001 From: Olivier Gayot Date: Fri, 16 Jan 2015 23:56:37 +0100 Subject: added content for the SSL practical Signed-off-by: Olivier Gayot --- practicals.adoc | 1 + ssl.adoci | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 102 insertions(+) create mode 100644 ssl.adoci 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 + >

It works!

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