’n Pasgemaakte VPN-sertifikaat is nie ’n ekstra versleutelingslaag nie

Om ’n pasgemaakte sertifikaat op ’n VPN-eindpunt te installeer voel soos om beskerming by te voeg, want sertifikate en versleuteling verskyn oral saam. In die praktyk verander dit twee dinge: watter identiteit die eindpunt voorhou, en watter uitreiker sy eweknie bereid is om te vertrou. Nie een van dié twee draai jou data ’n tweede keer toe nie. As die werklike vereiste ’n tweede beskermde kanaal is, het jy ’n tweede kanaal met sy eie eindpunte nodig, nie nóg ’n sertifikaat nie.

Drie afsonderlike take in ’n TLS 1.3-handdruk

RFC 8446 hou dié dinge apart, en juis dié skeiding is die antwoord. Die Certificate-boodskap dra die eindpunt se sertifikaatketting. CertificateVerify bewys besit van die ooreenstemmende private sleutel en bind die handdruk-transkripsie. Die rekordlaag beskerm verkeer met die onderhandelde verkeersleutels.

Vervang die sertifikaat en die eerste twee items verander. Die rekordbeskerming loop nie twee keer nie, en dit word nie sterker omdat die uitreiker nou privaat is nie.

Wat ’n privaat CA werklik koop

Dit koop ’n beheerde identiteitstelsel: jy besluit wie sertifikate kry, jy besluit watter uitreikers eweknieë aanvaar, en jy kan op jou eie skedule herroep. Dit is werklik nuttig wanneer jy beide kante bestuur.

Dit bring ook verpligtinge mee. Vertroue moet doelbewus versprei word, eweknie-verifikasie moet aan bly, en iemand moet eienaar van die lewensiklus van die geloofsbriewe wees. ’n Privaat CA is nie ’n kortpad om enige van dié drie nie.

Wanneer ’n tweede kanaal die regte antwoord is

Veronderstel ’n toepassing open ’n geverifieerde HTTPS-verbinding na sy eie diens terwyl sy pakkette ook deur ’n VPN beweeg. Daardie ontwerp het twee grense met moontlik verskillende eindpunte, en dit is hoe ’n tweede beskermde kanaal lyk.

Die onderskeid maak saak by die poort. As die toepassing se TLS-sessie by die VPN-poort eindig eerder as by die toepassing, is die beskerming wat jy gedink het jy buite die tonnel het, nie daar nie. Skryf neer wie elke kanaal beëindig voordat jy die eienskap opeis.

Vra wat die installasie verander

’n Versoek om ’n sertifikaat te installeer kan drie verskillende dinge beteken. Dit kan die kliënt se eie identiteit verander, ’n toepassing-spesifieke vertrouensanker, of vertroue op platformvlak vir alles op die toestel. Dié is nie gelykwaardig nie, en net die laaste een raak sagteware wat niks daarmee te doen het nie.

Vra watter van die drie bedoel word, en vra dan wat dit veronderstel is om te bereik. As die antwoord meer versleuteling is, is die voorstel op die verkeerde meganisme gerig.

Skryf die grense neer

Vir elke kanaal: teken die eindpunte aan, die identiteit wat elke kant verifieer, en wat die operateur in die middel kan sien. Teken dan die foutgedrag aan: wat gebeur wanneer verifikasie misluk, en wat gebeur wanneer die kanaal geweier word.

Twee reëls op een bladsy besleg gewoonlik ’n argument wat ’n sertifikaat-rotasie nie kan nie.

Besluit met drie vrae

Is die probleem wie die eindpunt voorgee om te wees, of wat met die data gebeur? Moet beskerming verby die VPN-poort na ’n spesifieke toepassing voortduur? En kan jy die twee eindpunte noem wat ’n tweede kanaal sou beëindig?

As die eerste vraag die regte een is, maak identiteit en vertroue reg. As die tweede of derde dit is, ontwerp die tweede kanaal en laat die sertifikaat waar dit hoort.