Selsûndertekene VPN-sertifikaat: wat it betsjut en wa't it fertrout

Twa oertsjûgingen rjochtsje hjir de measte skea oan: dat in selsûndertekene VPN-sertifikaat betsjut dat de tunnel net fersifere is, en dat it ynstallearjen fan wat de VPN-klant ek frege hat allinnich de VPN rekket. Gjin fan beide oerlibbet kontakt mei in echte útrôl. In selsûndertekene sertifikaat beskriuwt in ûndertekeningsrelaasje, net in feiligensferdiel, en de berik fan it fertrouwen dat jo tafoegje hinget ôf fan hokker opslach it telâne komt. Ik haw sjoen dat in helpdesk in providerwoartel yn in Windows-masine ymportearre om ien warskôging stil te meitsjen, en dêrnei in middei trochbrocht mei út te lizzen wêrom't de browser opholden wie te kleien oer in net besibbe portaal. De twa helten fan dizze fraach hearre byinoar, behannelje se dus as ien.

In sertifikaat is gjin fertrouwensopslach

It bestân dat de server presintearret draacht in iepenbiere kaai, in subjektnamme, in útjouwernamme, jildichheidsdatums en útwreidings. Selsûndertekene betsjut dat it subjekt en de útjouwer deselde entiteit binne en de ûndertekening ferifiearret mei de eigen kaai fan it sertifikaat. Neat yn dy definysje seit dat de ferbining swak is, en neat seit dat de klant it akseptearje sil.

Akseptaasje komt earne oars wei: in CA-bestân dêr't jo de klant nei wize, in fingerôfdruk dy't jo mei de hân ferlykje, of in woartel dy't al yn in opslach sit dy't de klant lêst. In útrôl kin folslein sûn wêze wylst syn sertifikaat elke iepenbiere test mislearje soe. openssl verify tsjin de systeembondel sil in ûnbekende útjouwer rapportearje, en dat rapport is korrekt, net in fout.

De opsje ca fan OpenVPN is it dúdlikste gefal fan oan 'e applikaasje beskoattele fertrouwen. Dat bestân neamt de ankers dy't de klant akseptearje sil, en it kin ien partikuliere CA befetsje of, yn in lytse útrôl, it eigen selsûndertekene sertifikaat fan de server. Ferzje 2.6 akseptearret ek --peer-fingerprint om in SHA-256-fingerôfdruk fêst te setten ynstee fan in CA-bestân te fersprieden. WireGuard stiet noch fierder bûten: it hat hielendal gjin sertifikaten, allinnich in statyske iepenbiere kaai per peet, sadat de fraach oer selsûndertekening dêr net op past.

Wêr't jo fertrouwen ynstallearje, bepaalt wa't it erft

Set itselde sertifikaat op trije plakken en jo krije trije ferskillende eksploazjeradia. In bondel dy't allinnich troch de VPN-klant lêzen wurdt, rekket dy klant. In woartel yn 'e opslach fan it bestjoeringssysteem rekket elk programma dat dy opslach rieplachtet. In browser mei syn eigen fertrouwensdatabank kin beide negearje, en dêrom kin in warskôging in ymport oerlibje dy't like te wurkjen.

Op Debian of Ubuntu feroaret it falle litten fan in bestân yn /usr/local/share/ca-certificates/ en it draaien fan update-ca-certificates de systeembrede bondel. Op Windows skriuwt certutil -addstore -f Root nei de masine-opslach en hat in ferhege opdracht nedich, wylst it tafoegjen fan -user ynstee de opslach fan 'e hjoeddeiske brûker rjochtet; de twa binne net útwikselber. Firefox hâldt syn eigen NSS-databank, dus in ymport op OS-nivo sil dêr miskien nea ferskine.

Berik is fan belang fanwegen wat in autoriteit dwaan kin. In útjaande CA kin foar nammen ûndertekenje dêr't it gjin relaasje mei hat, dus alles dat dy opslach fertrout, sil dy ûndertekeningen akseptearje. Ien fêstsette blêd kin dat net; it autentisearret krekt ien identiteit fan in peet. As it doel is om ien VPN ferbine te litten, berikt in oan 'e applikaasje beskoattele CA of in fêstsette blêd dat, wylst in masinebrede woartel in folle gruttere konsesje is as wat it symptoom freget.

Jo fersiferje noch hieltyd sûnder in iepenbiere CA

De TLS-hânskôging liedt sesjekaaien ôf, itsij it peetsertifikaat keatst nei eat dat jo al fertrouwe, itsij net. Selsûndertekene betsjut net platte tekst, en it betsjut net dat it ferkear ûnderweis lêsber is. It betsjut dat de klant gjin aprioaryske reden hat om te leauwen dat de kaai by de server heart dy't er frege hat.

Yn dy kleau libje echte oanfallen. In klant dy't ynsteld is om elk sertifikaat te akseptearjen, itsij troch in útskeakele ferifikaasjeynstelling, itsij troch in fertrou-dochs-mar-knop dy't ien kear klike en ferjitten is, sil fleurich fersiferje nei wa't ek antwurdet. De ûnderskeping bart yn 'e autentikaasjestap, foardat applikaasjegegevens bewege. Fersifering sûnder identiteitskontrôle hâldt in passive waarnimmer bûten en docht net folle oars.

It fertrouwen fan 'e útjouwer slacht de nammerkontrôle net oer

Ketenfalidaasje, nammematch en sertifikaatdoel binne aparte besluten. In keten kin jildich wêze wylst de namme ferkeard is, en in namme kin matche wylst it sertifikaat foar in oare rol útjûn is. RFC 5280 definiearret de fjilden dy't dy beheiningen drage, en hoe strang in klant se hanthavenet is in saak per applikaasje.

OpenVPN makket de splitsing sichtber. verify-x509-name set it ferwachte subjekt fêst fia name-, name-prefix- of subject-match. remote-cert-tls server easket dat it peetsertifikaat brûkber is as servercertifikaat, wat in allinnich-klantsertifikaat wegeret sels as de útjouwer fertroul is. Gjin fan beide ynstellingen wurdt ferfongen troch it stjoeren fan in CA-bestân.

Besjoch it sertifikaat foardat jo wat dan ek beslute:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName lit sjen wa't it útjûn hat, foar hokker nammen en oant wannear.
• openssl verify -CAfile ca.crt server.crt kontrolearret oft de keten dy't jo stjoere wolle it blêd echt falidearret.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error wurket foar TLS-einpunten lykas in webportaal; it OpenVPN-protokol op 1194 is gjin gewoane TLS-stream, dus dy test jildt dêr net.

In sertifikaat mei in ferrûne datum, sûnder subjectAltName foar de namme dêr't jo mei ferbine, of sûnder serverAuth-brûk mislearret, hoewol't de anker ek sa soarchfâldich ynstallearre is.

Fiif kontrôles foardat jo ien akseptearje

Ferlykje de fingerôfdruk fia in kanaal dat net de ferbining is dy't jo besykje te reparearjen: in konsole, in ynstaller dy't jo al hawwe, in ûndertekene konfiguraasjebestân. openssl x509 -in server.crt -noout -fingerprint -sha256 op 'e server en deselde wearde yn it klantlog binne genôch om te witten dat jo nei ien objekt sjogge.

Beslute dan wat jo ynstallearje: ien blêd, of in autoriteit dy't mear slaan kin. Beslute dêrnei wêr't it hinne giet, en neam de applikaasjes dy't dy opslach lêze. Skriuw it fuortheljenpaad op wylst jo it noch betinke, want fertrou-en-fierder is hoe't in tydlike ymport permanint wurdt.

Beslute úteinlik de feroaring. In fêstset sertifikaat of fingerôfdruk moat fia itselde fertroude kanaal bywurke wurde as it sertifikaat rotearret, en in partikuliere CA hat syn eigen útjaan- en ynlûken-libbenssyklus. As de partikuliere kaai lekt, reparearret it op 'e nij fertrouwen fan in kopy fan itselde sertifikaat neat; de identiteit moat ferfongen wurde.

As in warskôging alle fiif kontrôles oerlibbet, is de nuttige fraach net hokker knop it stil makket, mar hokker opslach de klant eins lêst en wêr't dy woartel wei kaam. Beäntwurdzje dat, en de ymport dy't jo op it punt steane te dwaan wurdt in beslút ynstee fan in refleks.