gmail.com: all encrypted, all the time (for those that want it)

[yesthattom]

http://gmailblog.blogspot.com/2008/07/making-security-easier.html

The “Settings menu” now has a “always use HTTPS” option.

Comments

[ninaf.livejournal.com]

Finally.

[ladyinfidel.livejournal.com]

thanks!

[bored2sleep.livejournal.com]

Hooray! Now if they'd just add it to Docs and the rest... ;)

[etler.livejournal.com]

I have a couple questions I've always wondered about..

In reality, what is the processor hit for using https vs. http? Is it huge? I never find myself sitting at a page waiting for it to load and think to myself "oh, of course it's slow, it's using https".

I hope this doesn't give people a false sense of security about their e-mail. Unless I suppose it's between two gmail users. SMTP's not secure. Maybe this makes a targeted attack more difficult.

Anyway, I've often wondered about this https being slower than http claim.

[yesthattom.livejournal.com]

I don't have actual numbers but there is a rule of thumb in the industry that https consumes a multiple of cpu resources. A quick search tells me it might be 5x for some platforms.

In this load-balanced world, you have to think in terms of QPS and response time. A web server can get infinite QPS if you don't mind that response time (latency) will suck. If you send 500 QPS to a web server, the average response might be 100ms. That's fine for your requirements. You send 600 QPS and the latency goes to 150ms. You send 1000 QPS and the latency goes to 300ms. Your salesperson will say, "see! it handles 1000 QPS!" but your boss will say, "our customers don't tolerate more than 150ms. Therefore, that web server only should be USED for the first 600 QPS of traffic we receive, 500 is preferred." Therefore you program the load balancer to send the first 500 QPS to one machine, the next 500 QPS to the next, and so on. (If you receive a million hits per second, you need a lot of machines).

(Obviously you don't program a load balancer that way... you have it divide the traffic between those machines evenly until you hit 500QPS. However, you also tell it to start rejecting connections after 600 * X connections (where X is the number of machines).

So what does this have to do with HTTPS? Well, your boss comes to you and says we want HTTPS enabled. So you set it up and send 100 QPS, 200 QPS, 300 QPS, and each time measure the average latency. Don't be surprised if you find you need 5x the number of machines.

[yesthattom.livejournal.com]

After I posted my reply I realized a shorter version would be:

HTTP requires file I/O.
HTTPS requires MATH and file I/O.

HTTP is gated by the amount of file I/O you can do.
HTTPS is gated by which you run out of first: MATH or file I/O. For most computers, you run out of MATH first.

[etler.livejournal.com]

So it's a function of the server processing power, and not so much the browsing computer's power? Why does the Google blog post make it sound otherwise?

[ladyinfidel.livejournal.com]

doesn't work for a blackberry though. i had to go back to http on there.

[yesthattom.livejournal.com]

Try clearing your cache and your cookies. See if it works then.

If not, there is a special gmail client for BB that is better than the web interface any day. (Or so I'm told by my BB-using friends. I hope to borrow a BB next month to see how I like it.)

[ladyinfidel.livejournal.com]

thanks. i like the gmail as the web app though because it doesn't buzz every time i get an email

[yesthattom.livejournal.com]

It is slower for the browser too. Having to decrypted packets is slower than not having to. It is noticeable on slower computers. Not a problem at the desktop or laptop, but mobile devices and embedded computers tend to use a lot slower CPUs. On mobile platforms more math means more power used for the equivalent unencrypted action.