Estoy configurando un nuevo servidor web. Además de TLS / HTTPS, estoy considerando implementar Strict-Transport-Security y otros mecanismos de cumplimiento de HTTPS.
Todo esto parece basarse en el supuesto de que estoy sirviendo http://www.example.com además de https://www.example.com . ¿Por qué no solo sirvo HTTPS? Es decir, ¿existe una razón basada en la seguridad para servir HTTP? Por ejemplo, ¿podría alguien falsificar http://www.example.com si no configuro HSTS?
¿Por qué no solo sirvo https?
Las razones principales son el comportamiento predeterminado de los navegadores y compatibilidad con versiones anteriores .
Cuando un usuario final (es decir, sin conocimiento de los protocolos o la seguridad) escribe la dirección del sitio web en su navegador, el navegador utiliza HTTP por defecto. Consulte esta pregunta para obtener más información sobre por qué los navegadores eligen este comportamiento.
Por lo tanto, es probable que los usuarios no puedan acceder a su sitio web.
Es posible que algunos usuarios con sistemas antiguos y navegadores antiguos no sean compatibles con HTTPS o, más probablemente, no tengan una base de datos actualizada de certificados raíz , o no son compatibles con algunos protocolos.
En ese caso, no podrán acceder al sitio web o recibirán una advertencia de seguridad. Debe definir si la seguridad de sus usuarios finales es lo suficientemente importante como para forzar el HTTPS.
Muchos sitios web aún escuchan HTTP, pero redirigen automáticamente a HTTPS e ignoran a los usuarios con realmente navegadores antiguos.
¿alguien podría falsificar enlace si no configuro HSTS?
Si un atacante quiere falsificar http://www.example.com , debe tomar el control del dominio o tomar el control de la dirección IP de alguna manera.
Supongo que quiso decir: ¿podría un atacante realizar un ataque de hombre en el medio?
En ese caso, sí, pero incluso con o sin HSTS:
Sin HSTS : un atacante puede estar fácilmente en medio de su servidor y el usuario, y estar activo (es decir, modificar el contenido) o pasivo (es decir, escuchar a escondidas)
Con HSTS : la primera vez que un usuario intenta visitar el sitio mediante HTTP, un atacante podría obligar al usuario a utilizar HTTP. Sin embargo, el atacante tiene una ventana de tiempo limitado de cuándo puede realizar su ataque.
Como muchos sitios web, debe permitir conexiones HTTP y hacer que su servidor redirija al usuario a la versión HTTPS. De esta manera, anula el comportamiento predeterminado de los navegadores y se asegura de que sus usuarios usen la versión HTTPS.
Los sistemas antiguos sin los protocolos o certificados raíz adecuados no podrán acceder al sitio (o al menos tendrán una advertencia), pero dependiendo de su base de usuarios, esto no debería ser un problema.
Hará más daño que beneficio si deshabilita HTTP. Realmente no proporciona más seguridad.
Cualquier seguridad agregada para proteger un recurso es inútil si impide que la mayoría de sus usuarios accedan a él. Si sus usuarios finales no pueden acceder a su sitio web porque su navegador está configurado de forma predeterminada a HTTP y no escucha las conexiones HTTP, ¿cuál es el beneficio?
Simplemente realice la redirección HTTP 301 a la versión HTTPS.
Por razones de facilidad de uso, debe ofrecer una redirección a HTTPS desde todas las URL de HTTP: s. De lo contrario, los visitantes que ingresen example.com/some/page en la barra de URL del navegador recibirán un error de conexión.
Servir la redirección no te hace más vulnerable. Los usuarios que no tengan su entrada de HSTS en sus navegadores realizarán una solicitud HTTP de todos modos. Si hay o no un servicio real o no en HTTP es irrelevante para un hombre en el medio.
Entonces necesitas ejecutar un servidor HTTP, pero no necesita responder con nada más que las redirecciones.
Las respuestas arriba-votadas son muy buenas. Sacrificará la facilidad de uso sin un gran impacto en la seguridad si cierra HTTP por completo.
Sin embargo, puede mitigar eso con la opción de precarga HSTS. La precarga de su sitio web significa que usted registra su dominio con los proveedores de navegadores y ellos codificarán sus navegadores para que visiten su sitio web solo a través de HTTPS. Eso significa que si un usuario intenta acceder a su sitio web a través de HTTP, el navegador cambiará la solicitud a HTTPS. El usuario no necesita obtener primero el encabezado HSTS antes de estar seguro. Siempre se conectarán a usted a través de un canal seguro.
Ahora, esto no protege a los usuarios que usan navegadores que no han actualizado su lista de sitios web que solo contienen HTTPS. Incluso cuando se utiliza la precarga, recomiendo no apagar HTTP para las pocas personas que usan navegadores antiguos o no actualizados.
¡Pero cuidado, la precarga es permanente! Es extremadamente difícil salir de la lista de precarga.
Para entrar en la lista de precarga: enlace
No tienes que hacerlo.
Algunos navegadores y sistemas operativos más antiguos (que por lo general van de la mano) no tienen nuevas autorizaciones de raíz de certificados, pero tampoco son compatibles con los estándares HTTPS más nuevos, por lo que realmente no se pierde nada.
Es posible que tenga un dispositivo que no admita HTTPS, secuencias de comandos personalizadas, etc.
Nadie puede falsificar HTTP, porque el registro de DNS le pertenece a usted y el registro A apunta a su dirección IP específica (en un mundo perfecto).
Lo haces solo para mantener la compatibilidad, eso es todo.
Debería admitir HTTP solo para admitir la compatibilidad con versiones anteriores. Y asegúrese de hacer la redirección adecuada en el servidor de servicios de fondo a HTTPS. La mejor manera de implementar esto es proporcionar el soporte HTTP solo a su página de inicio o cualquier página que no tenga información confidencial. No debe admitir solicitudes HTTP a páginas a las que el usuario pueda acceder después de la autenticación.
Incluso si hay dispositivos (IoT) que acceden a los datos confidenciales de su servidor, debe obligarlos a usar TLS (muchos dispositivos actuales pueden almacenar su certificado y crear una conexión TLS). Tenga en cuenta que las versiones SSL anteriores a 3.0 tienen muchas vulnerabilidades como poodlebug, etc. Por lo tanto, desactive todas las versiones anteriores de su servidor web y permita solo > TLS 1.1.
Es bueno que implementes el HSTS. Le recomiendo que también analice la posibilidad de implementar HPKP en su sitio.
Yo uso http además de https para dos propósitos:
Una razón importante es que a veces no se requiere HTTPS, por ejemplo, servir repositorios de código abierto.
¿Por qué se asegura un flujo amplio cuando todos son públicos para usar? solo mire el repositorio de cygwin, por ejemplo, todos ellos están en forma simple.
No significa que el HTTPS no funcione, se trata de no sacrificar el procesamiento del cliente y del servidor cuando no es realmente necesario.