Web Security
Sankar Roy
1
Acknowledgement
While preparing the presentation slides and the
demo, I received help from
• Professor Eugene Vasserman
• Professor Simon Ou
• Professor Gurdip Singh
• Alex Bardas and Yuping Li
2
Web Activities
• Why do we browse Internet?
– email
– searching on
– social networking
– e-commerce
– driving directions
– reading
– watching
3
Security-sensitive Web Activities
Online shopping
Managing confidential emails
4
Common Risks
5
Goals of this Class
• Understand the risks of Web communication
• Understand the security mechanisms for Web
transactions
• Learn how to protect ourselves from the
common problems in practice
6
Understanding the Web Communication
s2
DNS
s1
s3
Google server
Your desktop
An example: Let’s do a Google search:
• 0-th step: type google.com on a browser
• The next three major steps (s1, s2 and s3) as
shown above are elaborated later
DNS = Domain name service
7
Step 0: Opening a Browser
• Open a browser (e.g. Safari, Firefox, IE, Chrome, etc.)
• Type google.com in the address bar (HTTP protocol is
used)
8
Step 1: Get Address of Google.com
What’s the IP address of Google?
Your
Browser
64.233.160.2
Domain Name
Service (DNS)
• The browser asks the DNS the IP address of Google.com
• DNS responds with the IP (e.g. 64.233.160.2)
Compare with the phone number search
Google.com = Contact name, IP = phone number
9
Step 2: Send Query to Google
Your
Browser
message
64.233.
160.2
(Google.com)
• The browser sends out a message
– with the connection request
• The packet (message) is routed over the Internet
– and finally reaches the destination (i.e. Google.com)
10
Step 3: Get Response from Google
Your
Browser
•
•
•
•
response
message
64.233.
160.2
(Google.com)
Google.com sends back the response message
The message finally reaches your computer
The browser displays Google’s home page
Then you type the “key words” in Google’s “search box”
– and hit “enter”; this sends a message to Google again (with “key words” now)
– this type of back-and-forth communication may continue
11
Physical vs. Web: Bank transaction example
• Physically visiting your bank: you are sure that
building is your bank? The bank teller verifies
your Driver’s license and thus authenticates you.
• On Web: It is a virtual world. Your browser and the
bank server needs some special tool to authenticate
each other. Also, the sensitive data traffic (including
your password) has to remain confidential.
12
Attacks: Connection Interception
query message
Your
Browser
(NOT Google.com)
• The browser sends out a message (with the query)
Mallory intercepts it and sends back a response claiming
that she is “google.com”
• The browser displays Mallory’s response page, which
may look identical to Google
13
Connection Interception: Another View
The adversary (let’s call him Mallory) intercepts the
communication between Alice and Bob.
Bob
Muahaha!
Bob
Alice
14
Where does Web Browsing Lack?
• HTTP is (more or less) OK for Google search because of no
confidential data being involved
• But when we deal with sensitive data (e.g. e-banking)
– then, we need:
authenticate
Server
Browser
authenticate
– Also, we need confidentiality: the password or credit
card info should not be transferred in clear text
– Default web browsing does NOT use authentication
or confidentiality
15
Viewing the Status of a Website
NO authentication
NO confidentiality
The browser can show the status of the connection, e.g. “no
authentication or no encryption” (as shown above when we visit
http://www.google.com).
16
Securing Web Browsing
• A feasible Solution:
– Each party B (e.g. a bank server) generates a Public
and Private key pair. Mathematical theory ensures
the correspondence b/w these key pair.
pub
mybank.com pri
(B)
B’s private cred.
B’s public cred.
cert
CA
has CA’s sig.
CA says “pub is B’s public key”.
– PKI (Public Key Infrastructure): Party B (e.g. a bank
server) can collect a certificate from a cert-authority
(CA) which is a trusted third party.
17
Securing Web Browsing
CRAP!
Bob
Bob
Alice
Confidential
Authenticated
18
Basics of PKI: comparison with DMV
• A party P’s certificate CP is like P’s Driver License where
CA takes the role of DMV
• A policeman (or a liquor shop) uses your Driver License
(DL) to verify your identity (or age)
• Likewise, server P’s certificate CP can be verified by
another party Q (e.g. your browser)
• Actually, Q verifies P’s public key by investigating CA’s
digital signature which is present in CP
• Note that there are multiple DMVs in USA, each of whose
DLs are trusted anywhere in USA
• Similarly, there are multiple CAs in PKI, each of whose
certificates are accepted by every browser
19
How to Do Secure Web Browsing?
Ensure that you see the lock symbol in the address bar. The drop down panel
above shows the https encryption and the certificate of this web server.
20
How to Check if We are Secure?
• It depends on the browser.
• Ensure you see the lock symbol or https in the address 21bar
Viewing the Certificate of a Server
The browser can show us the certificate of the server website. Here we view the certificate
of mail.google.com while using Firefox. Note the Certificate Hierarchy.
22
Secure Web Browsing Protocol
Secure browsing (HTTPS) is like running the HTTP protocol on top of SSL which is
a security technology
After you type mybank.com (say B) on a browser (say A) address bar, the
following events take place:
1.
2.
3.
4.
5.
Using the public/private key pair, A and B establish a confidential
communication channel. B’s certificate makes A sure that B is the
correct website
A displays the secure login page in front of you
You type the username and password, and A sends it to B over the
confidential channel
B decrypts your username and password and verify. B becomes sure
that it is communicating with you and nobody else
You (and A) can continue the mutually authenticated and confidential web
session with B
23
Weakness of the PKI System
1. One compromised CA can issue a certificate
to anybody X. Then, X can
issue certificates.
TRUSTED
ROOT
2. Possible usage of a hierarchy
of certificate
authorities (CAs) which form a chain of trust.
TRUSTED
Certificate, e.g.
A bad node inDELEGATE
the chain kills the system.
BigCorp.com
3. It is hard for a browser to manage the long
Certificate,
Certificate,
e.g.list of trusted CAs. Updating
e.g.the list of
Google.com
revoked/untrusted CAs isMyBank.com
even harder.
24
More Limitations of HTTPS
• We often encounter warning from the browser
due to invalid (or expired) certificates. It can be
very confusing to the common user to decide
what to do in such situations to guarantee safety
• Building trust could be confusing: trusted
authority vs. trustworthy authority
– Let’s compare two certificates of Citibank. One is
issued by Verisign and the other by a Russian CA. Both
of the certificates can be trusted by the browser, but
only the first one might be trustworthy.
25
Delegate Changes, You Don’t Notice
TRUSTED
ROOT
ROOT
UNTRUSTWORTHY
TRUSTED
DELEGATE
Certificate,
e.g.e.g.
NOT
Google.com
Certificate, e.g.
BigCorp.com
Certificate,
e.g.e.g.
NOT
MyBank.com
MyBank.com
26
Demonstration: Man-in-the-middle Attack
• Goal: We show that just getting “https://” displayed
on the address bar does not guarantee security.
• Each student has a desktop to connect to the Internet
– he/she may use the Firefox browser to visit a bank website
• As an example, type on the Firefox address bar
https://yourBank.com
• Caution: when the login page is displayed on Firefox,
– please use a bogus login id and password
– do not type any valid id or password to avoid problems
27
A Diagram of the Man-in-the-middle Attack
The adversary (Mallory) intercepts the connection between
Alice (e.g. you) and Bob (e.g. your bank).
Bob
Muahaha!
Bob
Alice
28
Demonstration
29
Explaining the Previous Demo
• Setup: One proxy server for the whole class/lab
• Each Desktop’s browser (Firefox) is pre-configured with the proxy server’s
information (i.e. the IP address, and the port)
Website 1
Desktop 1
You are
using
Firefox
on one
Desktop.
https conctn
https conctn
…
Desktop n
…
…
Proxy Server
One of
these
websites
is your
bank.
Website n
• If you are not careful, the proxy server can decrypt
– your login name, password, and the other communicated data
• Lesson: Never proceed if your browser warns
that it does not trust a website’s certificate
30
What could Happen if the PKI is Broken?
• Then, bogus certificates could be accepted.
• We demonstrated a man-in-the-middle attack in
a similar scenario.
• The following events occur in the demo attack:
– An HTTPS request from Client C to Server S is
intercepted by the adversary on a proxy server
– The adversary (Mallory) then sends a bogus certificate
in the name of Server S
– The Client C authenticates the certificate chain and
sends a session key, encrypted using the public key
supplied by Mallory
31
Problems if the PKI is broken (Contd.)
• The adversary Mallory decrypts the session
key
• Mallory opens an HTTPS session with Server S
and proxies the traffic between C and S
• All the data that is in transferred between C
and S is available to Mallory
32
Another Problem:
Only the Login is Done in HTTPS
In some portals (e.g. Yahoo mail) the web session after
successful login switches back to HTTP. The HTTP session
is then authenticated only by a cookie.
Problem: client’s cookie can be stolen
– (as an example) when the adversary does packet sniffing
on the same Ethernet or Wi-Fi network as the client’s
machine
Outcome: the HTTP session can be hijacked.
Solution: we suggest to use only those websites which
employ HTTPS for the whole session (e.g. Gmail)
33
Summary
• We discussed common security threats of Web
browsing
• We presented a few standard countermeasures
to mitigate the risks
• Remainder:
– the next homework is due before the next class (1pm
on February 7)
– the next class will be held in Room 127
34