An untrusted public network.
Problems: Eve eavesdrops on network packets, Eve modifies network
packets, Eve injects
messages pretending to come from Alice/Bob, ....
Data cannot be read by unintended recipients;
Data cannot be altered without detection;
Data attributed to correct originator;
A cryptographic cipher is a pair of Encrypt and Decrypt algorithms such
that given plaintext
P, encryption key K1 and decryption key
D(K2,E(K1, P)) = P
In absence of knowledge about K2, it must be not be feasible to
recover P from the
ciphertext E(K1, P).
Given P and E(K1, P), it must not be feasible to recover K1
Note that the plaintext P can be any data, including plain te
We call E(K1, P) the ciphertext.
Symmetric/Secret key cryptography: K1 = K2;
Public key cryptography Cryptography: K1 6= K2
Bob (browser) wishes to communicate securely with Alice (web server).
If Alice and Bob share a secret
symmetric encryption key KAB then
B → A : E(K
,message(eg credit card details))
and A can decrypt the message as
message = D(K
A can also use K
to send data securely to B
A → B : E(K
If B can be sure that they only other
ncipal who knows the secret key
KAB is A then he
can feel safe about sen
ding credit card details to the
However, how does A and B come to share the secret key KAB?
Suppose that A has a (encryption) pu
blic key KA and a
corresponding (decryption) private
, P)) = P and that A’s
public key is widely known.
If B knows that A’s public key is K
could first propose a random
and send it
securely to A using
B → A : E(K
knows that the only principal who can d
iscover his proposed secret key
is A since only
the private decryption key K
after the above exchange B can be sure
that only K
is known to A.
This is a very simple example of a secure
y exchange protocol: the two
parties exchange a
series of messages,
after which they share a secret
It is also a very simple variation of the SSL/TLS protocol.
HTTPS = HTTP + SSL
The HTTPS protocol uses SSL/TLS to es
tablish a shared secret
between a browser B
and a web
. One the key exchange protocol
has completed then all subsequent
HTTP requests and
encrypted using this key.
Public Key Certificates
How does the browser B come to learn that A’s public key is
A public key certificate is a statement that is issued a
nd signed by a trusted
declaring that a given principal
(eg A) owns a given public key
This trusted third party is called a Certific
ation Authority and the CA uses
its own p
to ‘sign’ the certificate. This signature can be co
by anyone who knows the CA’s
A browser contains the public keys of a
number of well
known CAs. When
a browser first
connects to a web
over HTTPS the server sends its
certificate, and if it is signed by a
the browser recognizes then the
browser can continue the protocol and establish
the shared key.
B → A
A → B
certificate for K
B → A
A → B
X500 Names for X509 Certificates
We need to be able to uniquely name
principals if we are to support
that bind principal (identities) to their public keys.
X500: A proposed hierarchical naming
scheme. The intention was that
Names can be use
d to give a guaranteed name for
everything in the world!
. . .
X500 DNs are used to name principals
in X509 certificates.
X509 PKI in Practice
No clear plan on how to organize X500 dir
ectory in reality: hierarchical
naming suits military
and government but
does not work for businesses or
In practice, we have just one hierarchy pe
ation and/or have many
that sign certificates for each
other and for other principals
such as UCC and for individuals.
How does Alice learn Bob’s public key?
Alice knows and trusts a number of roo
CAs: eg, verisign.
CA Alice trusts to Bob provides
As only certify end
note the dan
ger of delegating to customer’s
be trusted to delegate).
HTTPS in the Browser
We use the protocol https://www.foo.bar
.com to indicate a desire f
from the browser to the web
The secure connection is successful if the c
ertificate is accepted as valid
and that web
demonstrates that it
can decrypt the key proposed by
the browser and that the Common
cert matches the domain
in the URL of the request/response.
This is a secure authentic connection.
Browser gives an indication if the secure connection is successful
Don’t embed HTTP content in HTTPS
If a page loads over HTTPS, but it includ
es some content that loads over
Browser (IE7/Firefox3) does not display lock and/or gives a warning
to the user.
(Safari does not detect mixed content).
However, embedded flash does not give this warning. Thus, a
in an HTTPS web page might be
exploitable by an attacker!
→ Check whether this applies to most recent versions of Firefox/IE.
Regardless, to be safe, should avoid spec
ifying the protocol in embedded
Don’t embed HTTP
content in HTTPS
web page is http, however, its
HTML source contains a form
<form method= "post"
A visitor using http does not know whether
they are actually visiting the
website or some site m
asquerading as wachovia.com and
therefore does not know where
their login credentials are being sent.
A request to http://wachovia.com shou
ld have resulted in a re
://wachovia.com where the user can then enter their
credentials. The visitor should be
o ’see’ that they have a secure
connection to the website they expect.
Flaws in the HTML
An old version of https://www.onsale.
com used GET for sensitive form
ibutes; on some
the URL was not secured by SSL
(though the contents of the page were).
Regardless, its best to do a POST.
Many examples of errors in the html:
BT once had a web
server with only 40
bit crypto enabled.
Verisign once forgot
the ’s’ in an http reference to a page where user
Modern browsers like Firefox provide
a range of checks for possible
‘mistakes’. However, it
is ultimately the user’
s responsibility to ensure that
the connection is secure and to t
An attacker registers the website
amason.com and obtains a valid
certificate that associates
their public key w
ith that website. Valid secure
connections can be made by the browser to
user might be confused about the domain of
Recall the GBK Chinese character set. It includes characters that l
/, ?, . and =.
Attacker owns domain evil.cn and gets a cert for *.evil.cn
Attacker sets up a
How is the ?u interpreted?
A browser visiting this web
site under https has a valid secure
connection to (a sub
in of) evil.cn, however, the user of the
browser probably thinks they are visiting
Extended Validation Certificates
A conventional certificate makes few claims
about the true identity of the
owner of a
An extended validation certificate requi
res a human lawyer at the CA to
validate the identify
of the individual re
questing the certificate. These
certificates are indented for highly secure
connections such as banks.
Look at http://verisign.com
Man in the Middle and Elsewhere Attack
Attacker sits between bank.com and user browser.
Attacker masquerades as bank.com to user browser.
User browser unknowingly connects to attacker via HTTP,
cker connects to bank via HTTPS
Attacker masquerades as bank.com to user browser.
User browser mistakenly connects to attacker via HTTPS,
Attacker connects to bank via HTTPS
Problems with accepting invalid certificates
If the browser user is niave
and is willing to a
ccept invalid certificates then
the browser user
will be subject to a man
Suppose that a malicious third party (bunk
.com) resides on the connection
browser and a web
The browser sends an https
ct request to bank.com. This is
intercepted by the man in
le who passes the request on to
The man in the middle responds
to the browser, masquerading as
bank.com but with an
invalid certificate (issued to bunk.com.
The browser war
ns the user that the certi
ficate is invalid as its Common
Name CN does not
match that of the
URL (bank.com) that the user is
If the user accepts the invalid certificate then the man
in the middle has a
to the user and a secur
connection to the bank and can
relay (and read/modify) data sent
between the user browser and the bank.