OpenVPN-beheerpakette naspoor: tls-auth voor TLS

'n tls-auth-fout word gewoonlik as 'n handdrukprobleem gerapporteer, en dit was nooit een nie. Die HMAC word op die beheerpakket nagegaan voordat enige TLS-verwerking plaasvind, so 'n verkeerde sleutel of rigting lewer 'n fout op wat soos 'n sertifikaatprobleem lyk en twee lae vroeër beslis word. Om die omhulsel as sy eie objek te behandel, maak die diagnose kort: lees die velde, bevestig dat die kontrole vroeg afvuur, en vergelyk dan die drie dinge waaroor beide kante dit eens moet wees.

Lees die omhulsel in die volgorde waarin dit gebou word

'n Beheerpakket dra 'n sessie-identifiseerder, die opsionele tls-auth-HMAC, herspel- en bevestigingsinligting, en 'n betroubare boodskapidentifiseerder, met die boodskaptipe-lading daarna. Wanneer die boodskap 'n handdrukboodskap is, is die lading toevallig TLS-syferteks. Dit is die hele verhouding: TLS-materiaal reis binne 'n boodskap wat die omhulsel reeds beskerm. Die OpenVPN-netwerkprotokol-verwysing lys die beheerkanaalvelde in daardie volgorde.

Die betroubaarheidslaag is maklik om vir kriptografie aan te sien. Bevestigings, herversending en die boodskapidentifiseerder bestaan sodat beheerboodskappe een keer en in volgorde oor 'n onbetroubare transport aankom. Hulle is nie verifikasie nie, en 'n korrekte boodskapidentifiseerder bewys niks oor wie die pakket gestuur het nie.

Hou hierdie groepering konseptueel. Dit is nie 'n greeporde-diagram nie, en dit is nie genoeg om 'n etiket te bereken nie, want die velde wat in die HMAC ingaan, hang van implementering, weergawe en modus af.

Wys dat die kontrole voor die handdruk afvuur

'n Ontvanger met die gedeelde sleutel kan die HMAC verifieer en 'n vervalste pakket dadelik laat val, sonder om handdruktuimte toe te wys of publieke-sleutelwerk te doen. Die beskerming dek ook die aanvanklike handdrukpakette, en juis daarom wys 'n verkeerde sleutel op as 'n mislukte verbinding eerder as as 'n laat verifikasiefout.

Verhoog die daemon se breedsprakigheid en dophou die beheerkanaal eerder as die tun-toestel:

openvpn --config /etc/openvpn/server.conf --verb 6

Wat jy soek, is 'n beheerkanaal-HMAC-verifikasiefout wat op pakketvlak gerapporteer word, voor enige TLS-waarskuwing. 'n TLS-waarskuwing in die log beteken die omhulsel is aanvaar en die fout het na binne geskuif, wat 'n ander ondersoek met 'n ander oplossing is.

Rigtinghantering sit ook hier. Wanneer 'n statiese sleutellêer met tls-auth gebruik word, neem die twee kante teenoorgestelde sleutelrigtings in, en die protokol gebruik daardie splitsing sodat 'n gevange pakket nie na sy sender teruggekaats kan word nie. Om die rigting om te draai hou die sleutel identies en laat steeds elke pakket misluk. Verander een kant op 'n slag, en herbegin dan beide daemons sodat die paar saam gelaai word.

Pas sleutel, rigting en digest aan beide kante op mekaar

Drie waardes moet ooreenstem, en net een daarvan is die lêer. Die statiese sleutelinhoud moet aan beide kante identies wees, die rigting moet teenoorgesteld wees, en die digest wat vir die HMAC gebruik word, moet ooreenstem. Kontroleer die konfigurasie voordat jy aan die sleutelmateriaal raak, want 'n enkele omgekeerde rigting verklaar meer mislukkings as 'n beskadigde lêer:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Skep die gedeelde geheim met die gereedskap eerder as met 'n redigeerder, en hou die regte streng:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Ouer weergawes het 'n effens ander opsieorde vir sleutelskepping aanvaar, en profiele wat vir daardie weergawes geskryf is, sirkuleer steeds. Die geskepte lêer is in beide gevalle dieselfde soort objek, so die kontrole is of beide kante identiese grepe hou, nie watter spelling dit voortgebring het nie.

Moenie tls-auth met tls-crypt verwar nie. Beide beskerm die beheerkanaal, maar tls-crypt versyfer dit ook en verberg die handdruk van waarnemers, en dit vervang die rigtingsplitsing met sy eie sleutelhantering. 'n Profiel wat een gebruik, sal nie met 'n eweknie wat vir die ander opgestel is, saamwerk nie, en geen hoeveelheid digest-instelling maak daardie gaping toe nie.

Reproduseer 'n etiket net uit die werklike formaat

Greep-presiese reproduksie is 'n aparte taak van om 'n VPN te laat loop, en dit werk net met die werklike insette: die implementering en weergawe wat die pakket gebou het, die gekose digest, die rigting, en die werklike grepe insluitend sessie-identifiseerder en bevestigingsverskeidenheid. 'n Teksvoorstelling van die veldlys is nie daardie grepe nie.

Etiketlengte volg uit die digest, so 'n vaste-lengte-aanname breek die oomblik wanneer iemand dit verander. Hash die pakket soos die implementering dit doen, nie soos 'n tabel in 'n blogpos dit voorstel nie, en vergelyk met 'n opname van dieselfde eweknie eerder as met 'n verwagting wat jy met die hand afgelei het.

Hou daardie oefening weg van produksieprofiele. Niks aan die reproduseer van 'n etiket sê vir jou of 'n ontplooiing die beskerming moet aktiveer nie.

Draai 'n wanpassing terug sonder om die beskerming te verwyder

Die verleidelike toets is om tls-auth te skrap, te sien dat die verbinding slaag en af te lei dat die sleutel verkeerd was. Daardie antwoord kos jou die beskerming en leer niks oor watter van die drie waardes verskil het nie. Kry eerder die goedgekeurde passende konfigurasie van die bedienerkant en vergelyk daarmee.

Berei die verandering voor sodat dit omkeerbaar is. Hou die vorige bedienerkonfigurasie en sleutellêer, pas die reggestelde paar toe, verifieer dat 'n kliënt die handdruk voltooi, en verwyder eers dan die rugsteun. As kliënte ná die verandering misluk, herstel die vorige lêers eerder as om tydens 'n onderbreking 'n derde variant te improviseer. Die herstel moet een opdrag wees wat jy reeds ken voordat jy begin.

Onthou laastens wat 'n geslaagde kontrole beteken. Dit bewys die eweknie hou die gedeelde sleutel, nie dat sy sertifikaat of rekening gemagtig is nie, en dit sê niks oor die onderhandelde datakanaal-syfer nie. Magtiging en databeskerming word later gevestig, so 'n skoon omhulselkontrole is 'n beginpunt eerder as 'n uitspraak.