Deurgevoerde VPN-poort: wat besoekers en die verskaffer kan sien

Om 'n poort deur te voer gee vreemdelinge 'n roete na 'n diens via die verskaffer se openbare adres. Daardie enkele verandering raak blootstelling en herkenbaarheid tegelyk, en nie een van die twee publiseer die naam van wie die diens bedryf nie. Om die twee uitmekaar te hou vermy die teenoorgestelde foute om deurvoer as anonimiteit te sien en om dit as identifikasie te sien. Drie vrae skei hulle skoon, en die antwoorde kom uit verskillende bewyse.

Drie objekte, drie verskillende vrae

Hou die openbare adres apart van die toepassing wat daar agter antwoord, en hou beide apart van die persoon of organisasie wat die ding bedryf. Elkeen het sy eie gehoor en sy eie bewyse. Om hulle te vermeng lewer gevolgtrekkings wat netjies klink en verkeerd is.

Werk hulle in daardie volgorde deur. Die eerste is 'n bereikbaarheidsvraag, die tweede is 'n vraag oor toepassingsidentiteit, en die derde is 'n toeskrywingsvraag waaroor die eerste twee net gedeeltelik lig gee. Wanneer iemand vra of poortdeurvoer privaat is, vra watter van die drie hulle bedoel. Die antwoorde verskil werklik, en ’n beleidsblad dek gewoonlik net een van hulle.

Wat ’n besoeker oor eindpunte kan koppel

'n Besoeker verbind met die eindpunt en sien wat die toepassing wettig aanbied: ’n gasheernaam, ’n sertifikaatnaam, ’n aanmeldbladsy, gepubliseerde inhoud. Daardie besonderhede identifiseer die diens selfs wanneer sy gewone toegangsadres agter die tonnel versteek is. Twee eindpunte wat dieselfde genoemde werf aanbied, gee waarnemers 'n basis om hulle te koppel. Niks in daardie gedrag is ’n lek nie, want die toepassing is ontwerp om gesien te word.

Om sertifikate, aansture en bladsyinhoud oor twee eindpunte te pas, is ’n sterk teken dat hulle aan een diens behoort. Dit bly ’n stelling oor die diens, nie oor ’n mens nie, totdat een of ander ander rekord die twee verbind.

Die IETF-privaatheidsriglyne beskryf hoe aanhoudende identifiseerders dit moontlik maak om interaksies oor tyd te korreleer. Korrelasie is nie toeskrywing nie, want verskeie mense kan ’n enkele diens administreer en ’n adres kan tussen onverwante intekenare verskuif. Daardie onderskeid is wat verhoed dat ’n korrelasiebevinding in ’n beskuldiging verander.

Wat die deurvoerverskaffer moet weet

Om ’n inkomende verbinding te lewer, moet die verskaffer se stelsel die aktiewe verhouding tussen die openbare toegangspunt en die interne bestemming hou. Daardie operasionele feit verskil van wat ’n besoeker sien, en verskil weer van wat die verskaffer kies om te bewaar. Hou die twee vrae apart wanneer jy ’n beleidsblad lees, want een is onvermydelik en die ander is ’n besluit. ’n Stelling dat geen blaaierygeskiedenis bewaar word nie, sê niks oor karteringgeskiedenis nie.

Of historiese karterings, rekeningassosiasies of verbindingsrekords bly voortbestaan, is ’n vraag vir die verskaffer se werklike beleid en implementering. Deurvoer bewys nie dat elke kategorie gelog word nie. Vra spesifiek watter velde oorleef nadat die kartering teruggetrek is, en vir hoe lank.

Inkomende bereikbaarheid is ook apart van die kliënt se uitgaande roetering, DNS en foutgedrag. Om ’n kartering by te voeg, beskryf nie hoe die res van die kliënt se verkeer uitgaan nie.

Hoe lank die kartering duur, verander die blootstelling

’n Kartering kan vir ’n sessie duur, vir ’n bespreking, of onder ’n verskafferbeleid wat dit verander. Nóg permanente toewysing nóg konstante rotasie moet aanvaar word; lees die produk se gedokumenteerde gedrag en teken op wat jy sien. Twee waarnemings ’n week uitmekaar vertel jou meer oor rotasie as enige bemarkingsin op die produkblad. Plaas die waargenome interval langs die eindpunt in jou notas, want die interval is deel van die blootstelling.

Die leeftyd verander watter korrelasie moontlik is. ’n Stabiele eindpunt nooi langtermynopsporing van een diens uit, terwyl ’n roterende een elke waarneming moeiliker maak om by die vorige aan te sluit. Nie een eienskap is ’n waarborg oor die verskaffer se rekords nie, en nie een is ’n plaasvervanger vir die besluit wat die diens self publiseer nie.

Publiseer doelbewus, sluit dan albei deure

Bevestig dat die verskaffer die protokol toelaat wat jy nodig het, dat die teikengehoor die een is wat jy bedoel het, en dat gasheer- en toepassingsbeheer steeds toegang beperk. Kyk voor publikasie na wat die diens aan ’n vreemdeling sal wys. Hierdie twee opdragte wys die sertifikaat en die opkoppe wat ’n besoeker ontvang.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

Om iets te publiseer regverdig nie die blootstelling van sy administrasiebladsye of die weglating van die toepassing se aanmelding nie, en vertaling verskaf nie TLS aan ’n diens wat dit nooit gehad het nie. Hou die geënkripteerde protokol en sy bedieneridentiteitskontroles in plek ongeag hoe die verkeer aankom. Kontroleer dan die antwoordopkoppe, want ’n banier of ’n ontfoutingsblad kan ’n vreemdeling meer vertel as wat die diens bedoel. Wat die twee opdragte teruggee, is dieselfde beeld wat ’n waarnemer kry.

Om die diens te onttrek beteken twee sluitings, nie een nie: trek die kartering deur sy eienaar terug, en hanteer dan die gehoor en die reg as aparte items. ’n Gemerkte eindpunt wat ophou antwoord, herroep nie ’n geloofsbrief nie, en dit haal nie inligting terug wat reeds gelewer is nie.