Search the Community

I assume that organizations like the NSA can monitor and save metadata of all VPN traffic in the world. I think, then, that all VPNs are useless because having access to metadata of incoming and outgoing traffic of a VPN server can reveal almost everything and cracking the encrypted traffic is not necessary as they can look on decrypted traffic that exited a VPN server. Some correlation attacks scenarios I could think of: ​ ​1) If a VPN user accesses a less popular site, say abc.net then it can be safely assumed that he/she is the only VPN user that accesses it. Then the user can be easily identified, because it may be looked up that whenever a request was sent to this site by the VPN, a user X was also connected (for example sent/received requests from the VPN within 5-10 seconds) to the VPN. This can hardly be a coincidence so the anonymity is compromised. ​ ​2) Similarly, some pattern in the traffic can be seen. For example, a user usually spends some time on one site before moving on to some other site. So it is plain to see that if whenever some user X sent a request to the VPN and the VPN sent a request to some site abc.net 2 seconds later (or at any regular interval) and this continued for, say, several minutes, then those outgoing requests from the VPN are likely to correspond to the incoming requests from the user to the VPN. ​ ​There are probably dozens of other variations of correlation attack that can be performed. ​I think that 60-100 people on a server is much too less to provide any anonymity. ​ ​The point is that organizations like the NSA don't even have to decrypt the data but just seek for patterns. With all the computational power they have it should be easy. They wouldn't even need to perform the attack on specific targets only, but simply use computers to deanonymize almost every user. ​ My questions are: ​ ​1. Does the NSA use correlation attacks? Why or why not? I have never read any news about it but saw a bunch of posts like this on forums that dangers of a correlation attack. I have only read about them cracking VPNs (but only those that were vulnerable because they were apparently run by lazy people and AirVPN is not one of them) here: http://arstechnica.com/security/2015/10/how-the-nsa-can-break-trillions-of-encrypted-web-and-vpn-connections/ and here: http://arstechnica.com/tech-policy/2014/12/nsa-has-vpns-in-vulcan-death-grip-no-really-thats-what-they-call-it/. But no information about correlation attacks. ​ ​2. What measures does AirVPN take to prevent correlation attacks? Do you use multihop network i.e. different entry and exit IP? If so, are there any additional hops inbetween, similar to TOR relay nodes? Does it make correlation attacks any harder? What can we do to increase our security against these type of attacks? Would routing the traffic through AirVPN SSH tunnel (in the client) help or further compromise anonymity?

SLOTH attack targets old hash functions Researchers from the Prosecco team at INRIA published a number of attacks that exploit the use of weak hash functions in TLS and other protocols. They called their attack SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes). The most severe attack is affecting the systems that use of client certificates and continue to support RSA-MD5 signatures. It’s been known since 2005 that MD5 hash collisions are easy to carry out. Many practitioners have argued in the past that the hash collisions don’t matter in certain scenarios and that the security of many protocols only relies on the so-called second preimage resistance. The INRIA researchers debunked many of these claims with their new publication. The most notable scenario where an attack is possible is when client certificates are used. If a user authenticates himself at a malicious server using a client that supports RSA-MD5 signatures, then the server can use the information provided to impersonate the user on some other target server (which must also support RSA-MD5). A surprising aspect of this is that TLS 1.2 is vulnerable to this attack while prior versions are not. The reason for this is that TLS 1.2 allows negotiation of the signature algorithm (prior versions always use a concatenation of MD5 and SHA1) and, crucially, still supports the insecure MD5 as an option. This is very surprising given the fact that TLS 1.2 was published in 2008—several years after practical attacks against MD5 were announced. This attack is made worse by the fact that various implementations accept RSA-MD5 signatures even if they advertise that they don’t do this. Several cryptographic libraries have received updates in response to this research, including NSS, GnuTLS, BouncyCastle and mbedTLS. An old version of OpenSSL (before 1.0.1f) was also affected.

Am I under attack, I have been seeing way too much of this for the past week now.