Back to Basics – SSL Security
Hypertext Transfer Protocol (HTTP) is an application-based protocol used for communications over the Internet. It is the foundation for Internet communication. Of course, as time has gone on there are new ways to communicate over the internet. For example, SIP trunking is a popular way to send voice transfers over the internet. Many businesses look on sites like www.siptrunk.com to learn more about how it can benefit them. HTTP uses TCP (port 80) as its transport protocol for data delivery (image, HTML files) and to specify standards for communication. Due to its connectionless and stateless features, HTTP has numerous security limitations, not only at an application layer but also exposed to a variety of TCP control plane attacks. It is vulnerable to a wide range of attacks including file and name based attacks, DNS Spoofing, location headers and spoofing, and HTTP proxy man-in-the-middle attacks. It carries a lot of important personal information, such as usernames/passwords, email addresses, and potentially encryption keys making it inherently open to personal information leakage.
SSL was introduced to provide security for the client to server communications by a) encrypting the data transfer and b) ensuring the authenticity of the connection. Encryption means that the data cannot be read by a 3rd party. Essentially, hiding what is sent from one computer to another by changing the content. Codes are used to encrypt traffic and SSL puts a barrier around the data. Authenticity means that you can trust the other end of the connection.
SSL uses TCP as the transport protocol enabling security services for other application-based protocols that ride on TCP including FTP and SMTP. Some well-known TCP ports for SSL are 443 https, 636 ldaps, 989 ftps-data, 990 ftps, 992 telnets, 993 imaps, 994 ircs, 995 pop3s, 5061 sips. It relies on cryptography, shared keys are used to encrypt and decrypt the data. SSL certificates, assigned by certificate authorities (CA) issue public keys, creating trusted 3rd parties on the Internet.
Firstly, client and server agree on “how” to encrypt data by sending HELLO messages containing Key Exchange Message, Cipher, version of SSL, and the Hash. The server replies with a HELLO messages with the chosen parameters (The client offers what it can do and the server replies with what they are going to do). Next stage, the server sends a certificate to the client containing its public key. A client key exchange message is used and once this message is sent, both computers calculate a master secret code, which is used to encrypt communications. The computer then changes back to the Cipher Spec previously agreed in the previous HELLO messages. Encryption then starts.
Certificates are used for identification and signed by a trusted Certificate Authority (CA). Firstly, you need to apply for a certificate via a CA (Similar to the analogy of a passport application). The CA creates the certificate and signs it. The signature is created by condensing all the company details into a number through a Hash function. The CA encrypts with the private keys so anyone holding the public key can encrypt. For example, the certificate is then installed on a web server at the customer’s site and used in the handshake process.
Google started the “SSL everywhere” initiative to enhance online communications and promote safer browsing. It actually gives SSL based sites an SEO boost, alongside the international seo keyword research that so many companies invest in. If you’re interested in SEO, you can learn more at ninja reports, a company that offers similar services. SSL is the only security protocol we have globally. There is IPSEC, but you had to be part of the group in order to gain trust. More Internet traffic is getting encrypted and there are many initiatives to enhance security with additional features such as Forward Secrecy, Strict Transport Security and 2048-bit key lengths.
Most sites supporting HTTPS operate in a non-forward secret mode, exposing themselves to retrospective decryption. Forward secrecy is a feature that prevents the compromise of a long-term secret key. It allows today’s information to be kept secret even if the private key get compromised in the future. For example, if someone is trying to sniff client to server communications but couldn’t as the server was using a 128-bit key, they can record the entire transmission for the next 5 years. And when the server gets decommissioned they attempt to get the key and decrypt the traffic. Forward secrecy solves this problem by double encrypting every connection. Even if someone gets the key in the future, they can’t decrypt the traffic. Google supports forward secrecy on many of its HTTPS websites, such as Gmail, Google Docs, and Google+. Around ? of the internet uses forward secrecy.
Strict Transport Security (HSTS)
In 2009, a computer security researcher, Moxie Marlinspike introduced the concept of SSL stripping. He released a tool called “sslstrip“, which could prevent a browser from upgrading to SSL in a way that would go unnoticed to the end user. Strict Transport Security is a security feature that lets a website inform browsers it should be communicating with HTTPS and not HTTP in a way the prevents man-in-the-middle attacks. The deployment of HSTS has been slow, around 1% of the Internet is using it.
POODLE Attack – Flaw in SSLv3
In October 2014, Googles security team uncovered the POODLE attack (Padding Oracle On Downgraded Legacy Encryption) and released a paper called “POODLE bites”. They uncovered a flaw in SSLv3, allowing an attacker to decrypt HTTP cookies and hijack your browser session. Essentially, another man-in-the-middle attack. Many browsers will revert to SSL 3.0 when a TLS connection is unavailable and an attacker may force a server to default back to SSL v3.0 to exploit the vulnerability. One way to overcome this is to completely disable SSL ver 3.0 on client and server. However, there are variants of POODLE for TLSv1 and TLS v2. Prior to the poodle attack, a large proportion of the internet supported SSL Ver 3.0 but in response to the attack this has considerably dropped.
2048-bit keys SSL certificate
There are strong recommendations to use 2048-bit certificates. The NIST and other companies feel the encryption provided by 1048-bit keys is not sufficient. Computer are getting faster and 1048-bit keys are not going to protect you for the lifetime of the secret. On the other hand, 2048-bit certificates will give you about 30 years of security. The impact of larger key length is a reduction in performance. 2048-bit keys will reduce transactions per second (TPS) by 5 times. There are options to configure a “Session Reuse” feature that lets you reuse the session id that are negotiated asymmetrically. Session Reuse is a mechanism that allows you to do less asymmetric key exchanges. But essentially you are trading performance with less security.
SSL all the way to the server can bring the application to it’s knees. Generic hardware is not optimized for this type of handling and 2048-bit keys don’t work well on generic software and processors. Consolidated the SSL with an appliance that handles the SSL load is better for TPS and performance. The driver for SSL offload on optimized hardware is more compelling with the use of 2048 bit keys.