The SSL (Secure Sockets Layer) or know as TLS (Transport Layer Security) is a building block and not just a standalone application. It is the foundation for secure communication in a lot of networked applications. Netscape Communications developed the SSL originally. In 1995, version 2.0 was released and the first version made available publicly. In 1996, due to some security flaws, it was updated to version 3.0. IETF (Internet Engineering Task-Force) continued to work on SSL and the first IETF standard (RFC 2246) in 1999 was published. At that time the protocol name was changed as TLS. TLS 1.0 version has no direct compatibility with SSL 3.0 so to make backward compatible, has to downgrade a connection. In RFC 5246, the current TLS version 1.2 is defined. It supports modern ciphers such as the AES.

TLS can be defined as a client/server protocol. This protocol has two phases: an application phase and a negotiation phase. TLS makes use of the asymmetric key algorithms such as RSA, DSA, and Hellman for exchanging session keys and for server authentication and if the client is applicable and makes use of the symmetric key algorithms to encrypt the actual link.

Implementation of SSL

SSL has used both asymmetric and symmetric cryptography. It has been used asymmetric private and public key pairs and symmetric session keys which is used to encryption and decryption.

  1. Before engaging the secure communication between client and user; an SSL certificate must be installed on the server that is verified by the certificate authority.
  2. After the browser informs that It would prefer to start communication with that particular server.
  3. Then the server sends the SSL certificate along with the public key of the server.
  4. If the browser verified the certificate that is sent by the server; it created the symmetric session key and encrypted with servers public key and send back to the server.
  5. After server decrypts the symmetric session key that is sent by the browser; using servers asymmetric private key.
  6. This decrypted session key is used to secure communication between server and client in a proper manner.

Common Applications of TLS

HTTPS is the application most often used of TLS. In web page transferring, HTTPS is the secured version compared to the HTTP protocol. It is been used for securing online transactions for credit cards, protection of password data exchanges while logging into online sites and accessing e-banking web sites. TLS is also used to secure protocols which was previously insecure with the addition of SSL. Examples are providing security to SMTP protocol which is using to end emails, IMAP and POP3 protocols, accessing remotely the emails and the FTP protocol, to file transfer across networks. Adding the “S” to these protocol names is common convention to indicating they make use of TLS/SSL (FTPS, IMAPS, POP3S). TLS provide security to data only in transit, no protection to data stored in both endpoints. An Attacker always try the weak link, so when data in transit are protected, he/she will attempt to intercept it from the not encrypted endpoint of the link. ‘man-in-the-browser’ is a common attack of this kind.

There are a number of commonly used open-source TLS implementations E.g. OpenSSL, Gnu TLS, and NSS (included in the Firefox web browser).

Harm and weaknesses of TLS

The most commonly used security protocol is TLS, Among the security protocols widely used is TLS. This protocol is maintained and developed actively but also been inspected by hackers as well as security researchers. As time passed some weaknesses have been found in the TLS protocol. The weaknesses are,

  • SSL cipher downgrade attacks – Old SSL protocol versions such as V2 and lower are prone to cipher downgrading attacks. In this case, an SSL server is tricked to think that only low-grade security (40-bit RC4) is supported by the client. Therefore servers need to be configured to not allow SSL V2 and lower.
  • TLS renegotiation attacks This is the most recent issue and was identified by Marsh Ray; this attack affects sites that use client authentication.

luckily, after modifications made to the protocol, all the weak points are mitigated successfully. As a result, TLS protocol is considered a secure and good way of adding encryption to the transport layer of an application if and only adequate patching is done to the software that is used. It is encouraged strongly to use TLS in any application and avoid developing homemade solutions. A big downside of the TLS protocol is relying of the X.509 certificates to authenticate servers. Frequently errors happen from these certificates. A few example errors are,

  • The certificates are expired
  • The certificates include invalid hostnames for the server
  • Untrusted certificate or broken certificate trust chains (occurs often if using homemade self-signed certificates)

Example of a TLS certificate warning in Firefox.

Fire Fox | Unsecured | Untusted | TLS | SSL

Example of a TLS certificate warning in Google Chrom.

Fire Fox | Unsecured | Untusted | TLS | SSL

Therefore it is important to correctly configure the deployment of SSL or TLS. When warnings are infrequent users will not take them seriously. In an attempt to prevent a false sense of security in users, a good practice is to configure a web server in a way which will not allow support for older defective implementations like the SSL V2 and rejection of cryptographic algorithms that are weak and allows only the use of strong algorithms. Not all the users will bother about checking the cryptographic algorithm that is been used in the connection is actually secure. Users will most of the time be relying on that padlock like symbol in a browser to indicate that they if their connection is safe. a good practice is to always make use of a service like SSL to the testing of a configured web server. After discussions with Eric Verheul (Dutch security researcher), it was decided to add a test to the latter service to identify whether weak ciphers are not accepted by a web server.