Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

lists.zx2c4.com

Post reply on HN
Print view View original

181–187 of 187 posts

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#181

Post by 1vuio0pswjnm7 »

shawnz wrote: post #180
1vuio0pswjnm7 wrote: post #178

Earlier quoted context omitted.

First, I provided the cable. They were commenting on the idea of using a crossover cable, not a request for one. Second, you are guessing what the commenter meant by crossover cable. I think he meant crossover cable. There is nothing to suggest otherwise. Third, I never said auto-sensing had anything to do with the OS or Microsoft. I said the IT department loved Microsoft. You got confused and made a connection betwe…

I am just trying to explain why your comment is grey. To be clear, there is no speed increase from using a crossover cable instead of a straight-through cable together with auto sensing.

But is it slower. I never said it was faster than using auto-sensing. I said it was faster (for me) than using a third computer or using Wifi.

Plus you are (again) ignoring the situations where it's an older computer that does not have auto-sensing.

True or false: Crossover cable is more versatile for direct data transfers and is not any slower than using auto-sensing.

AFAICT, there is nothing wrong with crossover cable. If there was, methinks the parent commenter wouldn't be mentioning it on HN.

I do not see grey because I use a text-only browser. It's all the same color (except italics), just how I like it. :)

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#182

Post by lmm »

tptacek wrote: post #166
lmm wrote: post #156

Earlier quoted context omitted.

> Why should WireGuard bake all that stuff into the core protocol Because all that stuff is security-critical. All that stuff needs to be incorporated into any audit of the system. Indeed it's probably where the vulnerabilities are going to be. > Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different…

This argument doesn't make any sense. The more you couple to the underlying protocol, the harder it is to audit. Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.

> Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.

Then why are modular cryptosystems (where e.g. the symmetric cipher algorithm is pluggable) a bad idea?

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#183

Post by benou »

tptacek wrote: post #179
benou wrote: post #175

Earlier quoted context omitted.

Here is an example for VPP, ~8Gbps/core of IPsec forwarding with AES-256-GCM and IMIX traffic on Skylake @2.3GHz: https://docs.fd.io/csit/master/report/vpp_performance_tests/... Note that thanks to AES-NI vectorization (an example of hw acceleration I was referring to) it reaches more than 16Gps/core on the same test on Icelake. Those numbers can grow up to 50% for big packets (1500-bytes and higher). With a high per…

This is DPDK-style user-mode direct/raw networking, isn't it?

Yes. But VPP also supports Wireguard, and when doing apple-to-apple comparisons, the performance difference between Wireguard vs IPsec AES-256-GCM is close to 2x. See https://fosdem.org/2021/schedule/event/sdn_calicovpp/attachm... slides 23 and 26: 5Gbps of Wireguard vs 9.5Gbps of IPsec.

And the main reason is the cipher: one is hw-assisted (AES-NI on x86), the other is not.

Again, I do think Wireguard is nice because it is a clean sheet design with good choices and it "just works". However when I hear "Wireguard is faster than IPsec" it is not true in my experience, and can be easily explain by the cipher choice.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#184

Post by riobard »

no_time wrote: post #172
riobard wrote: post #159

Earlier quoted context omitted.

To be honest WireGuard over Shadowsocks is neither common nor recommended, coz essentially it's TCP-over-TCP which will wreak havoc on TCP congestion control. Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common. (Disclaimer: I wrote the official Go port of Shadowsocks https://github.com/shadowsocks/go-shadowsocks2 )

Thank you for your work :D Sometimes a bad solution is better than no solution at all.

Actually I'd rather WireGuard adopt some obfuscation mechanisms, but as Jason stated it's a non-goal and the focus is to get WireGuard into mainstream OS kernels. So the only hope is to provide some obfuscation transport underneath.

Tunneling WG over SS would be inefficient for obvious reasons. Maybe there should be a more lightweight solution.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#185

Post by akerl_ »

lmm wrote: post #182
tptacek wrote: post #166

Earlier quoted context omitted.

This argument doesn't make any sense. The more you couple to the underlying protocol, the harder it is to audit. Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess.

> Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess. Then why are modular cryptosystems (where e.g. the symmetric cipher algorithm is pluggable) a bad idea?

Having a predictable boundary and having modular crypto systems are two things that can sound similar, but are really pretty opposite.

To take the popular example: OpenSSL has a plethora of extensions. If there’s a thing you want to do, odds are the spec has been extended to cover that use case.

One result of that is that many code paths exist that aren’t part of everyday usage for most users, and so those code paths get less love (and more bugs): this makes things like Heartbleed radically more likely.

Another result is that parties using the system to communicate need to agree which modules/extensions they’re going to use. This kind of negotiation has been a punching bag for vuln after vuln, because it turns out some options are going to end up having weaknesses, and thus attackers can make their lives easier if they focus on tricking parties into downgrading to weaker modules.

By contrast, having Wireguard exclusively handle point-to-point tunnel behavior, without any negotiation of modules or extensions or similar, both simplifies the code paths and avoids runtime negotiation. Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#186

Post by lmm »

akerl_ wrote: post #185
lmm wrote: post #182

Earlier quoted context omitted.

> Having a well-defined and predictable boundary between concerns in the system makes each component, and the system as a whole, easier to assess. Then why are modular cryptosystems (where e.g. the symmetric cipher algorithm is pluggable) a bad idea?

Having a predictable boundary and having modular crypto systems are two things that can sound similar, but are really pretty opposite. To take the popular example: OpenSSL has a plethora of extensions. If there’s a thing you want to do, odds are the spec has been extended to cover that use case. One result of that is that many code paths exist that aren’t part of everyday usage for most users, and so those code paths…

> Wireguard provides a boundary beyond that: it does not handle things like IPAM or a central authentication story, leaving those for another system to own. That system is then free to likewise provide a simple interface for whatever it’s doing, and gleaning all the same benefits.

Right, but that system actually needs to be implemented, and the two need to be integrated together, and that part is where I suspect the vulnerabilities are likely to be, because the interface between two systems developed separately is always the most likely point for bugs and misunderstandings to creep in.

People talk about WireGuard having fewer vulnerabilities than OpenVPN and that may be true as far as it goes, but it's missing the fact that you can't simply replace OpenVPN with WireGuard - you would have to replace it with WireGuard plus some certificate management system plus some integration between them. And if everyone builds the last part themselves, it will almost certainly have security vulnerabilities.

Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

#187

Post by midasuni »

fomine3 wrote: post #97
midasuni wrote: post #58

Earlier quoted context omitted.

I had an sstp tunnel refuse to establish a few weeks ago. WireGuard was fine. Turns out the provider was MITMing tcp/443 traffic

It's interesting that such "provider" (I assume corporate network, rather than consumer ISP) allows traffic on WireGuard UDP port.

It was a U.K. university building

They asked what ports we wanted (sigh), we said all, I suspect the ports were opened but MITM wasn’t disabled. Oddly it either passed through u mileages or it broke connections completely without inserting a fake cert.

Even more oddly GitHub was blocked but stackoverflow was allowed.

As we turned up in the vans on the Saturday morning and the recee team hadn’t clocked this (to be fair most https sites worked fine) we couldn’t get it changed - or the process for changing it was far too much given the other stuff we had to set up and the ease of the workarround.

Post reply on HN