Multi-tenancy, certificados SSL y nombre alternativo del sujeto

Si cada inquilino tiene una copia de la clave privada, bueno, todos la tienen, lo que significa que pueden falsearse entre ellos. También pueden descifrar el tráfico entre otros inquilinos y sus clientes, a menos que utilicen los conjuntos de cifrado de SSL "DHE", que elimina este problema específico; esto se conoce como Perfect Forward Secrecy . DHE no hace nada contra el problema de la suplantación de identidad, y solo se puede utilizar si el software del cliente está de acuerdo.

El truco es, entonces, no dar la clave privada a cada inquilino. En lugar de que compartan el mismo certificado , haga que compartan el mismo servidor SSL . Ejecute un único servidor HTTPS de confianza que use el certificado y luego reenvíe el tráfico HTTP descifrado al inquilino correspondiente (cuyo nombre se especifica en el encabezado HTTP - no es necesario que SNI es compatible aquí). De hecho, hay una situación de proxy inverso . Tal configuración es segura (los inquilinos no reciben nada); sin embargo, requiere que los inquilinos confíen en el servidor SSL compartido (eso es aún mejor que requerir que los inquilinos confíen entre sí), e interferirá con (es decir, en la práctica, previene) el uso de certificados de cliente .

Sí, es tan arriesgado como parece. No te equivocas y, AFAIK, no creo que te estés perdiendo nada.

Varias entidades que comparten el mismo certificado que firma una clave pública, significa que comparten la misma clave privada. No es una buena cosa ^TM . Si site1.com no confía en site2.com , entonces no deberían configurarse para usar un Nombre alternativo del sujeto ( SAN ) certificado.

Una buena CA verificará que la entidad que solicita un certificado tiene propiedad sobre los temas definidos en la SAN (nombre de dominio, dirección IP, dirección de correo electrónico, etc.)

En conclusión, los certificados SAN solo deben usarse cuando los temas cubiertos confían en los demás. Es un buen ejemplo de sitios diferentes que utilizan el mismo certificado (uno que mencionó en la DMZ ), es el caso de los sitios SE. Aunque stackoverflow.com es un sitio diferente de superuser.com , todavía confían en los demás y pertenecen a la misma entidad.

@Adnan y @Thomas Pornin ambos tocan en el primer tramo del trípode: si solo se accede a la llave por medio del proveedor compartido (por ejemplo, un CDN), la seguridad no es necesariamente más baja, y si es compartida por un desconectado partes entonces la seguridad es ridículamente menor.

Hay una segunda pata para el trípode, que es el mantenimiento. Supongamos que la clave solo la tiene el proveedor compartido (HostCo), por lo que la seguridad no es un problema. HostCo tiene 20 inquilinos que mete en la clave usando Nombres alternativos de sujeto (SAN). ¡Genial! Pasa junio, llega julio, salen 3 inquilinos y aparecen 4 nuevos. Whoops! Es hora de obtener un nuevo certificado emitido que refleje los agregados / cambios. Genial. Whoops! Llega agosto ... ¿A dónde va esto? El mantenimiento de rehacer un certificado con múltiples SAN es estúpido con el tiempo, a menos que el conjunto de nombres que se incluye en una SAN sea bastante estático.

La tercera pata del trípode es el dinero. Puede ser más barato para HostCo usar un certificado SAN que salir y comprar 20 certificados. Esta etapa no tiene sentido, en realidad, debido a que los inquilinos son unidades realmente desconectadas que no confían entre sí, HostCo solo les va a pasar los costos de los certificados individuales. No hay el mismo incentivo económico que, digamos, Massive Dynamic tiene que ahorrar dinero en el certificado para el sitio web que atiende a sus 273 subsidiarias.

Son tres patas notablemente tambaleantes. No me sentaría en ese taburete dada la opción.