Secure Socket Layer (SSL) and Transport Layer Security (TLS)

1. Overview

The main difference between Secure Sockets Layer(SSL) and Transport Layer Security(TLS) is that the SSL is a protocol that provides communication security in a computer network while TSL protocol is an evolution of the SSL protocol and consists of additional privacy and security features. In brief, SSL is the predecessor to TLS, TLS is more secure and efficient than the SSL.

2. Description

2.1 Secure Sockets Layer (SSL)

A protocol to allow web browsers and web servers to communicate securely which is one of the most popular web security mechanisms. It works between the application layer and the transport layer so the SSL layer can be considered as an additional layer in the TCP/IP protocol.

2.1.1 SSL connection Process(handshake)

• A browser requests a secure page 
• The web server sends its public key with its certificate
• The browser checks that the certificate was issued by a trusted root authority or Certificate Authority and that the certificate is still valid and that the certificate is related to the site contacted
• The browser uses the public key to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted HTTP data
• The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and HTTP data
• The web server sends back the requested HTML document and HTTP data encrypted with the symmetric key.
• The browser decrypts the HTTP data and HTML document using the symmetric key and displays the information

2.2 Transport Layer Security (TLS)

2.2.1 TLS connection process(handshake)

• A client tries to open up a communication with a target server with a list of its supported cipher suites
• The server responds with the most secure cipher suite supported by both the client and the server with its public certificate
• The client verifies the signature is from a trusted certificate authority. 
  • Depending on the Authentication Algorithm the server will have hashed a message with its private key
  • The client decrypts the message with the public key of the server and the message is correct then the client knows that the server is authorized
• The client will attempt to negotiate a symmetric key using the Key Exchange Algorithm
  • This will result in back and forth communication between the client and the server. 
  • The exact number of messages depends on the algorithm
  • Once the key has been negotiated, both parties are now able to start communicating securely
• The client sends its first HTTP request and encrypts it's with the Bulk Encryption Algorithm
  • The server is able to decrypt the request with the negotiated key(same key as the client)
  • The server verifies the integrity of the data by using the Message Authentication Code Algorithm
• The server then sends its encrypted HTTP Response to the client
  • The client then decrypts the message and verifies its integrity
• This back and forth will continue for as long as the session is active
  • Once the session is over, new session keys will need to be exchanged to start a new round of secure communication.

2.3 Cypher Suite

A cipher suite is a set of cryptographic algorithms used during SSL or TLS sessions to secure network connections between the client and the server.

The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a Message Authentication Code (MAC) algorithm.

2.4 OpenSSL

OpenSSL is a software library toolkit licensed under an Apache-style license for the implementation of the SSL and TLS protocols.

2.5 POODLE attack vulnerability

The POODLE attack (which stands for "Padding Oracle On Downgraded Legacy Encryption", CVE-2014-3566) is a man-in-the-middle (MITM) exploit which allows a hacker to decrypt select content within the SSL session.

Variations of the POODLE vulnerability affect TLS because an active MITM attacker can force a browser to downgrade the session down to SSLv3, which can then be exploited.

2.6 BEAST attack vulnerability

The BEAST attack, reported as CVE-2011-3389, exploits a weakness in SSL/TLS cipher-block chaining (CBC), allowing a man-in-the-middle attacker to recover certain session information, such as cookie data, from what should be a secure connection.

2.7 SWEET32 attack vulnerability

The SWEET32 attack (assigned as CVE-2016-2183) exploits a collision attack in SSL/TLS protocol supporting cipher suites that use 64-bit block ciphers to extract plain text of the encrypted data when CBC mode of encryption is used.

2.8 X.509

In cryptography, X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.

2.8.1 Structure of X.509

• Certificate
  • Version Number
  • Serial Number
  • Signature Algorithm ID
  • Issuer Name
  • Validity period
    • Not Before
    • Not After
  • Subject name
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
    • ...
• Certificate Signature Algorithm
• Certificate Signature

3. Compare

Feature	SSL	TLS
Name	Secure Sockets Layer	Transport Layer Security
Secure	less secure than TLS	More secure than SSL
Based on which protocol	No basis. derived from communication needs and related issues.	SSL v3.0 protocol and with improvements
Predecessor		SSL
Vulnerable attacks	SSL 2.0 & 3.0 are vulnerable to BEAST and POODLE attacks	TLS v2.0 is susceptible to both BEAST & POODLE attacks
When to choose	When the server is not capable of running TLS 1.2, go head with SSL v3.0	When your server is capable of running the latest version of TLS
Certificates	Certificates for use with SSL and TLS of the respective version
Compatible	Not compatible with versions of TLS	Not compatible with versions of SSL
Deprecated	Both SSL 2.0 and 3.0 have been deprecated by the IETF	Will be deprecated TLS 1.0 and 1.1 starting in 2020

4. Root Certificate

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed (or it is possible for a certificate to have multiple trust paths, say if the certificate was issued by a root that was cross-signed) and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string (RFC 5280). For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.

5. Extensions

extension	Description
.pem	.pem stands for PEM, Privacy Enhanced Mail; it simply indicates a base64 encoding with header and footer lines. Mail traditionally only handles text, not binary which most cryptographic data is, so some kind of encoding is required to make the contents part of a mail message itself (rather than an encoded attachment). The contents of the PEM are detailed in the header and footer line - .pem itself doesn't specify a data type - just like .xml and .html do not specify the contents of a file, they just specify a specific encoding;
.key	.key can be any kind of key, but usually it is the private key - OpenSSL can wrap private keys for all algorithms (RSA, DSA, EC) in a generic and standard PKCS#8 structure, but it also supports a separate 'legacy' structure for each algorithm, and both are still widely used even though the documentation has marked PKCS#8 as superior for almost 20 years; both can be stored as DER (binary) or PEM encoded, and both PEM and PKCS#8 DER can protect the key with password-based encryption or be left unencrypted;
.csr or .req or sometimes .p10	.csr or .req or sometimes .p10 stands for Certificate Signing Request as defined in PKCS#10; it contains information such as the public key and common name required by a Certificate Authority to create and sign a certificate for the requester, the encoding could be PEM or DER (which is a binary encoding of an ASN.1 specified structure);
.crt or .cer	.crt or .cer stands simply for certificate, usually an X509v3 certificate, again the encoding could be PEM or DER; a certificate contains the public key, but it contains much more information (most importantly the signature by the Certificate Authority over the data and public key, of course).
.p8, .pkcs8	.p8, .pkcs8 are private keys. PKCS#8 defines a way to encrypt private keys using e.g. a password. However, quite often, only the inner unencrypted PKCS#8 structure is used instead (which just defines the type of key). The inner structure can then e.g. contain a PKCS#1 formatted private key for RSA or a SEC1 one for Elliptic Curves. [dave_thompson: X9.62 defined commonly-used formats for EC public key and parameters (curve), but I'm pretty sure not private key although I won't spend my money to verify; for publickey and parameters SEC1 cites X9.62, and rfc5480 cites both SEC1 and X9.62, but for privatekey rfc5915 cites only SEC1 which cites nothing. Also I would say: generally not transported, but still fairly commonly PEM encoded, because many programs that use a separate key file or section, often via the OpenSSL library, require or prefer PEM: Apache httpd, nginx, haproxy, nodejs, python, wget and some curl; also Apache tomcat depending on version and option. But Java natively uses PKCS#8 DER, unencrypted.]
.p12 or .pfx	.p12 or .pfx is a PKCS#12 defined key store, commonly password protected. It can contain trusted certificates, private key(s) and their certificate chain(s), but also other information such as secret keys and (very uncommonly) other personal information; .p12 is usually binary / DER encoded. PKCS#12 has lots of options plus extensions (i.e. attribute OIDs) with varying support, so it is not safe to assume that every P12 file will work in anything that uses (some) P12 files.
.crl	.crl is a Certificate Revocation List which is defined within the X.509v3 certificate specifications, and this is usually DER encoded as well.
.p7b or .p7c	.p7b or .p7c is a specialized kind of PKCS#7/CMS message: a SignedData that doesn't contain data and isn't signed, and is used only to as a way to conveniently handle a group of certificates and/or CRLs. In particular it is often used as a way to handle the certificates which make up a 'chain' or 'bundle' as a single, well-defined unit. Other kinds of PKCS#7/CMS messages exist but are less used, and may have extensions like .p7 or .p7m, except that detached signatures, as a special case, are usually .p7s. In addition S/MIME is layered on top of CMS: S/MIME messages are really CMS messages wrapped in MIME format, and as such are usually identified by the MIME-type (aka media-type) in the message not by a file extension.
.jks	.jks stands for Java Key Store. It can be used to store private keys with their certificate chains (root CA, intermediate CA's, leaf certificates or just a single self-signed certificate), certificates of other parties (usually but not necessarily CAs) to form a trust store, or both. The JKS format (like the Java KeyStore API) is technically agnostic and can use any type of certificate for which the installed crypto-providers offer a CertificateFactory object, but in practice the only CertificateFactory implemented is X.509 (or PKIX) and the main applications in Java for keystores - code signing, S/MIME, XML/SOAP, and SSL/TLS - use only X.509. .jks key stores are password protected, using a proprietary (and weak) cipher Sun created back during the munitions-list era, but they have been deprecated since 2017 in favor of PKCS#12 with transitional support.

6. References

www.securesign.kr/guides/kb/54

en.wikipedia.org/wiki/X.509

en.wikipedia.org/wiki/Root_certificate

crypto.stackexchange.com/questions/43697/what-is-the-difference-between-pem-csr-key-and-crt-and-other-such-file-ext

https://pediaa.com/difference-between-ssl-and-tls/

http://www.differencebetween.net/technology/difference-between-tls-and-ssl/

https://support.venafi.com/hc/en-us/articles/215914997-Introduction-to-SSL-TLS-X-509-Certificates-and-Keys

https://medium.com/iocscan/transport-layer-security-tls-ssl-8e02b6d1d648

https://www.globalsign.com/en/blog/ssl-vs-tls-difference/

https://kb.iweb.com/hc/en-us/articles/230268628-SSL-TLS-issues-POODLE-BEAST-SWEET32-attacks-and-the-End-of-SSLv3-OpenSSL-Security-Advisory

https://www.openssl.org/news/vulnerabilities.html

https://www.openssl.org/news/secadv_20141015.txt

https://www.websecurity.digicert.com/security-topics/what-is-ssl-tls-https