CODEWITHSUNDEEP
sslsecurity
gizmo
gizmo

Reputation: 21

SSL security concern

I'm wondering why ssl encrypted data can't be cracked easily once the packets are intercepted. As i understand it when you connect to a site like facebook the browser and site agree on a cipher, what stops the sniffer from seeing what cipher they agreed to?

Upvotes: 2

Views: 132

Answers (6)

blackhat016
blackhat016

Reputation: 1

Like Derek H said, there are fundamental differences between symmetric and asymmetric encryption. Look up stuff like DH key exchange protocol and RSA cipher, they are fundamental in SSL/TLS. On the other hand, it's relatively easy to decrypt sniffed data (ROBOT attack).

If you just need to be sure your communication is secure, you can simply use SSL/TLS Server Test, there you can see if you're not using recommended algorithms or see if your SSL/TLS configuration is PCI-DSS/HIPAA/NIST compliant.

Upvotes: 0

ebelisle
ebelisle

Reputation: 1207

There's a lot of ways to describe it. For me, my ah-hah moment was when I figured out that, after information is encrypted multiple times, it can be decrypted in any order.

  1. A encrypts first, passes to B a single encrypted message [A encryption].
  2. B encrypts the message a second time, and passes to A a double encrypted message [A encryption and B encryption]
  3. A removes [A encryption] from the message, leaving only [B encryption], and sends the message to B.
  4. B now has a [B encrypted] message, and knows how to decrypt it.

The sniffer sees the message encrypted three different ways: [A], [AB], and [B].

That's three message passes to exchange one message, but once it's passed and both sides have the unique information to decrypt further communication, future messages only need one trip.

If you want a simple example of how a message could be decrypted in any order, you can use XOR as a sample encryption method. For keys A and B, message M, and XOR is ^, then

  • M ^ A ^ A = M
  • M ^ A ^ B ^ A ^ B = M

Upvotes: 1

Matthew Flaschen
Matthew Flaschen

Reputation: 285047

Yes, the cipher is public. However, the client asymmetrically encrypts a random session key (or rather a precursor) using Facebook's public key (they verify it's really Facebook's key by checking that it is signed by someone trusted). So only Facebook (who has a private key) should be able to derive the actual symmetric keys that are used to exchange website data.

See this detailed walk-through. In that example, an eavesdropper can tell that the connection uses RSA, RC4, and MD5. But they don't have Amazon's private key, so they can't derive the session keys.

Upvotes: 0

Darko Kenda
Darko Kenda

Reputation: 4960

Imagine sending a box with an open padlock to the other side - when the other side wants to send a message, they put it inside the box, lock the padlock and send it back to you, where you use your (private) key to unlock it. Even if the intercepting party has sees the padlock, they still don't have the key.

Upvotes: 2

Christian
Christian

Reputation: 26427

Facebook signs it's package with a certificate that Facebook got from an certificate authority such as RapidSLL.

As long as you trust the certificate authorities that all certificate they issue for facebook.com do really belong to facebook.com the connection is safe.

Facebook then sends you via a signed message it's public encyrption key which you can use to encrypt your messages to be read by facebook.

Upvotes: 0

Elle H
Elle H

Reputation: 12237

SSL uses asymmetric encryption, meaning the decryption key is different than the encryption key. So if you as a client encrypt your packets with the server's public key, it can only be decrypted by the private key, which remains on the server. Of course, this is a simplification of everything that happens in an SSL transaction, but that's the basis of the concept.

Upvotes: 9

Related Questions