31 comments
Ioan B. • It is more than 2 years since I heard about "Man in the Middle Attack" and at that time it was demonstrated. But... improvements came after that: on the server side by using a version of Apache greater than 2.2.15(if i remember correctly), these attacks were no longer possible! I guess on the Web Browser also there was a fix already... So don't worry about that attack, search for something new kind of attacks.
Software is evolving, so if there is a known security hole, there will be someone to fill it!
Software is evolving, so if there is a known security hole, there will be someone to fill it!
Nurul Haszeli • HTTPS / SSL is no longer safe from hackers... You might want to check papers produce by Fazli Mat Nor
Alessandro Parisi • Nurul, if you mean "Man in the Browser Attacks", that's exactly what I'm suggesting here:
the problem has nothing to do with SSL/HTTPS in itself, but with the applications (browsers) that make (unsafe) use of it;
the weakest links of the chain are human factor and browsers...
the problem has nothing to do with SSL/HTTPS in itself, but with the applications (browsers) that make (unsafe) use of it;
the weakest links of the chain are human factor and browsers...
Nurul Haszeli • @Alessandro - agreed with you if it is because of the browsers, but, if I'm not mistaken, few people in Havard University proved that they can brake the SSL using MIM attack + sniffing.
Nurul Haszeli • by the way, their research is using OpenSSL
Mark Currie • @Nurul – I had a look at some of Fazli Mat Nor's work -.pretty good. However it is mainly based around the Man-in-The-Browser (MiTB) attack. As Alessandro says, MiTB is not an attack on HTTPS. It is an attack on the integrity of a user's platform (virus/Trojan). It operates at the application layer independent of any network security layer.
Fazli Mat Nor is correct that MiTB has to be counteracted with hardware security but I am not sure if I agree with his solution (uses the TPM). The online banking problem is more about trusted user interfaces rather than a trusted platform. You can look at my paper on this (google "In-the-wire authentication")
@loan B – The only MiTM attacks that I know about with regard to HTTPS are either when a user ignores warnings about bad certificates, or a fake certificate from a compromised CA is used. In both these cases HTTPS cannot really be blamed. The fake CA cert will affect any PKI system.
@Nurul - If you find any info on the Harvard attack please let us know, but this is probably just an implementation problem rather than a problem with SSL/TLS itself.
Fazli Mat Nor is correct that MiTB has to be counteracted with hardware security but I am not sure if I agree with his solution (uses the TPM). The online banking problem is more about trusted user interfaces rather than a trusted platform. You can look at my paper on this (google "In-the-wire authentication")
@loan B – The only MiTM attacks that I know about with regard to HTTPS are either when a user ignores warnings about bad certificates, or a fake certificate from a compromised CA is used. In both these cases HTTPS cannot really be blamed. The fake CA cert will affect any PKI system.
@Nurul - If you find any info on the Harvard attack please let us know, but this is probably just an implementation problem rather than a problem with SSL/TLS itself.
Alessandro Parisi • @Nurul; quite easy experiment to do, indeed, that I'm used to demonstrating in my security courses, too ;-)
for sure your colleagues at University used a mix of these tools, in order to exploit MIM, even in HTTPS/SSL scenario:
Ettercap, or ArpSpoof + DNSSpoof;
you also need to inject a spoofed X.501 certificate, or exploit a browser vuln, in order to prevent browser's warnings:
check out this post from Securiteam, old but still explicative conceptually:
http://www.securiteam.com/securitynews/5EP0L1PDFG.html
Please note: exploits techniques evolve on daily basis, as new vulnerabilities are discovered, but exploits concepts/approaches remain almost always the same;
As you can see, there is really no need to break SSL protocol (and OpenSSL is with no doubt an excellent implementation of cryptography algos), that remains reliable;
the weakest links are human factor, browsers, DNS, ARP, javascript, XSS, etc...
I mean, the internet was not designed with security in mind, so HTTPS/SSL is a way to overcome INTERNET'S security issues;
SSL is far from perfect, but has proved to be a reliable and viable solution during the years...
of course, SSL cannot substitute user's awareness...
for sure your colleagues at University used a mix of these tools, in order to exploit MIM, even in HTTPS/SSL scenario:
Ettercap, or ArpSpoof + DNSSpoof;
you also need to inject a spoofed X.501 certificate, or exploit a browser vuln, in order to prevent browser's warnings:
check out this post from Securiteam, old but still explicative conceptually:
http://www.securiteam.com/securitynews/5EP0L1PDFG.html
Please note: exploits techniques evolve on daily basis, as new vulnerabilities are discovered, but exploits concepts/approaches remain almost always the same;
As you can see, there is really no need to break SSL protocol (and OpenSSL is with no doubt an excellent implementation of cryptography algos), that remains reliable;
the weakest links are human factor, browsers, DNS, ARP, javascript, XSS, etc...
I mean, the internet was not designed with security in mind, so HTTPS/SSL is a way to overcome INTERNET'S security issues;
SSL is far from perfect, but has proved to be a reliable and viable solution during the years...
of course, SSL cannot substitute user's awareness...
Ismail Kaleem • just curious.. there are many firewalls which do ssl inspection.. if they can do ssl inspection? then it shud be possible to intercept as well. if u can hack the firewall or the router, then u can obviously make a box and become yourself as the gateway and without any arp poisoning still just sniff all the data. i've tried sslstrip on a pfsense box. i had a look at forefront TMG.
"HTTPS inspection allows the TMG firewall to terminate outbound HTTPS sessions at the firewall. Essentially it provides a true proxy for HTTPS, instead of simply just tunneling HTTPS communication blindly. TMG accomplishes this by acting as a trusted man-in-the-middle. When a request is made of the TMG firewall for an HTTPS protected resource, the TMG firewall will establish a new connection to the destination server and retrieve its SSL certificate. TMG then copies the information from the certificate and creates its own certificate using these details and provides that to the client. As long as the client trusts the root certificate of the TMG firewall (more details on that later) the process is completely transparent to the end user."
if it is so? then isn't it possible to just sniff ssl with a root certificate in the firewall which client trusts? O.o
"HTTPS inspection allows the TMG firewall to terminate outbound HTTPS sessions at the firewall. Essentially it provides a true proxy for HTTPS, instead of simply just tunneling HTTPS communication blindly. TMG accomplishes this by acting as a trusted man-in-the-middle. When a request is made of the TMG firewall for an HTTPS protected resource, the TMG firewall will establish a new connection to the destination server and retrieve its SSL certificate. TMG then copies the information from the certificate and creates its own certificate using these details and provides that to the client. As long as the client trusts the root certificate of the TMG firewall (more details on that later) the process is completely transparent to the end user."
if it is so? then isn't it possible to just sniff ssl with a root certificate in the firewall which client trusts? O.o
Mark Currie • @Ismail - A legitimate HTTPS proxy gateway requires the user's browser to be re-configured. The user also has to install its certificate, or else the gateway must possess a valid root certificate that the user's browser already has in order to sign its own cert.
In organisations where these are used, I assume that user's are informed about them so that they are made aware that any personal secure sessions are not private. If they tried to connect with their own laptop it would not work since the browser needs to be reconfigured (so the user will know about it).
So if a HTTPS gateway is hacked then it's just like hacking a legitimate web server. This is not breaking HTTPS. This is not really any different from the MiTB argument I made above.
In organisations where these are used, I assume that user's are informed about them so that they are made aware that any personal secure sessions are not private. If they tried to connect with their own laptop it would not work since the browser needs to be reconfigured (so the user will know about it).
So if a HTTPS gateway is hacked then it's just like hacking a legitimate web server. This is not breaking HTTPS. This is not really any different from the MiTB argument I made above.
Nurul Haszeli • @Mark and @Alessandro - Thanks for sharing me the information and yes, I do agreed that SSL issue is more of implementation.
1
1
2You can easily set up a man in the middle attack to circumvent https for example. This is one of the reasons you shouldn't rely on https keeping your data secure when using a public WiFi network.
Johan
2
1Yes. For example, I've done a man in the middle attack that could easily be implemented in a place like Starbucks to intercept banking (or any other SSL encrypted info).
Disclaimer: this was part of a demonstration, with permission, and fully legal.
Johan.
2
1Have a look at some of the security issues, both older versions and current ones:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Security
One quote: "As of March 2013, an estimated 65.7% of web sites were supporting protocol variants vulnerable to the BEAST attack, 30.0% vulnerable to the CRIME attack, and 34.2% with insecure ciphers."
Johan.
If you are using it to protect highly secret stuff then you should know what you are doing and force the use of the latest versions at both ends as well as forcing the use of a strong cipher suite. In this scenario HTTPS is probably as strong as any other crypto protocol.
If you are using it in relatively lower security applications, then the weaknesses pointed out in this discussion are often not an issue because they are not worth the attack effort. These attacks generally require special circumstances and often many, many, sessions before they become practical. Even if successful, the attack might not actually be significant in your application.
WRT people ignoring warnings about bad certificates, etc. - It is the browser that is allowing the user a choice of connecting to a dodgy website, and the user for ignoring the warnings. This cannot really be blamed on HTTPS.
Of course there is always going to be bad implementations, bad configurations etc. I blame these mainly on service providers who are not responsible enough with their user’s security, not on HTTPS.
2
1http://www.schneier.com/paper-ssl-revised.pdf
SSL/TLS has withstood the test of time (the greatest test of any cryptosystem). No other crypto protocol has been subjected to anywhere near the same amount of scrutiny and attack. Warts and all, it is the Godzilla of all crypto protocols.
Probably the most popular cipher suite - TLS_RSA_WITH_RC4_128_SHA (not affected by “Beast” and “Crime”) has protected very many online bank accounts for nearly 2 decades. Regardless of the weaknesses in RC4, there has still been no reported attack where money was stolen due to its breaking. In fact, even if an attack was able to reveal the plaintext, the attacker could still not steal your money because the HMAC prevents modification.
IMHO it is better to fix HTTPS whenever a weakness is revealed and move on rather than introduce a completely new protocol as this would put us right back to the beginning e.g. unproven.
my post was precisely intended to show that even if HTTPS has some (minor) issues, they can be easily managed, as Bruce Schneier, a guru of cryptography, clearly explains in the paper.
From my point of view, apart from human factors, the real problem involves back compatibility constraints, due to the fact that not all browsers implement SSL/HTTPS correctly/completely, nor even care to take advantage of newer security features exposed by the protocol, as soon as they become available.