Note: Article has been updated since original submission January 30, 2015 for a college assignment. 

Everybody is listening.  Whether a person is talking on the phone while waiting in line, or someone is conversing with another sitting in a food court.  It is easy enough to see that anyone, purposely or not, can see and hear things that someone else does not want to be known.  All pla0 is based on SSL 3.0, and they vary little.  As stated in Request for Comments (RFC) 2246, “The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate,” (Dierks and Allen 4).  SSL 3.0 and TLS 1.2 (soon to be 1.3) are the most recent versions of the protocols which work together to secure information sent over the internet.

These protocols are layered upon other protocols, such as TCP (Transmission Control Protocol) and IP (Internet Protocol), to secure internet communications.  Before SSL and TLS, TCP/IP protocols and alike did not have a means of protecting information against unwanted users (Garfinkel and Spafford 107).  TCP and IP allow for the passing of information between applications but do not necessarily secure the connection.  SSL and TLS are mechanisms that are able to encrypt the information and the session between applications.  By using asymmetric and symmetric cryptography to encrypt the data between two applications, such as a client and server, SSL and TLS can maintain a safe session.  The first thing that occurs when a client is initiating a session with a server is a handshake.  A handshake is a greeting and a first welcome sign that acknowledges another’s existence (Garfinkel and Spafford 690).  In a SSL and TLS handshake, the handshake begins with the use of a ClientHello, which is a message containing the protocol version, a random string including a time stamp, a session id, a list of supported cipher suites, and a list of compression methods that the client supports (Garfinkel and Spafford 693).  The SSL/TLS server, upon receiving the ClientHello, will then respond with a handshake failure alert or a ServerHello message that contains similar things to the ClientHello, except the server will have chosen a cipher, which is an algorithm for encryption, and a compression method to use during the session (Garfinkel and Spafford 694).  The next possible steps are certificate exchanges and key exchanges between the server and the client.  This will be further discussed later on when discussing the weaknesses of SSL and TLS.  At the end of the handshake, the client and server send ChangeCipherSpec messages, which allows all following message to be encrypted according to the agreed-upon cipher suite and compression method.  TLS has further actions, such as a record protocol that transmits information called as records between applications.   A record has more information pertaining to the security such as the content type, data payload, and message authentication codes (MAC) (Garfinkel and Spafford 690).  In either case, with the use of SSL and TLS, messages are sent between applications, and the connection is protected.

Successful use of the SSL and TLS protocol provides authentication of the server and client through digital signatures, data confidentiality through the use of encryption, and data integrity through the use of message authentication codes (MAC).  SSL and TLS are highly extensible and adaptive with internet security.  Some internet applications that are protected are web emails, login credentials, and other stream related information.  Yet, because the protocols are so extensible and adaptive to other protocols such as TCP and HTTPS, there is uncharted ground that is not protected.  While SSL and TLS do support popular protocols, they do not work well with others, such as UDP (Viega, Chandra, and Messier 20).  Specifically, SSL does not have support for non-repudiation (need to use S/MIME), does not protect against buffer overflows, race conditions, protocol errors in the design or implementation in the application (Viega, Chandra, and Messier 21).  SSL, and ergo TLS have many openings for creating compromised security measures.

When SSL 3.0 was released, there were conflicting issues with the older version SSL 2.0.  For example, if one has not upgraded to the latest versions of SSL/TLS, it is possible to downgrade/pretend that SSL 2.0 is SSL 3.0.  Considering the SSL 2.0 had errors, security can be compromised with having SSL 3.0 look like SSL 2.0 (Freier, Karlton and Kocher 63).  It seems easy enough to fix this problem by configuring their browser to allow SSL 3.0 and TLS, but most people do not configure it to only allow the most recent versions.  Another issue associated with SSL is the certificate validation process.  During this process, the client extracts a public key from the certificate, and the server gets a private key used later for encryption of data through public key cryptography (Garfinkel and Spafford 693).  This is the only validation that happens during the connection between server and client.  It is possible to protect certificate validation through Certificate Authorities (CA), who are third-party negotiators that deal with proving the validity of certificates for servers, but deciding on which to trust is potentially a lot of work (Viega, Chandra, and Messier 17).  Certificates used as an authentication mechanism may prove to be faulty for SSL and TLS.  Adversaries could potentially get certificates representing other people that is not themselves.   CAs may make the mistake of believing someone is who they claim to be.  It becomes troublesome to deal with someone having a “fake” certificate, a certificate given to the wrong person.  A method that deals with stolen certificates is the creation of Certificate Revocation Lists (CRL), in which the CA reports bad certificates and numbers them, so that clients or servers can monitor their activity (Viega, Chandra, and Messier 16).  Yet, there are factors that delay this process.  An example of such could be a time delay of not noticing what has been stolen.  For a CA, it could potentially take time to update CRL, not including that the client has to download them.  The process of finding a potential certificate stealer becomes lengthy when a client must depend on a CA acting in real time (Viega, Chandra, and Messier 17).  Also, it is questionable if having CAs are substantial enough security for security.  They lack mobility, which is important with trying to protect information in a timely manner.  In addition, some clients or servers may fail to check the entirety of the contents of the certificate, and a potential attackers may be able to get credentials.  More often than not, people are unaware of what digital certificates they do have access to, since most digital certificates are hidden in the web browser.  It is a weak point that some attackers may prey upon.  They know what to look for in SSL/TLS protocols.

Associated with certificates are private keys.  These keys are later used to help encrypt data being sent over a connection between client and server (Viega, Chandra, and Messier 15).  The possible error with using keys along with certificates is that they may not be hidden on the server, specifically their hardware.  An attacker who has access to their hardware is able to extract the key if the key is unencrypted (Viega, Chandra, and Messier 16).  Even if the key were to be kept in memory of the system, it would have to remain unencrypted in order to allow for new connections to be made.  Again the attacker would be most likely able to access this information if they knew what they were doing.  In turn, SSL and TLS could fail to protect data because of weakly protected keys.

Since SSL and TLS attempt to defend data from attackers, it takes a lot of effort.  This effort could be seen as cost or consequence of the abilities of SSL.  Assuming one would like to exchange a vast amount of information back and forth between a client and server, it takes time.  SSL and is slower than TCP/IP transmissions because its main job is to encrypt and authenticate information over a connection.  One of the first steps when starting a session with SSL is handshaking.  The initial handshake is slow because it uses public key cryptography, which requires large keys, hence the computational math required to encrypt takes longer (Viega, Chandra, and Messier 12-14).   It is an issue when first doing this because TCP/IP is not secure on its own.  The earlier it is in an SSL/TLS session, the less secure it is likely to be.

With slow workings, faulty certificates, weak keys, these are possible reasons to have Man in the Middle Attacks.  Potentially, the failure of validating certificates may make for a potential Man In The Middle attack (MITM), where an eavesdropper puts himself in between the client and server, somehow accessing their session credentials and listen and put forth his own agenda during the connected session (Opplinger, Hauser, and Basin 54).  Generally, MITM attacks are when an attacker intercepts server or client messages by pretending to be the client or server by using a proxy connection and listens to the data exchanged between the applications.  There are many variations of possible compromised connections with the use of a MITM attack.  One example of such case is called a BEAST attack, or Browser Exploit Against SSL/TLS.  BEAST attacks assume that a possible attacker can see an encrypted session taking place between a client and server.  Hence, the attacker, if knowing what to look for, can also see the initialization vector used for encryption.  Initialization vectors are used to randomize plain text messages (information before being encrypted) before encryption during cipher block chaining, which is the encryption of data in blocks with each blocks’ encryption depending on the one before(Rohit).  If an attacker were to have IV information, they could use it to uncover what the original plaintext message was (Rohit).  BEAST attacks deal with finding multiple IVs to get the most information they can get by sniffing the network.  An attacker will know that the plaintext message with the known IV is correct by checking the session cookie and seeing if the ciphertext matches.  It seems relatively easy for attackers to use the BEAST, but one failure of BEAST is that it has to modify traffic over the connections used in the browser. Also, when checking the plaintext message with the IV, it is only possible to guess one block at a time due to the next block’s information is dependent on the one before it (Rohit).  Yet, it is important to note that SSL/TLS provides leeway with its encryption standards.  If the initialization vector of the cipher block chaining process can be exploited, it is reasonable to see that other parts of the encryption process could be seen as well.

Even though TLS is more recent, it has its vulnerabilities.  One of the key features of TLS is that when it encrypts data, it compresses it.  This is necessary in order to reduce bandwidth used during Internet sessions and latency requirements while maintaining the security features of TLS (Hollenbeck).  Possible attackers could force a browser to compress and encrypt requests with attacker controlled data.  It is known as Compression Ratio Info-leak Made Easy or a CRIME attack. Attackers find this method as another way to see information encrypted with SSL/TSL protocols. First, assuming that attackers are aware that an SSL/TSL connection is occurring, attackers are able to see cookie information.  Cookies are stored pieces of data saved from a client’s previous sessions with a server that provides information on the activity of their sessions (Goodin).  These cookies are available during SSL/TLS connections because they are located in the messages between clients and servers.  With the cookie information, it is possible to make attacker requests look like it belongs in the connection.  In a CRIME attack, an attacker is trying to compress their request into the client’s request.  Since there is no space for some of the request, it becomes lossless data (Goodin).  Basically extra, but not unnecessary.  The attacker uses this information to find out to see if what the client’s now lossless data matches the encrypted data the attacker cannot read matches.  If it the two sets of data match then it is successful information stealing.  TLS tries to maintain the effectiveness of the browser by compressing data, but it may give up some security points in the process.

Going along with the idea of compressing data as a method of weakness, BREACH attacks focus on using compressed data against clients.  BREACH stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext.  During a BREACH attack, clients are forced, without knowing, into using or visiting an attacker’s website (Leyden).  When a client visits/uses the website, bytes of data from the attacker are made to match the ones encrypted in the connection between the server and client.  The web browser notices that there is an excess amount of data and tries to compress it to reduce the size of the transmission.  Eventually, an attacker can compile bytes useful enough to create useful information, such as an email address, a security token, etc. (Leyden).  Attackers do not need to know much in order to use this technique.  They do not need to know the encryption algorithm or cipher.  Their only job is to continually listen to the traffic of client and server.  Knowing that a connection exists is enough for attackers to get what they want.  SSL and TLS cannot do much to stop people from watching traffic.

In some cases, connections over the internet have to be re-authenticated.  SSL and TLS are in an already existing state, and suddenly there may be a change on the client or server’s side where they must authenticate themselves.  This is known as renegotiation (Rohit).  Perhaps a user was buying something online and they made it to checkout, but want to use their account with the website, or the server has a timed out session with a client, which makes it necessary to sign in with their credentials again.  In an SSL/Renegotiation attack, an attacker inserts plaintext into a client’s request to a web server during renegotiation (Rohit).  The attacker’s plaintext is what they want, it is their own personal request (agenda).  The client will have seemed to be the one to put forth the request themselves, but really it is the attacker’s.  Renegotiation can be a fatal point depending on what the attacker requests, but there are limitations.  Attacks can only send their requests and not alter the requests of the client and server during this process.  Hence if an attacker wants something useful to them, they would make a request to make the HTTPS (Hypertext Transfer Protocol Secure) to an HTTP (Hypertext Transfer Protocol).  HTTP is responsible for being able to exchange or transfer hypertext (interactive text used for the Internet) (Goodin).  On its own, HTTP isn’t secured, HTTPS is able to use the attributes of SSL/TLS and protect hypertext (Goodin).  So, if during a renegotiation, an attacker’s request to change an HTTPS connection to an HTTP is made, the web browsing session is compromised.  It fails without it being directly the fault of SSL or TLS.

For conclusion, it is arguably to say that even with recent versions or capabilities of SSL/TLS, there are underlying security concerns.  The attacks mentioned, BREACH, CRIME, BEAST, are some to name a few that have recently been more pertinent in recent years.  Attackers focus their attention more on finding the tradeoffs that SSL/TLS give in order to secure a session.  It could be a slower encrypting time or perhaps compressing data in order to save bandwidth.  SSL and TLS cannot do it all.  Although it seems like a miracle cure, it is still in its early stages.   Nothing is ever truly secure.  People have to start understanding how their information, their interactions are secured over the internet.  If they begin to understand how attackers do what they do, maybe then will SSL/TLS be used to the best of its abilities.  In order truly to have a secure connection, SSL and TLS, along with the other protocols it works with, have to be improved to the point where everyone knows about them.

 

Works Cited

Dierks, T.,Allen, C.. “The TLS Protocol Version 1.0.” Request for Comments 2246 (1999): 9-10.

Freier, A., Karlton, P., Kocher P..  “The SSL Protocol Version 1.0.” Request for Comments 6101 (1996): 4-6. Print.

Garfinkel, Simson; Spafford, Gene. Web Security, Privacy & Commerce. Sebastopol: O’Reilly Media, 2001. Ebook Library. Web. 24 Jan. 2015.

Goodin, Dan. “Crack in Internet’s Foundation of Trust Allows HTTPS Session Hijacking.”Arstechica. Condé Nast, 13 Sept. 2012. Web. 26 Jan. 2015. <http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/>.

Hollenbeck, S.. “Transport Layer Security Protocol Compression Methods”. Request for Comments 3749 (2004): 1-4.

Leyden, John. “Step into the BREACH: HTTPS Encrypted Web Cracked in 30 Seconds.” • The Register. The Register, 2 Aug. 2013. Web. 26 Jan. 2015. <http://www.theregister.co.uk/2013/08/02/breach_crypto_attack/>.

Rohit, T. “SSL ATTACKS – InfoSec Institute.” InfoSec Institute. InfoSec Institute, 28 Oct. 2013. Web. 26 Jan. 2015. <http://resources.infosecinstitute.com/ssl-attacks/#disqus_thread>.

Oppliger, Rolf, Ralf Hauser, and David Basin. “Protecting Ecommerce Against The Man-In-The-Middle.” Business Communications Review 37.1 (2007): 54-58. Communication & Mass Media Complete. Web. 24 Jan. 2015.

Viega, John; Messier, Matt; Chandra, Pravir. Network Security with OpenSSL : Cryptography for Secure Communications. Sebastopol: O’Reilly Media, 2002. Ebook Library. Web. 24 Jan. 2015.