Re: WG interface to ipv4

["Toke Høiland-Jørgensen" <toke@toke.dk>]

=D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vtol@gmx.net> writes:

> For that matter it is pretty easy in ssh to limit its socket and
> iface/ip range exposure. Is it due to the inferior design of ssh that
> such security hardening features are made available/considered? If you
> keep the ssh keys safe that should be all that matters, should it not?

SSH is different for two reasons: It runs over TCP, and it runs in
userspace.

Because it runs over TCP, it will react to unauthenticated packets,
perform a handshake and exchange quite a bit of traffic before its gets
to the point where it can authenticate its peer. Wireguard does not
exhibit this behaviour: Instead, every data packet is authenticated
individually, and if it doesn't match it is simply dropped. So an
attacker that doesn't know the private key can't even discover that a
host is running wireguard.

Secondly, because SSH runs in userspace, a lot of the processing (such
as the TCP handshake) is done by the kernel on the application's behalf.
So the only way the application has of telling the kernel not to do
this, is by setting the listen address. Wireguard lives directly in the
kernel and so can perform the authentication directly after receiving
the packet, without suffering a context switch to userspace.

The first reason is obviously more important than the second one. Either
way, the decision about whether to add a configuration knob is a
tradeoff; where any possible security gains have to be weighed against
the added complexity (which includes maintaining the extra code, the
risk of misconfiguration, and the cognitive load on the user who has to
deal with more options). Wireguard, in general, tries very hard to avoid
configuration knobs that are not absolutely necessary; and since in this
case the security gains are lower than in many other cases (to the point
where they are mostly theoretical), this decision does make sense :)

-Toke