wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Gawen ARAB]

[-- Attachment #1.1: Type: text/plain, Size: 3518 bytes --]

Hello,

I've been giving my free time on a side project called WireHub
(https://github.com/gawen/wirehub), which is a simple tool to build
decentralized, peer-to-peer and secure overlay networks. It dynamically
configures WireGuard tunnels, discoverying peers' endpoints via a
authenticated
DHT, going through NATs, and relaying the WireGuard traffic if no P2P
communication is possible.

Overlay networks are defined by a single human-readable file which lists the
hostname and public key for each nodes of the network. Here's an example:

    name test               # network name is 'test'
    subnet 10.0.42.0/24     # overlay subnetwork is 10.0.42.0/24
    workbit 8               # PoW parameter for DHT security

    # a public bootstrap node
    boot P17zMwXJFbBdJEn05RFIMADw9TX5_m2xgf31OgNKX3w bootstrap.wirehub.io

    # Add trusted node 'a.test' to the overlay network.
    # Each trusted node are at least identified by an human-readable
hostname
    # and a base64 public key.
    trust a.test KJ7YGrBeqLLm_JJ1huIS26OnqAVFy57z5UJqjyMagW4

    # If the endpoint of a peer is static, it might be set after the public
key.
    # Note that this is optional, as endpoints can be dynamically found in
the
    # DHT.
    trust b.test eIix5ldvqDzOIrG9ViKTe9TSBlF4g9nUwKi20C06hFM 12.34.56.78

    # By default WireHub assigns nodes an (overlay) private IP, but a static
    # private IP might be defined
    trust c.test 10.0.42.254 kKZzuIm11zkBSHL9ETRwEthIBbLTvz840F_k4mhI_Hs
    ...

To start a peer,

    # wh up ./config private-key ./sk

When a network is up, the node's hostnames are resolved in userland.

    # ping b.test
    PING 10.0.42.2 (10.0.42.2): 56 data bytes
    64 bytes from 10.0.42.2: seq=0 ttl=64 time=106.801 ms
    64 bytes from 10.0.42.2: seq=1 ttl=64 time=49.778 ms

WireGuard and WireHub uses the same Curve25519 key. WireHub keys must be
generated with `wh genkey`, which adds a Proof-of-Work to the generation of
the
Curve25519 key, in order to mitigate Sybil attacks on the DHT. A high
workbit
will require more work to generate a valid key.

    # wh genkey workbit 8       # fast
    MFaqLuutFvNs79Xc9zhOUofIbL3xSLz1uo+RB1xB73s=
    # wh genkey workbit 8 | wh pubkey | wh workbit
    8
    # wh genkey workbit 16      # will take more time to generate
    kLfotsCIfB/7OcDGeLenptfy2Dzav9wmVZjVQ0Gvnk0=
    # wh genkey workbit 16 | wh pubkey | wh workbit
    16

    # wg genkey | wh pubkey | wh workbit    # WireGuard keys have 0 workbit
    0

Under the hood, WireHub runs its own UDP protocol, binding the same UDP port
than the WireGuard interface (for NAT trasversal technique reasons). It
does so using
libpcap. The first byte of a WireHub packet is 0xff, which corresponds to an
invalid WireGuard packet with message type outside the valid range
0x00-0x03.

WireHub currently authenticates its packets with a custom cryptographic
scheme
based on the node's keys. In the future, it might be better to tunnel
WireHub
packets through WireGuard, yet I'm not sure how to do that simply at the
moment,
as WireHub packets are not IP packets but more like authenticated messages.

There's much room for improvement (security, allowed-ips management, more
UDP
hole punching techniques, faster relaying), but it's usable. Docker images
are
provided to ease quick starting.

Feel free to test and give some feedbacks!

Also, I'll be at FOSDEM 2019 next week-end, so see you there! 🍺

Gawen

[-- Attachment #1.2: Type: text/html, Size: 4120 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Steve Gilberd]

[-- Attachment #1.1: Type: text/plain, Size: 5762 bytes --]

I very much like the idea of this project - I've been looking for a decent
full-mesh L3 VPN for ages, and have never found a solution I've been
properly happy with. Thanks for your work in developing this solution :-).

However - I'm concerned about some of the potential increased attack
surface that your architecture introduces:
 - uses extra crypto functionality which is not already part of wireguard;
and
 - passes messages across public networks using that functionality; and
 - clamps the wireguard keys in some unspecified way to embed a
proof-of-work (in fairness, I haven't read the code, so please correct me
if I have misunderstood).

For what it's worth, if it would be possible to also encapsulate your
control protocol inside wireguard, that would be vastly preferable: it
allows the transport cryptography to be implemented in one place, once
(i.e. in wireguard), and lets wirehub be a purely organisational overlay
for managing links, rather than touching the crypto and introducing
troubling extra complexities.

I would also love to see some sort of PKI option with this project, to
avoid having to explicitly trust all the peers. I'd prefer to be able to
simply provide the peers with a signature they can present to other peers
that proves they can be trusted (or even better, have that signature
generated by a nominated host at connect / setup time for each peer, which
avoids much of the shenanigans involved with handling expiry, revocations
etc.) Having the ability to tell all peers on the network to immediately
terminate all connections with a specific compromised peer would also be
handy.

Cheers,
Steve

On Wed, 30 Jan 2019 at 10:15 Gawen ARAB <g@wenarab.com> wrote:

> Hello,
>
> I've been giving my free time on a side project called WireHub
> (https://github.com/gawen/wirehub), which is a simple tool to build
> decentralized, peer-to-peer and secure overlay networks. It dynamically
> configures WireGuard tunnels, discoverying peers' endpoints via a
> authenticated
> DHT, going through NATs, and relaying the WireGuard traffic if no P2P
> communication is possible.
>
> Overlay networks are defined by a single human-readable file which lists
> the
> hostname and public key for each nodes of the network. Here's an example:
>
>     name test               # network name is 'test'
>     subnet 10.0.42.0/24     # overlay subnetwork is 10.0.42.0/24
>     workbit 8               # PoW parameter for DHT security
>
>     # a public bootstrap node
>     boot P17zMwXJFbBdJEn05RFIMADw9TX5_m2xgf31OgNKX3w bootstrap.wirehub.io
>
>     # Add trusted node 'a.test' to the overlay network.
>     # Each trusted node are at least identified by an human-readable
> hostname
>     # and a base64 public key.
>     trust a.test KJ7YGrBeqLLm_JJ1huIS26OnqAVFy57z5UJqjyMagW4
>
>     # If the endpoint of a peer is static, it might be set after the
> public key.
>     # Note that this is optional, as endpoints can be dynamically found in
> the
>     # DHT.
>     trust b.test eIix5ldvqDzOIrG9ViKTe9TSBlF4g9nUwKi20C06hFM 12.34.56.78
>
>     # By default WireHub assigns nodes an (overlay) private IP, but a
> static
>     # private IP might be defined
>     trust c.test 10.0.42.254 kKZzuIm11zkBSHL9ETRwEthIBbLTvz840F_k4mhI_Hs
>     ...
>
> To start a peer,
>
>     # wh up ./config private-key ./sk
>
> When a network is up, the node's hostnames are resolved in userland.
>
>     # ping b.test
>     PING 10.0.42.2 (10.0.42.2): 56 data bytes
>     64 bytes from 10.0.42.2: seq=0 ttl=64 time=106.801 ms
>     64 bytes from 10.0.42.2: seq=1 ttl=64 time=49.778 ms
>
> WireGuard and WireHub uses the same Curve25519 key. WireHub keys must be
> generated with `wh genkey`, which adds a Proof-of-Work to the generation
> of the
> Curve25519 key, in order to mitigate Sybil attacks on the DHT. A high
> workbit
> will require more work to generate a valid key.
>
>     # wh genkey workbit 8       # fast
>     MFaqLuutFvNs79Xc9zhOUofIbL3xSLz1uo+RB1xB73s=
>     # wh genkey workbit 8 | wh pubkey | wh workbit
>     8
>     # wh genkey workbit 16      # will take more time to generate
>     kLfotsCIfB/7OcDGeLenptfy2Dzav9wmVZjVQ0Gvnk0=
>     # wh genkey workbit 16 | wh pubkey | wh workbit
>     16
>
>     # wg genkey | wh pubkey | wh workbit    # WireGuard keys have 0 workbit
>     0
>
> Under the hood, WireHub runs its own UDP protocol, binding the same UDP
> port
> than the WireGuard interface (for NAT trasversal technique reasons). It
> does so using
> libpcap. The first byte of a WireHub packet is 0xff, which corresponds to
> an
> invalid WireGuard packet with message type outside the valid range
> 0x00-0x03.
>
> WireHub currently authenticates its packets with a custom cryptographic
> scheme
> based on the node's keys. In the future, it might be better to tunnel
> WireHub
> packets through WireGuard, yet I'm not sure how to do that simply at the
> moment,
> as WireHub packets are not IP packets but more like authenticated messages.
>
> There's much room for improvement (security, allowed-ips management, more
> UDP
> hole punching techniques, faster relaying), but it's usable. Docker images
> are
> provided to ease quick starting.
>
> Feel free to test and give some feedbacks!
>
> Also, I'll be at FOSDEM 2019 next week-end, so see you there! 🍺
>
> Gawen
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019, The Terrace, Wellington 6143, NZ*

[-- Attachment #1.2: Type: text/html, Size: 7328 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Rene 'Renne' Bartsch, B.Sc. Informatics]

Am 30.01.19 um 00:55 schrieb Steve Gilberd:
> I very much like the idea of this project - I've been looking for a decent full-mesh L3 VPN for ages, and have never found a solution I've been properly happy with. Thanks for your work in developing this solution :-).

Me, too - Thanks! :-)

> However - I'm concerned about some of the potential increased attack surface that your architecture introduces:
>   - uses extra crypto functionality which is not already part of wireguard; and
>   - passes messages across public networks using that functionality; and
>   - clamps the wireguard keys in some unspecified way to embed a proof-of-work (in fairness, I haven't read the code, so please correct me if I have misunderstood).
> 
> For what it's worth, if it would be possible to also encapsulate your control protocol inside wireguard, that would be vastly preferable: it allows the transport cryptography to be implemented in one place, once (i.e. in wireguard), and lets wirehub be a 
purely organisational overlay for managing links, rather than touching the crypto and introducing troubling extra complexities.

I agree. Piggybacking Wirehub communication on Wireguard encryption instead of custom UDP saves an additional layer of encryption an thus superfluous code.
Wirehub should only use ZINC functions to sign/validate the DHT entries with the Wireguard private/public key.

I suggest to use a cryptographically generated IPv6 address (128-bit hash of Wiregurad public key with first n bits replaced by a Wireguard-specific IPv6 prefix)
for routing and management purposes. Adding a reverse-lookup IPv6-address -> Wireguard public key via DHT would allow a public IPv6 overlay network
with authorization via firewall rules. Nodes should also be able to announce their subnets via DHT.

> 
> I would also love to see some sort of PKI option with this project, to avoid having to explicitly trust all the peers. I'd prefer to be able to simply provide the peers with a signature they can present to other peers that proves they can be trusted (or even better, have that signature generated by a nominated host at connect / setup time for each peer, which avoids much of the shenanigans involved with handling expiry, revocations etc.) Having the ability to tell all peers on the network to immediately terminate all connections with a specific compromised peer would also be handy.

A PKI increases complexity a lot. I suggest using the cryptographically generated IPv6 address approach with distributed firewall rules.

Regards,

Renne
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Gawen ARAB]

[-- Attachment #1.1: Type: text/plain, Size: 4178 bytes --]

Hey Steve,

Thank you for your feedback.

> - uses extra crypto functionality which is not already part of wireguard;
and
> - passes messages across public networks using that functionality; and
>
> For what it's worth, if it would be possible to also encapsulate your
control protocol inside wireguard, that would be vastly preferable: it
allows the transport cryptography to be implemented in one place, once
(i.e. in wireguard), and lets wirehub be a purely organisational overlay
for managing links, rather than touching the crypto and introducing
troubling extra complexities.

I agree.

The main issue to implement this is to accept message_handshake_initiation
packet from unknown initiators. WireHub peers discover themselves through
the
DHT. One peer does not know in advance what peers will communicate with it.
The
current implementation of WireGuard drops packets from unset peers.

I plan to implement a replay mechanism of the message_handshake_initiation
packet, where WireHub peeks it, decrypts the initiator's public key, and if
unknown and has enough workbit, will add it to WireGuard's peers before
replaying the packet. The main advantage is to avoid adding usage-specific
features to WireGuard, but I need to re-implement part of the WireGuard
crypto
scheme (plus the replay mechanism might be a little dirty).

Another approach might be to modify WireGuard to add a hook called when a
unknown peer initiates a session. When it happens, a userland app (here,
WireHub) is called to accept or reject dynamically the initiator. This
reduces
the overhead of processing twice the message_handshake_initiation packet
from
the previous solution, but it would add complexity to the WireGuard's code.

    on_message_handshake_initiation(m) {
        // decrypt static_public

        if (unknown_peer(static_public)) {
            if (hook) {
                r = hook(static_public)     // call dynamically WireHub
            }

            // if no hook or hook rejects initiator, drop packet
            if (!hook or !r.accept_initiator) {
                return drop();
            }

            // else add iniatiator to peers
            set_peer(iniator.static_public,
                allowed_ips=r.allowed_ips,
                endpoint=iniator.endpoint,
                preshared_key=r.preshared_key,
                persistent_keep_alive=r.persistent_keep_alive)
        }

        // process message_handshake_initiation
    }

> - clamps the wireguard keys in some unspecified way to embed a
proof-of-work (in fairness, I haven't read the code, so please correct me
if I have misunderstood).

The workbit of a Curve25519 key is the count of trailing zeros of a
derivation
of the public key.

    workbit(sk, namespace='public') {
        k = pub(sk)
        h = blake2b(k ⊕ namespace)
        wb = trailing_0s(h) // see __builtin_clz
        return wb
    }

WireHub peers only accept peers which public key has enough workbits. This
makes
identity expensive to generate, which mitigates Sybil attacks.

When workbit is incremented by one, the count of possible Curve25519 keys is
divided by 2. I don't know if it's a problem? I explored other PoW scheme,
but
the current implementation is the simplest one I found.

> I would also love to see some sort of PKI option with this project, to
avoid having to explicitly trust all the peers. I'd prefer to be able to
simply provide the peers with a signature they can present to other peers
that proves they can be trusted (or even better, have that signature
generated by a nominated host at connect / setup time for each peer, which
avoids much of the shenanigans involved with handling expiry, revocations
etc.) Having the ability to tell all peers on the network to immediately
terminate all connections with a specific compromised peer would also be
handy.

I plan to build this on top of WireHub, once it will be more mature.

A PKI daemon may read peer's certificates, signed by a given authority,
keeps a
list of the trusted peers and updates in live the wirehub's conf file.

Cheers,
Gawen

[-- Attachment #1.2: Type: text/html, Size: 4702 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Gawen ARAB]

[-- Attachment #1.1: Type: text/plain, Size: 533 bytes --]

Hey Rene,

> I suggest to use a cryptographically generated IPv6 address (128-bit hash
of Wiregurad public key with first n bits replaced by a Wireguard-specific
IPv6 prefix)
> for routing and management purposes. Adding a reverse-lookup IPv6-address
-> Wireguard public key via DHT would allow a public IPv6 overlay network
> with authorization via firewall rules. Nodes should also be able to
announce their subnets via DHT.

I agree. I plan to use the subnet ORCHID as defined by RFC 4843.
See command `wh orchid`.

Cheers,
Gawen

[-- Attachment #1.2: Type: text/html, Size: 635 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Rene 'Renne' Bartsch, B.Sc. Informatics]

Am 30.01.19 um 16:46 schrieb Gawen ARAB:
> Hey Rene,
> 
>  > I suggest to use a cryptographically generated IPv6 address (128-bit hash of Wiregurad public key with first n bits replaced by a Wireguard-specific IPv6 prefix)
>  > for routing and management purposes. Adding a reverse-lookup IPv6-address -> Wireguard public key via DHT would allow a public IPv6 overlay network
>  > with authorization via firewall rules. Nodes should also be able to announce their subnets via DHT.
> 
> I agree. I plan to use the subnet ORCHID as defined by RFC 4843.
> See command `wh orchid`.
> 

Great! :-)

RFC 4843 has been obsoleted by RFC 7343. Please use RFC 7343 instead and re-use as much cryptographic code of Wireguard as possible to reduce possible bugs and weaknesses.

I suggest to omit the custom UDP protocol and libpcap by adding an ORCHIDv2 address to the wireguard network device and run the DHT via a port of the ORCHIDv2 address.
That way you can easily calculate the ORCHIDv2 address of a peer from the public key and connect the DHT.


Regards,

Renne
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard