Thanks to TeLeScope, TLS Communication With Your Virtual Servers Can Now Be Unencrypted
Earlier this week, BitDefender demonstrated the TeLeScope technique, which allows an attacker to decrypt TLS communication between a target and a virtualized server. TLS stands for Transport Layer Security and is widely used. The TeLeScope technique is both operating system agnostic and crypto library agnostic. Any TLS key that is generated on a virtualized server is susceptible this technique. This security scare reminds us that your VPN service should use their own bare metal servers.
TeLeScope Reminds Us the Cloud Is Inherently Not Secure
Common knowledge has always dictated that if you are running a virtual machine remotely, whoever has access to the actual hardware is clearly able to view your activity if they really want to. Users have always known that critical snooping techniques that would defeat encryption use like TLS is possible. The TeLeScope revelation by BitDefender just reminds us of the specifics of the situation. A similar cache attack also allows malicious third parties to access your RSA keys and other important cryptographic keys. This isn’t just a possibility that we need to trust Amazon not to exploit – anyone with a VM that is used on the same physical machine as yours can snoop these items.
Use a VPN instead of a VPS
Many people and companies around the world rely on TLS and virtualization to run crucial services – but TeLeScope makes a VPS useless to a dedicated attacker. Private Internet Access reminded VPS and VPN users around the world that are affected by this news:
If you are using a VPS or VPN on virtualized hardware (i.e., a VPS such as Digital Ocean, Amazon, Azure, etc.), you should assume that your traffic has been and is being decrypted.
Private Internet Access™ is default secure from this vulnerability since we use real bare metal servers.
Comments are closed.
5 Comments
If you are using a VPN provider such as PIA, you should assume that your traffic has been and is being decrypted, because that’s how VPNs work. Also, it’s trivial for a VPN provider to log all your traffic without you noticing, so you should also assume that a copy of all your traffic has been and is being sent to NSA, GCHQ and other 3- and 4-letter agencies around the world. Why? Because if they can, why won’t they?
Good one. Caleb, do you care to elaborate on that?
You almost understand it! PIA, as well as other VPNs, encrypt traffic specifically because ISPs engage in the activity you just described. Assuming that a copy of my traffic is being send to the NSA, GCHQ, and other 3-4 letter agencies is exactly why I use a VPN service on top of my ISP. I want that copy to be encrypted by a company I trust. This article points out that a company you trust that uses a service like Amazon, Azure, DO, etc, shouldn’t be trusted because of the described attack vector. Unless you control every virtualized instance on a server, nothing happening on that server is secure. Using a VPN service with real bare metal servers as opposed to virtualized and insecure instances is necessary to ensure that the data collected on you isn’t useful.
If a company uses a service like Amazon, Azure, DO, etc., you only have to trust the company that runs that service (ie Amazon, Azure, DO, etc), because only they are in position to perform this attack. There is no need to control “every virtualized instance”, because TeLeScope attack can only be conducted from the hypervisor, ie by the service operator.
Similarly, even if using bare metal servers, it is necessary to trust the hosting/colocation provider, because they have physical access to the servers which means they can control them (eg provide KVM access to said 3-4 letter agencies), so the provider should be trusted in any case.
You are absolutely correct. The hypervisor and hosting/colocation provider are two entities that need to be trusted and controlling “every virtualized instance” does nothing against a snooping service operator.