1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
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!
|
