Con el próxima venida de TLS 1.0 para el cumplimiento de PCI , pensé que confirmaría algo: ¿qué categorías de activos con referencia externa (en su caso) podrían causar una falla de cumplimiento si sus dominios aún aceptaban conexiones TLS 1.0 después de junio de 2018?
Mi conjetura sería "todo", ya que todas esas cosas se han utilizado como vectores de explotación en el pasado, pero tengo curiosidad por si hay algo oficial.
Hasta ahora no hay nada oficial, pero es casi seguro que dependerá del criterio del ASV individual. Este es casi siempre el caso a propósito, porque permite que las evaluaciones se adapten a los nuevos vectores de ataque y diferentes contextos.
Por ejemplo, en un dominio aislado donde no se ingresa información y no se pueden realizar acciones con estado (por ejemplo, un portal de enlace estático dentro del entorno PCI), ninguno de estos casos es particularmente crítico y cometeré un error al dejar de se aprobará siempre que la empresa pueda demostrar un plan a largo plazo para migrar a una configuración más segura.
Por el contrario, en un sistema que acepta datos financieros y realiza transacciones financieras, es casi seguro que fallaría en cualquiera de esos casos. Se sabe que los scripts y CSS son vectores XSS, por lo que son el mayor riesgo aquí. Históricamente, las fuentes han sido riesgosas para el punto final del cliente, pero en general son más difíciles de explotar fuera de escenarios extremadamente específicos. Las imágenes son el riesgo más bajo aquí.
En teoría , PCI solo requiere que deje caer TLS 1.0 "para proteger los datos confidenciales de los titulares de tarjetas durante la transmisión a través de redes públicas abiertas" y para "todos los accesos administrativos que no sean de consola . " Por lo tanto, se podría argumentar que cosas como las imágenes estáticas no están sujetas a la prohibición de "principios TLS".
En realidad , sin embargo, la configuración de TLS es un problema por servidor / aplicación. Si su sitio ofrece contenido sensible y no confidencial, no puede negociar el TLS temprano según el tipo de solicitud, ya que la solicitud solo se produce después de que se haya negociado TLS. Y con HTTP / 1.1, por ejemplo, puede tener una conexión que canaliza múltiples solicitudes, todas bajo el mismo TLS negociado. Realmente no puede negociar el TLS temprano y luego aceptar o rechazar solicitudes en función de su sensibilidad. E incluso si pudiera, si se trata de una solicitud POST que le envía datos PAN, el daño ya se hizo cuando usted ve la solicitud.
Por lo tanto, encontrará que los ASV requieren la eliminación de todo el sitio de TLS en cualquier sitio que tenga contenido confidencial.
Personalmente, creo que encontrará que la prohibición temprana de TLS se extenderá para cubrir todos los hosts y servicios, internos o externos, sensibles o no. Debido a que el ASV no quiere estar revisando casos individuales y diciendo "Oh, tienes razón, esa es la interfaz de la OIT para tu máquina de café, está bien si tiene TLS 1.0, porque solo es café". Cuando SSL 3 se prohibió hace unos años, mi experiencia fue que se eliminó universalmente.