All of lore.kernel.org
 help / color / mirror / Atom feed
From: ѽ҉ᶬḳ℠ <vtol@gmx.net>
To: wireguard <wireguard@lists.zx2c4.com>
Subject: Re: WG interface to ipv4
Date: Sun, 6 May 2018 18:33:09 +0200	[thread overview]
Message-ID: <dfcc55c3-795b-dfa2-7034-74b537519ea4@gmx.net> (raw)
In-Reply-To: <874ljk24jh.fsf@toke.dk>

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]


> 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.

Thanks for the expansive discourse.

> 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

Depends perhaps a bit of what the (long term) aim/goal of the WG is - 
whether to be a niche product for enthusiasts (only guessing here that 
this is the current state) or to make it into the 
mainstream/corporate/commercial arena. I doubt that server 
administrators will take to it with no control over WG's socket/iface 
exposure. Probably time will tell and/or I am wrong with that 
perspective already.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

  reply	other threads:[~2018-05-06 16:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 16:57 WG interface to ipv4 ѽ҉ᶬḳ℠
2018-05-04  1:06 ` Jason A. Donenfeld
2018-05-04  9:27   ` ѽ҉ᶬḳ℠
2018-05-05  3:44     ` Jason A. Donenfeld
2018-05-05  8:18       ` ѽ҉ᶬḳ℠
2018-05-05  9:28         ` Kalin KOZHUHAROV
2018-05-05 17:33           ` Christophe-Marie Duquesne
2018-05-05 17:53             ` ѽ҉ᶬḳ℠
2018-05-06  1:27               ` Jason A. Donenfeld
2018-05-06  7:31                 ` ѽ҉ᶬḳ℠
2018-05-06  9:00                   ` Matthias Urlichs
2018-05-06  9:26                     ` ѽ҉ᶬḳ℠
2018-05-06  0:14             ` RFE: Name of peer in configuration John Huttley
2018-05-06  1:21         ` WG interface to ipv4 Jason A. Donenfeld
2018-05-06  8:58           ` ѽ҉ᶬḳ℠
2018-05-06 13:34             ` Jordan Glover
2018-05-06 14:12               ` ѽ҉ᶬḳ℠
2018-05-06 14:17                 ` Jason A. Donenfeld
2018-05-06 15:21                 ` Toke Høiland-Jørgensen
2018-05-06 16:33                   ` ѽ҉ᶬḳ℠ [this message]
2018-05-06 18:09                     ` Jordan Glover
2018-05-06 19:39                       ` ѽ҉ᶬḳ℠
2018-05-06 21:37                         ` Android Configuration File John Huttley
2018-05-06 22:10                           ` Jason A. Donenfeld
2018-05-07  4:22                             ` John Huttley
2018-05-07 13:35                         ` WG interface to ipv4 Christophe-Marie Duquesne
2018-05-07 16:34                           ` ѽ҉ᶬḳ℠
2018-05-08  8:48                             ` Christophe-Marie Duquesne
2018-05-08  9:35                               ` ѽ҉ᶬḳ℠
2018-05-07  8:24                   ` ѽ҉ᶬḳ℠
2018-05-07  8:41                     ` Jordan Glover
2018-05-07  9:37                       ` Matthias Urlichs
2018-05-07 11:21                         ` Jordan Glover
2018-05-07  6:49           ` Kalin KOZHUHAROV
2018-05-08 15:44 Riccardo Berto
2018-05-08 16:23 ` logcabin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfcc55c3-795b-dfa2-7034-74b537519ea4@gmx.net \
    --to=vtol@gmx.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.