" /> Networking - Libretech Journal
Libretech Journal

Networking

Various Networking Types, Protocols, Procedures, Ideas

  • Posted on

    Comprehensive WireGuard Analysis: The research performed a unified symbolic analysis of the WireGuard protocol (including WireGuard with cookies) using three tools (ProVerif, Tamarin, and Seic+), going beyond previous analyses in scope and depth of the threat model.

    Threat Model Enhancements: The analysis incorporated a more comprehensive threat model than previous work, including:
    - Read and write access to all keys.
    - Pre-computation vulnerability: Modeling the impact of pre-computed values stored in memory, showing that its compromise can be as detrimental as private key compromise.

    Security Property Verification: The analysis verified three key security properties:
    - Message agreement.
    - Key secrecy (including perfect forward secrecy).
    - Anonymity.

    Key Findings Regarding Security Properties:
    - Compromise of initial static key distribution severely impacts all security properties.
    - Compromise of the pre-shared key (PSK) jeopardizes all security properties; the PSK should be mandatory, not optional.
    - The pre-computation significantly weakens security in some cases, mirroring the impact of private key compromise; its removal is recommended.
    - WireGuard does not provide anonymity as claimed. Attacks were identified leveraging MAC values in the first two messages, revealing initiator and responder identities.

    Proposed Anonymity Fixes: Three fixes for the anonymity flaws are proposed: removing MACs entirely or modifying the MAC computation to incorporate a secret key known only to the initiator and responder. These fixes have been formally verified.

    Recommendations:
    - Users should always use a pre-shared key.
    - Secure initial static key distribution is crucial.
    - Users should not rely on WireGuard for anonymity.
    - Stakeholders should remove the pre-computation step to enhance security and address the anonymity vulnerabilities.

    Methodology: The use of multiple tools (ProVerif and Tamarin, with Seic+ as a bridge) provided faster results from ProVerif and a more in-depth threat model analysis from Tamarin. The models and results are publicly available.

  • Posted on

    WireGuard is a new, fast, and simple VPN protocol now integrated into the Linux kernel (version 5.4 and later).

    Installation on Ubuntu is straightforward using the apt package manager:
    sudo apt install wireguard

    Configuration involves generating private and public keys using wg genkey and wg pubkey.

    The server and client configurations are managed through text files (e.g., wg0.conf), specifying private keys, IP addresses, listening ports, and peer public keys.

    To route all client traffic through the VPN, use AllowedIPs = 0.0.0.0/0 in the client configuration. The server needs IP forwarding enabled (/proc/sys/net/ipv4/ip_forward = 1).

    A persistent keep-alive setting (e.g., PersistentKeepalive = 30) is recommended to prevent connection drops caused by firewalls or NAT devices.

    The server needs to explicitly allow the client by adding the client's public key and allowed IPs to the server's configuration using wg set.

    WireGuard uses UDP, which is stateless, so the keep-alive setting is crucial for maintaining the connection.

    Flexible configuration options allow for routing only specific traffic through the VPN, rather than all traffic.

    00:00 Introduction
    01:50 Installation on server & client
    02:50 Create private and public server keys
    04:24 Configure server interface
    07:00 Create private and public client keys
    07:34 Configure client interface
    10:55 Add Client peer to the server configuration
    12:03 Configure persistent keep-alive
    13:58 Test the connection via ping
    14:30 Configure the server to forward network packets
    16:05 How to change clients traffic routing
    17:10 Summary

    💡 Support the creator: Patreon - Christian Lempa

  • Posted on

    Private, encrypted Matrix server: self-hosted.

    The video details setting up a self-hosted Matrix chat server using Dendrite, an alternative to Synapse, touted as being lighter weight and easier to run on less powerful servers (ideal for home or small business use).

    Setting up the server requires: - A server capable of running Docker (LXC container, VM, or physical machine suggested). - A reverse proxy (Nginx Proxy Manager recommended). - A domain name with DNS A-record pointing to your server's public IP (or dynamic DNS for changing IPs). - Port forwarding for port 8448 (for Federation).

    The tutorial walks through installing Dendrite via Docker, including: - Creating a non-root user.
    - Generating keys.
    - Configuring dendrite.yaml (hostname, keys location, database connection, Federation settings, registration, and rate limiting).
    - Using docker-compose to start the server.

    Reverse Proxy Setup:
    Using Nginx Proxy Manager (or another reverse proxy) is shown, including obtaining an SSL certificate via Let's Encrypt.

    User Account Creation:
    The video explains how to manually create admin and regular user accounts within the Dendrite server, emphasizing the importance of saving generated access tokens.

    Federation Testing:
    Using federationtester.matrix.org is demonstrated to verify successful Federation setup and connectivity.

    Matrix Clients:
    A brief overview of available Matrix clients for various platforms (iOS, desktop) is given, highlighting some compatibility issues and suggesting alternatives to Element.

    A follow-up video is promised to cover setting up a TURN server for audio/video calling.

  • Posted on

    Matrix is an open, decentralized, and secure real-time communication network supporting various applications, including chat, VoIP, VR/AR, and IoT. It aims to create a global, encrypted communication network.

    Matrix offers end-to-end encryption (using OLM and the Double Ratchet algorithm), group and one-to-one messaging, VoIP (WebRTC), push notifications, a content repository for media, and decentralized conversation history.

    The network uses four main APIs: Client-Server, Server-Server (Federation), Application Service (for bridges and bots), and Identity Server (for managing email/phone number associations).

    Currently, Matrix uses a client-server based federated architecture, but peer-to-peer functionality is under development.

    The Matrix ecosystem includes various clients (Element, Quaternion, Fractal, etc.) and servers (Synapse, Dendrite), with SDKs available for numerous platforms.

    The presentation details installing and configuring Synapse, the reference Matrix homeserver, on Arch Linux. This involves using the Arch Linux repository, generating a configuration file, and enabling registration (optional, but recommended for private use).

    Key configuration aspects discussed include enabling registration, database selection (PostgreSQL recommended over SQLite), and logging configuration.

    Using a reverse proxy (like Caddy) is highly recommended for secure HTTPS access and proper TLS certificate management, avoiding issues with Synapse's built-in ACME v1 support.

    Synapse uses workers for horizontal scaling, particularly useful for handling CPU-bound tasks like syncing.

    Delegation allows for flexible server name configuration and port management, enabling clients and federation APIs to use different ports or even the same port (443) for both.

    Dendrite, a next-generation homeserver, has released its first beta version. Portable identities (moving accounts between servers) are in development.

    Synapse currently supports SQLite and PostgreSQL, with a move towards primarily supporting PostgreSQL for performance reasons. NoSQL databases are not currently supported.

    The Matrix App Service IRC bridge works well for smaller communities, but performance issues arise when bridging large networks.

  • Posted on

    🎙 FLOSS Weekly Episode 730 – Meshtastic: Off-Grid Adventures with Mesh Networks

    Hosts: Doc Searls & Jonathan Bennett
    Guests: Ben Meadors & Garth Vander Houwen

    Meshtastic is an open-source, off-grid, decentralized mesh network that runs on low-power devices. In this episode, the team explores how Meshtastic enables communication and data sharing without traditional infrastructure—perfect for adventures and remote applications.

    🔗 Watch or Listen on FLOSS Weekly

  • Posted on

    ▶ YouTube Playlist: Meshtastic for Makers

    Welcome to the Meshtastic for Makers Workshop, a short 1-hour course where we teach you how to add Meshtastic to your maker projects to wirelessly send data over long ranges.

    Whether you want to:
    - Open a gate on the other side of your farm,
    - Monitor the water level in a nearby river, or
    - Just want to play around with some 21st-century radio communications...

    This course gives you everything you need to know to get data from point A to point B with Meshtastic, one of the coolest open-source, community-oriented projects around.

    🔧 Hardware Featured

    • Pico H
    • LoRa Module

    Workshop Timeline

    • 0:00 – Intro to the Course
    • 2:11 – What is Meshtastic?
    • 7:19 – Setting up the Pico
    • 13:04 – Channels and Frequencies
    • 21:51 – Sending Sensor Data
    • 31:38 – Controlling Hardware
    • 44:01 – Integrating MQTT
    • 52:11 – A Simpler Way to Send Simpler Data
    • 58:59 – Outro
  • Posted on

    This course covers everything from getting started all the way through building a containerized web application and deploying it to the cloud!

    Course Resources

    Whether you're just starting out or want to level up your Docker skills, this course provides a clear and practical path to mastering containers.

  • Posted on

    Master Docker's Complex Networking

    The video emphasizes the importance of understanding Docker networking, highlighting its complexity and potential for increased control and isolation of containers.

    Seven Docker Network Types

    Docker offers seven distinct network types:
    1. Default bridge
    2. User-defined bridge
    3. Host
    4. MacVLAN
    5. IPVLAN (L2 and L3)
    6. Overlay
    7. None

    Each offers different levels of isolation, connectivity, and complexity.

    Default Bridge Network

    This default network is simple to use but lacks isolation. Containers share a virtual network, requiring manual port exposure for external access. It automatically creates virtual ethernet interfaces and handles DHCP.

    User-Defined Bridge Network

    This allows for creating custom networks, providing better isolation than the default bridge. Containers on different user-defined bridge networks cannot communicate unless specifically configured. Offers container-to-container DNS resolution by name.

    Host Network

    Containers on the host network share the host's IP address and ports, eliminating the need for port exposure but sacrificing isolation. Suitable for applications requiring direct host access.

    MacVLAN Network

    Connects containers directly to the physical network, giving each container its own MAC and IP address.

    • Requires enabling promiscuous mode on the host and network interfaces.
    • Can cause conflicts with devices that don't support multiple MACs on a single port.
    • Offers direct access without port exposure but requires manual IP assignments to avoid DHCP conflicts.

    IPVLAN Network (L2)

    Similar to MacVLAN but avoids MAC conflicts by sharing the host's MAC address with containers. Provides a balance between isolation and ease of network integration.

    IPVLAN Network (L3)

    A layer 3 network turning the host into a router.

    • Containers are connected via IP addresses, eliminating broadcast traffic.
    • Requires static route configuration on the physical network router to enable communication with external networks.
    • Offers fine-grained control and isolation through routing configurations.

    Overlay Network

    Designed for multi-host environments like Docker Swarm or Kubernetes. Abstracts network complexity by providing a single logical network across multiple hosts.

    None Network

    Provides no networking capabilities, isolating containers completely from external access.

"> ');