Ketting van vertroue. CC BY-SA 4.0
SSL-verkeerinspeksie (SSL/TLS-dekripsie, SSL- of DPI-analise) word 'n toenemend warm onderwerp van bespreking in die korporatiewe sektor. Die idee om verkeer te dekripteer blyk die konsep van kriptografie te weerspreek. Die feit is egter 'n feit: meer en meer maatskappye gebruik DPI-tegnologieë, wat dit verduidelik deur die behoefte om inhoud na te gaan vir wanware, datalekkasies, ens.
Wel, as ons die feit aanvaar dat sulke tegnologie geïmplementeer moet word, dan moet ons ten minste maniere oorweeg om dit op die veiligste en goed bestuurde manier moontlik te doen. Moet ten minste nie staatmaak op daardie sertifikate, byvoorbeeld, wat die DPI-stelselverskaffer vir jou gee nie.
Daar is een aspek van implementering waarvan nie almal weet nie. Trouens, baie mense is regtig verbaas wanneer hulle daarvan hoor. Dit is 'n private sertifiseringsowerheid (CA). Dit genereer sertifikate om verkeer te dekripteer en weer te enkripteer.
In plaas daarvan om op self-ondertekende sertifikate of sertifikate van DPI-toestelle staat te maak, kan jy 'n toegewyde CA van 'n derdeparty-sertifikaatowerheid soos GlobalSign gebruik. Maar laat ons eers 'n bietjie oorsig gee van die probleem self.
Wat is SSL-inspeksie en hoekom word dit gebruik?
Al hoe meer publieke webwerwe skuif na HTTPS. Byvoorbeeld, volgens , aan die begin van September 2019 het die aandeel van geïnkripteer verkeer in Rusland 83% bereik.
Ongelukkig word verkeerskodering toenemend deur aanvallers gebruik, veral omdat Let's Encrypt duisende gratis SSL-sertifikate op 'n outomatiese wyse versprei. HTTPS word dus oral gebruik - en die hangslot in die blaaieradresbalk het opgehou om as 'n betroubare aanwyser van sekuriteit te dien.
Vervaardigers van DPI-oplossings bevorder hul produkte vanuit hierdie posisies. Hulle is ingebed tussen eindgebruikers (d.w.s. jou werknemers wat op die web blaai) en die internet, wat kwaadwillige verkeer uitfiltreer. Daar is vandag 'n aantal sulke produkte op die mark, maar die prosesse is in wese dieselfde. HTTPS-verkeer gaan deur 'n inspeksietoestel waar dit gedekripteer word en vir wanware gekontroleer word.
Sodra die verifikasie voltooi is, skep die toestel 'n nuwe SSL-sessie met die eindkliënt om die inhoud te dekripteer en weer te enkripteer.
Hoe die dekripsie-/herenkripsieproses werk
Om die SSL-inspeksie-toestel pakkies te dekripteer en weer te enkripteer voordat dit aan eindgebruikers gestuur word, moet dit SSL-sertifikate dadelik kan uitreik. Dit beteken dat dit 'n CA-sertifikaat moet hê.
Dit is belangrik vir die maatskappy (of wie ook al-in-die-middel) dat hierdie SSL-sertifikate deur blaaiers vertrou word (dit wil sê, moenie skrikwekkende waarskuwingsboodskappe soos die een hieronder aktiveer nie). Daarom moet die CA-ketting (of hiërargie) in die blaaier se trustwinkel wees. Omdat hierdie sertifikate nie van publiek vertroude sertifikaatowerhede uitgereik word nie, moet jy die CA-hiërargie handmatig aan alle eindkliënte versprei.
Waarskuwingsboodskap vir selfondertekende sertifikaat in Chrome. Bron:
Op Windows-rekenaars kan jy Active Directory en Groepbeleide gebruik, maar vir mobiele toestelle is die prosedure meer ingewikkeld.
Die situasie word selfs meer ingewikkeld as jy ander wortelsertifikate in 'n korporatiewe omgewing moet ondersteun, byvoorbeeld van Microsoft, of gebaseer op OpenSSL. Plus die beskerming en bestuur van private sleutels sodat enige van die sleutels nie onverwags verval nie.
Beste opsie: privaat, toegewyde wortelsertifikaat van 'n derdeparty-CA
As die bestuur van veelvuldige wortels of selfondertekende sertifikate nie aanloklik is nie, is daar 'n ander opsie: staatmaak op 'n derdeparty-CA. In hierdie geval word sertifikate uitgereik vanaf privaat 'n GR wat in 'n ketting van vertroue gekoppel is aan 'n toegewyde, private wortel-GR wat spesifiek vir die maatskappy geskep is.
Vereenvoudigde argitektuur vir toegewyde kliënt wortelsertifikate
Hierdie opstelling elimineer sommige van die probleme wat vroeër genoem is: dit verminder ten minste die aantal wortels wat bestuur moet word. Hier kan jy net een private wortelowerheid gebruik vir alle interne PKI-behoeftes, met enige aantal intermediêre CA's. Byvoorbeeld, die bostaande diagram toon 'n multi-vlak hiërargie waar een van die intermediêre CA's gebruik word vir SSL verifikasie/dekripsie en die ander word gebruik vir interne rekenaars (skootrekenaars, bedieners, lessenaars, ens.).
In hierdie ontwerp is dit nie nodig om 'n CA op alle kliënte te huisves nie, want die topvlak-CA word deur GlobalSign gehuisves, wat privaatsleutelbeskerming en vervalkwessies oplos.
Nog 'n voordeel van hierdie benadering is die vermoë om die SSL-inspeksie-owerheid om enige rede te herroep. In plaas daarvan word 'n nuwe een eenvoudig geskep, wat aan jou oorspronklike private wortel gekoppel is, en jy kan dit dadelik gebruik.
Ten spyte van al die kontroversie, implementeer ondernemings toenemend SSL-verkeerinspeksie as deel van hul interne of private PKI-infrastruktuur. Ander gebruike vir private PKI sluit in die uitreiking van sertifikate vir toestel- of gebruiker-verifikasie, SSL vir interne bedieners, en verskeie konfigurasies wat nie toegelaat word in publieke vertroude sertifikate soos vereis deur die CA/Blaaierforum nie.
Blaaiers veg terug
Daar moet kennis geneem word dat blaaierontwikkelaars probeer om hierdie neiging teë te werk en eindgebruikers teen MiTM te beskerm. Byvoorbeeld, 'n paar dae gelede Mozilla Aktiveer DoH (DNS-oor-HTTPS)-protokol by verstek in een van die volgende blaaierweergawes in Firefox. Die DoH-protokol verberg DNS-navrae van die DPI-stelsel, wat SSL-inspeksie moeilik maak.
Oor soortgelyke planne 10 September 2019 Google vir die Chrome-blaaier.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Dink jy 'n maatskappy het die reg om die SSL-verkeer van sy werknemers te inspekteer?
-
Ja, met hul toestemming
-
Nee, om vir sulke toestemming te vra is onwettig en/of oneties
122 gebruikers het gestem. 15 gebruikers het buite stemming gebly.
Bron: will.com