Dead Simple VPN
balaskas.gr
balaskas.gr
I also port-forwarded 443 to my SSH server in case port 22 is blocked.
dnscrypt-proxy, libsodium, libhydrogen, minisign, dsvpn, probably others I've never heard of.
TCP is sometimes a must (library Wi-Fi that supports only known ports). But UDP is (i think?) better for wrapping TCP traffic.
My point was your conflation of L3 and L4. And in fact TCP does have some changes on v6 from v4. Consider, for example that ARP, is replaced by Neighbor Discovery (ND) and that is added to TCP/IPv6. So... If we're splitting hairs now then not exactly.
Also, when you are using TCP you don’t care whether it is using ND or ARP. That’s what abstraction means. The implementation of course cares, but when you use it you do not and if you do the implementation is incorrect.
There is only one L3 to the local stack at any given point in packet flow. Sure, you can run IP in IP but the parent, or root, IP stack is the one in control until the encapsulated IP is deencapsulated and moved up. Encapsulating a L3 protocol doesn't magically make it something else as it pertains to OSI.
Finally TCP isn't an abstraction and it has rules based on it's version. So, yes, if you're writing network applications at the TCP level you very much do care about ND or ARP.
As for ARP vs ND, when I do
bind('localhost', 5555, 'TCP')
And herein lies the issue. A layer 3 protocol can never be anything else. Unless you're writing some sort of dissector or have another use case. This isn't a "belief", it is what it is. But even when said layer 3 protocol rides a higher layer, let's say IPv4 on UDP, it's still a layer 3 protocol that is layer 4 payload until decapsulated and processed as such. What you describe is encapsulation and decapsulation, this isn't new or interesting and in most cases it's generally a bad idea just looking at it from a perspective of overhead.
I'm also not sure your pseudo code is legit considering you're binding a socket that's already been defined and the socket() is the real question mark here that differentiates IPv4 and IPv6. I think you may have glossed over the fact that some platforms don't support binding v4 on v6 sockets, while some do. Regardless your example is neither universally correct or ideal in many cases.
Or say you managed to run UDP directly on top of ETH. Because if you don’t need routing across different networks this is perfectly possible. A protocol is just two interfaces: where it interacts with the lower level protocol and higher level protocol. It is all encapsulation, that’s my point. This is why the layer model is mostly not really used when discussing these things.
So back to the example or UDP being implemented as a layer 3 protocol: when using it, you wouldn’t actually know the difference, would you?
As for my code example, you are right. It should be like so:
s = socket(TCP, IPv6);
bind(s, “localhost”, 5555);
c = accept(s);
"This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol."
As for your code, again, you make a lot of assumptions. As I mentioned before opening a socket as IPv6 does not guarantee backwards compatibility with IPv4 addressing. So, again, my point is that you do have to care about the version of IP. In your original example you conveniently skipped the socket call and claimed "See, I can just consume any IP!". Now you're just glossing over the glaring assumption, as I stated in the last post, that not every platform guarantees backward compatibility with IPv4 on an IPv6 socket.
Also... Your pigeon analogy makes zero sense to the argument you're attempting to make because it's highly irrelevant to the protocols and how they actually work in computing environments.
If you care to read the OSI layer 3 protocols state that they are concerned with deciding which physical path data will take. UDP and TCP have no routing facilities I'm aware of because port numbers don't define path. So, again, UDP is not a layer 3 protocol just because you feel like it is.
Where in there do you see anything about ARP or ND? Or hops vs TTL? Or IP packet header sizes? Or header checksums? Or priority flags? You can take this code, add a couple of macros for getting the correct AF_ value and structs and the code would be 100% abstracted away from any mention of the underlying layer 3 protocol.
Google has been developing transport layer protocols on top of UDP for years now. Why? Because getting a new layer 4 protocol to work is nearly impossible. Yet, if we all agreed that it was something we wanted, they could easily do so, which makes these new protocols functionally transport layer. If it helps you sleep at night, you can say that they are temporarily exiled to be encapsulated in UDP, but really they'll return some day to their proper place in the OSI model.
That statement could need some more explanation in my opinion. I never felt it being much difficult.
It sounds like OP would've like to use wg really, but only had TCP 80/443 to play with.
Most people configuring their own OpenVPN installation will think the job done when it begins functioning, but there is a difference between functional and secure; just look at telnet! OpenVPN makes it too easy to create a system that 'works' but isn't secure.
`ssh -D 1080 -C -q -N root@your-vps`
> root@your-vps
People allow for root ssh connections?
Keys should make it secure, and a personal VPS obviates audit requirements, so sure.
Security is multi dimensional matter, you can't just rely on rules like "no ssh to root" or "password should be more than 20 characters".
In my case ssh is allowed from 2 IP addresses (much more useful rule then "no ssh to root "btw!) with key auth (passwd auth disabled). Don't see any problem with that.
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).
I had similar experience lately whenever using the mobile internet in poorer coverage cases (eg. a high speed train Brussels-Paris or Brussels-London) which result in frequent and big variations of latency. Of course that all is decoupled congestion control.
If anyone compared the performance of this solution on poor connections with and without BUFFERBLOAT_CONTROL, would be very very interesting to know the results!
Casinos are so 20th century
For most business and domestic issues they just lack enforcers, interest, will
For data yeah it would create a silly game if there were attractive hosting privileges. But there still might be a business play here: people flock to Iceland and Switzerland on pure misinterpretations of what a law means in practice.
There was a founder here that chose Iceland servers because of no formal data sharing agreement with US, and people showed case law where the FBI merely asked Reyjavik police to tap a server.
Point being that it could still be a cash cow for US reservations
Which reinforces my point? These countries offer people nothing.
It’s probably less hassle than dealing with uncle sam, the cia/fbi and more than anything else, billing to random weirdos that this month have funds on their prepaid card and next month who knows.
Cash is better, I guess.
When working for an un-named poker company we had a hosted a server. When a hardware problem happened we had to drive and replace ourselves.
The cost is high and getting accepted requires knowing someone but safest place to host in North America for gaming related materials.
Remember bodog.. I believe they hosted game servers as well there.
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.
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.
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.
> 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.
Wireguard achieves PFS using regular ephemeral diffie-hellman key exchanges. If I understand the scenario you describe, Police has initial (long-term) key (from either endpoint or both) and taps VPS traffic. The long term key can probably be used to get the initial negotiation of the tunnel, but after the first ephemeral key exchange it can't decrypt any more of the traffic. Why? Well both endpoints kept their secret (random) portion of the key exchange on their machine, and continually wipe it (and the derived key) after every key exchange. So police needs the interstitial derived keys from either endpoint to decrypt the traffic. But it'll be probably too late after the conversation is over.
So what does those last two ip means? Similarly for the client.
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.