Tor and the BEAST SSL attack

by nickm | September 24, 2011

Today, Juliano Rizzo and Thai Duong presented a new attack on TLS <= 1.0 at the Ekoparty security conference in Buenos Aires. Let's talk about how it works, and how it relates to the Tor protocol.

Short version: Don't panic. The Tor software itself is just fine, and the free-software browser vendors look like they're responding well and quickly. I'll be talking about why Tor is fine; I'll bet that the TBB folks will have more to say about browsers sometime soon.

There is some discussion of the attack and responses to it out there already, written by seriously smart cryptographers and high-test browser security people. But I haven't seen anything out there yet that tries to explain what's going on for people who don't know TLS internals and CBC basics.

So I'll do my best. This blog post also assumes that I understand the attack. Please bear with me if I'm wrong about that.

Thanks to the authors of the paper for letting me read it and show it to other Tor devs. Thanks also to Ralf-Philipp Weinmann for helping me figure the analysis out.

The attack

How the attack works: Basic background

This writeup assumes that you know a little bit of computer stuff, and you know how xor works.

Let's talk about block ciphers, for starters. A block cipher is a cryptographic tool that encrypts a small chunk of plaintext data into a same-sized chunk of encrypted data, based on a secret key.

In practice, you want to encrypt more than just one chunk of data with your block cipher at a time. What do you do if you have a block cipher with a 16-byte block (like AES), when you need to encrypt a 256-byte message? When most folks first consider this problem, they say something like "Just split the message into 16-byte chunks, and encrypt each one of those." That's an old idea (it's called ECB, or "electronic codebook"), but it has some serious problems. Most significantly, if the same 16-byte block appears multiple times in the plaintext, the ciphertext will also have identical blocks in the same position. The Wikipedia link above has a cute demonstration of this.

Okay, so nobody reasonable uses ECB. Some people, though, do use a mode called CBC, or "Cipher Block Chaining." With CBC, when you want to encrypt a message, you start your ciphertext message with a single extra random block, or IV ("initialization vector"). Now, when you go to encrypt each plaintext block to get its ciphertext block, you first xor the plaintext with the previous ciphertext. (So you xor the IV with the first plaintext block, encrypt that, and output it. Then you xor that ciphertext block with the second plaintext block, encrypt that, output it, and so on. The Wikipedia page has pretty good examples and illustrations here too.)

TLS and its earlier incarnation, SSL, are the encryption protocols that many applications, including Tor, use to send streams of encrypted data. They use CBC mode for most of their block ciphers. Unfortunately, before TLS version 1.1, they made a bad mistake. Instead of using a new random IV for every TLS message they sent, they used the ciphertext of the last block of the last message as the IV for the next message.

Here's why that's bad. The IV is not just supposed to be random-looking; it also needs to be something that an attacker cannot predict. If I know that you are going to use IV x for your next message, and I can trick you into sending a message that starts with a plaintext block of [(NOT x) xor y], then you will encrypt y for me.

That doesn't sound too bad. But Wei Dai and Gregory V. Bard both found ways to exploit this to learn whether a given ciphertext block corresponds to a given plaintext. The attacker makes the user encrypt C' xor p, where p is the guessed plaintext and C' is the ciphertext block right before where the attacker thinks that plaintext was. If the attacker guessed right, then the user's SSL implementation outputs the same ciphertext as it did when it first encrypted that block.

And even that doesn't sound too bad, even in retrospect. In order to mount this attack, an adversary would need to be watching your internet connection, and be able to force you to start your next TLS record with a given string of his choice, and be able to guess something sensitive that you said earlier, and guess which part of your TLS stream might have corresponded to it.

Nevertheless, crypto people implemented workarounds. Better safe than sorry! In version 1.1 of the TLS protocol, every record gets a fresh IV, so the attacker can't know the IV of the next message in advance. And OpenSSL implemented a fix where, whenever they're about to send a TLS record, they send an empty TLS record immediately before, and then send the record with the message in it. The empty TLS record is enough to make the CBC state change, effectively giving the real message a new IV that the attacker can't predict.

These fixes haven't gotten very far in the web world, though. TLS 1.1 isn't widely implemented or deployed, even though the standard has been out since 2006. And
OpenSSL's "empty record" trick turns out to break some non-conformant SSL implementations, so lots of folks turn it off. (The OpenSSL manual page for the option in question even says that "it is usually safe" to do so.)

I suppose that, at the time, this seemed pretty reasonable. Guessing a plaintext is hard: there are something like 3.4 x 10^38 possible values. But as they say, attacks only get better.

How the attack works: What's new as of today

Juliano Rizzo and Thai Duong have two contributions, as I see it. (And please correct me if I'm getting this wrong; I have not read the literature closely!) First, they came up with a scenario to implement a pretty clever variation of Dai's original attack.

Here's a simplified version, not exactly as Rizzo and Duong present it. Let's suppose that, for some reason, the user has a secret (like a web cookie) that they send in every TLS record. And let's assume also that the attacker can trick the user into inserting any number of characters in their plaintext at the start of the record right before the secret. So the plaintext for every record is "Evil | Secret", where Evil is what the attacker chooses, and Secret is the secret message. Finally, let's suppose that the attacker can make the user send as many records as he wants.

The ability to decide where block boundaries fall turns out to be a big deal. Let's suppose that instead of filling up a full plaintext block with 16 bytes of Evil, the attacker only fills up 15 bytes... so the block will have 15 bytes the attacker controls, and one byte of the secret.

Whoops! There are only 256 possible values for a single byte, so the attacker can guess each one in turn, and use the older guess-checking attack to see if he guessed right. And once the attacker knows the first byte, he starts sending records with 14 attacker-controlled bytes, one byte that he knows (because he made a bunch of guesses and used the older attack to confirm which was right), and one byte that he doesn't. Again, this block has only 256 possible values, and so guessing each one in turn is efficient.

They then show how to extend this to cases where the attacker doesn't actually control the start of the block, but happens to know (or is able to guess) it, and make other extensions to the attack.

The second neat facet of Duong and Rizzo's work is that they actually found some ways to make this attack work against web browsers. That's no mean feat! You need to find a way to trick a web client into sending requests where you control enough of the right parts of them to mount this attack, and you need to be able to do it repeatedly. It seems to have taken a lot of HTTP hackery, but it seems they managed to do it. There's more detailed information here at Eric Rescorla's blog, and of course once Juliano and Thai have their paper out, there will be even more to goggle at. This is really clever stuff IMO.

[Disclaimer: Again, I may have made mistakes above; if so, I will correct it when I wake up in the morning, or sooner. Please double-check me if you know this work better than I do.]

So, does this attack work on Tor?

Nope.

Tor uses OpenSSL's "empty fragment" feature, which inserts a single empty TLS record before every record it sends. This effectively randomizes the IV of the actual records, like a low-budget TLS 1.1. So the attack is simply stopped.

This feature has been in OpenSSL since 0.9.6d: see item 2 in Bodo Müller's good old CBC writeup for full details on how it works. It makes our SSL incompatible with some standards-non-compliant TLS implementations... but we don't really care there, since all of the TLS implementations that connect to the Tor network are OpenSSL, or are compatible with it.

Tor requires OpenSSL 0.9.7 or later, and has since 0.2.0.10-alpha. Amusingly, we were considering dropping our use of the empty fragment feature as "probably unnecessary" in 2008, but we never got around to it. I sure don't think we'll be doing that now!

Now, it's possible that clients we didn't write might be using other TLS implementations, but the opportunity for plaintext injection on client->relay links is much lower than on relay->relay links; see below. As far as I know, there are no Tor server implementations compatible with the current network other than ours.

Also, this only goes for the Tor software itself. Applications that use TLS need to watch out. Please install patches, and look for new releases if any are coming out soon.

But what if...

Okay, but would it work if we didn't use OpenSSL's empty-fragment trick?

For fun, what would our situation be if we weren't using openssl's empty fragment trick?

I'm going to diverge into Tor protocol geekery here. All of the next several sections are probably irrelevant, since the OpenSSL trick above protects Tor's TLS usage already. I'm just into analyzing stuff sometimes... and at the time I originally wrote this analysis, we didn't have confirmation about whether the OpenSSL empty-record trick would help or not.

This part will probably be a little harder to follow, and will require some knowledge of Tor internals. You can find all of our documents and specifications online at our handy documentation page if you've got some free time and you want to come up to speed.

The attack scenario that makes sense is for an attacker to be trying to decrypt stuff sent from one Tor node to another, or between a Tor node and a client. The attacker is not one of the parties on the TLS link, obviously: if they were, they'd already know the plaintext and would not need to decrypt it.

First, let's make some assumptions to make things as easy for the attacker as possible. Let's assume that the attacker can trivially inject chosen plaintext, and can have the TLS records carve up the plaintext stream anywhere he wants.

(Are those assumptions reasonable? Well, it's easy to inject plaintext on a relay->relay link: sending a node an EXTEND cell will make it send any CREATE cell body that you choose, and if you have built a circuit through a node, you can cause a RELAY cell on that node to have nearly any body you want, since the body is encrypted/decrypted in counter mode. I don't see an obvious way to make a node send a chosen plaintext to a client or make a client send a chosen plaintext to a node, but let's pretend that it's easy to do that too.

The second assumption, about how it's easy to make the boundaries of TLS records fall wherever you want, is likely to be more contentious; see "More challenges for the attacker" below.)

Also let's assume that on the targeted link, traffic for only one client is sent. An active attacker might arrange this through a trickle attack or something.

I am assuming that the attacker is observing ciphertext at a targeted node or client, but not at two targeted places that allow him to see the same traffic enter and leave the network: by our threat model, any attacker who can observe two points on a circuit is assumed to win via traffic correlation attacks.

I am going to argue that even then, the earlier attack doesn't get the attacker anything, and the preconditions for the Duong/Rizzo attack don't exist.

CLAIM 1: The earlier (Dai/Bard) attacks don't get the attacker anything against the Tor protocol

There are no interesting guessable plaintexts sent by a well-behaved client or node[*] on a Tor TLS link: all are either random, nearly random, or boring from an attacker's POV.

[*] What if a node or client is hostile? Then it might as well just publish its plaintext straight to the attacker.

Argument: CREATE cell bodies contain hybrid-encrypted stuff that (except for its first bit) should be indistinguishable from random bits, or pretty close to indistinguishable from random bits. CREATED cell bodies have a DH public key and a hash: also close to indistinguishable from random. CREATE_FAST cell bodies *are* randomly generated, and CREATED_FAST cell bodies have a random value and a hash.

RELAY and RELAY_EARLY cell bodies are encrypted with at least one layer of AES_CTR, so they shouldn't be distinguishable from random bits either.

DESTROY, PADDING, NETINFO, and VERSIONS cells do not have interesting bodies. DESTROY and PADDING bodies are either 0s or random bytes, and NETINFO and VERSIONS provide only trivial information that you can learn just by connecting to a node (the time of day, its addresses, and which versions of the Tor link protocol it speaks).

That's cell bodies. What about their headers? A Tor cell's header has a command and a circuit ID that take up only 3 bytes. Learning the command doesn't tell you anything you couldn't notice by observing the encrypted link in the first place and doing a little traffic analysis. The link-local 2-byte circuit ID is random, and not
interesting per se, but possibly interesting if you could use it to demultiplex traffic sent over multiple circuits. I'll discuss that more below at the end of the next section.

CLAIM 2: You can't do the Duong/Rizzo attack against the Tor protocol either

The attack requires that some piece of sensitive information M that you want to guess be re-sent repeatedly after the attacker's chosen plaintext. That is, it isn't enough to get the target to send one TLS record containing (evil | M) -- you need to get it to send a bunch of (evil | M) records with the same M to learn much about M.

But in Tor's link protocol, nothing sensitive is sent more than once. Tor does not retry the same CREATE or CREATE_FAST cells, or re-send CREATED or CREATED_FAST cells. RELAY cells are encrypted with at least one layer of AES_CTR, and no RELAY cell body is sent more than once. (The same applies to RELAY_EARLY.)

PADDING cells have no interesting content to learn. VERSIONS and NETINFO cells are sent only at the start of the TLS connection (and their contents are boring too).

What about the cell headers? They contain a command and a circuit ID. If a node is working normally, you can already predict that most of the commands will be RELAY. You can't predict that any given circuit's cells will be sent reliably after yours, so you can't be sure that you'll see the same circuitID over and over... unless if you've done a trickle attack, in which case you already know that all the cells you're seeing are coming from the same place; or if you've lucked out and one circuit is way louder than all the others, but you would already learn that from watching the node's network. So I think that anything that is sent frequently enough to be decryptable with this method is not in fact worth decrypting. But see the next section.

Hey, what if I'm wrong about those cell headers?

Let's pretend that I flubbed the analyis above, and that the attacker can read the command and circuitID for every cell on a link. All this allows the attacker to do is to demultiplex the circuits on the link, and better separate the traffic pattern flows that the link is multiplexing for different clients... but the attacker can't really
use this info unless the attacker can correlate it with a flow somewhere else. This requires that the attacker be watching the same traffic at two points. But if the attacker can do that, the attacker can already (we assume) do a passive correlation attack and win.

And what if I'm wrong entirely?

Now let's imagine that I am totally wrong, and TLS is completely broken, providing no confidentiality whatsoever? (Assume that it's still providing authenticity.)

Of course, this is a really unlikely scenario, but it's neat to speculate.

The attacker can remove at most one layer of encryption from RELAY cells in this case, because every hop of a circuit (except sometimes the first) is created with a one-way-authenticated Diffie-Hellman handshake. (The first hop may be created with a CREATE_FAST handshake, which is not remotely secure against an attacker who can see the plaintext inside the TLS stream.) Anonymized RELAY traffic is encrypted in AES_CTR mode with keys based on at least one CREATE handshake, so the attacker can't beat it. Non-anonymized RELAY traffic (that is, tunneled directory connections) don't contain sensitive requests or information.

So if the attacker can use this attack to completely decrypt TLS at a single hop on a Tor circuit, they still don't win. (All they can do is demultiplex circuits, about which see above.) And for them to do this attack at multiple points on the circuit, they would have to observe those points, in which case they're already winning according to our threat model.

More challenges for the attacker

It's actually even a little harder to do this attack against Tor than I've suggested.

First, consider bandwidth-shaping: If a node or a link is near its bandwidth limit, it will split cells in order to stay under that limit.

Also, on a busy node, you can't really send a cell and expect it to get decrypted and put into the next output record on a given link: there are likely to be other circuits queueing other cells for that link, and by the time your cell is sent, it's likely that they'll have sent stuff too. You can get increased priority by making a very quiet
circuit, though.

Finally, I don't actually think it's possible to cause chosen plaintext to appear on a client->server link.

Recommendations

We dodged an interesting bullet on this one: part of it was luck, and part of it was a redundant protocol design. Nevertheless, let's "close the barn doors," even though the horse is still tied up, chained down, and probably sedated too.

First, as soon as OpenSSL 1.0.1 is out and stable, we should strongly suggest that people move to it. (It provides TLS 1.1.) We should probably build all of our packages to use it. But sadly, we'll have to think about protocol fingerprinting issues there, in case nobody else jumps onto the TLS 1.1 bandwagon with us. :/

We should include recommended use of the OpenSSL empty-record trick in our spec as a requirement or a strong recommendation. I'll add a note to that effect.

In future designs of replacements for the current RELAY and CREATE format, we should see if there are ways to prevent them from being used for chosen plaintext injection. This might not be the last attack of its kind, after all.

Perhaps we should put an upper bound on the circuit priority algorithm if we haven't already, so that no circuit can achieve more than a given amount of priority for being quiet, and so that you can't reliably know that your cell will be sent next on a link. But that's pretty farfetched.

And in closing

longpost is loooooooong

Thanks to everybody who followed along with me so far, thanks to Juliano and Thai for letting me read their paper ahead of time, and thanks to everybody who helped me write this up. And thanks especially to my lovely spouse for proofreading.

Now, it's a Friday evening, and if you'll excuse me, I think I'm going to go off the 'nets for a little while.

Comments

Please note that the comment area below has been archived.

September 24, 2011

Permalink

This is a very good overview of the topic for crypto-layman (e.g. me). However one section took a bit of decompressing:

"If I know that you are going to use IV x for your next message, and I can trick you into sending a message that starts with a plaintext block of [(NOT x) xor y], then you will encrypt y for me."

Maybe add something like:
"This works because in order to encrypt the message [(NOT x) xor y], you will first xor it with the IV [x]. The (NOT x) and x will cancel each other out as part of this xor operation and leave only [y] for encryption. "

This is not so much to explain xor'ing to the reader (though that always helps) but to make clear that the xor operation in '[(NOT x) xor y]' is not referring to xor'ing with the IV but the actual construction of the plaintext block that will later be xor'd with the IV and then enciphered.

I think the description of the SSL attack would benefit from the same elaboration.

"The attacker makes the user encrypt C' xor p, where p is the guessed plaintext and C' is the ciphertext block right before where the attacker thinks that plaintext was.
So if the attacker knows the SSL implementation will use [x] as the IV, he gets the user to encrypt a plaintext that is constructed as [(NOT x) xor C' xor p]. The SSL implementation will xor the IV [x] against this text and get [C' xor p]. It will then encrypt [C' xor p] and send it to the attacker. If the attacker finds that this encrypted message matches byte for byte the one he received right after the ciphertext block C' earlier in the stream he knows he has correctly guessed the plaintext [p] that was contained in the ciphertext block right after C'."

September 27, 2011

In reply to nickm

Permalink

So I suppose the idea here is that the "y" is the chosen plain text and since I know the IV "x", I would ask the Oracle to encrypt [x XOR y] for me, knowing that [x XOR y] will be XOR'd with "x" before it was encrypted in CBC mode, which makes the final result encryt(y). So I think in above paragraph is wrong, it should have been [x XOR y] instead of [(NOT x) XOR y]. Am I right?

Choose y = 1 using 1-bit numbers for your result:
1 ^ y == y
1 ^ 1 == 1 => false

In fact
0xfff..fff ^ y = ~y

and
0x000..000 ^ y = y

So I believe the question is correct and unless there is another subtle NOT to be worked out somewhere it should read [x XOR y] instead of [(NOT x) XOR y].

As written:
encrypt(x ^ (~x) ^ y)
encrypt(0xfff..fff ^ y)
encrypt(~y)

vs.
encrypt(x ^ x ^ y)
encrypt(0x000..000 ^ y)
encrypt(y)

x XOR x => 0
y XOR 0 => y
x XOR x XOR y =>y

x XOR (NOT x) => 0xffff..
0xffff.... XOR y <> y

e.g.
assume
x = 0101
y = 1111
then
NOT x = 1010
x XOR (NOT x) = 0101 XOR 1010 = 1111
x XOR (NOT x) XOR y = 1111 XOR 1111 = 0000
0000 is not 1111

September 24, 2011

Permalink

Thanks for taking the time to write this up so soon. It helps put the attack into context as other news sources have already started reporting about this issue as if the world is about to end.

As with many tech issues, putting into context helps to realize the risk associated with this issue and steps that can be taken to mitigate it.

Not more than you see there; we'd like to know more about the attack, if there's a real cause for concern. As far as I know, the speaker hasn't been in touch with us (though it's possible he contacted somebody else, and I didn't hear about it). We're asking him for more info now.

The abstract there says that the attack builds on earlier work by the same author here: http://cansecwest.com/csw11/filiol_csw2011.pdf -- that's the CanSecWest talk that the abstract is talking about. In that talk, the big idea was that if an attacker can install malware on your computer, and that malware can replace crypto primitives and do similar stuff, then it can make security programs on your computer act in an insecure way.

There were some neat ideas there about what malware could do to a crypto program... but ultimately, once you're running malware that can replace the code you're running, you have basically lost out. The place to stop attacks of this kind would seem to be before the malware is installed.

Then again, I'm just guessing here, based on the older talk, and I could be missing something big. The abstract says that there are non-malware-based attacks too, "depending on the scenario." I hope we hear from Eric soon--he says he's got suggestions for our protocol, and it would be good to hear what they are.

September 24, 2011

Permalink

Thank you very much for this very good post and thanks to anonymous for the extra precisions.
However I'm curious about something: how can Bob decrypt Alice's first block if Alice uses a random IV unknown from Bob?
Is the IV simply sent in plaintext together with the first block? (according to wikipedia it doesn't need to be secret)
Or are we like systematically sending a dumb first block and start to send actual data from the 2nd block?

Ah, you're asking about the IV for the first encrypted record.

In TLS 1.0, the same process that generates the shared symmetric keys between Alice and Bob is also generates the starting IVs.

And if you're curious how *that* works ... Basically, in the simple case, during the initial TLS handshake, the client and server each send the other a random number, and the client sends the server a "pre-master secret" encrypted to the server's public key. These are used in a HMAC-based pseudorandom function to derive a "master secret", and then the master secret and the random values are used to derive the encryption keys, some HMAC keys for data integrity, and the initial IVs.

(There's more stuff going on, too, to prevent various attacks and enable various features. The Wikipedia TLS handshake in detail section of the TLS article isn't too bad, and the relevant RFCs have the whole story.)

September 24, 2011

Permalink

I don't know much about this stuff. I do know I appreciate Tor and am curious about computer security. This post was great. Upon reaching "Claim 1," I skipped to "Recommendation.," Still, I think this was interesting and informative and I enjoyed reading it. Well done, nickm.

September 24, 2011

Permalink

Thanks for the update. Always good to see redundant security in this insecure world.

September 24, 2011

Permalink

thanks for this long and nice job article! If it is possible to you tell your short conclusion as advice?how we can detect these BEAST ssl atack and it 's maleware as non expert user?do you suggest we enable tls 1.x or ... instead of tls 1?

September 25, 2011

Permalink

Thanks for checking this out so soon and reporting it. The other thing I take away is that there is no such thing as 'redundant' security :p

September 25, 2011

Permalink

"block of [(NOT x) xor y], then you will encrypt y for me"

Hi, shouldn't block = [x xor y], since: x xor [x xor y] = y?

Thanks!

September 25, 2011

Permalink

"If I know that you are going to use IV x for your next message, and I can trick you into sending a message that starts with a plaintext block of [(NOT x) xor y], then you will encrypt y for me."

There's one thing I don't understand: Shouldn't x xor ((NOT x) xor y) cause NOT y to be encrypted, and not y? x xor (NOT x) is 1, not 0.

September 25, 2011

Permalink

the tor is an open source software?yes.it is not bad for a security software to show it's hand to public?specially if dictatorial goverment that like to prevent their people to reach the INFORMATION LEDGE be able to crack it?thanks.b

I assume you are asking it Tor is open source (or free software) and if it is bad for security software to be published.

The answer to your second question is that cryptographically sound algorithms and software that implements them benefit from the scrutiny of the masses. The more people that look at the code, the less likely any Easter eggs, back doors or bugs are to survive.

There are several examples of closed source solutions where various regimes have installed back doors in cryptographic equipment eventually leading to serious diplomatic crises and of course the demise of the company in question. Can't find an example right now but one involves a Swiss company.

You must be quite new to computer security to think that keeping the source closed would improve security.

If you show all the source code and encryption algorithms you are using and people still cannot compromise your software, then you got *real* security.

Otherwise you just get security by obscurity, but Crackers have proven many, many times that they don't need the source code to find vulnerabilities in softwares.

If still in doubt, just look at http://openbsd.org (including OpenSSL) and try to find a widespread commercial software with a similar security track record. Certainly not Adobe (PDF), Java, MacOS (well, at least they don't have viruses anymore) or Internet Explorer (or anything ever made by Microsoft).

Examining source code for exploits is like looking at the floor plan for a building: it will show you the doors and windows, and perhaps non-structural walls that can be broken through easily. Examining the binary code is like examining the actual building itself, revealing things like places where a wall wasn't extended above a drop ceiling, or a cipherlock whose combination is never changed and four digits show much more wear than all the others.

The map is not the territory, the source is not the code.

-- AJWM

September 26, 2011

Permalink

I saw this scroll by on xxx.lanl.gov recently, it's unrelated to cryptography but interesting nonetheless:

http://lanl.arxiv.org/abs/1109.0597

Stealthy Traffic Analysis of Low-Latency Anonymous Communication Using Throughput Fingerprinting

"Anonymity systems such as Tor aim to enable users to communicate in a manner that is untraceable by adversaries that control a small number of machines. To provide efficient service to users, these anonymity systems make full use of forwarding capacity when sending traffic between intermediate relays. In this paper, we show that doing this leaks information about the set of Tor relays in a circuit (path). We present attacks that, with high confidence and based solely on throughput information, can (a) reduce the attacker's uncertainty about the bottleneck relay of any Tor circuit whose throughput can be observed, (b) exactly identify the guard relay(s) of a Tor user when circuit throughput can be observed over multiple connections, and (c) identify whether two concurrent TCP connections belong to the same Tor user, breaking unlinkability. Our attacks are stealthy, and cannot be readily detected by a user or by Tor relays. We validate our attacks using experiments over the live Tor network. We find that the attacker can substantially reduce the entropy of a bottleneck relay distribution of a Tor circuit whose throughput can be observed-the entropy gets reduced by a factor of 2 in the median case. Such information leaks from a single Tor circuit can be combined over multiple connections to exactly identify a user's guard relay(s). Finally, we are also able to link two connections from the same initiator with a crossover error rate of less than 1.5% in under 5 minutes. Our attacks are also more accurate and require fewer resources than previous attacks on Tor."

September 27, 2011

Permalink

thanks dear friends for answer.i have 20 years experience with computer and may be new to computer security.i agree and know the methods that cracker work and how the codes be found via reverse engineering but do you can find the source code of the popular and pioneer anti virus/securty software as open source available to public?thanks

September 29, 2011

Permalink

The above post of 26th september - Stealthy Traffic Analysis of Low-Latency Anonymous Communication Using Throughput Fingerprinting- true or false?

September 29, 2011

Permalink

Whenever I read this much math (way over my head), my eyes glaze over ... but I trudge on regardless.

If attacks are this sophisticated (they are ... and more), it is important that the defense squad stays on their toes. I am glad that the TOR team does just that ... now, where is that donate button? ... these conferences and resultant cogitation cost money.

October 18, 2011

Permalink

Isn't the empty fragment workaround disabled by default in OpenSSL?

Maybe I'm just tired, but I look at the OpenSSL 0.9.8r ssl.h and it says:

/* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added
* in OpenSSL 0.9.6d. Usually (depending on the application protocol)
* the workaround is not needed. Unfortunately some broken SSL/TLS
* implementations cannot handle it at all, which is why we include
* it in SSL_OP_ALL. */
#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS 0x00000800L /* added in 0.9.6e */

/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FFFFFL before 0.9.7. */
#define SSL_OP_ALL 0x00000FFFL

You are not reading the paper correctly.

It is a nice attack, and seems like it would work pretty well to identify the relays in the user's circuit. But that is not enough by itself to identify the Tor user.

I encourage you to visit http://freehaven.net/anonbib/ and read the wide variety of attack and defense papers.

February 28, 2012

Permalink

uk