Cadea de confianza. CC BY-SA 4.0
A inspección de tráfico SSL (descifrado SSL/TLS, análise SSL ou DPI) está a ser un tema de discusión cada vez máis candente no sector corporativo. A idea de descifrar o tráfico parece contradicir o propio concepto de criptografía. Non obstante, o feito é un feito: cada vez son máis as empresas que utilizan tecnoloxías DPI, o que explica a necesidade de comprobar o contido de malware, fugas de datos, etc.
Ben, se aceptamos o feito de que esa tecnoloxía debe ser implementada, polo menos deberíamos considerar formas de facelo da forma máis segura e ben xestionada posible. Polo menos non te basees neses certificados, por exemplo, que che proporciona o provedor do sistema DPI.
Hai un aspecto da implementación que non todos coñecen. De feito, moitas persoas quedan moi sorprendidas cando oen falar diso. Esta é unha autoridade de certificación privada (CA). Xera certificados para descifrar e volver cifrar o tráfico.
En lugar de confiar en certificados autoasinados ou certificados de dispositivos DPI, podes usar unha CA dedicada dunha autoridade de certificación de terceiros como GlobalSign. Pero primeiro, imos facer unha pequena visión xeral do problema en si.
Que é a inspección SSL e por que se usa?
Cada vez son máis os sitios web públicos que pasan a HTTPS. Por exemplo, segundo , a principios de setembro de 2019, a participación do tráfico cifrado en Rusia alcanzou o 83%.
Desafortunadamente, os atacantes utilizan cada vez máis o cifrado de tráfico, especialmente porque Let's Encrypt distribúe miles de certificados SSL gratuítos de forma automatizada. Así, HTTPS úsase en todas partes e o cadeado da barra de enderezos do navegador deixou de servir como un indicador fiable de seguridade.
Os fabricantes de solucións DPI promoven os seus produtos desde estas posicións. Están integrados entre os usuarios finais (é dicir, os seus empregados que navegan pola web) e Internet, filtrando o tráfico malicioso. Hai unha serie de produtos deste tipo no mercado hoxe en día, pero os procesos son esencialmente os mesmos. O tráfico HTTPS pasa por un dispositivo de inspección onde se descifra e comproba se hai malware.
Unha vez completada a verificación, o dispositivo crea unha nova sesión SSL co cliente final para descifrar e volver cifrar o contido.
Como funciona o proceso de descifrado/recifrado
Para que a aplicación de inspección SSL poida descifrar e volver cifrar os paquetes antes de envialos aos usuarios finais, debe poder emitir certificados SSL sobre a marcha. Isto significa que debe ter un certificado CA instalado.
É importante para a empresa (ou quen sexa quen sexa do medio) que os navegadores confíen nestes certificados SSL (é dicir, que non desencadeen mensaxes de aviso de medo como a seguinte). Polo tanto, a cadea de CA (ou xerarquía) debe estar na tenda de confianza do navegador. Dado que estes certificados non se emiten por autoridades de certificación de confianza pública, debes distribuír manualmente a xerarquía da CA a todos os clientes finais.
Mensaxe de aviso para o certificado autofirmado en Chrome. Fonte:
Nos ordenadores con Windows pódese utilizar Active Directory e Políticas de grupo, pero para os dispositivos móbiles o procedemento é máis complicado.
A situación complícase aínda máis se precisa admitir outros certificados raíz nun contorno corporativo, por exemplo, de Microsoft ou baseado en OpenSSL. Ademais da protección e xestión das claves privadas para que ningunha das chaves non caduque de forma inesperada.
A mellor opción: certificado raíz privado e dedicado dunha CA de terceiros
Se xestionar varias raíces ou certificados autoasinados non resulta atractivo, hai outra opción: confiar nunha CA de terceiros. Neste caso, expídense certificados de privado unha CA que está vinculada nunha cadea de confianza a unha CA raíz privada e dedicada creada especificamente para a empresa.
Arquitectura simplificada para certificados raíz de clientes dedicados
Esta configuración elimina algúns dos problemas mencionados anteriormente: polo menos reduce o número de raíces que hai que xestionar. Aquí pode usar só unha autoridade raíz privada para todas as necesidades internas de PKI, con calquera número de CA intermedias. Por exemplo, o diagrama anterior mostra unha xerarquía de varios niveis onde unha das CA intermedias úsase para a verificación/descifrado SSL e a outra para ordenadores internos (portátiles, servidores, escritorios, etc.).
Neste deseño, non é necesario aloxar unha CA en todos os clientes porque a CA de nivel superior está aloxada por GlobalSign, o que resolve os problemas de protección da chave privada e de caducidade.
Outra vantaxe deste enfoque é a posibilidade de revogar a autoridade de inspección SSL por calquera motivo. En cambio, simplemente créase un novo, que está ligado á túa raíz privada orixinal, e podes usalo inmediatamente.
A pesar de toda a controversia, as empresas están a implementar cada vez máis a inspección de tráfico SSL como parte da súa infraestrutura PKI interna ou privada. Outros usos da PKI privada inclúen a emisión de certificados para a autenticación de dispositivos ou usuarios, SSL para servidores internos e varias configuracións que non están permitidas en certificados públicos de confianza, tal e como require o CA/Browser Forum.
Os navegadores están a loitar
Nótese que os desenvolvedores de navegadores están tentando contrarrestar esta tendencia e protexer aos usuarios finais de MiTM. Por exemplo, hai uns días Mozilla Activa o protocolo DoH (DNS-over-HTTPS) de forma predeterminada nunha das próximas versións do navegador en Firefox. O protocolo DoH oculta as consultas DNS do sistema DPI, dificultando a inspección SSL.
Sobre plans similares 10 de setembro de 2019 Google para o navegador Chrome.
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Cres que unha empresa ten dereito a inspeccionar o tráfico SSL dos seus empregados?
-
Si, co seu consentimento
-
Non, pedir ese consentimento é ilegal e/ou non é ético
Votaron 122 usuarios. 15 usuarios abstivéronse.
Fonte: www.habr.com