HTTPS
Network Security
An untrusted public network.
Problems: Eve eavesdrops on network packets, Eve modifies network packets, Eve injects
messages pretending to come from Alice/Bob, ....
 Confidentiality - Data cannot be read by unintended recipients;
 Integrity - Data cannot be altered without detection;
 Authentication - Data attributed to correct originator;
Cryptography
A cryptographic cipher is a pair of Encrypt and Decrypt algorithms such that given plaintext
P, encryption key K1 and decryption key K2 then
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 text.
We call E(K1, P) the ciphertext.
Symmetric/Secret key cryptography: K1 = K2;
Public key cryptography Cryptography: K1 6= K2
Secure Communication
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(KAB,message(eg credit card details))
and A can decrypt the message as
message = D(KAB,E(KAB,message))
A can also use KAB to send data securely to B
A → B : E(KAB,message)
If B can be sure that they only other principal who knows the secret key KAB is A then he
can feel safe about sending credit card details to the web-server.
However, how does A and B come to share the secret key KAB?
Authentication
Suppose that A has a (encryption) public key KA and a corresponding (decryption) private
key K A−1 where D(KA−1 ,E(KA, P)) = P and that A’s public key is widely known.
If B knows that A’s public key is KA then B could first propose a random key KAB and send it
securely to A using
B → A : E(KA, [KAB...])
B knows that the only principal who can discover his proposed secret key KAB is A since only
A knows the private decryption key KA−1. Therefore, after the above exchange B can be sure
that only KAB is known to A.
This is a very simple example of a secure key exchange protocol: the two parties exchange a
series of messages, after which they share a secret symmetric key.
It is also a very simple variation of the SSL/TLS protocol.
HTTPS = HTTP + SSL
The HTTPS protocol uses SSL/TLS to establish a shared secret key KAB between a browser B
and a web-server A. One the key exchange protocol has completed then all subsequent
HTTP requests and responses are encrypted using this key.
Public Key Certificates
How does the browser B come to learn that A’s public key is KA?
A public key certificate is a statement that is issued and signed by a trusted third party
declaring that a given principal (eg A) owns a given public key (eg KA).
This trusted third party is called a Certification Authority and the CA uses its own private key
to ‘sign’ the certificate. This signature can be confirmed by anyone who knows the CA’s
public key.
A browser contains the public keys of a number of well-known CAs. When a browser first
connects to a web-server over HTTPS the server sends its certificate, and if it is signed by a
CA that the browser recognizes then the browser can continue the protocol and establish
the shared key.
Msg 1 B → A hello
Msg 2 A → B certificate for KA
Msg 3 B → A E(KA, [KAB...])
Msg 4 A → B E(KAB, success...)
X500 Names for X509 Certificates
We need to be able to uniquely name principals if we are to support universal certificates
that bind principal (identities) to their public keys.
X500: A proposed hierarchical naming scheme. The intention was that X500 Distinguished
Names can be used to give a guaranteed name for everything in the world!
C=country,
S=state,
L=locality,
O=organization,
OU=organization unit,
CN=common name,
...
X500 DNs are used to name principals in X509 certificates.
X509 PKI in Practice
No clear plan on how to organize X500 directory in reality: hierarchical naming suits military
and government but does not work for businesses or individuals.
In practice, we have just one hierarchy per organization and/or have many commercial CAs
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 root CAs: eg, verisign.
Route from CA Alice trusts to Bob provides certificate chain.
Some CAs only certify end-principals: note the danger of delegating to customer’s CA (must
be trusted to delegate).
HTTPS in the Browser
We use the protocol https://www.foo.bar.com to indicate a desire for a secure connection
from the browser to the web-server.
The secure connection is successful if the certificate is accepted as valid and that web-server
demonstrates that it can decrypt the key proposed by the browser and that the Common
Name CN in the 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 includes some content that loads over HTTP then
 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 programmer error
<embed src=http://www.bank.com/anim.swf> 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 specifying the protocol in embedded content. <embed
src=//www.bank.com/anim.swf>
Don’t embed HTTPS content in HTTPS
The web page is http, however, its HTML source contains a form
<form method= "post"
action="https://onlineservices.wachovia.com/..."
A visitor using http does not know whether they are actually visiting the wachovia.com
website or some site masquerading as wachovia.com and therefore does not know where
their login credentials are being sent.
A request to http://wachovia.com should have resulted in a re-direct response to
https://wachovia.com where the user can then enter their credentials. The visitor should be
able to ’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 attributes; on some
early browsers 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 provided
userid/pin.
 ...
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 the right
website.
Semantic Attacks
An attacker registers the website amason.com and obtains a valid certificate that associates
their public key with that website. Valid secure connections can be made by the browser to
https://www.amason.com.
A browser user might be confused about the domain of
https://amazon.com@amason.com/buy.html
Recall the GBK Chinese character set. It includes characters that look like /, ?, . and =.
 Attacker owns domain evil.cn and gets a cert for *.evil.cn
 Attacker sets up a sub-domain
www.bank.com/accounts/login.php?userid=simon.evil.cn How is the ?u interpreted?
 A browser visiting this web-site under https has a valid secure connection to (a subdomain of) evil.cn, however, the user of the browser probably thinks they are visiting
www.bank.com.
Extended Validation Certificates
A conventional certificate makes few claims about the true identity of the owner of a
website.
An extended validation certificate requires a human lawyer at the CA to validate the identify
of the individual requesting the certificate. These certificates are indented for highly secure
connections such as banks.
Look at http://verisign.com and http://paypay.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,
 Attacker 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 accept invalid certificates then the browser user
will be subject to a man-in-the-middle attack.
Suppose that a malicious third party (bunk.com) resides on the connection between the
browser and a web-server.
The browser sends an https connect request to bank.com. This is intercepted by the man in
the middle who passes the request on to bank.com.
The man in the middle responds to the browser, masquerading as bank.com but with an
invalid certificate (issued to bunk.com.
The browser warns the user that the certificate is invalid as its Common Name CN does not
match that of the URL (bank.com) that the user is requesting.
If the user accepts the invalid certificate then the man in the middle has a secure connection
to the user and a secure connection to the bank and can relay (and read/modify) data sent
between the user browser and the bank.