Selfondertekende VPN-sertifikaat: wat dit beteken en waaraan dit vertroue gee

Twee oortuigings rig hier die meeste skade aan: dat 'n selfondertekende VPN-sertifikaat beteken die tonnel is nie versleutel nie, en dat die installering van wat die VPN-kliënt ook al gevra het net die VPN raak. Nie een van die twee oorleef kontak met 'n werklike ontplooiing nie. 'n Selfondertekende sertifikaat beskryf 'n ondertekeningsverhouding, nie 'n veiligheidsoordeel nie, en die reikwydte van die vertroue wat jy byvoeg hang daarvan af watter stoor dit beland. Ek het gesien hoe 'n helpdesk 'n verskafferwortel in 'n Windows-masjien invoer om een waarskuwing stil te maak, en toe 'n middag spandeer om te verduidelik waarom die blaaier opgehou kla het oor 'n onverwante portaal. Die twee helftes van hierdie vraag hoort saam, so behandel hulle as een.

'n Sertifikaat is nie 'n vertrouestoor nie

Die lêer wat die bediener aanbied, bevat 'n publieke sleutel, 'n subjeknaam, 'n uitreikernaam, geldigheidsdatums en uitbreidings. Selfondertekend beteken die subjek en die uitreiker is dieselfde entiteit en die handtekening verifieer met die sertifikaat se eie sleutel. Niks in daardie definisie sê die verbinding is swak nie, en niks sê die kliënt sal dit aanvaar nie.

Aanvaarding kom van elders: 'n CA-lêer waarna jy die kliënt wys, 'n vingerafdruk wat jy met die hand vergelyk, of 'n wortel wat reeds in 'n stoor sit wat die kliënt lees. 'n Ontplooiing kan heeltemal gesond wees terwyl sy sertifikaat elke publieke toets sou faal. openssl verify teen die stelselbundel sal 'n onbekende uitreiker rapporteer, en daardie rapport is korrek eerder as 'n fout.

OpenVPN se ca-opsie is die duidelikste geval van programgebonde vertroue. Daardie lêer noem die ankers wat die kliënt sal aanvaar, en dit kan een private CA bevat of, in 'n klein ontplooiing, die bediener se eie selfondertekende sertifikaat. Weergawe 2.6 aanvaar ook --peer-fingerprint om 'n SHA-256-vingerafdruk vas te pen in plaas van om 'n CA-lêer te versprei. WireGuard lê selfs verder buite: dit het glad geen sertifikate nie, net 'n statiese publieke sleutel per eweknie, so die selfondertekende vraag pas nie daarop nie.

Waar jy vertroue installeer, bepaal wie dit erf

Plaas dieselfde sertifikaat op drie plekke en jy kry drie verskillende trefradiusse. 'n Bundel wat net deur die VPN-kliënt gelees word, raak daardie kliënt. 'n Wortel in die bedryfstelselstoor raak elke program wat daardie stoor raadpleeg. 'n Blaaier met sy eie vertrouedatabasis kan albei ignoreer, en daarom kan 'n waarskuwing 'n invoer oorleef wat gelyk het of dit gewerk het.

Op Debian of Ubuntu verander dit die stelselwye bundel om 'n lêer in /usr/local/share/ca-certificates/ te laat val en update-ca-certificates te laat loop. Op Windows skryf certutil -addstore -f Root na die masjienstoor en het 'n verhoogde opdrag nodig, terwyl die byvoeging van -user eerder die huidige gebruiker se stoor teiken; die twee is nie uitruilbaar nie. Firefox hou sy eie NSS-databasis, so 'n invoer op bedryfstelselvlak sal dalk nooit daar verskyn nie.

Omvang maak saak weens wat 'n owerheid kan doen. 'n Uitreikende CA kan vir name onderteken waarmee dit geen verhouding het nie, so enigiets wat daardie stoor vertrou, sal daardie handtekeninge aanvaar. 'n Enkele vasgepende blaar kan dit nie doen nie; dit verifieer presies een eweknie-identiteit. As die doel is om een VPN te laat verbind, bereik 'n programgebonde CA of 'n vasgepende blaar dit, terwyl 'n masjienwye wortel 'n veel groter toegewing is as wat die simptoom vereis.

Jy versleutel steeds sonder 'n publieke CA

Die TLS-handskud lei sessiesleutels af ongeag of die eweknie-sertifikaat aan iets koppel wat jy reeds vertrou. Selfondertekend beteken nie klanteks nie, en dit beteken nie die verkeer is in vlug leesbaar nie. Wat dit beteken, is dat die kliënt geen a-priori rede het om te glo die sleutel behoort aan die bediener waarvoor hy gevra het nie.

Daardie gaping is waar werklike aanvalle woon. 'n Kliënt wat ingestel is om enige sertifikaat te aanvaar, hetsy deur 'n afgeskakelde verifikasiestelling of 'n vertrou-maar-ry-knoppie wat een keer gekliek en vergeet is, sal vrolik versleutel na elkeen wat antwoord. Die onderskepping gebeur in die verifikasiestap, voordat toepassingsdata beweeg. Versleuteling sonder 'n identiteitskontrole hou 'n passiewe waarnemer uit en doen min anders.

Om die uitreiker te vertrou slaan nie die naamkontrole oor nie

Kettingvalidering, naampassing en sertifikaatdoel is afsonderlike besluite. 'n Ketting kan geldig wees terwyl die naam verkeerd is, en 'n naam kan pas terwyl die sertifikaat vir 'n ander rol uitgereik is. RFC 5280 definieer die velde wat daardie beperkings dra, en hoe streng 'n kliënt dit afdwing, is 'n saak per program.

OpenVPN maak die skeiding sigbaar. verify-x509-name pen die verwagte subjek vas deur name, name-prefix of subject-passing. remote-cert-tls server vereis dat die eweknie-sertifikaat as 'n bedienersertifikaat bruikbaar is, wat 'n slegs-kliënt-sertifikaat verwerp selfs wanneer die uitreiker vertrou word. Nie een instelling word deur die versending van 'n CA-lêer vervang nie.

Inspekteer die sertifikaat voordat jy enigiets besluit:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName wys wie dit uitgereik het, vir watter name en tot wanneer.
• openssl verify -CAfile ca.crt server.crt kontroleer of die ketting wat jy beplan om te stuur, die blaar werklik valideer.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error werk vir TLS-eindpunte soos 'n webportaal; die OpenVPN-protokol op 1194 is nie 'n gewone TLS-stroom nie, so daardie toets geld nie daar nie.

'n Sertifikaat met 'n vervalde datum, geen subjectAltName vir die naam waaraan jy verbind nie, of 'n ontbrekende serverAuth-gebruik faal ongeag hoe sorgvuldig die anker geïnstalleer is.

Vyf kontroles voordat jy een aanvaar

Vergelyk die vingerafdruk oor 'n kanaal wat nie die verbinding is wat jy probeer herstel nie: 'n konsole, 'n installeerder wat jy reeds het, 'n ondertekende konfigurasielêer. openssl x509 -in server.crt -noout -fingerprint -sha256 op die bediener en dieselfde waarde in die kliëntlog is genoeg om te weet jy kyk na een objek.

Besluit volgende wat jy installeer: een blaar, of 'n owerheid wat meer kan munt. Besluit dan waar dit gaan, en noem die toepassings wat daardie stoor lees. Skryf die verwyderingspad neer terwyl jy dit nog onthou, want vertrou-en-gaan-aan is hoe 'n tydelike invoer permanent word.

Beplan laastens die verandering. 'n Vasgepende sertifikaat of vingerafdruk moet deur dieselfde vertroude kanaal opgedateer word wanneer die sertifikaat roteer, en 'n private CA het sy eie uitreikings- en herroepingslewensiklus. As die private sleutel lek, herstel die hervertroue van 'n kopie van dieselfde sertifikaat niks; die identiteit moet vervang word.

As 'n waarskuwing al vyf kontroles oorleef, is die nuttige vraag nie watter knoppie dit stilmaak nie, maar watter stoor die kliënt werklik lees en waar daardie wortel vandaan kom. Beantwoord dit, en die invoer wat jy op die punt is om te maak word 'n besluit in plaas van 'n refleks.