Guidance for implementors of HTTPS-only sites (Server side)

Question

The recent trend in HTTPS attacks is to attack the HTTP protocol. What should I do to increase my site's security if the only protocol I want is HTTPS?

Some easy to implement ideas are

• Implement HTTPS Strict Transport Security
• Issue the authentication page over SSL
• Use HTML Form-posts for the login page's submit button not CSS DIV's
  • ... why? the user can't see the target URL when they hover
• Permit the client to cache the navigation page, as this will deter certain MITM attacks
• Use SSL-Only cookies
• Use an I-Frame Buster and the X-Frames-Options header
• Edit the cipher list to only use RC4, AES or PFS

More advanced/technical options may include

• Use DNSSec to protect vulnerable users
• Use SSL Only Cookies everywhere
• Use HTTPS padding on all AJAX data
• Only issue the "session key" over HTTPS
• Send off-site links to an intermediate page

Options that may break things (such as the user experience)

• Disallow web browsers that:
  • ...don't clearly indicate the TLS status in the URL
  • ...are subject to IDN attacks
  • ...are unpatched
• Disallow port 80
• Only allow redirects from a whitelisted set of domains. Don't permit someone to link to your site, and force the user to type in the HTTPS URL
• Use a private certificate for all operations for that site. Issue the thumbprint (or RootCA) over a SSL connection

What are your thoughts on a website that implements some or all of these techniques?

What additional techniques would you recommend? (e.g. Use / Don't use OpenID, certain HTTP header directives, etc)

Answer 1

The main ones are:

• Use SSL sitewide. Don't offer anything over http. Instead, any connection via http should immediately redirect to the main site's landing page via https.

• Use HTTPS Strict Transport Security. This will tell users' browsers: please, only connect to me over https. This defends against sslstrip and similar man-in-the-middle attacks.

• Set the secure flag on all cookies. This will ensure that the cookies will only be sent over a https channel, never over an insecure http link.

• Avoid third-party active content served over http. Don't load external active content over http. Make sure that any CSS, Javascript, widgets, analytics, or ads that you load from third-party sources are loaded over https.

  • Potentially better yet, you can consider making your own copy and serving these resources from your own server if possible, so you don't need to load them from a third-party source. In many cases you can avoid loading CSS, Javascript libraries, or widgets from third-party sources simply by storing a copy on your own server.

  • For analytics, note that Google Analytics does support https.

  • Ads are the hardest part. If you use ads, you may not have any choice but to accept third-party ads over http, which is a security risk. If you do, serve the ads in an iframe (do not use SCRIPT SRC to integrate the ads into your page).

  It is OK to load images hosted on a third-party host as long as they are loaded over HTTPS (to avoid mixed-content warnings).

I think if you do these four things, you'll cover most of the issues. The rest are details that can be evaluated on a site-specific basis, but they are probably secondary in importance (in my opinion).

If you want to get fancy, you can look at certificate pinning and similar emerging technology, but starting with the above four is already a significant enough project.

Answer 2

User's Security

• You are missing one extremely important thing: CSRF mitigation.

  Be sure to fully understand the related problems. Tldr: in addition to the authorization token (e.g. session cookie), you need a challenge per action to identify if the action is intended by the user or unintended.

• Fix JSONP leaks.

• X-Content-Type-Options: nosniff, on all pages to prevent MIME sniffing, especially for user-generated pages.

• Content Security Policy.

• Ensure secure "reset password" mechanism to prevent people from resetting other people's password and gaining fraudulent access.

• Show a huge huge warning when users use weak passwords, or not accept it altogether.

• Train users (perhaps via an arrow image on every page pointing to the green bar) to check whether your pages are loaded with HTTPS. If they ever use a browser that does not support HSTS, at least they would notice that HTTPS is missing.

---

Server's / User's Security

• Ensure that secrets are not leaked due to timing attacks.

---

User's Privacy

• Applying padding to only ajax is insufficient. To protect your users against network monitoring, all requests and responses must be data padded. Requests do not need to be time-padded, but responses must.

• Fix history leaking due to variance in the timings for responses:

  Suppose that Alice is surfing the Web, and she visits Bob’s Web site at http://www.bob.com. Bob wants to find out whether Alice has visited Charlie’s Web site (http://www.charlie. com).

  First, Bob looks at Charlie’s site, and picks a file that any visitor to the site will have seen. Let’s say Bob picks the file containing Charlie’s corporate logo, at http://www.charlie.com/ logo.jpg. Bob is going to determine whether the logo file is in Alice’s Web cache. If the file is in her cache, then she must have visited Charlie’s Web site recently.

  Bob writes a Java applet that implements his attack, and embeds it in his home page. When Alice views the attack page, the Java applet is automatically downloaded and run in Alice’s browser. The applet measures the time required to access http://www. charlie.com/logo.jpg on Alice’s machine, and reports this time back to Bob. If the time is less than some threshold (say, 80 milliseconds), Bob concludes that Alice has been to Charlie’s site recently; if it is greater than the threshold, he concludes that she has not been to the site recently.

---

Server's Privacy

• Ensure invulnerability to clock skew attacks.

---

Availability

• User-based / IP-based throttling in the event of DoS and DDoS.

---

Other misc stuff which you can't fix (browser problems):

• History leaking via HSTS