Firefox ready to block certificate authority that threatened Web security

Enlarge

The organization that develops Firefox has recommended the browser block digital credentials issued by a China-based certificate authority for 12 months after discovering it cut corners that undermine the entire transport layer security system that encrypts and authenticates websites.

The browser-trusted WoSign authority intentionally back-dated certificates it has issued over the past nine months to avoid an industry-mandated ban on the use of the SHA-1 hashing algorithm, Mozilla officials charged in a report published Monday. SHA-1-based signatures were barred at the beginning of the year because of industry consensus they are unacceptably susceptible to cryptographic collision attacks that can create counterfeit credentials. To satisfy customers who experienced difficulty retiring the old hashing function, WoSign continued to use it anyway and concealed the use by dating certificates prior to the first of this year, Mozilla officials said. They also accused WoSign of improperly concealing its acquisition of Israeli certificate authority StartCom, which was used to issue at least one of the improperly issued certificates.

"Taking into account all the issues listed above, Mozilla's CA team has lost confidence in the ability of WoSign/StartCom to faithfully and competently discharge the functions of a CA," Monday's report stated. "Therefore we propose that, starting on a date to be determined in the near future, Mozilla products will no longer trust newly issued certificates issued by either of these two CA brands."

Read 10 remaining paragraphs | Comments

HTTPS and OpenVPN face new attack that can decrypt secret cookies

Enlarge / From an upcoming paper laying out a new attack against 64-bit block ciphers used by HTTPS and OpenVPN. (credit: Karthikeyan Bhargavan and Gaëtan Leurent)

Researchers have devised a new attack that can decrypt secret session cookies from about 1 percent of the Internet's HTTPS traffic and could affect about 600 of the Internet's most visited sites, including nasdaq.com, walmart.com, match.com, and ebay.in.

The attack isn't particularly easy to carry out because it requires an attacker to have the ability to monitor traffic passing between the end user and one of the vulnerable websites and to also control JavaScript on a webpage loaded by the user's browser. The latter must be done either by actively manipulating an HTTP response on the wire or by hosting a malicious website that the user is tricked into visiting. The JavaScript then spends the next 38 hours collecting about 785GB worth of data to decrypt the cookie, which allows the attacker to log into the visitor's account from another browser. A related attack against OpenVPN requires 18 hours and 705GB of data to recover a 16-byte authentication token.

Impractical no more

Despite the difficulty in carrying out the attack, the researchers said it works in their laboratory and should be taken seriously. They are calling on developers to stop using legacy 64-bit block-ciphers. For transport layer security, the protocol websites use to create encrypted HTTPS connections, that means disabling the Triple DES symmetric key cipher, while for OpenVPN it requires retiring a symmetric key cipher known as Blowfish. Ciphers with larger block sizes, such as AES, are immune to the attack.

Read 7 remaining paragraphs | Comments

New attack steals SSNs, e-mail addresses, and more from HTTPS pages

Enlarge / A demo planned for Wednesday will show how an ad hosted on nytimes.com could attack other HTTPS-protected sites. (credit: Vanhoef, Van Goethem)

The HTTPS cryptographic scheme protecting millions of websites is vulnerable to a newly revived attack that exposes encrypted e-mail addresses, social security numbers, and other sensitive data even when attackers don't have the ability to monitor a targeted end user's Internet connection.

The exploit is notable because it doesn't require a man-in-the-middle position. Instead, an end user need only encounter an innocuous-looking JavaScript file hidden in an Web advertisement or hosted directly on a webpage. The malicious code can then query a variety of pages protected by the secure sockets layer or transport layer security protocols and measure the precise file sizes of the encrypted data they transmit. As its name suggests, the HEIST technique—short for HTTP Encrypted Information can be Stolen Through TCP-Windows—works by exploiting the way HTTPS responses are delivered over the transmission control protocol, one of the Internet's most basic building blocks.

Once attackers know the size of an encrypted response, they are free to use one of two previously devised exploits to ferret out the plaintext contained inside it. Both the BREACH and the CRIME exploits are able to decrypt payloads by manipulating the file compression that sites use to make pages load more quickly. HEIST will be demonstrated for the first time on Wednesday at the Black Hat security conference in Las Vegas.

Read 12 remaining paragraphs | Comments

HTTPS is not a magic bullet for Web security

People seem Grover-levels of excitement about some "S" sweeping the Web.

We're in the midst of a major change sweeping the Web: the familiar HTTP prefix is rapidly being replaced by HTTPS. That extra "S" in an HTTPS URL means your connection is secure and that it's much harder for anyone else to see what you're doing. And on today's Web, everyone wants to see what you're doing.

HTTPS has been around nearly as long as the Web, but it has been primarily used by sites that handle money—your bank's website, shopping carts, social networks, and webmail services like Gmail. But these days Google, Mozilla, the EFF, and others want every website to adopt HTTPS. The push for HTTPS everywhere is about to get a big boost from Mozilla and Google when both companies' Web browsers begin to actively call out sites that still use HTTP.

The plan is for browsers to start labeling HTTP connections as insecure. In other words, instead of the green lock icon that indicates a connection is secure today, there will be a red icon to indicate when a connection is insecure. Eventually secure connections would not be labeled at all, they would be the assumed default.

Read 46 remaining paragraphs | Comments