Entries Tagged "TLS"

Page 2 of 2

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 AMView Comments

New RC4 Attack

This is a really clever attack on the RC4 encryption algorithm as used in TLS.

We have found a new attack against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted at a fixed location across many TLS sessions.

The attack is very specialized:

The attack is a multi-session attack, which means that we require a target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS sessions. The attack currently only targets the first 256 bytes of the plaintext stream in sessions. Since the first 36 bytes of plaintext are formed from an unpredictable Finished message when SHA-1 is the selected hashing algorithm in the TLS Record Protocol, these first 36 bytes cannot be recovered. This means that the attack can recover 220 bytes of TLS-encrypted plaintext.

The number of sessions needed to reliably recover these plaintext bytes is around 230, but already with only 224 sessions, certain bytes can be recovered reliably.

Is this a big deal? Yes and no. The attack requires the identical plaintext to be repeatedly encrypted. Normally, this would make for an impractical attack in the real world, but http messages often have stylized headers that are identical across a conversation—for example, cookies. On the other hand, those are the only bits that can be decrypted. Currently, this attack is pretty raw and unoptimized—so it’s likely to become faster and better.

There’s no reason to panic here. But let’s start to move away from RC4 to something like AES.

There are lots of press articles on the attack.

Posted on March 29, 2013 at 6:59 AMView Comments

Man-in-the-Middle Attack Against SSL 3.0/TLS 1.0

It’s the Browser Exploit Against SSL/TLS Tool, or BEAST:

The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target’s browser into the encrypted request stream to determine the shared key. The code can be injected into the user’s browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0­which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.

While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley’s David Wagner pointed out in a 1999 analysis of SSL 3.0 that “SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative.” And TLS’s vulnerability to man-in-the middle attacks was made public in 2009. The IETF’s TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.

Another article.

EDITED TO ADD: Good analysis.

Posted on September 23, 2011 at 1:37 PMView Comments

Firesheep

Firesheep is a new Firefox plugin that makes it easy for you to hijack other people’s social network connections. Basically, Facebook authenticates clients with cookies. If someone is using a public WiFi connection, the cookies are sniffable. Firesheep uses wincap to capture and display the authentication information for accounts it sees, allowing you to hijack the connection.

Slides from the Toorcon talk.

Protect yourself by forcing the authentication to happen over TLS. Or stop logging in to Facebook from public networks.

EDITED TO ADD (10/27): To protect against this attack, you have to encrypt the entire session—not just the initial authentication.

EDITED TO ADD (11/4): Foiling Firesheep.

EDITED TO ADD (11/10): More info.

EDITED TO ADD (11/17): Blacksheep detects Firesheep.

Posted on October 27, 2010 at 7:53 AMView Comments

NIST Hash Workshop Liveblogging (1)

I’m in Gaithersburg, MD, at the Cryptographic Hash Workshop hosted by NIST. I’m impressed by the turnout; a lot of the right people are here.

Xiaoyun Wang, the cryptographer who broke SHA-1, spoke about her latest results. They are the same results Adi Shamir presented in her name at Crypto this year: a time complexity of 263.

(I first wrote about Wang’s results here, and discussed their implications here. I wrote about results from Crypto here. Here are her two papers from Crypto: “Efficient Collision Search Attacks on SHA-0” and “Finding Collisions in the Full SHA-1 Collision Search Attacks on SHA1.”)

Steve Bellovin is now talking about the problems associated with upgrading hash functions. He and his coauthor Eric Rescorla looked at S/MIME, TLS, IPSec (and IKE), and DNSSEC. Basically, these protocols can’t change algorithms overnight; it has to happen gradually, over the course of years. So the protocols need some secure way to “switch hit”: to use both the new and old hash functions during the transition period. This requires some sort of signaling, which the protocols don’t do very well. (Bellovin’s and Rescorla’s paper is here.)

Posted on October 31, 2005 at 9:02 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.