🥇DPI (SSL Inspection) va en contra de la criptografia, però les empreses ho estan implementant

Cadena de confiança. CC BY-SA 4.0 Yanpas

La inspecció de trànsit SSL (desxifrat SSL/TLS, anàlisi SSL o DPI) s'està convertint en un tema de discussió cada cop més candent al sector corporatiu. La idea de desxifrar el trànsit sembla contradir el mateix concepte de criptografia. No obstant això, el fet és un fet: cada cop són més les empreses que utilitzen tecnologies DPI, la qual cosa ho explica per la necessitat de comprovar continguts per malware, fuites de dades, etc.

Bé, si acceptem el fet que s'ha d'implementar aquesta tecnologia, almenys hauríem de considerar maneres de fer-ho de la manera més segura i ben gestionada possible. Almenys no us confieu en aquests certificats, per exemple, que us ofereix el proveïdor del sistema DPI.

Hi ha un aspecte de la implementació que no tothom coneix. De fet, molta gent es sorprèn molt quan en senten parlar. Aquesta és una autoritat de certificació privada (CA). Genera certificats per desxifrar i tornar a xifrar el trànsit.

En lloc de confiar en certificats autofirmats o certificats de dispositius DPI, podeu utilitzar una CA dedicada d'una autoritat de certificació de tercers, com ara GlobalSign. Però primer, fem una petita visió general del problema en si.

Què és la inspecció SSL i per què s'utilitza?

Cada cop hi ha més llocs web públics que passen a HTTPS. Per exemple, segons Estadístiques de Chrome, a principis de setembre de 2019, la quota de trànsit xifrat a Rússia va arribar al 83%.

Malauradament, els atacants utilitzen cada cop més el xifratge de trànsit, sobretot perquè Let's Encrypt distribueix milers de certificats SSL gratuïts de manera automatitzada. Per tant, HTTPS s'utilitza a tot arreu i el cadenat de la barra d'adreces del navegador ha deixat de servir com a indicador fiable de seguretat.

Els fabricants de solucions DPI promocionen els seus productes des d'aquestes posicions. S'incrusten entre els usuaris finals (és a dir, els vostres empleats que naveguen per la web) i Internet, filtrant el trànsit maliciós. Actualment hi ha diversos productes d'aquest tipus al mercat, però els processos són essencialment els mateixos. El trànsit HTTPS passa per un dispositiu d'inspecció on es desxifra i es comprova si hi ha programari maliciós.

Un cop completada la verificació, el dispositiu crea una nova sessió SSL amb el client final per desxifrar i tornar a xifrar el contingut.

Com funciona el procés de desxifrat/rexifratge

Perquè l'aparell d'inspecció SSL desxifra i torni a xifrar els paquets abans d'enviar-los als usuaris finals, ha de poder emetre certificats SSL sobre la marxa. Això vol dir que ha de tenir un certificat CA instal·lat.

És important per a l'empresa (o per a qui estigui al mig) que aquests certificats SSL siguin de confiança pels navegadors (és a dir, no activen missatges d'advertència aterridors com el següent). Per tant, la cadena de CA (o jerarquia) ha d'estar a la botiga de confiança del navegador. Com que aquests certificats no s'emeten per autoritats de certificació de confiança pública, heu de distribuir manualment la jerarquia de CA a tots els clients finals.

Missatge d'advertència per al certificat autofirmat a Chrome. Font: BadSSL.com

На компьютерах с Windows можно задействовать Active Directory и групповые политики, но для мобильных устройств процедура сложнее.

La situació es complica encara més si necessiteu suportar altres certificats arrel en un entorn corporatiu, per exemple, de Microsoft o basat en OpenSSL. A més la protecció i gestió de les claus privades perquè cap de les claus no caduqui de manera inesperada.

Millor opció: certificat arrel privat i dedicat d'una CA de tercers

Si la gestió de múltiples arrels o certificats autofirmats no és atractiu, hi ha una altra opció: confiar en una CA de tercers. En aquest cas, s'emeten certificats de privat una CA que està vinculada en una cadena de confiança a una CA arrel privada dedicada creada específicament per a l'empresa.

Arquitectura simplificada per a certificats arrel de client dedicats

Aquesta configuració elimina alguns dels problemes esmentats anteriorment: almenys redueix el nombre d'arrels que cal gestionar. Aquí podeu utilitzar només una autoritat arrel privada per a totes les necessitats internes de PKI, amb qualsevol nombre de CA intermèdies. Per exemple, el diagrama anterior mostra una jerarquia multinivell on una de les CA intermèdies s'utilitza per a la verificació/desxifrat SSL i l'altra s'utilitza per a ordinadors interns (ordinadors portàtils, servidors, ordinadors de sobretaula, etc.).

En aquest disseny, no hi ha necessitat d'allotjar una CA a tots els clients perquè la CA de nivell superior està allotjada per GlobalSign, que resol els problemes de protecció de clau privada i caducitat.

Un altre avantatge d'aquest enfocament és la possibilitat de revocar l'autoritat d'inspecció SSL per qualsevol motiu. En canvi, simplement se'n crea un de nou, que està lligat a la vostra arrel privada original, i podeu utilitzar-lo immediatament.

Malgrat tota la controvèrsia, les empreses estan implementant cada cop més la inspecció de trànsit SSL com a part de la seva infraestructura PKI interna o privada. Altres usos de la PKI privada inclouen l'emissió de certificats per a l'autenticació de dispositiu o d'usuari, SSL per a servidors interns i diverses configuracions que no es permeten als certificats públics de confiança, tal com requereix el CA/Browser Forum.

Els navegadors estan lluitant

Cal tenir en compte que els desenvolupadors de navegadors estan intentant contrarestar aquesta tendència i protegir els usuaris finals de MiTM. Per exemple, fa uns dies Mozilla va prendre una decisió Activeu el protocol DoH (DNS-over-HTTPS) de manera predeterminada en una de les properes versions del navegador a Firefox. El protocol DoH amaga les consultes DNS del sistema DPI, cosa que dificulta la inspecció SSL.

Sobre plans similars 10 de setembre de 2019 va anunciar Google per al navegador Chrome.