Jaime Blasco, director of AlienVault Labs, has added his thoughts:
“TOR provides anonymity, if you want to have privacy you still have to use something like a VPN in order to connect to the TOR network. You are still facing other problems like tracking and profiling or unauthorized access to your system using exploitation of the browser or any other software you are using over the TOR network. As an example the FBI used an exploit affecting Firefox to deanonymize TOR users accessing illegal content. On the other hand, governments are actively investing a huge amount of money and resources in order to compromise the TOR network. If you want to be secure you should assume TOR is compromised and use other methods to maintain your anonymity and privacy within TOR.”
Yesterday, Tor issued a security advisory which revealed that a group of relays had been discovered on July 4th which looked like they "were trying to deanonymize users."
The advisory states that the attack "involved modifying Tor protocol headers to do traffic confirmation attacks" with the relays having joined the network at the start of the year. This means they were potentially deanonymizing users between January 30th and July 4th when they were finally removed.
A Tor spokesperson says that they know the attack "looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic" so no details of pages visited or whether hidden services searched for were actually visited at all for that matter. The advisory goes on to warn that it is likely that the attackers tried to learn "who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service."
No evidence was found to suggest that any exit relays were being operated, so the probability of linking users to destinations on standard Tor circuits remains remote. For full technical details of the attack methodology, see the advisory which goes into this at some length.
The following steps have been taken to remediate the damage in the short term:
Attacking relays removed from the Tor network
A software update has gone out for relays in order to prevent such use of 'relay early' cells again
A new Tor version warns in the logs if a relay on your path injects any relay-early cells
Meanwhile, Amichai Shulman who is the CTO at security experts Imperva says "sadly the ideal of having a distributed, crowd based network for protecting free speech is largely abused by pirates (software and content) as well as evil-doers – from child pornography to drug trafficking and terrorism. This in turn makes the TOR network a target for all intelligence agencies as well as some domestic security organizations. I suspect the reported attack, targeted mostly at people who operate and access TOR hidden service, is of that origin."
Craig Young, a security researcher at Tripwire, takes a slightly different view saying "While the attacker(s) in this case are still technically anonymous, it would appear that there is most likely a connection between this incident and the recently withdrawn Black Hat presentation on deanonymizing TOR users. If this was in fact a university research project, it was conducted without appropriate regard to users of the TOR network. This attack involved manipulating TOR protocol messages to encode information about observed requests so that the information could be correlated with an identity by relays in other parts of the network. In doing so the attackers not only made it possible to themselves unmask some TOR hidden services and users but they have also created an unquantifiable risk as these messages could also be decoded by other parties either while the attack was in progress or in retrospect by analyzing stored packet captures."
Well, it's a somewhat broad topic that can range from implementation details to mathematical proofs in number theory. How about I give you an overview, and then you can ask for the details that interest you?
One thing I will warn you: Do not implement your own cryptographic software or algorithms for production use! You'll regret it, unless your working with a team of mathematitions and computer scientists who understand how to prevent side channel attacks, and are willing to regurously inspect the code.
First I'll assume that you know how a symmetric cypher kind-of works. You give it plaintext and a password, and out pops the cyphertext. Then the other person can combine the password and the cyphertext to give back the plaintext. A little commic about AES can be found here.
End-to-end encryption is exactly what it sounds like; it's when one person encrypts a message, and it is not decrypted until it reaches it's destination (no matter the actual medium used).
A simple form would be that Alice and Bob pick a secret password, and all messages are encrypted before Alice sends a message and after Bob recieves it. An attacker Eve would not be able to see what Alice and Bob are talking about, even if she can see the cyphertext because she is still missing the password.
There is a small problem with this system. What if Alice and Bob haven't actually met in person to share a password (and all they have is an unsecure connection that is being tapped by Eve)? If Alice and Bob were to share the password over a public channel where Eve is listening in, then Eve will be able to decrypt the messages with the password!
That's where asymetric encryption come's in. There are various ways to do this, but one of the more famous examples would be RSA. The basic idea is that Alice generates a private and public key (and Bob does the same). Then then openly share their public keys (even if Eve see's the public keys). If Alice wanted to send a message to Bob, she would use Bob's public key to encrypt the message. The trick is that only Bob's private key can decrypt the message. Thus Eve (she has two public keys) does not have enough information to decrypt messages going either way.
(aside: RSA would generally be used to find a shared key, then AES would be used for the rest of the message. The reason is that it's hard to calculate RSA for large messages)
This is great... Except this system introduces a new flaw. Eve can pretend to be Alice and send a message using Bob's private key. Bob has no way of knowing that the message actually came from Alice (and Eve can set up a trap like "leave the goods in the forrest at midnight").
That's where signing comes in. In RSA, encryption and decryption are inverses of each other. So, Alice can compute a secure hash of the message and "decrypts" it using her private key, and send that with the message. Then Bob "encrypts" the hash with Alices public key giving the original hash and compairs it with the hash of the message sent. If the hash's match, then the person who sent the message must be Alice.
This is a lot better... Except there is still a problem. What if Eve is able to swap messages out with her own? Then when Alice and Bob trade public keys, she switches them with her public keys. Now when Alice think's she's talking to Bob she's really talking to Eve. And when Bob think's he's talking to Alice, he's really talking to Eve. This is called a "man-in-the-middle" attack (or MiTM).
This is where certificate authorities come in. When Alice and Bob install their operating system (which came on a physical disk that was not tampered with), the operating system comes with a list of public keys for some certificate authorities. Thus when Alice and Bob generate their keys, the submit the public keys to a certificate authority. If Alice want's to confirm that Bob's public key is not a forgery, she computes the hash of Bob's public key, and asks the certificate authority if it's legitimate. Eve is unable to make a forged public key, and is unable to MiTM the CA since the public keys were predefined on the operating system.
This is why when you send information to a website, you should be sure that the certificate is valid, and all information is being transferred through that connection (generally you can see it by clicking on the left of the address bar).
Guys plz help me. i have a gmail account. i forgot the password. unfortunatley the email id for my recovery mail has been declined since i have not logged on to it for few weeks. Is there any way i can able to access my gmail account. Is there any software or techniques to get into my account. Guys plz help me. I promise that am nt asking to hack anyother email id. plz help . i have impt files on my account. thanks !!!
This question has been put before..but there has been no definite solution for this..so i am re typing this question...
I have been working with ultrasurf just fine for 3 years now...but recently when i closed it...and tried to access the internet...the internet won't work...i spotted this problem first when i tried to run spotflux...it shows error...but that's because of this ultrasurf prob..please help
The police need to prove he is guilty in court to a judge (they won't bother unless they have credable evidence) - you do not need to (ever) prove your innocent to the police. Just saying "my wifi is open" should be enough. It's just like running a TOR exit node. You can even use open wifi/tor exit node as plausable deniability if you wanted. They probably wouldn't have enough evidence for a even warrent, at which point they need to leave you alone.
Also, the vast magority of attackers seem to prefer commercial public wifi anyways, especially with the possibility of people knoticing strange cars/cameras set up (wheras it's harder to notice at a public resturant).
Finally, police would prefer to use banking information to find leads. IP addresses are well known to be unreliable. If the attackers are smart enough to hide there bank trail, there also probably smart enough to anonymise the connection. So if attackers were to use your internet, and if the transaction was tracable to police, then there is a fairly high probability that the transaction left some kind of information for another lead. For example, if the police already know that illigal things are being traded, then they'll probably also have a little more detail, like how the trade is taking place, how the payment is made, etc.. something, almost anything can be made into a lead.
The thing with TLS is, it's very strong mathematically. The most that the NSA seem to be able to do is break RC4 maybe, which is depreiciated anyways. If you don't trust TLS, then you should probably avoid all banking with your computer. If someone was capable is breaking it, then their certianly capable of breaking into your wifi. Also, they would be capable of (physically) intercepting traffic between ISP's, and breaking into 100's of banking accounts no problem at all, so why even bother with targetting yours? The thing with doing banking in public is that someone might be watching you close enough. If your careless, then can get enough information to do damage. Another possibility is that your ignorant and fall for a spoof.
In general people are not educated about security, thus this can really damange them. Security of public wifis can lead to losing private details such as bank card(I don't understand why would u use it on public network even on an SSL connection) etc, but on the other hand insecurying your own wifi is probably as much if not more dangerious. Currently had a friend who owned an IP address to be visited by police. Apparently someone had hacked his wifi, and sells stolen things from that address... trust me he had hard time proving it wasn't him ...
I'm not generally concerned over public wifi security. I don't even see too much credible reason to encrypt your home wifi. Most websites I trust information with correctly use TLS. Someone might fall for a spoof if they don't keep there eye on website certificates, but if you do, your're pretty much safe (unless there's some other vunerability on your computer). There are a few sites that don't quite get TLS correct (their easier to spot, thus I don't trust them as much for information). To provent those, I might use a VPN.
The only thing that I'm concerned with when people watch porn in public is the possiblity of onlookers.