What is SSL?

SSL (Secure Sockets Layer) is a protocol that operates directly on top of TCP. Due to this higher layer protocols, such as HTTP, can continue to work unchanged while providing enhanced security.

What protection is offered?

When implemented correctly SSL disguises the contents of packets between the server and client. Any eavesdropper will only be able to identify the client and server IP, the encryption and compression method and a rough size of the data. This stops eaves droppers from gaining access to critical data such as passwords or credit card details. However there are a few ways for a determined attacker on the same network to bypass this security.

SSL also verifies that the server you are connecting to is in fact the server you want to be connecting to. This removes the possibility of man in the middle attacks. You can however self-sign certificates which does not verify that you are connecting to the right server but still offers the same protection against eavesdroppers.

How does it work?

A normal TCP connection is first built then an SSL handshake is started by the client. This handshake contains information regarding the specification to be used, which version, compression, ciphersuite etc. On this request the server replies with it’s certificates public key. When the client receives a certificate it validates it against it’s internal list of valid certificates or that it is signed by a recognised certificate authority (CA). All browsers come with this list of trusted CAs pre-installed although they can be easily edited in the browser. In firefox for example you can go to preferences -> advanced -> certificates -> view certificates -> authorities, this will present you with a list of trusted authorities where you can view more information.

[block]
What is a CA?
A certificate authority is an entity that issues digital certificates. If a certificate has been issued by a trusted CA then the ownership of the public key can also be trusted. The CA is a trusted third party that is trusted by both client and server.
[/block]

After the client has verified the certificate the browser uses the servers public key to encrypt all the necessary details that the browser will send to the server. The client then sends back all the required data including a symmetric key. The server can decrypt this message using its private key and checks that an authentication message is correct and decrypts correctly. One final message is sent back from the server for the client to verify and the handshake is complete.

![Image](/images/640/64:33/up_8428da40297277edf8c1a2448cd72171)[/center] #Problems with SSL? Certificate authorities do not actually verify a domain or business before issuing a certificate. This can lead to a false sense of security when it comes to phishing sites. A victim can be tricked into accessing a phishing site and see that there is padlock symbol by the URL and assume that the site is safe. This has been overcome by EV (extended validation) certificates which require the CA to fully verify the organisation before issuing a certificate. These include checking government records and contacting the organisation to verify the person requesting the certificate is authorised to do so. A EV certificate usually is displayed as a green bar or text and more detailed information about the company. [center]![Image](/images/460/46:33/up_30e292de0d661f16cac081f88139003e)

Another concern is what happens when a CA is hacked. DigiNotar in 2011 had a serve security breach which resulted in a large number of fraudulently issued certificates. These certificates included domains of Yahoo, Mozilla, WordPress and Tor. As a browser is responsible for the list of verified authorities it is not easy to update this list when one authority can no longer be trusted. All major browsers issued security updates blacklisting DigiNotar’s root certificate.

An investigation into the hacking by Dutch-government appointed Fox-IT consultancy identified 300,000 Iranian Gmail users as the main target of the hack (targeted subsequently using man-in-the-middle attacks), and suspected that Iranian government was behind the hack.

Attacking SSL

SSLStrip

In a 2009 paper, Marlinspike introduced the concept of SSL stripping, a man-in-the-middle attack in which a network attacker could prevent a web browser from upgrading to an SSL connection in a subtle way that would likely go unnoticed by a user. He also announced the release of a tool, sslstrip, which would automatically perform these types of man in the middle attacks. The basic concept behind sslstrip is to proxy all SSL connections via a MITM attack. By intercepting and replacing all https:// references with http:// the attack will stop the victims browser from trying to create an SSL connection with the server. Then to keep the server happy it also intercepts any http:// connections the client makes that should have been https:// and performs the secure connection with the server, capturing all sensitive data at the same time.

How To: Use SSLstrip On A WiFi Pineapple

HTTP Strict Transport Security (HSTS) specification was subsequently developed to combat this attack. HSTS declares that complying user agents are to only use secure conections during a period of time. When a brwoser recieves this policy is automatically turns any insecure links into secure ones. Also if the security of the connection cannot be ensured and error message is presented and users are not allowed to connect. Deployment of HSTS however has been slow and SSL stripping is still widely used.

SSL Renegotiation Attack

A vulnerability was discovered in the SSL renegotiation procedure that allows an attacker to inject plaintext into the victim’s requests. For instance, it allows an attacker who can hijack an HTTPS connection to add their own requests to the conversation the client has with the web server. Note that the attacker cannot decrypt the client-server communication. The attack exploits TLS’s renegotiation feature, which allows a client and server who already have a TLS connection to negotiate new parameters, generate new keys, etc. Renegotiation is carried out in the existing TLS connection.

BEAST

Browser Exploit Against SSL/TLS Attack was revealed at the Ekoparty Security Conference in 2011. The attack is based on a “chosen plain text attack” which is a type of cryptographic attack. BEAST has three conditions that must be met for this attack to take place:
[list=1]
[] JavaScript or applet injection into the same origin of the web site
[
] Network sniffing of the connection must be possible
[*] A vulnerable version of SSL must be used which is using a block cipher
[/list]

In brief this attack allows the attacker to access HTTPOnly cookies that are being sent via SSL. TLS 1.0, when dealing with multiple packets, allows the following packets to use an IV that is the last cipher text block of the previous packet. Simply put, an active attacker will be able to gather the IVs for each record just by sniffing the network. So if the attacker can “guess” a plaintext message, he can make a guess at the session cookie and see if the cipher text matches.