Fixing the Web Trust Model Last updated: Tuesday, January 01, 2019 © Amir Herzberg Computer Science Department, Bar Ilan University http://AmirHerzberg.com 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Agenda The Web Trust Model: Reality Check Site Identification (even for Naïve Users) URL, name, nickname, logo or icon CA Identification: too complex or essential? Example: TrustBar implementation Protecting non-SSL/TLS sites Why most pages are unprotected? What can be done? Warning against scam sites Beyond Basic Identification Certificate classes, guarantees and credentials Conclusions 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Current Web Trust Model HTTP’s request-response gives basic identification Attacker must receive request… easy for MITM adversary Sensitive sites are protected via SSL/TLS: Site identified by URL, PK in cert, signed by CA Without SSL: identify only by URL (fails against MITM) CA identified by PK list in browser (init by vendor) User identified by <uid,pw> (encrypted by SSL) User identification by certificate exists but rarely used Present credentials as `seals` (click to validate?) Users are responsible to: Validate domain of sites (from URL) [SSL and non SSL!] SSL sites: validate padlock/https indicators SSL sites: validate that the CA (or all CAs) are trustworthy Reality check… 1/1/2019 http://AmirHerzberg.com

Reality check: Users rarely… Notice SSL indicators (padlock, https) Tests: most (77%) did not detect SSL indicators! Many login sites are not protected by SSL E.g. Chase, PayPal, MS Passport, EquiFax, SmithBarney… See `Hall of Shame`: http://AmirHerzberg.com/shame.html Notice URL in wrong domain Wrong domain login: http://BankOfAmerica.REO.com Tests: most (65%) did not detect wrong domain and no SSL! Are aware of and trust the CAs Almost none identified CAs correctly Validate credentials (`seals`) presented in sites Although seals often link to a validation page of issuer Note: http://BankOfAmerica.REO.com is (apparently…) really a domain used by BoA, for real-estate accounts, including a (non-SSL-protected) login page. 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Goal: Fixing the Web Trust Model Most users are naïve, inattentive Need simple, clear indicators – URLs too complex And `lack of padlock` is hardly sufficient warning! `Click-through syndrome` - don’t even ask Humans use non-verbal recognition (graphics, …) Empower users to manage trust & identification Present relevant info, e.g. brand of CA Allow users to explicitly delegate trust management Make trust a competitive service, not liability for vendors Allow user-selected identifiers (`pet-names`) Warn users against suspect scams and spoofed sites More sites/pages should be protected against MITM adversaries Fix / extend / replace SSL… or sites? Trust beyond identification: secure credentials TrustBar: our open-source implementation of these ideas Many users… and ideas adopted by browsers and other bars 1/1/2019 http://AmirHerzberg.com

Site Identification Identification by URL is too complex Users don’t know URL and domain structure Depends on registrars… another trusted entity? Identify to the user by… Legal name, or user-selected `petname` Logo or user-selected icon or image Identification vs. Protection… Secure identification of SSL protected sites Authenticated using public key, certificate Identification of non-SSL-protected sites Secure against spoofers, but not against MITM Separate protection and identification indicators In TrustBar – as of version 0.4 Later: alternate (non-SSL) protection against MITM We present later some ideas on non-SSL protection against MITM (and we are working on implementing them in future TrustBar releases). 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Identification of Certificate Authority This is controversial May have existed in very early prototype SSL browsers Arguments for `hiding` identity of CA: Many CAs, too complex for most (naïve) users Most/all CA brands not well known/trusted Unfair advantage to large / known / trusted CAs Solutions: Allow users to hide CA identity (if confusing) But display it as default so user is responsible Allow users to delegate choice of CA to a service Similar to anti-virus service; e.g. from ISP Use icons to represent `classes` (of certificate, CA) 1/1/2019 http://AmirHerzberg.com

TrustBar Implementation Identify CA by logo or name Identify site by logo or name Avoid jargon (CA) TrustBar appears in every window to prevent spoofing, only user can disable Window too small for `regular` padlock TrustBar avoids `jargon` terms like certificate, CA and uses more intuitive terms such as `identified by`. 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Adding `Protection Status/Class` Icons Add indicator for protection status/class Separate protection status from identification Allows (weak) identification of unprotected sites Same CA can differentiate among `cert classes` And this is visible to the consumer By levels (classes 1 to 3), industry (`Bank`), … Third-party `trust service` can identify class Each user subscribes to trust service (like antivirus) CA identification can be removed for simplicity Trust services will use judgment to select class Based on CA’s reputation, history 1/1/2019 http://AmirHerzberg.com

TrustBar’s Protection Status Indicator… Protected site 1/1/2019 http://AmirHerzberg.com

Alternative: Trust Service, No CA Identity Protected financial site (identified by a CA trusted by the trust service to which the user subscribed) `Guaranteed compensation` for failures $$ Financial Site $$ A protocol between the CA and the trust services can provide added security, when the CA guarantees certain compensation to the service if the site is found to have claimed unjustified attributes. 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Unprotected – yet identified - site… Unprotected site Detect sites with wrong URL Does not protect against MITM attack 1/1/2019 http://AmirHerzberg.com

Protecting non-SSL/TLS sites Why most pages are not protected by SSL? Not due to cost of certificate (<50$ certificates available!) Performance penalty of SSL (esp. RSA decrypt) Lack of awareness – even by site designers Site-hosting by third party (e.g. Akamai) Solutions: Current state: no protection against MITM… or… Session-Ticket TLS extension (avoid RSA) Sending digitally-signed pages (less overhead) Validating of static pages (by hash) Signed <URL,hash> of login sites provided by service List of login-sites-identifiers distributed e.g. via DNS Or: browser simply identifies that a site has not changes These solutions do not require change in server/site!! 1/1/2019 http://AmirHerzberg.com

Unprotected yet Unchanged Site… Unprotected site, but did not recently change (check by hash) Problem: many sites change frequently 1/1/2019 http://AmirHerzberg.com

Warning against Suspect Sites Many types of suspect (scam) sites… Some use SSL and/or legitimate domain, name Browser should detect, indicate scam sites Based on site’s contents (e.g. rogue scripts) Based on warnings from experts and peer users Distribute e.g. via DNS As a service (like antivirus) We can prevent `framing` Make it hard to ignore This web site is suspected as scam. Click here for more information Only if you are 100% sure, click here to proceed anyway One risk is false scam alerts to harm an innocent site. This can be prevented by making the complaints involve cost (money or computational, e.g. hashcash), possibly only inflicted if the site proves the accusation is groundless (to pre-agreed TTP). 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Beyond Basic Identification… Not all SSL certificates are equal… Domain validated certificate: no validation of organization Organization-validated (high-assurance) certificates Some CAs offer several validation classes E.g. with different liability levels Some may include Logotype extension TrustBar: present the name/logo and class We can also present ratings of site or contents: Site ratings: privacy, BBB, adult, … Or: ratings for specific product (e.g. hotel) , program, etc. Ratings are signed (by issuer) or only guaranteed by site A difficulty here is that there is a difficult bootstrapping problem – reviewers (e.g. BBB, Zagat) do not have incentive to provide signed ratings without browsers using them (and maybe even with them…) and browsers will not implement display of ratings without it provided by sites – see the market failure of PICS… Solution: sites can sign a guarantee to pay if the ratings they present are incorrect. By (automated and manual) random checking, with payment when fake credentials are detected, the Internet can validate ratings! More details in the (forthcoming) paper… 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com

Conclusions Beyond authentication: display credentials Current Web trust model is broken Should validate domain, padlock and trusted CA Unrealistic; users do none of these validations Solution: add simple indicators: Site identification by logo / name (from site/user) Identify CA and/or cert class by logo / name / icon Protected / Unprotected / Unchanged / Suspect Beyond authentication: display credentials Signed by third party (e.g. Zagat, BBB)… Or: claimed by site, with guaranteed payment if untrue! Try from http://TrustBar.MozDev.Org 1/1/2019 http://AmirHerzberg.com http://AmirHerzberg.com