Estaba mirando el certificado del sitio web de mi banco y descubrí que se emitió a varios sitios web, y el nombre de dominio del banco solo se incluye entre muchos otros dominios en el campo "nombres alternativos".
¿Se considera esto una mala práctica? ¿A qué riesgos están sujetos sus clientes? (¿hombre en el medio? ¿personificación?)
Es un certificado de una red de entrega de contenido , una compañía estadounidense Incapsula Inc., que intercepta toda su comunicación con banco. El certificado en sí no representa un riesgo directo para los datos de los clientes, pero:
¿Se considera esto una mala práctica?
A diferencia de otro responde , diría que no es normal y la situación indica un cierto nivel de incompetencia en el banco.
De acuerdo con los planes de precios de Incapsula, su banco podría estar usando $ 59 / mes, mientras que la compañía ofrece SSL personalizados por $ 299 al mes (función "Admite certificados SSL personalizados") y un plan real para empresas.
Incluso si el banco le paga más a CDN, el banco está usando una funcionalidad dirigida a blogs profesionales y no está usando las funciones que ofrece su plan / acuerdo.
Su banco puede estar violando las leyes de privacidad en su país al permitir que una compañía de otro país, bajo una legislatura diferente, procese los datos de identificación personal de los clientes.
¿A qué riesgos están sujetos sus clientes? (¿hombre en el medio? ¿personificación?)
Los datos están encriptados entre su navegador y el punto final de la CDN. La clave privada se almacena (con suerte) solo en los servidores de CDN, por lo que no hay riesgo de que otras compañías de la lista puedan hacerse pasar por el banco.
Mientras los estándares de seguridad se cumplan en un enlace entre CDN y el banco, el MitM tampoco es posible técnicamente.
Note incapsula.com en el asunto. Incapsula es una compañía que ofrece seguridad de aplicaciones web que incluye protección WAF, DDOS y algunos servicios más.
Mi conjetura es que el sitio web de su banco en realidad está proxy a través de su servidor y también lo son todos esos otros sitios. Ese servidor entrega el mismo certificado en todos esos sitios porque, en realidad, todos se procesan a través del mismo servidor.
No hay razón para preocuparse aquí.
Esto puede ser normal.
Los bancos a menudo se consolidan, compran, cruzan el mercado y hacen todo tipo de cosas que significan que están respondiendo a más de un nombre. No es raro que un banco tenga numerosas entradas de SAN para permitir que todos sus clientes variados accedan a su sitio web, incluso si son clientes de un banco comprado por un banco comprado por un banco comprado por un banco que fue comprado por un banco que ellos han adquirido.
Es posible que desee comprobar si los otros nombres que aparecen en la lista coinciden con la misma dirección IP y / o son atendidos por sitios web que utilizan el mismo certificado. Si esos dominios realmente comparten un propietario común, esto puede ser una práctica normal.
En términos de seguridad, es potencialmente peor, si la clave privada se comparte con numerosos servidores, numerosos administradores, pero no definitivamente . No sabes lo que realmente está sucediendo detrás de escena como para decirlo.
No es necesariamente un riesgo de seguridad concreto, tan pronto como usted (el administrador de TI) esté preparado para los nuevos riesgos.
Si tiene un solo certificado para muchos dominios, es un punto único de falla y el anillo de cadena más débil. Debe aplicar procedimientos de TI costosos para mantener su clave privada "solo ojos" o mejor "solo servidor HTTPS". El compromiso de la clave única afectará a todos los servicios a la vez. Todo su negocio depende de un número largo de 4096 bits.
Cuando una clave única se comparte a través de varios servicios en un CDN, su compromiso hará que todo el CDN baje durante el período de renovación de la clave. Agregar un nuevo dominio para el servicio implica volver a emitir el certificado con su tiempo de inactividad asociado.
Hay una ventaja de usar tales certificados compartidos. En un CDN, puede efectivamente configurar proxies HTTPS. Esta es una práctica ampliamente utilizada y tiene grandes ventajas de rendimiento.
Básicamente, su DMZ aloja un conjunto de servidores proxy reverse con equilibrio de carga que recibirán tráfico HTTPS, lo descifrarán y reenviarán el tráfico HTTP (aviso, no S) a los servidores reales dentro de la red CDN . Esto requiere una configuración sólida de la red interna para garantizar la seguridad de los paquetes, pero hay profesionales que trabajan en eso, y recuerde que el tráfico sin cifrar fluye solo dentro de una zona de confianza.
Entonces, ¿por qué balanceo de carga? Porque si su CDN aloja 1000 sitios y algunos de ellos obtienen un aumento de tráfico, no necesita aprovisionar máquinas para ellos. Puedes dejar que los proxies funcionen como round-robin.
Hay una razón técnica detrás de los certificados multialisados y es que la CDN no quiere requerir SNI (Identificación del nombre del servidor) de los clientes. Especialmente en el mundo financiero / empresarial, los navegadores de algunas personas pueden ser demasiado antiguos para admitir SNI.
Aprovisionar un nuevo certificado para cada nuevo servicio, con una clave privada diferente, es una buena práctica de seguridad.
Estoy con el equipo de Imperva Incapsula.
Parece que hay mucha confusión, así que me gustaría señalar algunos hechos:
Pero lo más importante es que no es un peligro para la seguridad. De cualquier manera.
Tome todos los comentarios aquí con una gran cantidad de sal.
Creo que es importante afirmar que estos comentarios (incluso si están escritos con buena intención) son infundados, erróneos y falsos:
HTH
En cuanto a la seguridad no. Como señalaron varias personas, los CDN protegen la clave privada con más seguridad que las organizaciones.
Pero el riesgo puede ser más de una apariencia. Por ejemplo, es posible que ABC Bank no quiera compartir un certificado con XYX Guns y Ammo. Es un problema de apariencia.
Lea otras preguntas en las etiquetas tls certificates