Hardening Web Browsers Against Man-in-the-Middle and Eavesdropping Attacks

Hardening Web Browsers Hardening Web Browsers Against Man-in-the-Middle Against Man-in-the-Middle

and Eavesdropping Attacksand Eavesdropping Attacks

Dr. José Carlos BrustoloniDept. Computer ScienceUniversity of [email protected] work with Haidong Xia

Jose' Brustoloni 2May 12, 2005

MotivationMotivation

♦ Technology for securing Web applications is thought to be well-understood: HTTPS = HTTP + SSL/TLS

♦ What about the usability of this technology?


ContributionsContributions

We performed user studies to answer three related questions:

1. With current browsers and users, how likely is an attack to succeed? A: Very likely. HTTPS provides alarmingly little actual

security.

2. Is it possible to make browsers more foolproof? A: Yes. We propose and demonstrate new user interface

techniques, CSCV and SPW, that greatly increase usable security.

3. Can user education improve Web browsing security? A: Yes, but better browser/CSCV had greater impact than did

education.


Eavesdropping attacksEavesdropping attacks

♦ Easy to perform on local area networks with shared medium, e.g.: Ethernet (with hubs) Wi-Fi

♦ Many free applications can be used for eavesdropping, e.g.: tcpdump ethereal


Man-in-the-middle (MITM) attacksMan-in-the-middle (MITM) attacks

♦ Actually only slightly more complicated than eavesdropping

♦ Easily available, free tools: arpspoof dnsspoof webmitm

♦ Necessary if no shared medium (e.g. switched Ethernet) or packets encrypted (e.g. WPA, SSL/TLS)


MITM attack on switched EthernetMITM attack on switched Ethernet


Access Point

SSID: “goodguy”

SSID: “badguy”

Stronger or CloserAccess Point(Tool: Airsnarf)

“ANY”

Wi-Fi Card

SSID: “goodguy”“badguy”

MITM attack on Wi-FiMITM attack on Wi-Fi


Certificate verification (in theory)Certificate verification (in theory)

♦ Browser has public keys of major certifying authorities (CAs, e.g., Verisign)

♦ Secure site supposed to get certificate from one of these CAs, with: CA’s signature certificate expiration site’s name site’s public key

♦ Browser supposed to: check CA’s signature, expiration, site’s name, CA’s

revocation list get site’s public key and use it to authenticate site


Certificate verification (in practice)Certificate verification (in practice)

♦ Public-key infrastructure (PKI) not universally deployed

♦ Certificate verification errors are common

♦ Browsers warn users of errors, but allow users to continue despite errors

→ Vulnerability to MITM attacks despite HTTPS


Why certificate verification failsWhy certificate verification fails

1. Browser does not have public key of certificate’s issuer very common for internal sites → often not attack uncommon for public sites → high risk of attack

2. Certificate expired may result from simple inattention unlikely to be attack

3. Certificate’s subject not desired site if subject in same domain as desired site → unlikely to be

attack otherwise → high risk of attack

Current browsers allow user to proceed despite error in all of these cases


Context-Sensitive Certificate Verification Context-Sensitive Certificate Verification (CSCV)(CSCV)

CSCV-aware private CA:1. Distributes its public key to organization members, on

removable media (e.g., floppy disk or USB key)2. Includes administrator’s contact information in issued

certificates

If certificate verification fails because issuer’s public key unknown, CSCV-aware browser:

1. Asks user for key on removable media2. If user does not have it, uses information in certificate to

guide user on how to contact CA’s administrator to overcome error

3. Does not allow user to continue without correcting error


Unencrypted passwordsUnencrypted passwords

Existing browsers warn against unencrypted transmission, but:

♦ Do not discriminate between passwords and other data

♦ Warnings occur quite frequently♦ Often ignored or disabled by users


Specific Password Warnings (SPW)Specific Password Warnings (SPW)

♦ Browser detects user about to send password unencrypted

♦ Asks if password protects important account♦ If so, strongly discourages user from

continuing: Tells user signs of secure site (https:, closed

padlock) Asks user to consider possibility of MITM replica

of usually secure site Asks user to consider consequences of financial

or privacy loss


Just-in-Time Instruction (JITI)Just-in-Time Instruction (JITI)

♦ Warn-and-Continue (WC) – e.g., Internet Explorer (IE):

1. Uses concepts that users do not understand2. Does not fully disclose possible consequences3. Does not tell users how to overcome error4. Can be ignored by users


Improving JITIImproving JITI

♦ Guidance Without Override (GWO) – e.g., CSCV:

Addresses all four shortcomings in WC Not always possible

♦ Guidance With Override (G+O) – e.g., SPW:

Unlike GWO, can be ignored by user More generally applicable, but less secure


Well-in-Advance Instruction (WIAI)Well-in-Advance Instruction (WIAI)

♦ Whitten’s alternative to JITI♦ Safe staging: each stage enables only data and

functions that user knows how to manipulate safely

♦ Our instantiation: Staged PKI Client (SPKIC)1. Use browser with restricted functions and learn to

reject unverified certificates, not to send unencrypted passwords, and how to get CA’s public key

2. Learn about MITM attacks, set up CA, issue bona fide and bogus certificates

3. Use IE without restrictions


User studiesUser studies

Male CS undergrads

1. Untrained, using unmodified IE

2. Untrained, using modified Mozilla with CSCV, SPW

3. After staged security training, using unmodified IE

Scenario

1. Check balance at “rewards” site in students’ university –

with HTTPS, certificate from unknown CA, correct local contact info

2. Spend rewards to buy one or more items at e-merchant site –

with HTTPS, certificate from unknown CA, bogus contact info

3. Get order confirmation message at Web-based email site –

with HTTP only / no certificate


Experimental resultsExperimental results

• Alarming insecurity for untrained users with existing browsers

• Users actually behaved less securely with HTTPS• CSCV, SPW, and SPKIC all had highly significant benefits• CSCV’s effect significantly higher than SPKIC’s


CaveatsCaveats

♦ Task completion bias♦ Difficulty effect♦ Age, gender, education level, ability not

controlled


Related workRelated work

♦ Usable security (Adams & Sasse, Anderson, Zurko & Simon, Sandhu, Xia & Brustoloni)

♦ Whitten & Tygar – PGP♦ Out-of-band certificate fingerprint verification♦ Identity-based cryptography♦ Ackerman & Cranor – critics♦ Ye & Smith – browser trusted paths♦ Yan & al. – education on password selection


ConclusionsConclusions

♦ Most users do not check or understand certificates and ignore warnings

♦ Delegating security decisions to users defeats Web security

♦ CSCV: Discriminate context in which certificate verification fails & guide user in correction

♦ SPW: Warn possible consequences of sending passwords unencrypted

♦ CSCV and SPW greatly increase usable security of browsers


Significance analysisSignificance analysis


Dialog for certificate on removable mediaDialog for certificate on removable media


Dialog for determining relationship between Dialog for determining relationship between client and serverclient and server


Dialog guiding inside member for Dialog guiding inside member for getting certificategetting certificate


Dialog cautioning public client about Dialog cautioning public client about certificate errorcertificate error


Dialog for unencrypted password – Dialog for unencrypted password – important accountimportant account

Documents

Hardening Web Browsers Against Man-in-the-Middle and Eavesdropping Attacks