A Proxy-Based Approach to Take Crypto Out of The Browsers for Better Security and Usability

1. A Proxy-Based Approach to Take Crypto Out of The Browsers for Better Security and Usability Marco “Kiko” Carnut <kiko@tempest.com.br> Evandro Hora <evandro@tempest.com.br> 4th PKI R&D Workshop NIST, Apr/2005

2. Agenda • Motivation • What we wanted to do • and why we couldn’t • Solution: a local filtering/rewriting proxy • Architecture • Filters and features • Conclusions & Future Directions

3. Disclaimer • We’ll be talking network protocols nuts and bolts • Focus on what we needed to change to seize control of PKI-related UI • From a pragmatic implementation point of view(programmers’ talk) • We won’t be talking HCI • We don’t claim our UI is the best • It’s a work in progress at the very best • A proper analysis from an HCI standpoint would require entirely different approaches and methodologies • But we do claim our tentative UI is already better than most browsers’

4. What we wanted to do • Sign a web form • IE doesn’t do this natively • Java Applets + CAPICOM  too many installation hassles; nonportable • Do HTTPS Client Auth • IE’s logon screen is confusing • shows expired certs along with valid ones • Hard to know the right cert to use for each app • IE’s logon screen is insecure • offers to save your passphrase • Bad failure handling • SSL failures break the connection; the app has no chance to display a nice error message or offer alternative auth methods

5. 2 1 9 11 10 3 13 12 4 6 5 8 7 16 14 15 17 23 18 19 22 20 24 21 Cert issuance on IE • Besides... getting a client cert is such a hassle 24 click count= click count=

6. The Unfinished Paper • A follow-up to Alma Whitten’s seminal work “Why Johnny Can’t Encrypt: An Usability Evaluation of PGP 5.0” • Never finished... It would be way too depressing... all problems and no solutions.

7. The Central Idea • Let’s do the crypto out of the browser • In a separate program • So we become free to try new UI ideas • A filtering/rewriting selective crypto proxy • A local proxy, so we can make the user feel like it’s part of the browser • Leave the browser to do only what it’s good at: render web pages

8. Infrastructure Filters FeaturesFilters Overall Architecture HTTP 3128/tcp Filter #1 Some web site Filter #2 . . . . . . HTTPS Dispatcher EncryptionDomain Filters Engagers Configures the browser to use ourselves as proxy Web Form Signer Filter . . . . . . CertificateStore Manager Filter #n HTTP Dispatcher

9. Infrastructure Filters • Command Parser Filter • catches URLs of the form: • ?x-kapanga-cmd=command(arg,...) • then sends the arguments to the appropriate filters • Version Tagger Filter • Adds Kapanga version number to theUser-Agentheader • Allows the site to determine whether Kapanga is active and thus provide Kapanga-specific functionality

10. Infrastructure Filters • Encoding Damper • Disable Encodings Kapanga doesn’t understand (gzip/deflate) • Should be replaced by filters to properly perform the decoding • Chunked Transfer Encoder • Converts the response body to the transfer-encoded form • This is needed because on-the-fly rewriting changes the body length, thus invalidating the Content-Length

11. Feature Filters • Web Form Signer • Activated by • ?x-kapanga-cmd=sign(in,out,flags) • Intercepts POST requests with the application/x-www-form-urlencoded MIME type • Decodes the form data • Signs the data in the field specified by in • Saves the result in out • flags controls whether to include the user’s own cert, the whole cert chain up to the root, etc. • Philosophical question: should we do that for multipart/form-data as well? (Signed File Upload)

12. Demonstrations • Cert Store Manager (CSM) • Trust Rules and such • Web Form Signing

13. Feature Filters • Web Form Signer • Activated by • ?x-kapanga-cmd=sign(in,out,flags) • Intercepts POST requests with the application/x-www-form-urlencoded MIME type • Decodes the form data • Signs the data in the field specified by in • Saves the result in out • flags controls whether to include the user’s own cert, the whole cert chain up to the root, etc. • Philosophical question: should we do that for multipart/form-data as well? (Signed File Upload)

14. Feature Filters • HTTPS Logon • Activated by • ?x-kapanga-cmd=addsite(p,t,e,f) • Adds the current site (host:port) to the Encryption Domain, along with the (p, t, e, f) tuple • p: port for HTTPS • t: site title (for bookmarking) • e: error path: where to go if SSL cert validation fails • f: flags

15. Feature Filters • Encryption Domain Filter • If the request’s host:port is in the Encryption Domain • Remove the request from the filter chain • Route it through the HTTPS Dispatcher • It handles the SSL negotiation and cert validation according to the current CSM rules • Handles client authentication as well with a nice friendly UI • If cert validation fails, redirects to the “error path”: site can offer assistance or alternative authentication methods • Otherwise, let the request pass untouched

16. Feature Filters • URL Rewriter Filter • Modifies the HTML to change https:// URLs to http:// • Acts only on responses coming back from the HTTPS Dispatcher • If we didn’t do this, the next image, form, link, etc., would not be handled by Kapanga • Kapanga is an HTTP-only proxy • It is Kapanga’s Achile’s Heel: it’s purely static • can’t handle dynamically generated URLs • in our experience, this has not been a deterrent

17. Feature Filters • HTTPS Logoff • Activated by • ?x-kapanga-cmd=delsite • Current ID Activator • Activated by • ?x-kapanga-cmd=activate(sha1) • Makes the ID whose cert sha1 fingerprint is sha1 the active one • Used just after a send-usable-ids • The site can automatically select an appropriate ID • But the user can override if he/she wishes: the only way cert validation might fail

18. Feature Filters • Usable ID Enumerator • Activated by • ?x-kapanga-cmd=send-usable-ids • If the request is GET, change it to a POST • Send a message listing all the ultimately trusted certificates • i.e., those that we have a corresponding private key for • Allows the site to offer assistance in selecting the appropriate cert to log on

19. Feature Filters • New Cert Generation • Activated by • ?x-kapanga-cmd=new-express-cert(name,email) • Starts Kapanga’s built-in New Certificate Wizard • Site can direct the user to get a new cert • Uses FreeICP-style instantaneous “guest-level” certificate • Satisfies the web users’ expectations to get registered immediately • Still not as fast as name+pwd+cookies but not too far behind

20. Feature Filters • New Cert Generation • Activated by • ?x-kapanga-cmd=new-express-cert(name,email) • Starts Kapanga’s built-in New Certificate Wizard • Site can direct the user to get a new cert • Uses FreeICP-style instantaneous “guest-level” certificate • Satisfies the web users’ expectations to get registered immediately • Still not as fast as name+pwd+cookies but not too far behind • most importantly, users don’t reject it • Our version of Jon Callas’ “Self-Assemling PKI” concept: we want every app to be an invitation for PKI enrollment

21. Conclusions • More usable, more secure HTTPS • Now we can make HTTPS sites with client auth without the users hating us • There’s improvement of HTTPS server cert validation as well • We can get rid of the browsers’ crypto vulns and bad UIs • Portable: we can do it the same way regardless of browser/platform • Web apps do need a few changes • Application-level proxies might be a good place to put PKI-related functionality in a backwards compatible way

22. Future Directions • More Nice Useful Filters • Web-based signature verification,... • making the filter system pluginnable • Implement generic proxies • “Stunnel on steroids” • Make enrollment even simpler • Make Kapanga an MTA • How about all that for email as well? • Implement OpenPGP support • Jon Callas’ “Format Agnosticism” concept • The best of both worlds

23. Thank you! Questions? Real Protection against Real Digital Threats kiko@tempest.com.br