[Cryptography] Verified privacy and VPNs

[Mark Karpelès]

Hi,

Thanks for your response.

This IETF group is very interesting. For now we're generating a private key
inside the enclave, and using it to self-sign a TLS certificate including
its public key in the quote's custom bytes (proving the key came from the
enclave), I understand it's the standard way to perform this with
openenclave, but it's a bit awkward and having a proper support in (D)TLS
would be useful.

In our case we're not just performing the decryption in the secure enclave,
but also authentication against the VPN services and packet routing
including network address translation (NAT). This ensures that an
administrator on the machine (or anyone really) would be in no way able to
know who encrypted or decrypted packets belong to. Packets flow in and out
of the enclave, and only the enclave holds the routing tables/etc.

A lot of VPN services out there use having "no logs" as a selling point,
yet are able to quickly link packets in real time to a given user account,
which goes against the promises they make in their advertisement materials,
as "no logs" implies for user the guarantee that their identity cannot be
linked to their traffic, be it afterward or in real time.

Not discussing the philosophical or legal issues that this may raise, the
fact is "no logs" (ie. protecting one's identity from being linked to one's
traffic) is a commercial argument, people buy VPN services relying on said
promise, and yet it's been recently disclosed by some of the largest VPN
providers that they do have the ability to link traffic to a user's
identity and will do that in "real time." I see this as false advertising,
abusing people's trust in the word of said companies to sell them a service
that fails to comply with the promises made to the user.

That's what led us to build this service, to replace trust with
verification, and offer a service answering what people are asking for.


Thanks,
M.

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20251014/a46e37f8/attachment.htm>