Why is a "secure connection" (SFTP, HTTPS, etc.) actually secure?

**djr33** · 02-06-2013, 04:10 AM

The problem with a non-secure website is that anyone on your internet connection can look for the packets you send and put the pieces back together. It's easy, for example, to silently steal passwords if you're sending them to a non-secure site.

And a secure connection encrypts that data. Let's assume the algorithm is not hacked. Ok, it works. The idea is simple: you and the server share an encryption key and all of the data transmitted is meaningless until decrypted with that key. Simple. If anyone is listening in, all they seem is useless characters.

But... what I don't understand is why that key is secure in the first place. If someone was listening to my entire session (let's say I go to my bank's website, I get the encryption key [unencrypted, right?], and then I send my now encrypted password, and I do my stuff, and I leave the coffee shop)... then, with all of the information, wouldn't they be able to see it, assuming they had the right methods to apply the key to the data?

Why is the key itself secure? Or is that just an extra measure used to make it one layer harder to hack people?

Moderator's note: This topic borders on hacking topics; my intention in posting it is to know about security, not to ask how to hack anything-- I'm interested in whether hacking in a certain situation is possible, not how to do it. This is not a hacking website, so please do not post any direct instructions for how to hack.

**james438** · 02-06-2013, 05:00 AM

Not being any expert it sounds like it is just an extra step which is important. It also is a way for corporations to let customers know that they are taking at least that one step to ensure their customer's information is protected.

**traq** · 02-06-2013, 05:27 AM

SSL really is fairly secure, even in the circumstance you describe. There are two keys: public and private. One encrypts, the other decrypts. They're paired, but you can't infer one from the other. The server can send you the public key (and your browser can send the server its public key), and it won't matter in the least if someone intercepts it, because it can't decrypt anything.

**djr33** · 02-06-2013, 05:25 PM

Aha! So each end of the connection can only encrypt, except with it's local-only decryption key. I've seen those terms (private/public key) and not known what they meant.
That's cool. I hadn't thought of it that way, but it makes sense!

Does the private key change sometimes? To avoid brute force problems, it seems to make sense to switch it once in a while.

**traq** · 02-06-2013, 08:02 PM

You can change your private key whenever you like, but you have to issue new public keys.

**djr33** · 02-06-2013, 09:06 PM

I mean, does it automatically rotate (and along with that, send the new public keys)? Or is a single computer generally associated with a single private (and public) key for a long time?

**traq** · 02-07-2013, 03:18 AM

A distinction: the server's (and sometimes, the client's) public key is used only to negotiate a secure connection. During this "handshake", the client and server use the the key - along with other data unique to the connection - to create session keys, which will be used to encrypt/decrypt later messages.

To answer the question, SSL is stateful - as opposed to the "stateless" HTTP protocol - the "handshake" only needs to happen once.
However, either end can decide to renegotiate (discard the current SSL session and start a new one) at any time. If this generally only happens under certain conditions, or if it "rotates" regularly, I don't know.