4

HTTPS is slow to start up, especially on low-bandwidth and high-latency connections, or on low-spec machines. Unfortunately it seems to be the standard method for securing logins used by all major websites.

But a lot of websites we usually visit simply to read information. If we only occasionally want to make a write/update, then waiting to get logged in is an unnecessary time overhead.

The most upsetting example for me is:

  • Github. I often want to visit a github page just to read a project's overview or view a file. But I must wait for the SSL handshake, even if I don't want to do anything related to my personal account. Github always redirects my browser from HTTP to HTTPS. Why?!

I understand a secure connection is important to authenticate a user account. But when this impacts the user experience of simply viewing public pages, we should try to work out an alternative (and encourage major sites to adopt it).

Here is a possible workaround (1):

  • Allow users to make HTTP connections to our website, so we can present pages quickly without the need for an SSL handshake.
  • Allow the login to occur after the page has loaded. Perhaps an Ajax request over HTTPS could authenticate the user, and provide relevant updates to the page. (Is this fundamentally insecure? Edit: Yes, it is not fully secure, see answer below.)

Another alternative might be (2):

  • Instead of long-lived cookies over HTTPS, use a combination of long-lived one-time-key cookies for persistent login, and short-lived cookies for non-linear browsing, over HTTP. Replace them frequently. (This may be less secure than HTTPS, but more secure than normal long-lived cookie usage over HTTP.)

Do these solutions seem secure enough, or can you suggest something better?

(It might not be a coincidence that I am writing this from somewhere near Indonesia, which is a long way from the USA net!)

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110
  • 1
    ssl is not "slow". It's just as fast as non-ssl connections for transfers. It does have significant startup overhead, but once the connection's going, there's very little difference. Allow http keep-alives so the connection/reconnection overhead becomes minimized. – Marc B Oct 22 '13 at 17:03
  • What programming language are you using ? In case it's Java - check out websockets: http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm btw, SSL is slow only during the first part where keys are exchanged, afterwards the encryption/decryption part is working pretty fast with an algorithm very similar to `3DES` – Nir Alfasi Oct 22 '13 at 17:03
  • It is the handshake that bothers me, so I have updated the question. It may seem a minor issue, until you experience it 20 times a day! Keep-Alive can certainly help, but at some point a user will need to handshake again, perhaps to a website he visited only an hour earlier. I consider this to be a web issue, and so language agnostic. – joeytwiddle Oct 23 '13 at 00:56
  • One possible solution is right under our noses! Stackoverflow itself uses HTTPS for login, then a short-lived HTTP cookie for the session. However this might not be considered secure enough when financial transactions are involved, e.g. on e-commerce sites. http://stackoverflow.com/questions/709085/secure-cookies-and-mixed-https-http-site-usage#709209 – joeytwiddle Oct 23 '13 at 06:48
  • http://stackoverflow.com/questions/733564/how-do-sites-support-http-non-ssled-sessions-securely – joeytwiddle Oct 23 '13 at 07:00

2 Answers2

0

Here is one alternative I can think of, albeit slightly restrictive:

  • Allow browsing of public pages over HTTP, but don't perform any user login. This avoids all security concerns.
  • The 'Login' link would then send us to an HTTPS page, and may be able to recover the user's account automatically from a long-lived HTTPS cookie.
  • Make an option available "Always log me in through HTTPS", for users who are not bothered by the handshake overhead, and prefer to be logged in at all times. Note that a cookie for this setting would need to be set on the HTTP domain, since it needs to work without the user being logged in!

In reality, we would probably offer the converse: default to the existing prevalent behaviour of redirecting to HTTPS automatically, but provide an opt-out "Do not always switch to HTTPS for login" for those users wishing to avoid the SSL handshake.

But there are still issues with this approach:

Unfortunately cookies are not namespaced to the protocol (http/https). We can mark cookies as "secure" to prevent them ever being sent over HTTP, but some browsers will wipe them entirely if an HTTP request does occur. One way to keep the cookies separate would be to use different domains for unauthenticated and authenticated access to the site. But then we find ourselves violating REST, with two different addresses pointing to essentially the same resource...

Can this be resolved?

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110
  • 2
    Using the login button to switch to https renders https completely useless, as the page with the login button could've easily been changed, enabling man-in-the-middle. If you want to serve non-logged in as http, you need to have the login area as a separate page, served over https. See this article by [Troy Hunt](http://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html) for more details. – Femaref Oct 23 '13 at 12:03
  • Yes I agree the login details must be given on an https page. I will rename "button" to "link" in my answer. This extra page load is a little inconvenient for the user, although the login page might be able to recover a persistent login ... if the secure cookie hasn't been wiped! – joeytwiddle Oct 28 '13 at 08:17
0

Workaround #1 in the question cannot provide full security to the first page, because a man-in-the-middle attack could have injected or modified scripts on the page before the login occurs.

Therefore we should not ask for a username/password on the HTTP page. However, the HTTPS Ajax operation might be able to inform the user that a persistent login session has/can be restored. (A script could then replace all HTTP links on the page with HTTPS links.)

But even if that succeeds, we still should not fully trust any user clicks or <form> POSTs originating from the first page. (Of course, requests to view other pages are fine, but it might be wise to reject updates to settings, password, and finance-related actions.)

This technique could at least be a way to perform the HTTPS setup in the background, without making the user wait for initial content. (StackOverflow uses something like this procedure.) Hopefully the browser will cache the HTTPS connection, or at least the keys, avoiding any delay on subsequent requests.

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110