Ask all your coding questions @ codequery.io
SSL is a protocol. A protocol defines a set of rules for communicating between systems. SSL provides a layer of encryption on top of other protocols like HTTP.
HTTPS is really just the HTTP protocol with the SSL layer on top of it.
Using SSL, browsers can encrypt sensitive data so it can travel safely to its destination. While anyone can inspect network traffic, if your data is encrypted then all they will see is gibberish. It takes a private key to decrypt the data.
SSL was renamed Transport Layer Security (TLS) in 1999. TLS represents the evolution of SSL under different ownership. When you hear “SSL”, it’s probably referring to TLS.
For more info, check out SSL vs TLS.
An SSL connection exists between a server (some app like Facebook) and a client (your web browser). When the client talks to the server it does so over HTTPS.
The SSL protocol calls for a handshake to initiate communication between a client and server. The steps of this handshake are fundamental to identifying trusted sources and keeping communication secure:
1) Your browser (client) askes a server for it’s SSL certificate
2) The server shows your browser its certificate
3) Your browser decides if it trusts the certificate or not.
4) If yes, your browser uses the certificate to encrypt a secret message
5) Your browser sends this encrypted message to the server
6) The server decrypts the message
7) Using the shared secret message, your browser sends more encrypted messages only the server can decrypt.
1) Your browser sends a request to the server including TLS version and cipher algorithms supported. This request also include a random string of characters called the client random.
2) The server responds with the chosen cipher, the server’s SSL certificate, and a similar random string of characters called the server random
3) Your browser decides if it trusts the SSL certificate. It may check with a trusted third party to ensure the issuer is who they say they are. Your browser verifies the third party by using the third party’s public key to verify the certificate’s digital signature.
4) If your browser trusts the certificate, it uses the public key provided in the SSL certificate to encrypt a premaster secret.
5) This encrypted secret is sent to the server.
6) The server decrypts the secret. At this point both the client and the server have the client random, server random, and premaster secret to generate a session key.
7) Using this shared session key, the client and server exchange encrypted information securely over an SSL connection.
For more details, check out How Does TLS Work?.
SSL encryption uses public key cryptography to generate pairs of keys. Each pair consists of a private key and a public key.
Only the private key can decrypt messages encrypted with the public key. Only the public key can decrypt messages encrypted with the private key.
One key is designated public and made available to anyone. Anyone can have the public key to encrypt messages.
One key is designated private and made available only to the creator of the keys. Only the creator of these keys has the private key. Only the private key can decrypt messages.
An SSL certificate contains an issuer’s public key. Clients request an SSL certificate to obtain this public key AND verify this public key comes from a trusted source…
Anyone can generate a public/private key. Using ssh-keygen or some other utility makes it rather simple. For these reasons, it’s important to verify the information on the SSL certificate. Clients do this by trusting a third party Certificate Authority (CA).
A CA issues SSL certificates to servers. A server requests an SSL certificate from a CA so it can be trusted by browsers and comply with SEO. This request is called a certificate signing request (CSR).
A server submits its public key to the CA as part of this CSR. The CA has it’s own public/private key pair. Once the CA decides the applicant is legit, it digitally signs a new certificate with it’s private key.
This new certificate is issued to the server. When clients initiate a handshake with the server it presents them with this SSL certificate.
While it may seem silly to encrypt something ANYONE can decrypt, this relationship makes it possible for anyone to validate a signature. If a public key can decrypt a message from a private key then a public key can verify a digitally signed certificate.
For these reasons, a CA will provide browsers/clients with it’s public key. Now browsers can trust certificates signed by a given CA by using the CA public key to verify the CA signature on the server’s SSL certificate.
Now the client can use a third party to verify the SSL certificate is coming from a trusted source. Knowing the SSL certificate is legit means knowing the server’s public key is legit.
Now the client can use the public key from the certificate to encrypt data that only the server can decrypt.
An SSL connection exists between a client and a server when the handshake process has completed. Once the client validates the SSL certificate it establishes an SSL connection with the server.
During this secured connection the client and server use a shared session key to encrypt / decrypt messages back and forth.
SSL is a protocol. HTTP is a protocol. SSL is an additional layer that sits on top of HTTP. An HTTP connection using SSL is communicating over HTTPS.
By itself, HTTP exists as a protocol. Just like any protocol, HTTP defines how two systems communicate.
Unlike HTTPS, HTTP is not considered secure. This is because HTTP by itself doesn’t encrypt data that’s being transmitted over a network.
Using SSL, HTTP can encrypt data and verify who it’s encrypting messages for.