I don't understand how any kind of encryption can exist when a key is still sent to the user, unencrypted. The initial connection to the site will be unencrypted until the key is sent. I'm still trying to wrap my head around this and can't see how someone sniffing can't simply pickup a key and automatically decrypt information from that connection. It seems too easy. Can someone explain this to me, plainly? Thank you.
SSL Uses public key cryptography which is a one-way cryptographic method. There are two keys involved, one to encrypt and one to decrypt.
Public key = encrypt
Private key = decrypt
The public keys (both yours and the servers) are exchanged in a handshake at the start of the transfer. The private keys are never sent.
Then you can both encrypt data that can only be decrypted by the private key on the other end.
This is also how SSL authentication works. You encrypt some data with the servers public key and send it. The servers decrypts and sends it back. If they match you know its the correct server and that the IP has not been spoofed.Please support us and post a [Link to www.digitalartsfront.com] on your website.
I still don't see how this prevents the middle-man from viewing the exchange and having a script which looks for the hand-shake. Once the public keys are intercepted it seems like the private keys will also be exposed.
The private key is a file usually stored at: /root/.ssh/id_rsa
It is used internally by apache or whatever server you're running and is never sent over the net, so it cant be intercepted.
The handshake could be intercepted and you could obtain the public keys, but they would be useless, as they can only encrypt the data, not decrypt it.
There is another layer to the process that I glossed over for simplicity. I'll try to explain here:
Once the handshake is done and both parties identities are verified, the server generates a random keystring and sends it to the client (encrypted by their public key, can only be decrypted by the clients private key).
This is then used as a symmetric encryption key for the connection and works in the usual way, both parties have the same key, can be used to encrypt/decrypt. But as the key was encrypted by the public key when it was sent, it can not be intercepted. This allows the connection to use faster more optimized cryptography (such as 3DES, Blowfish, IDEA, AES) while eliminating the problem of intercepting the key.
The symmetric key also gets timed out every few minutes and a new key exchange is done, so it prevents the key from being brute forced.
I just found out I don't have ssh on my server... They want me to upgrade to have shell access... I can't even play with encryptions through the public html... $ heart -a | broken
Admin
Public key = encrypt
Private key = decrypt
The public keys (both yours and the servers) are exchanged in a handshake at the start of the transfer. The private keys are never sent.
Then you can both encrypt data that can only be decrypted by the private key on the other end.
This is also how SSL authentication works. You encrypt some data with the servers public key and send it. The servers decrypts and sends it back. If they match you know its the correct server and that the IP has not been spoofed.
Please support us and post a [Link to www.digitalartsfront.com] on your website.
--Matt