diff options
author | Olivier Gayot <duskcoder@gmail.com> | 2015-01-16 23:56:37 +0100 |
---|---|---|
committer | Olivier Gayot <duskcoder@gmail.com> | 2015-01-16 23:56:37 +0100 |
commit | 0ad40b88ba4e2f00da0e3b861dd535516b3597cc (patch) | |
tree | 42c98ce23557bbcf709f2debe7050ee5ed827767 /ssl.adoci | |
parent | 0f0eb74c5cf637ed92b6db5c5b1127f4994115e4 (diff) |
added content for the SSL practical
Signed-off-by: Olivier Gayot <duskcoder@gmail.com>
Diffstat (limited to 'ssl.adoci')
-rw-r--r-- | ssl.adoci | 101 |
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! + |