Why is https only used for login?

Question

Is performance the only issue? Can't an https connection be used throughout a user's session? There is obviously less redirection happening!

I found this related question on http vs. https performance

Edit: Ok, I didn't mean 'used only for login'. Rather, what I'm trying to ask is if you come to a point where you need https anywhere on your site whether it be login or payments, why not make all communication to the site over http?

As an example, assume a blog site. Now, the blog posts might get created by sending an email. Further down the line, I might provide a 'login' and then an 'add post' action. In this scenario usually the https is used only for the login and then again regular http for actually adding the post. Since, now the need is to provide an 'admin' mode, so to speak, why not have all communication over https while a person is in the 'admin' mode, i.e. logged in.

Answer 1

Because the login and password are the most sensitive data that need to be protected.

The rest can be sniffed of course if not encrypted, but that will only be in "read-mode", the hacker will not be able to modify anything. By obtaining the login/password he however will.

Dependent on the application of course, the owner may decide the rest data are not sensitive enough to bear the extra load of encrypting all traffic. However certain applications like online banking systems do SSL on all the pages since the account state, transactions and even the settings can be considered sensitive enough to keep them away from prying eyes.

Answer 2

https is used for much more than login. Whenever I log into my on-line bank, or do shopping cart logic, or give a credit card on-line, I see https is the protocol. It'd better be, or I won't use the app.

Answer 3

A HTTPS connection can be used anywhere. It just transmits all data using SSL (TLS), which is a form of public/private and symetric encryption. It makes it very hard to decrypt the data sent to and from the server.

Due to the costs of encrypting and decrypting the data, it (in some cases) isn't used where sensitive data isn't transmitted. Not using it just reduces the server load. It should always be used when sensitive data needs to be transmitted. If you are entering (for example) credit card data, you should check that the protocol is https rather than http.

Answer 4

Simply put, you use HTTPS to send over secure information. Thus, credit card information and passwords will use HTTPS to protect them. Compare it to an armored car used to bring prisoners from a county jail to State Prison. But once this information is at the right location, a simple token can be used to refer to the information without any further exposure. When you logon, the secure connection will generate a session ID which will be valid for 10, 20 minutes before it expires. While there's a risk that someone will capture this session ID, it's still not enough information to take over your information completely. The hacker would just have a short window to misuse that ID. Thus, there's less risk with sessions than with passwords. Same with credit card information. Once the site knows your credit card numbers, it can just ask you if you want to use card 1, card 2 or another one. It just assigns an ID to each card, which is generally just a number from 1 to the number of cards you have. If someone reads this, they know you're paying $49.95 with card 1. They still don't know anything more about this card, though.

Things that need to be secured, are send with armored cars or HTTPS. Anything else can just use any other kind of transportation.

Answer 5

Performance is not the only issue. If you're going to use HTTPS, you really need to check that all your content, including third party images and libraries, is available through HTTPS. Otherwise, you will generate annoying mixed content messages on IE:

http://blog.httpwatch.com/2009/04/23/fixing-the-ie-8-warning-do-you-want-to-view-only-the-webpage-content-that-was-delivered-securely/

This also means that you'll need separate SSL certificates for each host name that you use (e.g. images.example.com ) or some sort of wild card SSL certificate (e.g. for *.example.com).

A carefully configured site should only suffer a slight CPU hit on client and server using HTTPS:

http://blog.httpwatch.com/2009/01/15/https-performance-tuning/

Answer 6

"Because the login and password are the most sensitive data that need to be protected. The rest can be sniffed ..., but that will only be in 'read-mode', the hacker will not be able to modify anything."

That sounds wrong to me.

If the log-in creates some sort of session, during which any data modification is allowed, then there must be some sort of session token or identifier, typically stored in a browser cookie (or equivalent). If you can sniff that session token, you can construct an update request and send it to the server.