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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
WWWOFFLE - World Wide Web Offline Explorer - Version 2.9
========================================================
This README describes how HTTPS connections work, the relationship of HTTPS to
SSL/TLS and how certificates work. More detail can be found in lots of places
on the internet.
The HTTPS protocol is a secure version of the HTTP protocol that is used for
transmitting web pages from the server to the browser. To allow the server to
distinguish between them a different port number is used. By default HTTP will
use port 80 and HTTPS will use port 443. WWWOFFLE will use port 8080 by default
for HTTP connections and when compiled with the GNUTLS library it will use port
8443 by default for HTTPS connections.
An HTTPS connection is just an HTTP connection but using SSL (Secure Socket
Layer) or TLS (Transport Layer Security) to encrypt and authenticate the data
between the server and the client. To be able to make a secure connection
there are various things that must be performed and options that can be used on
top of this for extra security.
Essential Security
------------------
The essential feature of a secure connection is that the server and client can
exchange data without anybody else being able to find out what the data is.
This means that even though the data that it transmitted goes through an
insecure network it has been encrypted so that nobody else can decode it. The
link must also be protected against an attacker being able to modify the data,
either be replacing the real data, adding more data or deleting data.
To establish a secure link the steps that are taken by the server and the client
are the following:
Agree on an encryption algorithm that both understand.
Exchange a secret key to use with the encryption.
The exchange of the encryption key must be performed so that anybody that has
visibility of the data being transmitted cannot determine the key. There are
several methods for doing this, Diffie-Hellman key exchange is one, RSA
public/private key encryption is another.
After these steps the data on the link can be encrypted with the chosen
algorithm and the chosen secret key.
Server Authentication
---------------------
An optional feature that is generally used for HTTPS is to have the server
authenticate itself to the client so that the client can be sure that the server
is the one it claims to be. This uses certificates and public/private key
cryptography to allow certificates to be signed by trusted certificate
authorities. If the browser trusts the certificate authority then it can also
trust any certificate that has been signed by that certificate authority.
Optional Client Authentication
------------------------------
As a further check on the link the server can require that the client
authenticates itself. This is supported in most browsers although it is rarely
used. Generally only bank or government HTTPS servers require this type of
authentication. A certificate must be loaded into the browser to identify the
user when connected to the server. The authentication is performed in the same
way that the server authenticates itself as described above.
Certificates
------------
With SSL and TLS the certificates that are used are defined as X509 objects.
This X509 object contains information about who the certificate represents (the
name, and location of the entity), the validity of the certificate (start date
and end date), a version number and serial number and what the certificate is
for.
For each certificate there is also a public and private key that is created at
the same time. The public key is included in the certificate and the
certificate contains information that can only be created by somebody with
knowledge of the private key. Using the public key it is possible to verify
that the certificate really does belong to the person that knows the private
key.
The certificate will also be signed by a certificate authority to make it
useful. When a certificate has been signed by a certificate authority the
contents cannot be changed. If the certificate was changed then this would
invalidate the certificate authority's signature. The certificate authority's
signature can be checked by using the certificate authority's public key. All
that an unsigned certificate proves is that the person that created it knows the
private key. It does not prove that the person that created it is who they say
they are.
Creating Certificates
---------------------
A certificate authority will create a master certificate whose usage is
certificate signing and will then sign that certificate themselves. This self
signed certificate is important since it is the root of the chain of trust that
ends in the browser. The certificate authority must make sure that this
certificate is made publicly available, and in particular that it is included
with all browsers.
The operator of a server who wants to be trusted by its users will create their
own certificate with the information about themselves and set the usage of the
certificate to be encryption. This certificate will be submitted to a
certificate authority who will sign it with their private key that belongs to
the master certificate. This signed certificate is then returned to the server
operator for use.
Trust
-----
The server can use this signed certificate during HTTPS connections. The browser
will be able to use the certificate authority's public key contained in the
certificate authority's certificate to verify the identity of the server. This
process relies on the browser trusting the certificate authority and the
certificate authority trusting the server operator.
To see the list of certificate authorities that are included in Firefox (version
1.0x was current at the time of writing this) select from the menu Edit ->
Preferences (or Tools -> Options on MS Windows). In the dialog box select the
"Advanced" tab and go down to "Certificates" and select "Manage Certificates".
In the certificate manager dialog box select "Authorities". There will be a
long list of certificates, many of these are certificate authorities for signing
other server certificates.
When you make a connection to a server that has a certificate signed by any of
these certificate authorities then your browser will not give you a warning. If
the server that you visit has a certificate that is signed by a different
certificate authority then the browser will warn you. This warning only means
that you cannot be sure who is operating the server that you have connected to.
The data that is transmitted between you and the server will be encrypted even
if the certificate is not trusted.
If there are any certificate authorities that are listed in your browser that
you do not trust then there is the risk of sending data to the wrong server.
When a server sends you a certificate during an HTTPS connection it will be
accepted by the browser if it validates with any of the loaded certificate
authorities. If you do not trust this certificate authority then the server may
not be who it says it is.
If any website ever asks you to load in a trusted certificate then be very
careful that it is not a certificate authority certificate. (You can identify a
certificate authority certificate because it will have a usage for certificate
signing.) If it is then you must trust the person giving it to you because this
certificate could be used to sign any other certificate and circumvent the normal
trust mechanism.
WWWOFFLE
--------
If you have enabled GNUTLS in WWWOFFLE then you have enabled some HTTPS
capability.
The WWWOFFLE server will create its own certificate authority certificate and a
certificate for each server name that the server can be accessed by. These can
be identified by the name information in the certificate that will contain the
word "WWWOFFLE" very clearly.
You can either load the certificate authority certificate from WWWOFFLE into
your browser (see the warning above about loading in new certificate authority
certificates) or you can accept the server certificate when your browser warns
you about it.
It is possible to use URLs like https://localhost:8443/ instead of
http://localhost:8080/ for access to the WWWOFFLE internal pages.
If you decide to allow it then you can cache HTTPS connections by abusing the
trust relationship between the browser and the certificate authority. When
accessing HTTPS servers through WWWOFFLE and caching the results WWWOFFLE will
re-encrypt the data from the server and send it to the browser using a fake
certificate. If you configure your browser to trust WWWOFFLE as a certificate
authority then the fake certificate from WWWOFFLE will be trusted just like it
was the real one from the original server.
Andrew M. Bishop
7th Jan 2006
|
