How secure is https:

August 1, 2007 1:29 PM

Gmail and google docs allow you to substitute https: for http: at both the login and document level for security. Does using https: in place of http: for gmail and google docs prevent my documents from being viewable by someone with access to the network? How is this security different from encryption?
posted by jeffreyclong to computers & internet (13 comments total)

The data you exchange with the server is, in fact, encrypted while in transit. For the nitty gritty details of how it's done, check out the wikipedia description of the TLS/SSL protocol.
posted by mr_roboto at 1:40 PM on August 1, 2007

https will force it to use encryption from the get go, but don't be alarmed by login pages that dont have https. Usually they transmit your username/password via https.

This is not at all different from encryption. What is does is encrypt the session between you and google. So someone sniffing the network wont be able to retrieve your data. SSL certificates are also signed so no one can impersonate google or whomever.

wikipedia link here. and here.
posted by damn dirty ape at 1:42 PM on August 1, 2007

Https is the encrypted version of http.

Does using https: in place of http: for gmail and google docs prevent my documents from being viewable by someone with access to the network?

Almost totally yes. The truth is, a really determined, experienced person with access to your local network with a lot of time on their hands could likely decrypt your https session. But this person probably does not work at your office.
posted by poppo at 1:43 PM on August 1, 2007

HTTPS uses encryption, but doesn't encrypt the documents while they're not in transport. That is, Google has unencrypted access to the document (it's stored on their servers, presumably in an unencrypted format), and you have unencrypted access (you can read it, can't you?), but your at every step between Google sending it down the wire and your web browser putting it on your screen, it's encrypted.

Here's an example. Say you call Alice. Normally, someone with access to your phone wires could drop a tap on it and record away. That's HTTP. Now let's say you and Alice each put a scrambler on your phone. Now you talk normally, and Alice hears your conversation normally, but anyone tapping your line gets gibberish. That's HTTPS. In contrast, let's say you record your message to Alice, and scramble it before you make the call. You call Alice, she records the scrambled message, and then unscrambles it to get your voice. Anyone tapping the line would still hear gibberish, but for different reasons. That's document-level encryption.
posted by TheNewWazoo at 1:45 PM on August 1, 2007 [1 favorite]

Yes, HTTP + SSL uses a key-exchange protocol where the server and client both encrypt their traffic using public-key encryption. The server has its info signed by an authority that has its info already in your browser as you downloaded it, and that prevents a man-in-the-middle attack.

This isn't automatic -- changing "http" to "https" and having it work. Getting the aforementioned authority to verify your identity and sign your key is costly, and not everyone bothers with that.
posted by cmiller at 1:47 PM on August 1, 2007

but don't be alarmed by login pages that dont have https. Usually they transmit your username/password via https.

No, wrong. You most definitely should be alarmed of login pages that do not use https. When you use https, you get more than just the encrypted transport layer. Just as importantly you get authentication. If someone can sit between you and your bank and pretend to be the bank, you don't want to give them your password. The HTTPS/SSL protocols also involves verifying a trusted chain of certificates that prove the entity you are talking to is who they claim to be.

If you call Alice, all the transport encryption in the world doesn't save you if Eve picked up Alice's phone and they sound the same (they're twin sisters, say).

By not using https on the login page, you have no assurance that you are indeed talking to who you think you are and you may be givingt your password away. See this link.
posted by jeffamaphone at 2:21 PM on August 1, 2007 [1 favorite]

Thank you everyone.

Using https: at the login of gmail creates an https: session. All future pages are https:

But using https: at the login of google docs does not create an https: session. Future pages are http:

Why is only the login secure? Doesn't this mean that the documents are not secure?

A workaround is once you've opened a document, add the "s" to the http: of the document and then bookmark that page. Then everytime you want to go to the page securely use the bookmark instead of google's start page.
posted by jeffreyclong at 2:56 PM on August 1, 2007

The encryption isn't strictly done using public-key encryption - typically, a symmetric session key is encrypted with public key methods, and that is used for the remainder of the session for efficiency reasons.
posted by kcm at 3:05 PM on August 1, 2007

My understanding is that only the logins are secure in order to save processing time on Google's servers. The most important thing to protect is your password/login credentials so that uses https. Then, if you don't care about someone reading the contents of your emails or documents, it's easier to just leave the rest unencrypted.
posted by metaname at 5:31 PM on August 1, 2007

Metaname has it; using TLS/SSL is expensive, processing-wise, and search isn't the kind of thing that people (generally) need to secure.

On the other hand, if you want to surf for questionable stuff on your work network, say, or on your neighbor's wireless without their knowledge, I can see why you'd want to do this. There are ways to accomplish it, but they're not easily described or done.
posted by davejay at 5:48 PM on August 1, 2007

The HTTPS/SSL protocols also involves verifying a trusted chain of certificates that prove the entity you are talking to is who they claim to be.

Sorry, but as someone who's set up secure certificates in the past this is something of a joke. Many, many companies have become resellers of chained certificates and used limited to know real verification checking when giving others certificates.

It's possible that if you click on a link and punch in your login information, then you might have someone landed on a spoof site that will malicious grab your information, but if you've typed in the URL of the website yourself that's not likely to happen.
posted by Deathalicious at 6:19 PM on August 1, 2007

No, wrong. You most definitely should be alarmed of login pages that do not use https.

This is certainly a good rule of thumb, but it's possible to have a page served up over http that then contains a form which posts to an https page (if you view the source of Google's login page you can see this in action). In such a case your login / password info is sent encrypted over the wire.

Of course, nobody wants to view the source of a page and dig out the form actions every time they log in, so verifying that the page itself is secure and the URL is correct is usually good enough - most browsers will warn you if you're posting an unencrypted (http) form request from an encrypted (https) page.
posted by whir at 2:49 AM on August 2, 2007

Deathalicious:

Yes, you're right. It's not a perfect system.
EV SSL tries to fix this.

Whir:

You missed the point entirely. Go back and re-read my post.

I agree that it's entirely possible to submit a form over https from a non-https page. But, if the page you type your login information into is not an https page, you have no way of knowing that it is actually the page you think it is, because there has been no authentication done.
posted by jeffamaphone at 9:20 AM on August 2, 2007