Update, 19th October. I was recently contacted indirectly by Eddy Nigg of StartCom, who points out, quite rightly, that this issue is not specific to StartCom, nor a problem created by StartCom. He commented further in a comment to Dan Raywood's article for SC Magazine arising from this blog entry, and I think it's only fair to quote it in full. In fact, I'm delighted that Eddy has elected to provide this reassurance about StartCom's security model.

"StartCom makes a 100% effort to prevent any misuse for all certificates (paid and free), I believe the success rate is pretty good as well. Obviously any CA may fail to completely prevent misuse in some form or the other and at some point. But I don’t think this depends on the amount a subscriber paid for the certificate. StartCom is very committed to provide the best services and security in the appropriate level to the Internet community, I hope for the benefit of all."

Here's another item from Sebastián Bortnik, my colleague at ESET Latin America, translated from his blog at http://blogs.eset-la.com/laboratorio/2009/10/02/mito-https.

One of the tips we frequently see given regarding phishing (and other related Internet attacks) is the importance of checking in the address bar for the presence of the HTTPS protocol to access web sites where you enter personal information.

Although this advice still holds true, it is very frequently misinterpreted as meaning that "whenever a site has HTPPS, it's safe."

Without going into too much detail, HTTPS (HyperText Transfer Protocol Secure) is intended to ensure that the information transmitted from a user's computer to a remote website is encrypted during transmission. An analogy might be that if you were sending a letter, the protocol would be like a sealed envelope that guarantees that the contents can't be read by anyone until it reaches the recipient.

However, once information reaches the web server, it is no longer encrypted. Therefore, if the server belongs to an attacker rather than the legitimate individual or organization you think you're sending information to, it's easy for him to read this information. For various reasons, malicious web servers have generally had to work directly with the HTTP protocol, where information in transit is not encrypted. This is why the advice is so commonly given to check which protocol is being used. However, while it doesn't commonly happen, an attacker can use the HTTPS protocol on a false (spoofed) or malicious website. To return to our postal analogy, it doesn't matter if the envelope keeps the letter's contents secret in transit if the person who eventually receives it has malicious intentions, because there's nothing to stop them opening the envelope.

Further to this idea, many people will have read the news this week that Internet Explorer is to support free certificates [http://www.h-online.com/security/Internet-Explorer-supports-free-certificates--/news/114332]. The article explains that  StartCom (a company that provides SSL certificates for free) has been added as a valid certifying authority to the Internet Explorer browser. As The H (a major source of security information in Europe) explains, StartCom certificates are now pre-installed as root certificates in Microsoft's operating system, so that Internet Explorer now accepts StartCom certificates  "without prompting the user or requiring any special configurations for the certificates. Third-party programs that use the operating system's certificate memory will also accept the certificates without asking further questions."

One of the main reasons that attackers don't purchase SSL certificates has, historically, been its cost (and the need to provide information when applying to buy them). The opportunity of getting certificates for free provides a significant potential opportunity for attackers. They can now register a domain, create an email account and set up malicious servers to work with the HTTPS protocol (and a valid certificate). Thus, if potential victims see the all-important letter "S" (httpS), and this persuades them that the web site is safe, this will provide attackers with a great opportunity to commit some form of malicious act.

Reading the Startcom post in which the news was announced [https://blog.startcom.org/?p=205], it is important to mention that other browsers (like Google Chrome or Firefox - see picture) already accept Startcome's free certificates from the company.

 

Although we've specifically considered the possibility that an attacker might install a server with HTTPS legitimately, it's worth mentioning that other attack vectors have existed previously that simulate the existence of a secure protocol: consider, for instance, the research work carried by Moxie Marlinspike (Null Attacks Against Prefix SSL Certificates [http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf]).

In summary:

- "When you access a site that presents a form where you enter personal information, you should verify that it uses the HTTPS protocol" -> TRUE
- "A place where you enter sensitive information and that does not have HTTPS is not safe" -> TRUE
- "Using the HTTPS protocol, information is transmitted encrypted" -> TRUE
- "Whenever a site has HTTPS, it can be considered safe" -> FALSE

Certainly you should verify that sites where you are expected to enter sensitive information use a secure protocol to preserve confidentiality.  However, the existence of a safe protocol certainly doesn't prove that you are connected to a safe, non-malicious website.

Sebastián Bortnik
Security Analyst
ESET Latin-America

David Harley
Director of Malware Intelligence
ESET LLC