ForceHTTPS: Protecting High-Security Web Sites from Network Attacks

1. ForceHTTPS:Protecting High-Security Web Sites from Network Attacks Collin Jackson and Adam Barth

2. Network Attacks • Eavesdrop or corrupt network traffic • Wireless networks • ISP • Pharming • Defense: HTTPS • Protects passwords • Use “Secure” cookies to protect session

3. HTTPS Errors • Intentional errors • Prevent passive attacks • Unintentional errors • Expired certs • Wrong cert installed • Misconfiguration or attack? • Browser doesn’t know • User doesn’t know

4. Threat Model • Active network attacker • Controls the network • Has a valid CA certificate for attacker.com • Does not have a valid CA certificate for bank.com • User • Clicks through certificate errors • Only types bank password at www.bank.com • If applicable, uses 2-factor auth (e.g. SiteKey) correctly

5. Proposal: ForceHTTPS • Site sets a “ForceHTTPS” cookie • Opts in to strict error processing • Not interested in compatibility • Treat errors as an attack, not a misconfiguration • Specification: • Non-HTTPS connections redirect to HTTPS • HTTPS errors treated as fatal • Importing non-HTTPS content (mixed content) fails

6. Case Study: PayPal • Wants to host entire website over HTTPS • HTTP redirects to HTTPS • User may arrive by typing "www.paypal.com" • Links pointing to HTTP • Cert errors on some dark corners… • Strong desire to prevent mixed content

7. Separate domain for logged-in users Session identifier stored in “Secure” cookie Second factor stored in “Secure” cookie Wants to prevent phishing, pharming Case Study: Bank of America

8. Case Study: Gmail • Login form always over HTTPS • Imperfect web developers

9. Use of non-Secure Cookies • Mail available over both HTTP and HTTPS • New account, always visited over HTTPS • Compromised by passive network attacker

10. Implementation • Firefox extension • Available for download at forcehttps.com • Monitors all network connections • Blocks connections with cert errors for sites that opt-in • Blocks mixed content for sites that opt-in • User-enabled protection • ForceHTTPS enabled for known-compatible sites • Safer Gmail at security conferences

11. Eliminating Mixed Content • Users can enable ForceHTTPS for any site • Few sites work perfectly “out of the box” • Logs mixed content errors to developer console • Found many issues with real sites just by browsing • Want to extend to combine with a web app scanner

12. Trick: Scheme Relative URLs • Mixed content is hard to avoid • Often host same content over HTTP and HTTPS • Only want to pay for HTTPS when needed • Omit the scheme <script src="//slashdot.org/foo.js“> • Works in all browsers

13. Related Work: Firefox 3 • Firefox 3 – Four clicks • User override harder • Controversial balance • Security • Compatibility • Low-security sites • Harder to use • High-security sites • User can still override • How will users react?

14. Related Work: WSKE • Web Server Key-Enabled Cookies • Secure cookies only sent for same TLS key • Intended to secure the user’s second-factor cookie

15. Related Work: Locked SOP • Augment same-origin policy with cert info • “Broken” HTTPS page can’t script valid HTTPS page • Importing libraries ignore scripting policy • <script src=“https://www.paypalobjects.com/...”> • User clicks through cert error for paypalobjects.com • Real PayPal imports script from paypalobjects.com • Attacker runs script as “unbroken” PayPal Sites cannot safely use <script src=“…”>, CSS, SWF, etc

16. Conclusions • Browsers trade off security for compatibility • High-security sites want more security • Browser can be stricter if sites opt-in • Simple kind of “content restriction” • ForceHTTPS • “Please enable strict HTTPS error processing” • Strong threat model, difficult to get mechanism right • More details in the paper • Denial of service, error recovery, cookie integrity, privacy, etc