diff options
author | Olivier Gayot <duskcoder@gmail.com> | 2015-05-10 20:36:08 +0100 |
---|---|---|
committer | Olivier Gayot <duskcoder@gmail.com> | 2015-05-10 20:36:08 +0100 |
commit | 0d0e3b3c05b5e3004f526bf0ace02885c36ce2d5 (patch) | |
tree | fa151f80dcdf2ca2174ac83aa137333947ef1a19 /ssl.adoci | |
parent | 013d621eb8e5493e1401a69ac99da1485d46cc37 (diff) |
use *.asciidoc(i) extension instead of *.adoc(i)
Signed-off-by: Olivier Gayot <duskcoder@gmail.com>
Diffstat (limited to 'ssl.adoci')
-rw-r--r-- | ssl.adoci | 101 |
1 files changed, 0 insertions, 101 deletions
diff --git a/ssl.adoci b/ssl.adoci deleted file mode 100644 index 87c9ef1..0000000 --- a/ssl.adoci +++ /dev/null @@ -1,101 +0,0 @@ -== 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! - |