Android 12 Appears To Support Using WireGuard

[ThoreauHD]

I'd like to see some server side connection benchmarks vs aes. The typical enterprise setup is cisco or juniper with a vpn hardware accelerator. If this is much more efficient, it may be a point of cost reduction in corp environments. Those things ain't cheap.

[flower]

Absolutly false, and I myself could make working attack on something of this sort in short amount of time. You can literally byte by byte (or character by character) decode entire sensitive information like that due to that most compressions are dictionary based.

bullshit. many https pages are gzipped and still secure.
that's even one of the arguments of the wireguard devs: do compression on the app level

good encryption doesnt care about data. and dictionary attacks? really? do you live around 1944 by any chance?

[hotaru]

bullshit. many https pages are gzipped and still secure.
that's even one of the arguments of the wireguard devs: do compression on the app level

good encryption doesnt care about data. and dictionary attacks? really? do you live around 1944 by any chance?

the pages are compressed, but cookies aren't, specifically because of this problem. it's ok to compress data that isn't sensitive (such as HTML/CSS/JS that's served to everyone), but not ok to compress data that you don't want an attacker to be able to decrypt. a VPN doesn't know which data is safe to compress and which isn't. the only secure option for a VPN is to not compress anything.

[CommunityMember]

I'd like to see some server side connection benchmarks vs aes. The typical enterprise setup is cisco or juniper with a vpn hardware accelerator. If this is much more efficient, it may be a point of cost reduction in corp environments. Those things ain't cheap.

The typical corporate VPN server does far more than just encrypt the data in transit. It integrates with the corporations authentication and authorization systems, it assigns users to subsets of networks based on those current assignments, it typically includes client side posture validation, and various client sandboxing, which corporate security folk expect in the total solution set. And it typically has to pass various certification processes, which means, in practice, not only the hardware, but service contracts, from a major vendor for ongoing support. And while the "beyondcorp" model may be the better remote work solution, it is not, yet, where most corporations are.

If you believe you can build a wireguard solution that checks all the boxes a lot cheaper than the existing solutions you should go do it, and corporations will certainly consider your alternative (and be sure to bid for booth space at the next RSA conference (whenever that is) to get visibility).

[Jabberwocky]

Great news for official wireguard support! It is a shame that some providers are not releasing wireguard configs and want you to use proprietary implementations while still marketing their service with wireguard support...

bullshit. many https pages are gzipped and still secure.
that's even one of the arguments of the wireguard devs: do compression on the app level

good encryption doesnt care about data. and dictionary attacks? really? do you live around 1944 by any chance?

Disclaimer: I am not an professional security expert nor did I spend a lot of time to make my conclusions.

I don't agree with piotrj3 or Jakobson since they failed to communicate the requirements for the attacks and claimed that it's a gernal problem which it is not, so it might sound like BS based on their claims but there is some truth to it if the conditions are right.

BREACH, CRIME, and similar like Bicycle-Attacks all depend on packet- or string-length as well as common characters which is usually linked to the src or dst addresses or URI. If the attacker cannot guess it, meaning if the data is not isolated or there's not any other traffic then it's worthless. A VPN makes this extremely expensive to guess. You have no idea to which domain the abetrary length data belongs... if it was outside of a VPN you can at least get the IP of the remote and try to obtain URIs or something.

Here's some references for someone who wants to go through the effort to make their own informed conclusions:

https://security.stackexchange.com/questions/20406/is-http-compression-safe

https://github.com/nealharris/BREACH (c# sigh)

https://arxiv.org/abs/2002.01513

My conclusion: It's good practice to pad data with variable length prior to encrypting/compressing (although this is usually up to the service provider not the end-user). There's much bigger things to worry about than these HTTPS vulnerabilites. I dread hardware vulnerabilities and corrupt/leaked CA certs. While there was a fair amount of those issues the ones that effected me the most over the past decade was much more simple... Much of my private data was leaked by my government over anonymous FTP (not too long ago). It is possible to open a credit bank account using only my leaked data. Nobody was held accountable for the leak. I'm not very patriotic at the moment.

[starshipeleven]

Still won't mean squat until servers also support it. I don't see that happening in corporate environments anytime soon. (Yes, I know it's happening elsewhere.)

The servers can just use the go userspace implementation, it's not like all other VPNs are supported in the kernel.

If you mean "windows" then tough luck, I'm still seeing way too much modern deployments that use the total shit pptp as "corporate VPN" (that not only is not secure but it's a pain to pass through firewalls if you have multiple connections).

[starshipeleven]

- Might need a LTM helper to maintain state if connection needs persistence

what does this mean?

[starshipeleven]

I'd like to see some server side connection benchmarks vs aes. The typical enterprise setup is cisco or juniper with a vpn hardware accelerator. If this is much more efficient, it may be a point of cost reduction in corp environments. Those things ain't cheap.

From my own experience and some other tests done by people on the internet https://blog.entrostat.com/openvpn-v...ormance-tests/ and https://blog.morad-edwar.com/wiregua...rk-vs-openvpn/ wireguard is at least twice as fast as a OpenVPN in the same x86 with AES-NI.


Since I've also used it in OpenWrt in devices that have very weak CPUs, you can usually expect wireguard to have between two and three times the performance/bandwith on a crappy ARM or MIPS system (crappy in the sense that it's running the whole pocket router and wifi AP from a USB port worth of power) like the small GL.Inet minirouters. So like 100Mbit instead of 30Mbit.
The official PR material of GL.Inet for this particular device also claims large performance difference (scroll down until you see the blue and black bars) https://www.gl-inet.com/products/gl-e750/ of 10 Mbit with OpenVPN and 50 Mbit with WIreguard.

It really there isn't much of a contest.

[edwaleni]

what does this mean?

LTM = Load Traffic Manager ie: F5, Cisco, Juniper
Wireguard default = UDP
if you are running an application with Wireguard that has specific timing requirements it may time out waiting for the tunnel to reestablish with its gateway. So you can tell an LTM to maintain a persistent state between the endpoints.

Also helpful if you are load balancing Wireguard clients to multiple Wireguard gateways. Instead of telling the Wireguard clients all of the IP addresses of its peers. You can provide a single VIP for them to talk to. Then the LTM can manage the persistence of the sessions being requested if necessary.

[starshipeleven]

LTM = Load Traffic Manager ie: F5, Cisco, Juniper
Wireguard default = UDP
if you are running an application with Wireguard that has specific timing requirements it may time out waiting for the tunnel to reestablish with its gateway. So you can tell an LTM to maintain a persistent state between the endpoints.

I'm not familiar with high end networking equipment so I might still not understand fully what a LTM does.

Wireguard has a keep-alive functionality to keep the NAT tunnel open and re-connects if something changes in the connection (i.e. for example the client is transitioning from a wifi to a LTE connection). The lowest value you can set this is to send acks every second, with default value of 25.

Does it still need configuration in the LTM to maintain a persistent state or does this suffice?

Also helpful if you are load balancing Wireguard clients to multiple Wireguard gateways. Instead of telling the Wireguard clients all of the IP addresses of its peers. You can provide a single VIP for them to talk to. Then the LTM can manage the persistence of the sessions being requested if necessary.

Afaik Wireguard can do that already, aka you can set a single "server" instance that knows all "clients" in its config and then set all clients to only know the "server" in their config, the "hub and spoke" topology. https://www.jordanwhited.com/posts/wireguard-endpoint-discovery-nat-traversal/
Everyone will be able to see everyone else even if the clients don't know all IPs or keys, but of course everything will be routed through the "VIP" server because that's the only one that knows all clients. (in that article the guy goes on and adds the ability to bypass the VIP when sending stuff between peers, but of course you still need the VIP for the first connection)

This is more or less the "default" situation for most people, with all their devices inside a NATted network that are connecting to a single "server" in a cheapo cloud VM or their home server with a public IP.