2 ms·
You might find this helpful: https://youtu.be/sz7NAe0G1_Y?si=focPEWli8xv7NCDi https://youtu.be/sz7NAe0G1_Y?si=focPEWli8xv7NCDi Re verifiability: the point isn’
by rasengan 1y ago
You might find this helpful: https://youtu.be/sz7NAe0G1_Y?si=focPEWli8xv7NCDi https://youtu.be/sz7NAe0G1_Y?si=focPEWli8xv7NCDi
Re verifiability: the point isn’t trust us, it’s that you don’t have to.
We built it so anyone can independently confirm what’s running.
1. All server and client code is published.
2. Builds are reproducible.
3. Each node provides cryptographic attestations of its runtime and routing identity.
4. Enclaves are used for verifiable isolation.
You can peruse the code yourself to see exactly why the transparency we bring makes legacy “trust based” VPNs obsolete: https://github.com/vpdotnet/vpnetd-sgx https://github.com/vpdotnet/vpnetd-sgx
- idiotsecant 1y agoIt looks like this boils down to 'check the magic number in the code against the magic number our server gives you. It matches!!!' Is there some indication the user has that your server isn't simply hard coded to return the right magic number? I don't understand how this provides any assurance of anything.
- MagicalTux 1y agoThe SGX certificate is signed by intel and includes a certification of the hash of the code loaded in the secure enclave ("MRENCLAVE"). When the client connects to the server, the server presents a tls certificate that includes an attestation (with OID 1.3.6.1.4.1.311.105.1) which certifies a number of things: - the TLS certificate's own public key (to make sure the connection is secure) - The enclave hash It is signed by Intel with a chain of custody going to intel's CA root. It's not "just a magic number" but "a magic number certified by Intel", of course it's up to you to choose to trust Intel or not, but it goes a much longer way than any other VPN.