OpenVPN-log: beheerkanal-syfer teenoor datakanal-syfer

'n Logreël wat DHE-RSA-AES256-SHA noem, is nie 'n opsomming van die hele verbinding nie. Dit hoort by die TLS-handdruk wat die beheerkanal beskerm, en die verkeer binne die tonnel kan heeltemal anders geënkripteer wees. Om dit as die VPN se datasifer aan te bied, is die fout om te vermy.

Twee resultate maak saak, en hulle beantwoord verskillende vrae. Een is die onderhandelde TLS-stel vir die beheerkanal; die ander is die datasifer vir die pakkette wat die tonnel vervoer.

Twee resultate, twee vrae

Die beheerkanal dra die handdruk en die bestuursboodskappe tussen die eweknieë. Sy syfer word deur die TLS-stapel gekies, dus volg die naam die TLS-konvensies. Die datakanal dra gebruikersverkeer en word deur OpenVPN se eie syferonderhandeling opgestel.

Bepaal watter vraag jy beantwoord voordat jy enige van die twee reëls lees. Of die tonnel geënkripteer is en of die handdruk sterk is, is nie dieselfde vraag nie.

'n Loguittreksel wat albei reëls wys, is die nuttige een. Lees die beheerlyn vir die TLS-weergawe en -stel, en die datalyn vir die algoritme wat die nutslading werklik beskerm.

Ontsleutel die TLS-stelnaam in sy eie konteks

In 'n historiese OpenSSL-styl naam soos DHE-RSA-AES256-SHA beskryf elke komponent 'n ander besluit. DHE is die efemere Diffie-Hellman-sleutelooreenkoms, RSA is die verifikasismetode, AES256 is AES-256 in CBC-modus vir TLS-rekords, en SHA is die rekord-MAC gebaseer op SHA-1.

Die laaste komponent is nie 'n sertifikaat-vingerafdruk nie, en om dit so te lees is 'n algemene fout. Die naam noem ook nie die protokolweergawe op sy eie nie, want TLS 1.3 gebruik 'n heeltemal ander naamskema. TLS_AES_256_GCM_SHA384 volg daardie nuwer vorm, waar die slot-hash deel van die stel se samestelling is eerder as 'n MAC-keuse. Pas die komponentlesing net op die ouer naamstyl toe.

Die OpenSSL-stelverwysing koppel hierdie name aan hul definisies as 'n komponent onbekend is.

Lees die datakanal-resultaat vir vervoerde verkeer

Lees vir vervoerde verkeer die datakanal-lyn uit dieselfde sessie. 'n data-ciphers-lys in die konfigurasie is 'n toegelate stel, nie bewyse dat 'n bepaalde algoritme onderhandel is nie. Die log teken die keuse aan; die konfigurasie lys die kieslys.

'n AEAD-syfer soos AES-GCM dra sy eie integriteitskontrole, dus 'n aparte datakanal-HMAC is nie deel van daardie pad nie.

Die richtlijn auth verbeter nie TLS, sertifikate of die datasifer nie. Dit kies 'n digest vir die dele van die protokol wat nog een gebruik, en met 'n AEAD-datasifer is daar geen aparte data-HMAC om op te stel nie.

Hou identiteitskontroles buite die syferresultaat

Sertifikaat-handtekeningalgoritme, validasie van die vertrouensketting en verifikasie van die eweknie-naam is nog drie eienskappe waaroor 'n syfernaam niks sê nie. 'n Verstreke sertifikaat misluk, maak nie saak hoe sterk die stel is nie. 'n Servernaam wat nie ooreenstem nie, misluk op dieselfde manier. Om 'n digest-instelling in die profiel reg te maak, herstel nie een van die twee nie.

Hou daardie kontroles in die resensienotas langs die syferresultaat, nie daarin saamgevoeg nie.

Teken die onderhandelde resultate van die huidige sessie aan

Neem die resultate van die huidige verbinding en teken die kliënt- en bedienerweergawes daarby aan. In log wat net aangevul word, kan die lyn van 'n ouer sessie bevat, en om dit as huidig aan te haal is hoe 'n reggemaakte probleem blyk te bly voortduur.

Gee vir 'n beleidsresensie die konfigurasie-eienaar die onderhandelde TLS-weergawe en -stel, die gekose datasifer en die sertifikaatvalidasie-instellings saam. Verander daardie laag en lees dan 'n nuwe log om die nuwe onderhandelde waardes te bevestig.