Entries Tagged "certificates"

Page 3 of 4

Forged SSL Certificates Pervasive on the Internet

About 0.2% of all SSL certificates are forged. This is the first time I’ve ever seen a number based on real data. News article:

Of 3.45 million real-world connections made to Facebook servers using the transport layer security (TLS) or secure sockets layer protocols, 6,845, or about 0.2 percent of them, were established using forged certificates.

Actual paper.

EDITED TO ADD (6/13): I’m mis-characterizing the study. The study really says that 0.2% of HTTPS traffic to Facebook is intercepted and re-signed, and the vast majority of that interception and resigning happens either on the user’s local computer (by way of trusted security software which is acting scanning proxy) or locally on a private network behind a corporation’s intercepting proxy/firewall. Only a small percentage of intercepted traffic is a result of malware or other nefarious activity.

Posted on May 16, 2014 at 6:43 AM • View Comments

Microsoft Retiring SHA-1 in 2016

I think this is a good move on Microsoft’s part:

Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016.

More news.

SHA-1 isn’t broken yet in a practical sense, but the algorithm is barely hanging on and attacks will only get worse. Migrating away from SHA-1 is the smart thing to do.

Posted on November 13, 2013 at 2:17 PM • View Comments

New NSA Leak Shows MITM Attacks Against Major Internet Services

The Brazilian television show “Fantastico” exposed an NSA training presentation that discusses how the agency runs man-in-the-middle attacks on the Internet. The point of the story was that the NSA engages in economic espionage against Petrobras, the Brazilian giant oil company, but I’m more interested in the tactical details.

The video on the webpage is long, and includes what I assume is a dramatization of an NSA classroom, but a few screen shots are important. The pages from the training presentation describe how the NSA’s MITM attack works:

However, in some cases GCHQ and the NSA appear to have taken a more aggressive and controversial route—on at least one occasion bypassing the need to approach Google directly by performing a man-in-the-middle attack to impersonate Google security certificates. One document published by Fantastico, apparently taken from an NSA presentation that also contains some GCHQ slides, describes “how the attack was done” to apparently snoop on SSL traffic. The document illustrates with a diagram how one of the agencies appears to have hacked into a target’s Internet router and covertly redirected targeted Google traffic using a fake security certificate so it could intercept the information in unencrypted format.

Documents from GCHQ’s “network exploitation” unit show that it operates a program called “FLYING PIG” that was started up in response to an increasing use of SSL encryption by email providers like Yahoo, Google, and Hotmail. The FLYING PIG system appears to allow it to identify information related to use of the anonymity browser Tor (it has the option to query “Tor events“) and also allows spies to collect information about specific SSL encryption certificates.

It’s that first link—also here—that shows the MITM attack against Google and its users.

Another screenshot implies is that the 2011 DigiNotar hack was either the work of the NSA, or exploited by the NSA.

Here’s another story on this.

Posted on September 13, 2013 at 6:23 AM • View Comments

VeriSign Hacked, Successfully and Repeatedly, in 2010

Reuters discovered the information:

The VeriSign attacks were revealed in a quarterly U.S. Securities and Exchange Commission filing in October that followed new guidelines on reporting security breaches to investors. It was the most striking disclosure to emerge in a review by Reuters of more than 2,000 documents mentioning breach risks since the SEC guidance was published.

The company, unsurprisingly, is saying nothing.

VeriSign declined multiple interview requests, and senior employees said privately that they had not been given any more details than were in the filing. One said it was impossible to tell if the breach was the result of a concerted effort by a national power, though that was a possibility. “It’s an ugly, slim sliver of facts. It’s not enough,” he said.

The problem for all of us, naturally, is if the certificate system was hacked, allowing the bad guys to forge certificates. (This has, of course, happened before.)

Are we finally ready to accept that the certificate system is completely broken?

Posted on February 3, 2012 at 10:49 AM • View Comments

The Security of SSL

EFF reports on the security of SSL:

The most interesting entry in that table is the “CA compromise” one, because those are incidents that could affect any or every secure web or email server on the Internet. In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 15 distinct CA organizations.

Posted on October 27, 2011 at 6:45 AM • View Comments

Tor Arms Race

Iran blocks Tor, and Tor releases a workaround on the same day.

How did the filter work technically? Tor tries to make its traffic look like a web browser talking to an https web server, but if you look carefully enough you can tell some differences. In this case, the characteristic of Tor’s SSL handshake they looked at was the expiry time for our SSL session certificates: we rotate the session certificates every two hours, whereas normal SSL certificates you get from a certificate authority typically last a year or more. The fix was to simply write a larger expiration time on the certificates, so our certs have more plausible expiry times.

Posted on September 26, 2011 at 6:41 AM • View Comments

Forged Google Certificate

There’s been a forged Google certificate out in the wild for the past month and a half. Whoever has it—evidence points to the Iranian government—can, if they’re in the right place, launch man-in-the-middle attacks against Gmail users and read their mail. This isn’t Google’s mistake; the certificate was issued by a Dutch CA that has nothing to do with Google.

This attack illustrates one of the many security problems with SSL: there are too many single points of trust.

EDITED TO ADD (9/1): It seems that 200 forged certificates were generated, not just for Google.

EDITED TO ADD (9/14): More news.

Posted on September 1, 2011 at 5:46 AM • View Comments

Comodo Group Issues Bogus SSL Certificates

This isn’t good:

The hacker, whose March 15 attack was traced to an IP address in Iran, compromised a partner account at the respected certificate authority Comodo Group, which he used to request eight SSL certificates for six domains: mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org and login.live.com.

The certificates would have allowed the attacker to craft fake pages that would have been accepted by browsers as the legitimate websites. The certificates would have been most useful as part of an attack that redirected traffic intended for Skype, Google and Yahoo to a machine under the attacker’s control. Such an attack can range from small-scale Wi-Fi spoofing at a coffee shop all the way to global hijacking of internet routes.

At a minimum, the attacker would then be able to steal login credentials from anyone who entered a username and password into the fake page, or perform a “man in the middle” attack to eavesdrop on the user’s session.

More news articles. Comodo announcement.

Fake certs for Google, Yahoo, and Skype? Wow.

This isn’t the first time Comodo has screwed up with certificates. The safest thing for us users to do would be to remove the Comodo root certificate from our browsers so that none of their certificates work, but we don’t have the capability to do that. The browser companies—Microsoft, Mozilla, Opera, etc.—could do that, but my guess is they won’t. The economic incentives don’t work properly. Comodo is likely to sue any browser company that takes this sort of action, and Comodo’s customers might as well. So it’s smarter for the browser companies to just ignore the issue and pass the problem to us users.

Posted on March 31, 2011 at 7:00 AM • View Comments

The Legality of the Certificate Authority Trust Model

Interesting research:

We looked at the standard legal documents issued by the certificate authorities or “CAs,” including exemplar Subscriber Agreements (agreements between CAs and website operators); “Certification Practice Statements” (statements by CAs outlining their business practices); and Relying Party Agreements (purported agreements between CAs and “relying parties,” such as end-users). What we found was surprising:

  • “Relying Party Agreements” purport to bind end-users to their terms despite the apparent absence of any mechanism to either affirmatively alert the end-user as to the existence of the supposed Agreements or afford the end-user an opportunity to register his or her acceptance or rejection of the Agreements’ terms
  • Certification Practice Statements that suffer from the same problem (i.e. no affirmative notice to the end-user and no meaningful opportunity for acceptance or rejection of terms)

There were other issues as well. For example, the Relying Party Agreements and Certification Practice Statements set forth various obligations on the part of end-users (i.e. “relying parties”) such as: the requirement that end-users make an independent determination of whether it is reasonable to trust a website offering a secure connection (isn’t that the whole point of having a CA, so that the end-user doesn’t have to do that?); the requirement that the end-user be familiar with the crypto software and processes used to carry out the authentication process; and the end-user’s duty to indemnify and hold harmless the CA in the event of legal claims by third parties.

Paper here.

EDITED TO ADD (2/10)> Matt Blaze on CAs.

Posted on January 21, 2011 at 5:31 AM • View Comments

1 2 3 4

Sidebar photo of Bruce Schneier by Joe MacInnis.