How does SSL actually encrypt information? [closed]

Question

I just recently set up SSL on my website's account creation page. I'm looking to expand this further to my entire site.

I had a question, though. How does SSL encryption actually work and protect data in transit? Furthermore, what methods are normally available to hackers to intercept data sent in plain-text over HTTP? I know there is "sniffing", but that is always the only method given, there is never any elaboration. Is there a way to examine the data being sent over HTTP and HTTPS? To compare and contrast?

Answer 1

HTTP is not encrypted in any way. Any network sniffer that can sniff the packets between the HTTP client and server (most network adapters support a promiscuous mode for this purpose) can view the HTTP data.

HTTPS data, on the other hand, is HTTP data that is encrypted with SSL/TLS. SSL/TLS encrypts outbound data before it hits the network, and decrypts inbound data after being leaves the network. There is no plain text on the network, so it doesn't matter if the packets are sniffed by a third-party. Without the encryption keys, the sniffed data is garbage. During the SSL/TLS handshake, the client and server negotiate encryption keys, certificates, etc with each other before any application data can then be exchanged. Data that is sent to the server is encrypted using the server's key, and data sent to the client is encrypted using the client's key. This ensures that encrypted data sent by the client can only be decrypted by the server, and vice versa.

About the only way to intercept and extract plain text from a SSL/TLS encrypted connection is with a man-in-the-middle attack. This means the SSL client connects to the MITM, and then the MITM connects to the SSL server, and funnels data back and forth between them. The MITM needs access to the network that the client or server are running on, and has to be able to reroute the client's connection to itself instead of the server. But if it can do that, the MITM can negotiate its own SSL/TLS connections with both parties so it has all of the necessary encryption information. It can then receive and decrypt the SSL client's sent data using the encryption keys it negotiated with the SSL client, then re-encrypt and pass that data to the SSL server using the encryption keys it negotiated with the SSL server. And vice versa. The SSL client and SSL server will not know they are talking to a MITM instead of each other, unless you use certificates so the SSL client and SSL server can verify each other's identity during the initial handshake. SSL/TLS does not require certificates, but they are good to use if you have them.