1 / 23

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

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. Agenda. Motivation What we wanted to do and why we couldn’t

donat
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related