How To Crack SSL-TLS


Our intent is to properly explain SSL-TLS and point out the weaknesses within the Protocol(s).

How To Crack SSL-TLS in summary:

  • Try if the user ignores certificate warnings;
  • The application may load data from an unencrypted channel (e.g. http), which can be tampered with;
  • An unprotected login page that submits to HTTPS may be modified so that it submits to HTTP;
  • Unpatched applications may be vulnerable for exploits like BEAST and CRIME;
  • Resort to other methods such as a physical attack.

See also: A scheme with many attack vectors against SSL by Ivan Ristic (png)

In detail:#

There is no simple and straight-forward way; SSL/TLS is secure when done correctly. An attacker can try if the user ignores certificate warnings though, which would break the security instantly. When a user does this, the attacker doesn't need a private key from a CA to forge a certificate, he merely has to send a certificate of his own.

Another way would be by a flaw in the application (server- or client-side). An easy example is in websites: if one of the resources used by the website (such as an image or a script) is loaded over HTTP, the confidentiality cannot be guaranteed anymore. Even though browsers do not send the HTTP Referer header when requesting non-secure resources from a secure page (source), it is still possible for someone eavesdropping on traffic to guess where you're visiting from; for example, if they know images X, Y, and Z are used on one page, they can guess you are visiting that page when they see your browser request those three images at once. Additionally, when loading Javascript, the entire page can be compromised. An attacker can execute any script on the page, modifying for example to whom the bank transaction will go.

When this happens (a resource being loaded over HTTP), the browser gives a mixed-content warning: Chrome, Firefox, Internet Explorer 9

Another trick for HTTP is when the login page is not secured, and it submits to an https page. "Great," the developer probably thought, "now I save server load and the password is still sent encrypted!" The problem is sslstrip, a tool that modifies the insecure login page so that it submits somewhere so that the attacker can read it.

There have also been various attacks in the past few years, such as the TLS renegotiation vulnerability, sslsniff, BEAST, and very recently, CRIME. All common browsers are protected against all of these attacks though, so these vulnerabilities are no risk if you are running an up-to-date browser.

Last but not least, you can resort to other methods to obtain the info that SSL denies you to obtain. If you can already see and tamper with the user's connection, it might not be that hard to replace one of his/her .exe downloads with a keylogger, or simply to physically attack that person. Cryptography may be rather secure, but humans and human error is still a weak factor. According to this paper by Verizon, 10% of the data Breaches involved physical attacks (see page 3), so it's certainly something to keep in mind.

More Information#

There might be more information for this subject on one of the following: