OpenVPN-kontrôlepakketten folgje: tls-auth foar TLS
De tls-auth-HMAC sit op ’e kontrôleenvelop, net binnen de TLS-hânjaan. Rjochtsje kaai, rjochting en digest opinoar ôf en ferifiearje dan sûnder de beskerming fuort te heljen.
In tls-auth-flater wurdt meastentiids as in hânjaanprobleem rapportearre, wylst it dat nea west hat. De HMAC wurdt op it kontrôlepakket kontrolearre foardat der ea TLS-ferwurking bart, sadat in ferkearde kaai of rjochting in flater oplevert dy’t op in sertifikaatprobleem liket en twa lagen earder beslist wurdt. De envelop as eigen objekt behannelje makket de diagnoaze koart: lês de fjilden, befêstigje dat de kontrôle betiid ôfgiet en fergelykje dan de trije dingen dêr’t beide kanten it oer iens wêze moatte.
Lês de envelop yn ’e folchoarder wêryn’t er boud wurdt
In kontrôlepakket draacht in sesje-identifikaasje, de opsjonele tls-auth-HMAC, werhellings- en befêstigingsynformaasje en in betroubere berjochtidentifikaasje, en dêrnei komt de lading fan it berjochttype. As it berjocht in hânjaanberjocht is, is de lading tafallich TLS-siferskrift. Dat is de hiele relaasje: TLS-materiaal reizget binnen in berjocht dat de envelop al beskermet. De OpenVPN-referinsje foar it netwurkprotokol listet de fjilden fan it kontrôlekanaal yn dy folchoarder op.
De betrouberenslaach wurdt maklik foar kryptografy oansjoen. Befêstigings, weromstjoering en de berjochtidentifikaasje besteane sadat kontrôleberjochten ien kear en yn folchoarder oer in net-betrouber ferfier oankomme. Se binne gjin autentikaasje, en in korrekte berjochtidentifikaasje bewiist neat oer wa’t it pakket stjoerd hat.
Hâld dizze groepearring konseptueel. It is gjin byte-folchoarder-diagram en it is net genôch om in label te berekkenjen, om’t de fjilden dy’t yn ’e HMAC geane fan ymplemintaasje, ferzje en modus ôfhingje.
Lit sjen dat de kontrôle foar de hânjaan ôfgiet
In ûntfanger mei de dielde kaai kin de HMAC ferifiearje en in ferfalske pakket daliks fuortsmite, sûnder hânjaansteat ta te wizen of iepenbiere-kaaiwurk te dwaan. De beskerming dekt ek de earste hânjaanpakketten, en dêrom krekt lit in ferkearde kaai him sjen as in mislearre ferbining en net as in lette autentikaasjeflater.
Fergees de spraaksumeens fan ’e daemon en hâld it kontrôlekanaal yn ’e gaten ynstee fan it tun-apparaat:
openvpn --config /etc/openvpn/server.conf --verb 6
Wat jo sykje is in HMAC-ferifikaasjeflater fan it kontrôlekanaal dy’t op pakketnivo rapportearre wurdt, foar elke TLS-warskôging. In TLS-warskôging yn it logboek betsjut dat de envelop akseptearre is en de flater nei binnen ta ferhuze is, wat in oar ûndersyk mei in oare oplossing is.
Rjochtingsôfhanneling sit hjir ek. As in statysk kaai-bestân mei tls-auth brûkt wurdt, nimme de beide kanten tsjinoerstelde kaairjochtings oan, en it protokol brûkt dy splitsing sadat in pakket dat opfongen is net werom nei syn stjoerder werombuoid wurde kin. De rjochting omdraaie hâldt de kaai identyk en dochs mislearret elk pakket. Feroarje ien kant tagelyk, en start dan beide daemons opnij sadat it pear tegearre laden wurdt.
Rjochtsje kaai, rjochting en digest oan beide kanten ôf
Trije wearden moatte oerienkomme en mar ien fan har is it bestân. De ynhâld fan ’e statyske kaai moat oan beide kanten identyk wêze, de rjochting moat tsjinoersteld wêze en de digest dy’t foar de HMAC brûkt wurdt moat oerienkomme. Kontrolearje de konfiguraasje foardat jo it kaaimateriaal oanreitsje, want ien omkearde rjochting ferklearret mear flaters as in skansearre bestân:
grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf
Meitsje it dielde geheim mei it helpmiddel ynstee fan mei in bewurker, en hâld de rjochten strak:
openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key
Aldere ferzjes akseptearren in wat oare opsjefolchoarder foar kaaien meitsjen, en profilen skreaun foar dy ferzjes geane noch altyd rûn. It makke bestân is yn beide gefallen itselde soarte objekt, dus de kontrôle is oft beide kanten identike bytes hawwe, net hokker stavering se makke hat.
Ferwikselje tls-auth net mei tls-crypt. Beide beskermje it kontrôlekanaal, mar tls-crypt fersiferet it ek en ferberget de hânjaan foar waarnimmers, en it ferfangt de rjochtingssplitsing troch syn eigen kaaiôfhanneling. In profyl dat ien brûkt sil net gearwurkje mei in tsjinpartij dy’t foar de oare konfigurearre is, en gjin digest-ôfstelling slút dat gat.
Reprodusearje in label allinnich út it echte formaat
Byte-presize reproduksje is in aparte taak fan in VPN draaie, en it wurket allinnich mei de echte ynfier: de ymplemintaasje en ferzje dy’t it pakket boud hawwe, de keazen digest, de rjochting en de werklike bytes, ynklusyf sesje-identifikaasje en befêstigingsarray. In tekstuele werjefte fan ’e fjildlist binne dy bytes net.
De labellange folget út ’e digest, dus in oanname fan fêste lingte brekt op it stuit dat immen it feroaret. Hash it pakket sa’t de ymplemintaasje dat docht, net sa’t in tabel yn in blogpost it presintearret, en fergelykje mei in opname fan itselde tsjinpartij ynstee fan mei in ferwachting dy’t jo mei de hân ôflaat hawwe.
Hâld dy oefening by produksjeprofylen wei. Neat oan it reprodusearjen fan in label fertelt jo oft in útrôling de beskerming oansette moat.
Draai in misferhâlding werom sûnder de beskerming fuort te heljen
De ferloklike test is tls-auth wiskje, sjen dat de ferbining slagget en konkludearje dat de kaai ferkeard wie. Dat antwurd kostet jo de beskerming en leart neat oer hokker fan ’e trije wearden net oerienkaam. Helje ynstee de goedkarde oerienkommende konfiguraasje fan ’e serverkant en fergelykje dêrmei.
Tariede de wiziging sa foar dat se weromdraaid wurde kin. Bewarje de foarige serverkonfiguraasje en it kaaibestân, pas it korrizjearre pear ta, ferifiearje dat in klant de hânjaan foltôget en helje pas dan de reservekopie fuort. As klanten nei de wiziging mislearje, restaurearje dan de foarige bestannen ynstee fan yn in steuring in tredde fariant te betinken. De restauraasje moat ien opdracht wêze dy’t jo al kenne foardat jo begjinne.
Tink úteinlik oan wat in slagge kontrôle betsjut. It bewiist dat it tsjinpartij de dielde kaai hat, net dat syn sertifikaat of akkount autorisearre is, en it seit neat oer de ûnderhannele sifertaal fan it datakanaal. Autorisaaasje en databeskerming wurde letter feststeld, dus in skjinne envelopkontrôle is in útgongspunt en gjin fûnis.