How to determine your HTTPS is really secure

At this time when not even HTTPS is considered 100% secure, how do we determine we are going through a secure connection? How can we tell that our connection from point A to point B is not being eavesdropped by a man in the middle? Nowadays, regular and more IT inclined users must be equally aware of their dangers and how to mitigate it. With recent vulnerabilities such as FREAK and Heartbleed, how can we know the TLS/SSL security are not being downgraded after we click a link? Well, read on.

Definitions

So, how do we determine if a connection is secure/insecure? First of all: what is considered insecure? Well, we know that a secure HTTPS connection includes the SSL/TLS data encryption and authentication protocols. We also know that SSL (Secure Socket Layer) protocol is the predecessor of TLS (Transport Layer Security). We now know that SSL (even its last version 3.0) is really insecure from what we've seen in old and recent bugs and vulnerabilities such as POODLE, BEAST, Heartbleed and FREAK. We also knwo that TLS 1.2 is the most secure (yet) protocol that goes along HTTPS communications. But things are not easy as they might seem, even TLS v1.2 (if not properly configured) can also be a target for BEAST vulnerability attacks.

Determining Vunerability Vectors

Depending of the attack, bug of vulnerability, there are different and many ways of compromise a system but the vectors associated with them are to be accounted for. For example, if you're susceptible for a MiTM (Man-in-the-middle) attack, he can potentially downgrade your secure connection thus leaving your system unprotected from the beforementioned attacks. This is call "Downgrade Attack". Also, believe it or not

Plan of Action

In order to have a plan of action, it is very important to determine what products are installed in your computer(s).  By maintaining your browsers at the most minimum (is there a reason to have 3 different browsers on your computer?), it will simply mitigate risks. This is because we do not always remember to update our browser or simply if we think our Operating System is patched, our Browser(s) are too.

Check SSL/TLS in Chrome

Check SSL/TLS in Firefox

This is a common mistake for amateurs and rookies in the subject, but they must be aware of the risks and take action.  Also, by running OpenSSL and TestSSL utilities, we can determine what SSL/TLS ciphers are at risk for example RC4-MD5 or RC4-SHA.  Also, such protocols such as TLS 1.0 is not secure anymore and you should rely on 1.2 at least. By using these utilities, it will help you in knowing what should be changed in order to have a little more secure web application.

You have to be careful because if your web application uses the RC4 Cipher Suite, the connection might not be as secure as you might think.  The RC4 cipher is not a pseudo-random value that gets generated but the first 65 bytes can be decrypted in order to obtain passwords or cookie information stealing the session.  By having this "Invariance Weakness", it leads to an attack called Bar Mitzvah which can be used to steal your session information.

In the Bar Mitzvah attack, it only takes 65 bytes to decrypted data (after the handshake) stealing cookies or passwords.

The plan of action for RC4 is to totally deactivate it in order to mitigate these risks.

Sources

Definition of POODLE: https://isc.sans.edu/forums/diary/SSLv3+POODLE+Vulnerability+Official+Release/18827/

Definition of BEAST:  http://www.webopedia.com/TERM/S/ssl_beast.html

Definition of Heartbleed: http://heartbleed.com

Definition of FREAK: https://freakattack.com/

Downgrade Attack: https://www.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack#MITM%20TLS%20Protocol%20Downgrade%20Attack 

OpenSSL: https://www.openssl.org

TestSSL: https://testssl.sh

RC4 Vulnerability: http://securityaffairs.co/wordpress/35352/hacking/bar-mitzvah-attack-on-rc4.html