If you already have OpenSSH installed, it has a built-in tunnel you can activate with a single command-line argument that exposes a SOCKS server on localhost.
UDP is just an IP packet with port information. That is all. That’s why it is so easy to do something like TCP/UDP instead of TCP/IP, even though nobody calls it that. TCP over TCP is bad because the protocol uses congestion for traffic control, and if the underlying connection is lossless and never gets congested, the inner TCP layer cannot work right.
So correct me if I am wrong but this is doing IP in TCP right ? Iirc, this is a big issue for tcp flow control, which relies on packet loss to detect congestion: as you encapsulate stuff in tcp stream, there will be no more packet loss and the tunelled tcp will not throttle correctly.
Did not read the code yet, so maybe there is something to simulate congestion packet loss.
TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).
Algo is a set of scripts that sets up IPSEC and WireGuard VPN on a Linux server. This dsvpn is an entirely new VPN implementation—like IPSEC or WireGuard—written by jedisct1 from scratch.
The security of block ciphers, permutations, hash functions and higher-level constructions is studied by modifying the function until some of its claimed properties are invalidated.
What is being analyzed is not the actual function. How much changes had to be made and how significant they were is an indication of the security margin of the actual function.
In this paper, key recovery requires a made-up mode, or an existing mode, but used incorrectly (nonce reuse with the same key and different messages) 2^43.8 times. In addition, the permutation had to be reduced to 6 rounds. The normal number of rounds is 12, which makes a huge difference.
The analysis actually shows that the security margin of the real construction is extremely comfortable.
While nice to have, this is not terribly useful in the context of a VPN.
PFS would prevent the following scenario: you’re suspected to be an axe murderer, the police asks the cloud provider to tap your VPS traffic, and, later, asks for a dump of that VPS to get the key. Haha, the key is still valid, so the previously recorded traffic can be decrypted!
PFS however would not prevent the following more likely scenario: the police asks for the key, and effortlessly decrypts everything from now on. PFS doesn’t provide post-compromise security, which is far more important.
But since a VPN server is essentially a proxy that decrypts traffic between itself and a client to forward decrypted packets to remote servers, here’s an even more likely scenario: the VPS is tapped, and packets exchanged with the VPN client is not something to waste any time on since for each of them, the server also sent or received a decrypted copy.
That being said, a simple way to get PFS and post-compromise security is to change the key regularly. If you’re just someone who needs a personal VPN to work in a coffee shop whose public WiFi has overzealous firewall rules, this is not something you have to worry too much about.
If you’re an axe murderer, just add key rotation to your post-crime routine.
A VPN creates a virtual network between two machines. Each end needs an IP address.
In your example, `10.8.0.254` is the address that will be assigned to the server and `10.8.0.2` is the address that will be assigned to the client. These addresses are only valid within the tunnel. They are not the real IP addresses.
If you do `ping 10.8.0.254` from the client, you'll get a response from the server. If you do `ping 10.8.0.2` from the server, you'll get a response from the client. If you do `ping 10.8.0.2` from the server, you'll get a response from itself. Which is not very useful.
These IP addresses are not reachable outside the tunnel. The network is private.
You can use any pair of addresses you want as long as they are not used by anything else.
[+] [-] TazeTSchnitzel|6 years ago|reply
[+] [-] rkeene2|6 years ago|reply
[+] [-] m-p-3|6 years ago|reply
I also port-forwarded 443 to my SSH server in case port 22 is blocked.
[+] [-] majke|6 years ago|reply
[+] [-] regecks|6 years ago|reply
dnscrypt-proxy, libsodium, libhydrogen, minisign, dsvpn, probably others I've never heard of.
[+] [-] aptmiguk|6 years ago|reply
https://github.com/jedisct1/minisign
[+] [-] loup-vaillant|6 years ago|reply
[+] [-] hoschicz|6 years ago|reply
TCP is sometimes a must (library Wi-Fi that supports only known ports). But UDP is (i think?) better for wrapping TCP traffic.
[+] [-] IgorPartola|6 years ago|reply
[+] [-] ahnick|6 years ago|reply
[+] [-] xrisk|6 years ago|reply
[1] https://github.com/jedisct1/dsvpn#why
[+] [-] kbody|6 years ago|reply
`ssh -D 1080 -C -q -N root@your-vps`
[+] [-] dependenttypes|6 years ago|reply
> root@your-vps
People allow for root ssh connections?
[+] [-] antoinealb|6 years ago|reply
Did not read the code yet, so maybe there is something to simulate congestion packet loss.
[+] [-] lox|6 years ago|reply
TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] galapago|6 years ago|reply
[+] [-] aorth|6 years ago|reply
[+] [-] grenoire|6 years ago|reply
[+] [-] xrisk|6 years ago|reply
[+] [-] qrbLPHiKpiux|6 years ago|reply
[+] [-] acqq|6 years ago|reply
https://eprint.iacr.org/2019/447
"Practical Key-recovery Attacks on Round-Reduced Ketje Jr, Xoodoo-AE and Xoodyak"?
As far as I understand round-reduced doesn't have to mean all rounds are broken, but it is still something to think about.
[+] [-] jedisct1|6 years ago|reply
What is being analyzed is not the actual function. How much changes had to be made and how significant they were is an indication of the security margin of the actual function.
In this paper, key recovery requires a made-up mode, or an existing mode, but used incorrectly (nonce reuse with the same key and different messages) 2^43.8 times. In addition, the permutation had to be reduced to 6 rounds. The normal number of rounds is 12, which makes a huge difference.
The analysis actually shows that the security margin of the real construction is extremely comfortable.
[+] [-] armitron|6 years ago|reply
[1] https://en.wikipedia.org/wiki/Forward_secrecy
[+] [-] jedisct1|6 years ago|reply
PFS would prevent the following scenario: you’re suspected to be an axe murderer, the police asks the cloud provider to tap your VPS traffic, and, later, asks for a dump of that VPS to get the key. Haha, the key is still valid, so the previously recorded traffic can be decrypted!
PFS however would not prevent the following more likely scenario: the police asks for the key, and effortlessly decrypts everything from now on. PFS doesn’t provide post-compromise security, which is far more important.
But since a VPN server is essentially a proxy that decrypts traffic between itself and a client to forward decrypted packets to remote servers, here’s an even more likely scenario: the VPS is tapped, and packets exchanged with the VPN client is not something to waste any time on since for each of them, the server also sent or received a decrypted copy.
That being said, a simple way to get PFS and post-compromise security is to change the key regularly. If you’re just someone who needs a personal VPN to work in a coffee shop whose public WiFi has overzealous firewall rules, this is not something you have to worry too much about.
If you’re an axe murderer, just add key rotation to your post-crime routine.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] tmd83|6 years ago|reply
So what does those last two ip means? Similarly for the client.
[+] [-] jedisct1|6 years ago|reply
A VPN creates a virtual network between two machines. Each end needs an IP address.
In your example, `10.8.0.254` is the address that will be assigned to the server and `10.8.0.2` is the address that will be assigned to the client. These addresses are only valid within the tunnel. They are not the real IP addresses.
If you do `ping 10.8.0.254` from the client, you'll get a response from the server. If you do `ping 10.8.0.2` from the server, you'll get a response from the client. If you do `ping 10.8.0.2` from the server, you'll get a response from itself. Which is not very useful.
These IP addresses are not reachable outside the tunnel. The network is private.
You can use any pair of addresses you want as long as they are not used by anything else.