OpenVPN-logboek: fersifering fan it stjoerkanaal tsjin fersifering fan it datakanaal

In logrigel dy't DHE-RSA-AES256-SHA neamt, is gjin gearfetting fan 'e hiele ferbining. Hy heart by de TLS-handshake dy't it stjoerkanaal beskermet, en it ferkear binnen de tunnel kin hiel oars fersifere wêze. Him foarstelle as de datafersifering fan 'e VPN is de flater dy't foarkommen wurde moat.

Twa resultaten binne wichtich, en se beantwurdzje ferskillende fragen. Ien is de ûnderhannele TLS-suite foar it stjoerkanaal; de oare is de datafersifering foar de pakketten dy't de tunnel ferfiert.

Twa resultaten, twa fragen

It stjoerkanaal ferfiert de handshake en de behearberjochten tusken de peers. Syn fersifering wurdt keazen troch de TLS-stack, dus folget de namme de TLS-konvinsjes. It datakanaal ferfiert brûkersferkear en wurdt konfigurearre troch OpenVPN syn eigen fersiferingsûnderhanneling.

Bepaal op hokker fraach jo antwurdzje foardat jo ien fan beide rigels lêze. Oft de tunnel fersifere is en oft de handshake sterk is, binne net deselde fraach.

In logútskrift dat beide rigels sjen lit, is it nuttige. Lês de stjoerrigel foar de TLS-ferzje en -suite, en de datarigel foar it algoritme dat de lading echt beskermet.

Untsiferje de TLS-suitnamme yn syn eigen kontekst

Yn in histoaryske OpenSSL-namme lykas DHE-RSA-AES256-SHA beskriuwt elk ûnderdiel in oare beslissing. DHE is de efemere Diffie-Hellman-kaaiôfspraak, RSA is de autentikaasjemetoade, AES256 is AES-256 yn CBC-modus foar TLS-records, en SHA is de record-MAC op SHA-1-basis.

It lêste ûnderdiel is gjin sertifikaatfingerprint, en it as sadanich lêze is in gongbere flater. De namme neamt ek net fan himsels de protokolferzje, omdat TLS 1.3 in hiel oare nammekonvinsje brûkt. TLS_AES_256_GCM_SHA384 folget dy nijere foarm, wêrby't de ôfslutende hash diel is fan 'e opbou fan 'e suite en gjin MAC-keuze. Pas it ûnderdiel-lêzen allinnich ta op 'e âldere nammestyl.

De OpenSSL-suitreferinsje ferbynt dizze nammen mei har definysjes as in ûnderdiel ûnbekend is.

Lês it resultaat fan it datakanaal foar it ferfierde ferkear

Lês foar it ferfierde ferkear de datakanaalrigel út deselde sesje. In data-ciphers-list yn 'e konfiguraasje is in tastiene set, gjin bewiis dat in bepaald algoritme ûnderhannele is. It logboek leit de kar fêst; de konfiguraasje listet it menu op.

In AEAD-fersifering lykas AES-GCM bringt syn eigen yntegriteitskontrôle mei, dus in aparte datakanaal-HMAC is gjin diel fan dat paad.

De rjochtline auth upgradeet TLS, sertifikaten of de datafersifering net. Hy kiest in digest foar de dielen fan it protokol dy't noch ien brûke, en mei in AEAD-datafersifering is der gjin aparte data-HMAC te konfigurearjen.

Hâld identiteitskontrôles bûten it fersiferingsresultaat

It ûndertekeningsalgoritme fan it sertifikaat, de falidaasje fan 'e fertrouwensketen en de ferifikaasje fan 'e peernamme binne noch trije eigenskippen dêr't in fersiferingsnamme neat oer seit. In ferrûn sertifikaat mislearret, hoe sterk de suite ek is. In net oerienkommende servernamme mislearret op deselde wize. In digest-ynstelling yn it profyl korrizjearje reparearret gjin fan beide.

Hâld dy kontrôles yn 'e beoardielingsnotysjes njonken it fersiferingsresultaat, net dermei ferraand.

Liz de ûnderhannele resultaten fan 'e aktuele sesje fêst

Nim de resultaten fan 'e aktuele ferbining en liz de client- en serverferzjes dêrby fêst. In logboek dat allinnich oanfolle wurdt, kin de rigel fan in âldere sesje befetsje, en it as aktueel sitearje is hoe't in reparearre probleem troch liket te duorjen.

Jou foar in beliedsbeoardieling de konfiguraasjeeigner de ûnderhannele TLS-ferzje en -suite, de keazen datafersifering en de sertifikaatfalidaasje-ynstellingen mei-inoar. Feroarje dy laach en lês dan in nij logboek om de nije ûnderhannele wearden te befêstigjen.