OpenVPN: TLS-baseret VPN-arkitektur

OpenVPN bruger to separate kanaler: kontrolkanalen og datakanalen. Kontrolkanalen håndterer autentificering, sessionsetablering og udveksling af konfiguration ved hjælp af TLS. Datakanalen transporterer den faktiske VPN-trafik, som er krypteret med en symmetrisk krypteringsalgoritme, der forhandles via kontrolkanalen. Denne adskillelse gør det muligt for OpenVPN at udnytte hele TLS-økosystemet til nøglehåndtering.

OpenVPNs kontrolkanal kører en komplet TLS-session. Begge sider autentificerer sig ved hjælp af X.509-certifikater, der er underskrevet af en fælles CA. TLS leverer nøgleudveksling, certifikatvalidering og forhandling af parametre for datakanalens krypteringsalgoritme. Fordi TLS understøtter ECDHE, giver kontrolkanalen perfekt fremadrettet hemmeligholdelse: Datakanalens nøgler kan ikke gendannes fra en optaget session, selv ikke med CA-nøglen.

Datakanalkryptering forhandles via TLS-kontrolkanalen. OpenVPN 2.4 og nyere bruger som standard AES-256-GCM, en AEAD-krypteringsalgoritme, der giver både fortrolighed og integritet i én operation. Tidligere versioner brugte AES-256-CBC sammen med HMAC-SHA256 separat. AEAD-tilstande foretrækkes, fordi de eliminerer behovet for separat MAC-verifikation og modstår polstringsorakelangreb.

Indstillingen tls-crypt indpakker hele TLS-sessionen, herunder ClientHello-meddelelsen, i en symmetrisk, HMAC-autentificeret indpakning ved hjælp af en forhåndsdelt nøgle. Det betyder, at uautentificerede klienter ikke engang kan begynde et TLS-håndtryk; deres første pakker kasseres lydløst. Det beskytter OpenVPN-serveren mod TLS-baserede DDoS-forstærkningsangreb og skjuler, at der kører en VPN-server.

Den ældre indstilling tls-auth føjer et HMAC-tag til TLS-kontrolkanalens pakker, men krypterer dem ikke. Det forhindrer indsættelse af pakker, men afslører stadig TLS-håndtrykket for iagttagere. tls-crypt krypterer og autentificerer indpakningen omkring kontrolkanalen og giver dermed både DoS-beskyttelse og modstandsdygtighed over for trafikanalyse. tls-crypt er den anbefalede moderne indstilling; tls-auth er udfaset til fordel for tls-crypt-v2.

OpenVPN autentificerer klienter ved hjælp af X.509-certifikater, der er underskrevet af VPN'ets certifikatmyndighed. Hver klient modtager et unikt certifikat og en privat nøgle. Serveren kontrollerer certifikatkæden og kan valgfrit kontrollere en certifikattilbagekaldelsesliste (CRL) for at afvise tilbagekaldte certifikater. Når et certifikat tilbagekaldes, fjernes klientens adgang med det samme, i modsætning til PSK-baserede systemer, hvor en ændring af en nøgle påvirker alle klienter.

OpenVPN kan køre over UDP (standard og anbefalet) eller TCP. UDP undgår problemet med TCP-over-TCP, hvor pakketab udløser dobbelt genudsendelse både på TCP-laget og på VPN-applikationslaget, hvilket forringer ydeevnen betydeligt. Nogle netværk blokerer dog UDP. Hvis OpenVPN køres på TCP-port 443, kan det omgå firewalls, der kun tillader HTTPS-trafik, men det koster ydeevne ved pakketab.

OpenVPN fungerer i tun-tilstand (rutning) eller tap-tilstand (brokobling). tun-tilstand opretter en punkt-til-punkt-IP-netværksgrænseflade, der rutter IP-pakker mellem klienten og VPN-netværket. tap-tilstand opretter en Ethernet-brogrænseflade, der videresender Ethernet-rammer, herunder udsendelser og ikke-IP-protokoller. tun-tilstand er mere effektiv og egner sig til de fleste VPN-anvendelser; tap-tilstand er nødvendig til brokobling af netværkssegmenter eller ikke-IP-protokoller.

OpenVPN-servere kan automatisk sende konfigurationsdirektiver til forbindende klienter. Almindelige push-direktiver omfatter push "route 10.0.0.0 255.0.0.0" (tilføjer en rute på klienten), push "dhcp-option DNS 10.0.0.1" (angiver DNS-serveren) og push "redirect-gateway def1" (ruter al klienttrafik gennem VPN'et). Det centraliserer styringen af klientkonfigurationen uden at ændre individuelle konfigurationsfiler hos klienterne.

OpenVPN opnår perfekt fremadrettet hemmeligholdelse gennem TLS ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) i kontrolkanalen. Et nyt efemer nøglepar bruges til hver TLS-session, så sessionsnøglen ikke kan udledes af serverens langsigtede private certifikatnøgle. Hvis krypteret trafik optages i dag, og servercertifikatet senere anskaffes, er det stadig ikke muligt at dekryptere tidligere sessioner.

OpenVPN 2.5 udfasede Blowfish-chifferet (BF-CBC), som historisk var standard. BF-CBC bruger en blokstørrelse på 64 bit, der er sårbar over for SWEET32-fødselsdagsangreb under lange sessioner. Moderne OpenVPN bruger som standard AES-256-GCM. OpenVPN 2.5 udfasede også ikke-AEAD-krypteringsalgoritmer i datakanalen og skærpede kravene til TLS-minimumsversionen, så understøttelsen af TLS 1.0 og 1.1 blev fjernet.

Opsummering af OpenVPN: kontrolkanalen bruger TLS til autentificering og forhandling af krypteringsalgoritme, datakanalen bruger den forhandlede AEAD-krypteringsalgoritme (som standard AES-256-GCM), tls-crypt indpakker TLS for at forhindre uautentificerede håndtryk, ECDHE giver fremadrettet hemmeligholdelse, certifikatbaseret klientautentificering med tilbagekaldelse via CRL, UDP foretrækkes frem for TCP af hensyn til ydeevnen, og tun-tilstand foretrækkes til anvendelser med IP-rutning.