Tag Archives: secure sockets layer

“Lucky Thirteen” attack snarfs cookies protected by SSL encryption

A representation of how TLS works.

Software developers are racing to patch a recently discovered vulnerability that allows attackers to recover the plaintext of authentication cookies and other encrypted data as they travel over the Internet and other unsecured networks.

The discovery is significant because in many cases it makes it possible for attackers to completely subvert the protection provided by the secure sockets layer and transport layer protocols. Together, SSL, TLS, and a close TLS relative known as Datagram Transport Layer Security are the sole cryptographic means for websites to prove their authenticity and to encrypt data as it travels between end users and Web servers. The so-called “Lucky Thirteen” attacks devised by computer scientists to exploit the weaknesses work against virtually all open-source TLS implementations, and possibly implementations supported by Apple, Microsoft, and Cisco Systems as well.

The attacks are extremely complex, so for the time being, average end users are probably more susceptible to attacks that use phishing e-mails or rely on fraudulently issued digital certificates to defeat the Web encryption protection. Nonetheless, the success of the cryptographers’ exploits—including the full plaintext recovery of data protected by the widely used OpenSSL implementation—has clearly gotten the attention of the developers who maintain those programs. Already, the Opera browser and PolarSSL have been patched to plug the hole, and developers for OpenSSL, NSS, and CyaSSL are expected to issue updates soon.

Read 12 remaining paragraphs | Comments

Firefox gets strict about enforcement of HTTPS protection

Developers of Mozilla’s Firefox browser are experimenting with a new security feature that connects to a specified set of websites only when presented with a cryptographic certificate validating the connection is secure.

A beta version of the open-source browser contains a list of sites known to deploy the HTTP Strict Transport Security mechanism that requires a browser to use the secure sockets layer or transport layer security protocols when communicating. HSTS is designed to provide an additional layer of security by mandating the channel is encrypted and the server has been authenticated using strong cryptography.

But there’s a chicken-and-egg problem with HSTS. “Man-in-the-middle” attackers, who are positioned in between a browser and website, have the ability to prevent browsers from receiving the server code that enforces the additional protection. That makes it possible for HSTS to be circumvented by the very types of people the measure is designed to thwart.

Read 3 remaining paragraphs | Comments



Phony certificates fool faulty crypto in apps from AIM, Chase, and more

Enlarge / A simplified SSL handshake.

Researchers have uncovered defects in a wide range of applications running on computers, smartphones, and Web servers that could make them susceptible to attacks exposing passwords, credit card numbers, and other sensitive data.

The Trillian and AIM instant messaging apps and an Android app offered by Chase Bank are three apps identified as vulnerable to so-called man-in-the-middle attacks. Like the other dozen or so applications identified, the threat stemmed from weak implementations of the secure sockets layer and transport layer security protocols. Together, the technologies are designed to guarantee the confidentiality and authenticity of communications between end users and servers connected over the Internet.

The weak implementations caused the programs to initiate encrypted communications without first assessing the validity of the digital certificates on the other end. As a result, one of the fundamental guarantees of the SSL—that the computer on the other end of the connection belongs to the party claiming ownership—was fundamentally compromised. Instead, the apps will trust imposter certificates that are signed by attackers or fail established validity tests for a variety of other reasons.

Read 12 remaining paragraphs | Comments



Many ways to break SSL with CRIME attacks, experts warn

A hexadecimal representation of a compressed POST Web request. By changing characters in attacker-controlled data and comparing the different sizes of the compressed request that results, hackers can figure out the encrypted values of authentication cookies.

Security professionals are recommending that operators of websites offering the secure hypertext transfer protocol (HTTPS) disable a bandwidth-saving compression feature to prevent a recently disclosed attack that permits the hijacking of encrypted browsing sessions.

As previously reported by Ars, browsers from Microsoft, Google, Mozilla, Apple, and Opera aren’t vulnerable to the exploit dubbed CRIME, which is short for Compression Ratio Info-leak Made Easy. But until recently both Chrome and Firefox users were susceptible to attacks that allowed hackers to decrypt secure cookies used to log in to e-mail and online bank accounts. Given the number of smaller browsers in use, or the possibility some end users may be using out-of-date software, website operators may want to proactively disable compression used during sessions protected by the SSL, or secure sockets layer, protocol.

“It’s clear that there are an uncountable number of ways to exploit the vulnerability if it is present,” researchers for security firm iSEC Partners wrote in a recent blog post. “Rather than trying to block individual avenues to exploitation—which is likely impossible—we recommend you mitigate the issue at the source by disabling SSL Compression (and SPDY Compression is used.)”

Read 3 remaining paragraphs | Comments



"Flame" malware was signed by rogue Microsoft certificate

Microsoft has pushed out a new patch for Windows.

Microsoft released an emergency Windows update on Sunday after revealing that one of its trusted digital signatures was being abused to certify the validity of the Flame malware that has infected computers in Iran and other Middle Eastern Countries.

The compromise exploited weaknesses in Terminal Server, a service many enterprises use to provide remote access to end-user computers. By targeting an undisclosed encryption algorithm Microsoft used to issue licenses for the service, attackers were able to create rogue intermediate certificate authorities that contained the imprimatur of Microsoft’s own root authority certificate—an extremely sensitive cryptographic seal. Rogue intermediate certificate authorities that contained the stamp were then able to trick administrators and end users into trusting various Flame components by falsely certifying they were produced by Microsoft.

“We have discovered through our analysis that some components of the malware have been signed by certificates that allow software to appear as if it was produced by Microsoft,” Microsoft Security Response Center Senior Director Mike Reavey wrote in a blog post published Sunday night. “We identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft. Specifically, our Terminal Server Licensing Service, which allowed customers to authorize Remote Desktop services in their enterprise, used that older algorithm and provided certificates with the ability to sign code, thus permitting code to be signed as if it came from Microsoft.”

Read more | Comments