### Start and Enable OpenVPN Server Source: https://context7.com/jabberwocky238/rfc-gen/llms.txt This snippet shows how to enable the OpenVPN server to start automatically on boot and then start the service immediately using systemctl. This ensures the VPN server is running and accessible. ```bash systemctl enable openvpn@server systemctl start openvpn@server ``` -------------------------------- ### OpenVPN Server Configuration Example Source: https://context7.com/jabberwocky238/rfc-gen/llms.txt Provides a comprehensive example of an OpenVPN server configuration file. It covers network settings, SSL/TLS configuration, encryption, network routing, and security hardening options. This configuration is suitable for setting up a secure VPN tunnel. ```bash # OpenVPN server configuration example cat > /etc/openvpn/server.conf << 'EOF' # Network settings port 1194 proto udp dev tun # SSL/TLS settings ca ca.crt cert server.crt key server.key dh dh2048.pem tls-auth ta.key 0 # Encryption settings cipher AES-256-GCM auth SHA256 # Network configuration server 10.8.0.0 255.255.255.0 topology subnet # Push routes to clients push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" # Client-to-client communication client-to-client # Connection settings keepalive 10 120 persist-key persist-tun # Security hardening user nobody group nogroup tls-version-min 1.2 tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 # Logging status /var/log/openvpn-status.log log-append /var/log/openvpn.log verb 3 EOF ``` -------------------------------- ### TLS 1.3 Binder Computation Examples Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc8446.txt Demonstrates the computation of binders for TLS 1.3 handshake messages, including handling of HelloRetryRequest. Binders are computed over transcript hashes of partial handshake messages. ```plaintext Transcript-Hash(Truncate(ClientHello1)) Transcript-Hash(ClientHello1, HelloRetryRequest, Truncate(ClientHello2)) ``` -------------------------------- ### TLS Padding Calculation Example Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc5246.txt Illustrates the calculation of padding length for block ciphers in CBC mode to ensure the total record length is a multiple of the block size. This is crucial for preventing length-analysis attacks. ```plaintext Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the IV. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC. ``` -------------------------------- ### Configure RIP Routing Protocol on Linux with FRR Source: https://context7.com/jabberwocky238/rfc-gen/llms.txt This snippet shows how to configure the RIP (Routing Information Protocol) routing daemon on a Linux system using FRR (Free Range Routing). It covers the configuration file setup, including RIP version, network statements, redistribution, passive interfaces, and authentication. It also includes commands to start the daemon and view the RIP routing table. ```bash # RIP configuration on Linux using FRR/Quagga cat > /etc/frr/ripd.conf << 'EOF' hostname router1 password zebra enable password zebra router rip version 2 network 192.168.1.0/24 network 10.0.0.0/8 redistribute connected redistribute static # Passive interfaces (no RIP advertisements) passive-interface eth0 # Neighbor authentication ip rip authentication mode md5 ip rip authentication string secretkey EOF # Start RIP daemon systemctl start ripd # View RIP routing table vtysh -c "show ip rip" # Example output: # Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP # # Network Next Hop Metric From Time # R(n) 192.168.2.0/24 192.168.1.2 2 192.168.1.2 00:02:15 # R(n) 192.168.3.0/24 192.168.1.2 3 192.168.1.2 00:02:15 # C(i) 192.168.1.0/24 0.0.0.0 1 self - # R(n) 10.1.0.0/16 192.168.1.3 2 192.168.1.3 00:01:48 # RIP timers: # - Update: 30 seconds (route advertisement) # - Invalid: 180 seconds (route marked invalid) # - Hold-down: 180 seconds (prevent routing loops) # - Flush: 240 seconds (route removed from table) ``` -------------------------------- ### Generate OpenVPN Certificates and Keys Source: https://context7.com/jabberwocky238/rfc-gen/llms.txt This snippet outlines the commands to initialize the PKI, build a Certificate Authority (CA), generate server and client certificates and keys, and create Diffie-Hellman parameters for OpenVPN. It uses the easyrsa utility and generates a static key for TLS authentication. ```bash cd /etc/openvpn/easy-rsa ./easyrsa init-pki ./easyrsa build-ca nopass ./easyrsa gen-req server nopass ./easyrsa sign-req server server ./easyrsa gen-dh openvpn --genkey secret ta.key ``` -------------------------------- ### Mandatory Variable-Length Vector Example in TLS Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc5246.txt An example of a mandatory variable-length vector in the TLS presentation language. 'mandatory' is defined as a vector of opaque type that must contain between 300 and 400 bytes and cannot be empty. ```plaintext mandatory is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. ``` -------------------------------- ### DHCP Client Initialization Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc2131.txt Describes the process of a DHCP client initializing and transitioning to the BOUND state upon receiving a DHCPACK message. ```APIDOC ## DHCP Client Initialization ### Description When a client's DHCPREQUEST message arrives from any server, the client is initialized and moves to the BOUND state. The client records the lease expiration time as the sum of the time at which the DHCPREQUEST message was sent and the duration of the lease from the DHCPACK message. ### Method Implicit (triggered by server response) ### Endpoint N/A ### Parameters None ### Request Example N/A ### Response #### Success Response (DHCPACK) - **lease_duration** (time) - The duration of the lease granted by the server. - **xid** (integer) - The transaction identifier matching the client's request. #### Response Example ```json { "lease_duration": "3600s", "xid": 12345 } ``` ``` -------------------------------- ### Intra-area-prefix-LSA Example (RT4) Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc5340.txt This snippet shows an example of an Intra-area-prefix-LSA originated by Router RT4 for network link N3. It details fields like LS age, LS type, Link State ID, Advertising Router, and prefix information. ```text LS age = 0 ;newly (re)originated LS type = 0x2009 ;Intra-area-prefix-LSA Link State ID = 5 ;LSA type/scope unique identifier Advertising Router = 192.0.2.4 ;RT4's Router ID # prefixes = 1 Referenced LS Type = 0x2002 ;network-LSA reference Referenced Link State ID = 1 Referenced Advertising Router = 192.0.2.4 PrefixLength = 56 ;N3's prefix PrefixOptions = 0 Metric = 0 Address Prefix = 2001:0db8:c001:0100 ;pad ``` -------------------------------- ### Dijkstra's Shortest Path First (SPF) Algorithm Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc1142.txt Describes the basis of the route calculation using Dijkstra's Shortest Path First (SPF) algorithm. It notes the algorithm's computational complexity and discusses potential optimizations such as using finite fields, incremental updates, and handling only End System LSP changes. ```pseudocode (* Dijkstra's Shortest Path First (SPF) Algorithm * Computational Complexity: O(N^2) where N is the number of nodes. Optimizations: a) Using data structures for small finite fields to remove log N factor. b) Incremental updates (though full updates are specified for this standard). c) Attaching/detaching End Systems as leaves of the tree without full recalculation. Limitation: Original algorithm does not support load splitting over multiple paths.) ``` -------------------------------- ### Example: Variable-Length Vector Usage in TLS Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc8446.txt Shows examples of variable-length vectors: 'mandatory' as opaque bytes between 300-400 bytes (2-byte length field, cannot be empty), and 'longer' as uint16 elements from 0 to 800 (2-byte length field, can be empty). ```tlsdef opaque mandatory<300..400>; /* length field is two bytes, cannot be empty */ uint16 longer<0..800>; /* zero to 400 16-bit unsigned integers */ ``` -------------------------------- ### Implement TLS 1.3 Server in Python Source: https://context7.com/jabberwocky238/rfc-gen/llms.txt This Python snippet demonstrates setting up a basic TLS 1.3 server. It uses the `ssl` module to create a secure context, loads server certificates and keys, and configures it to only support TLS 1.3 with specific cipher suites. The server then listens for incoming connections, prints connection details, and sends a simple response. ```python import ssl import socket # Create TLS context with TLS 1.3 context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) context.minimum_version = ssl.TLSVersion.TLSv1_3 context.maximum_version = ssl.TLSVersion.TLSv1_3 # Load certificate and private key context.load_cert_chain('server.crt', 'server.key') # Configure cipher suites (TLS 1.3) context.set_ciphers('TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256') # Create secure server with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock: sock.bind(('0.0.0.0', 8443)) sock.listen(5) with context.wrap_socket(sock, server_side=True) as ssock: while True: conn, addr = ssock.accept() print(f"Secure connection from {addr}") print(f"TLS version: {conn.version()}") print(f"Cipher: {conn.cipher()}") # Handle client data data = conn.recv(1024) conn.sendall(b"HTTP/1.1 200 OK\r\n\r\nSecure!") conn.close() # TLS 1.3 handshake flow (1-RTT): # Client Server # # ClientHello ``` -------------------------------- ### TLS 1.3 CertificateVerify Signature Content Example (Hex) Source: https://github.com/jabberwocky238/rfc-gen/blob/master/rfc8446.txt An example of the content covered by a digital signature for a server's CertificateVerify message. This includes padding, server random, context string, and a transcript hash. The length of the transcript hash depends on the hash algorithm used (e.g., 32 bytes for SHA-256). ```hex 2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020 544c5320312e332c207365727665722043657274696669636174655665726966 79 00 0101010101010101010101010101010101010101010101010101010101010101 ```