¿Cuál es el beneficio de obligar a un sitio a cargar sobre SSL (HTTPS)?


55

Digamos que tengo un gran sitio de solo contenido; sin inicio de sesión o cierre de sesión, sin nombres de usuario, sin direcciones de correo electrónico, sin área segura, nada secreto en el sitio, nada. La gente simplemente visita el sitio y va de página en página y mira el contenido.

Además de un ligero aumento en el SEO de Google ( muy leve, por lo que he leído), ¿hay algún beneficio de obligar al sitio a cargar a través de HTTPS?


1
¿No creo que esto sea un duplicado de Force Using SSL in Site ahora? . Aunque algunas respuestas pueden terminar siendo similares, esa pregunta es pedir consejos sobre si usar SSL o no, mientras que esta pregunta no lo es. En todo caso, la otra pregunta debería cerrarse por estar basada en la opinión.
Stephen Ostermiller

44
Volteemos esto: ¿cuál es el beneficio de NO usar SSL? No hay ninguno que yo sepa. Oh, claro, la implementación que sería única y no tomaría tiempo (comparativamente con todo lo demás) Entonces, si un enfoque no tiene inconvenientes y algunos inconvenientes, el otro no tiene inconvenientes y (según usted) no tiene inconvenientes, entonces ... ¿por qué quedarse con el último?
VLAZ

3
@Vld - rendimiento. En estos días, a menudo intentamos optimizar los tiempos de carga inicial del sitio a cifras de rendimiento inferiores a un segundo, con un objetivo de 1/2 segundo. En una conexión a Internet ligeramente lenta (latencia de paquete de alrededor de 100 ms), el protocolo de enlace SSL puede tomar fácilmente 300 ms, lo que podría empujarlo hacia un objetivo de rendimiento. Para los usuarios móviles es peor: las redes móviles tienen latencias de paquetes más largas y el tiempo de procesamiento para la verificación de la certificación podría ser fácilmente otros cientos de ms en un teléfono más lento.
Julio

66
Los operadores de telefonía móvil siempre manipulan el tráfico HTTP sin cifrar, ya sea para la compresión de imagen (sobre), inyectando Javascript malvado o encabezados de control de caché más agresivos. HTTPS evitará todas esas tonterías.
André Borie

2
@Josef No es cierto. HTTP / 2 también funciona sobre conexiones no encriptadas. Ningún navegador puede hacer eso, pero esa es la limitación del navegador, no HTTP / 2. Decir que "HTTP / 2 solo funciona sobre TLS" es como decir que "la tecnología X no funciona porque Internet Explorer no lo implementa". Mira a dónde nos llevó.
Agent_L

Respuestas:


84

HTTPS no solo proporciona secreto (del cual usted duda del valor, aunque todavía hay buenas razones para ello) sino también autenticidad , que siempre tiene valor. Sin él, un punto de acceso malicioso / enrutador / ISP / etc. puede reescribir cualquier parte de su sitio antes de mostrarlo al usuario. Esto podría incluir:

  • inyectando anuncios para sus competidores
  • inyectar anuncios o widgets molestos que hacen que su sitio se vea mal y dañe su reputación
  • inyectando exploits para realizar descargas automáticas de malware en la computadora del visitante, que luego (¡con razón!) lo culpa de que suceda
  • Reemplazar las descargas de software de su sitio con las que tienen malware incluido
  • bajando la calidad de tus imágenes
  • eliminando partes de su sitio que no quieren que vea, por ejemplo, cosas que compiten con sus propios servicios o las representan de mala manera
  • etc.

No proteger a sus usuarios de estas cosas es irresponsable.


27
@ Mike no realmente. Hay un montón de software listo para usar para hacer esto, y todo maneja bien la descompresión y la recompresión.
ceejayoz

3
@ Mike no realmente. Un proxy de reescritura completo puede decodificar todo el tráfico e inyectar cualquier cosa nueva que quiera de nuevo.
Nayuki

10
Para su información, la mayoría, si no todos, mis ejemplos se han visto en la naturaleza.
R ..

2
@DavidMulder su primer comentario dijo " de la centralización [...] no es una buena cosa"
jiggunjer

3
¿Podemos por favor no convertir los comentarios sobre esta respuesta en una diatriba fuera de tema sobre temas no relacionados?
R ..

25

"nada secreto en el sitio"

... De acuerdo a ti . Puede haber una razón perfecta para que alguien quiera una conexión segura. (En parte) crea privacidad:

Mi administrador puede ver que estoy navegando en algún sitio de imágenes en mi teléfono a través de la URL, pero no puede decir si estoy viendo fotos de gatos lindos o porno duro. Yo diría que es muy buena privacidad. "un contenido" y "el contenido" pueden marcar la diferencia en el mundo. - Agent_L

Puede pensar que es insignificante, o tal vez no es un gran problema ahora, pero podría estar en otro momento. Creo firmemente que nadie, aparte de mí y del sitio web, debería saber exactamente lo que estoy haciendo.

Crea confianza. Tener el candado es un signo de seguridad y puede significar cierto grado de habilidad con respecto al sitio web y, por lo tanto, a sus productos.

Te hace menos objetivo para, por ejemplo, los ataques MitM. La seguridad aumenta.

Con iniciativas como Let's Encrypt , que lo hacen mucho más fácil y gratuito , no hay muchos inconvenientes. La potencia de CPU utilizada por SSL es insignificante en estos días.


11
Desafortunadamente, SSL no impide que la TI corporativa o su ISP o las personas en el wifi público del café sepan qué sitios está visitando. Las búsquedas de DNS todavía se realizan de forma clara . Si bien no pueden ver el contenido, ni la URL exacta, ni que estás usando un navegador web, pueden ver que estás accediendo a penisland.com (que es, por supuesto, un sitio para entusiastas de la pluma, pero podría ser mal interpretado). El uso de un proxy VPN o SOCKS5 protegerá sus consultas DNS.
Schwern

3
@Martijn: con la indicación de nombre de servidor (que admiten todos los navegadores modernos), el nombre de host del sitio web se envía en forma clara como parte del protocolo de enlace HTTPS. No se trata solo de ataques de canal lateral y no se puede mitigar con, por ejemplo, DNSsec.
Kevin

3
@Schwern Nunca entendí el argumento de que HTTPS no protege el nombre del host porque la búsqueda de DNS y SNI y el certificado del servidor están claros. Por supuesto, eso es cierto como se dijo, ¡pero el texto plano HTTP no es en absoluto mejor en este sentido!
un CVn

55
@Schwern Mi administrador puede ver que estoy buscando tumblr en mi teléfono, pero no puede decir si estoy viendo fotos de gatos lindos o porno duro. Yo diría que es muy buena privacidad. "un contenido" y "el contenido" pueden marcar la diferencia en el mundo.
Agent_L

2
@Agent_L No, incluso eso no es un buen consejo. Si va a https://penisland.tumblr.com/su navegador, hará una solicitud de DNS para la penisland.tumblr.comcual, a menos que haya protegido sus consultas de DNS, el administrador de la red puede ver. Luego, su navegador tiene que obtener las imágenes, Javascript, CSS y anuncios de varios dominios que generan más solicitudes de DNS. Podrían ser de cualquier dominio. Los pocos dominios porno de Tumblr que probé no tienen nada obvio, Tumblr tiende a alojar imágenes y videos en casa, pero no puedes confiar en eso para tener privacidad.
Schwern

12

Obtiene soporte HTTP / 2 , el nuevo estándar web diseñado para mejorar significativamente las velocidades de carga del sitio web .

Debido a que los fabricantes de navegadores han elegido admitir HTTP / 2 solo a través de HTTPS, habilitar HTTPS (en un servidor que admita HTTP / 2) es la única forma de obtener esta actualización de velocidad.


1
Esto es bastante grande y necesita ser promocionado más. Presenta un argumento comercial para cargar HTTPS solo que la mayoría de los gerentes pueden respaldar.
Dewi Morgan

10

(Partes tomadas de mi respuesta a una pregunta similar).


HTTPS puede lograr dos cosas:

  • Autenticación . Asegurarse de que el visitante se está comunicando con el propietario del dominio real.
  • Encriptación . Asegurándose de que solo el propietario de este dominio y el visitante puedan leer su comunicación.

Probablemente todos estén de acuerdo en que HTTPS debería ser obligatorio al transmitir secretos (como contraseñas, datos bancarios, etc.), pero incluso si su sitio no procesa tales secretos, hay varios otros casos donde y por qué el uso de HTTPS puede ser beneficioso.

Los atacantes no pueden alterar el contenido solicitado.

Cuando se usa HTTP, los espías pueden manipular el contenido que sus visitantes ven en su sitio web. Por ejemplo:

  • Incluyendo malware en el software que ofrece para descargar (o si no ofrece ninguna descarga de software, los atacantes comienzan a hacerlo).
  • Censurando parte de su contenido. Cambiando tus expresiones de opinión.
  • Inyección de anuncios.
  • Reemplazar los datos de su cuenta de donaciones con los suyos.

HTTPS puede prevenir esto.

Los atacantes no pueden leer el contenido solicitado.

Al usar HTTP, los espías pueden saber a qué páginas / contenido en su host acceden sus visitantes. Aunque el contenido en sí mismo puede ser público, el conocimiento que una persona específica consume puede ser problemático:

  • Abre un vector de ataque para la ingeniería social .
  • Infringe la privacidad.
  • Puede conducir a la vigilancia y el castigo (hasta el encarcelamiento, la tortura, la muerte).

Esto, por supuesto, depende de la naturaleza de su contenido, pero lo que parece ser contenido inofensivo para usted puede ser interpretado de manera diferente por otras partes.

Mejor prevenir que curar. HTTPS puede prevenir esto.


1
De hecho, HTTPS puede prevenirlo. En algunas situaciones, puede que no. Ver Lenovo Superfish para un ejemplo bastante reciente.
un CVn

@ MichaelKjörling: Sí, soy consciente de esto (es por eso que me aseguré de usar "can";)), pero es un problema derivado del comportamiento del visitante, no un problema con HTTPS en sí o la forma en que el webmaster utiliza ¿bien? El visitante debe preocuparse por las CA en las que confiar (y el visitante debe preocuparse por el software que debe instalar, especialmente si tiene permiso para manipular la lista de CA en las que debe confiar).
hasta el

En efecto; No estoy discutiendo en contra de tu punto, ¡solo agrego más!
un CVn

6

Evita los ataques de hombre en el medio que te hacen pensar que estás visitando tu sitio, pero presentan una página que en realidad es de otro y pueden intentar obtener información tuya. Dado que los datos están encriptados, también hace que sea más difícil para un atacante manipular la página tal como la ve.

Debido a que necesita un certificado SSL, eso verifica que usted es el propietario del sitio como mínimo, lo que le da al menos alguna verificación de quién es usted.


3

Las empresas de marketing como Hitwise pagan a los ISP para recopilar datos sobre su sitio cuando no utiliza SSL. Se recopilan datos sobre su sitio que quizás no quiera que sus competidores sepan:

  • demografía del usuario
  • estadísticas de visitantes
  • páginas populares
  • palabras clave del motor de búsqueda (aunque con "no proporcionado" esto no es un problema en estos días)

3

Y, solo para agregar una cosa más a todas las respuestas, solo hablaré sobre la latencia. Porque parece que nadie escribió aquí sobre esto.

Tener una baja latencia HTTP de cliente a servidor es fundamental para crear sitios web receptivos y de carga rápida.

TCP / IP solo tiene un protocolo de enlace de 3 vías (la configuración de conexión inicial para HTTP simple sobre TCP requiere 3 paquetes). Cuando se usa SSL / TLS, la configuración de la conexión es más complicada, lo que significa que la latencia para las nuevas conexiones HTTPS es inevitablemente mayor que el texto sin formato HTTP.

El problema con HTTP es que no es seguro. Entonces, si tiene datos confidenciales, necesita algún tipo de seguridad. Cuando escribe algo en su navegador web que comienza con "https", le pide a su navegador que use una capa de cifrado para proteger el tráfico. Esto proporciona una protección razonable contra los espías, pero el problema es que será más lento. Como queremos encriptar nuestro tráfico, habrá algo de cómputo involucrado, lo que aumenta el tiempo. Esto significa que si no diseña su sistema correctamente, su sitio web parecerá lento para los usuarios.

Para concluir:

Tengo un gran sitio de solo contenido; sin inicio de sesión o cierre de sesión, sin nombres de usuario, sin direcciones de correo electrónico, sin área segura, nada secreto en el sitio, nada. La gente simplemente visita el sitio y va de página en página y mira el contenido.

Si este es el caso, no usaré SSL en absoluto. Me gustaría tener mi página cuando haga clic en ella para que se abra en un segundo. Eso es de la experiencia del usuario. Haz lo que quieras, simplemente no pongo certificados en todo lo que hago. En este caso particular, no lo usaría en absoluto.


OMI, esta es una respuesta tan correcta como la que obtiene todos los votos.
Michael Yaeger

youtube.com/watch?v=e6DUrH56g14 menciona algunas técnicas para mitigar el impacto en el rendimiento incluso si usted (o una gran parte de sus clientes) no puede hacer HTTP / 2 por alguna razón.
un CVn

1

Además de los beneficios mencionados por otros, hay una razón que lo hará cambiar a SSL a menos que no le interesen sus visitantes que usan Chrome: las nuevas versiones de Chrome (a partir de finales de año, por lo que recuerdo) son mostrará una advertencia (que alejará a los usuarios de su sitio) de forma predeterminada para todos los sitios que no usan HTTPS.

//EDITAR:

Aquí hay enlaces a dos artículos más detallados, aunque parece que no puedo encontrar el que leí cuando planean presentar oficialmente la función:

https://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https

http://www.pandasecurity.com/mediacenter/security/websites-that-arent-using-https/


No es una cita perfecta para la afirmación hecha en la respuesta, pero siempre hay Marcado HTTP como no seguro .
un CVn

1

La respuesta simple es que no hay una buena razón para no hacerlo . En el pasado, había argumentos sobre el uso de SSL solo cuando era absolutamente necesario (por ejemplo, en sitios de comercio electrónico que recopilaban detalles de pago).

Esto tenía que ver en gran medida con el procedimiento de instalación de certificados SSL, el costo, la carga adicional en el servidor web y las limitaciones de la red, en un momento en que las personas no tenían banda ancha, etc. Ninguna de estas razones realmente se aplica en 2016.

En términos de SEO, sabemos que el objetivo de la mayoría de los motores de búsqueda es proporcionar los mejores resultados para sus usuarios, y esto se puede lograr dándoles una conexión segura al sitio que están navegando. A este respecto, a los motores de búsqueda no les importa si hay datos "sensibles" en el sitio (ya sea que se presenten o se recopilen); Es simplemente el caso de que si el sitio se sirve a través de HTTPS, cualquier riesgo potencial de autenticación y cifrado se minimiza en gran medida, por lo que el sitio se consideraría "mejor" que el sitio equivalente sin HTTPS.

Esencialmente, es tan simple y directo de implementar que se considera una buena práctica hoy en día. Como desarrollador web, solo considero instalar un certificado SSL y luego forzar todas las solicitudes a través de HTTPS (muy fácil de usar .htaccess o un equivalente) como parte estándar de cualquier sitio o aplicación web que construya.


1

Además de las otras respuestas, los navegadores deben (como en RFC 2119) enviar el User-Agentencabezado. Proporciona suficiente información sobre qué plataforma está utilizando un usuario si envía la actual User-Agent. Si Eve puede espiar una solicitud hecha por Alice, y Alice envía el mensaje real User-Agent, Eve sabrá qué plataforma utiliza Alice sin que Alice se conecte al servidor de Eve. Será más fácil hackear la computadora de Alice con tal conocimiento.


Esto es un poco como decir que si Eve puede ver el número VIN del auto de Alice a través del parabrisas del auto, es más fácil para Eve entrar al auto de Alice porque el número VIN le permite averiguar qué marca y modelo de automóvil posee Alice. Claro, es una posibilidad, pero hay muchas maneras de obtener la misma información sin que MITM haga nada, de manera que apenas se registraría como algo más que el ruido de fondo de Internet para un nodo hoja en la red. Por ejemplo: Eve (o quizás Mallory) podría enviar un correo electrónico a Alice con un enlace a una página web bajo su control. A la gente le encanta hacer clic en los enlaces.
un CVn

1

Tiene dos opciones para proteger su dominio principal (mysite.com) y sus subdominios (play.mysite.com y test.mysite.com). SSL no es solo para comercio electrónico, sitios de comerciantes de pagos donde se comparten transacciones financieras o credenciales de inicio de sesión en el sitio web. Es igualmente importante para el sitio web basado en contenido. Los atacantes siempre buscan un sitio web HTTP simple o una laguna en el sitio web. SSL no solo proporciona seguridad sino que también autentica su sitio web. El principal beneficio de tener SSL en un sitio web basado en contenido es que,

  • Puede evitar ataques de hombre en el medio que pueden alterar el contenido del sitio.

  • Además, su sitio web tendrá autenticidad que notifica a los visitantes que su información estará segura si la comparten con el sitio web.

  • Se aseguran la autenticidad del sitio web.

  • Además, su sitio web estará libre de la inyección de anuncios maliciosos, exploits, widgets no deseados, reemplazo de software y daños a las páginas web una vez que tenga SSL en su sitio web.

  • El certificado SSL ofrece un sello estático del sitio que se puede colocar en cualquier página web para garantizar la seguridad y los clientes pueden hacer clic en el sello para conocer los detalles del certificado SSL instalado.


1

Otras respuestas hablaron sobre los beneficios de HTTPS. ¿Por un usuario se vería obligado a usar HTTPS? Por dos razones:

  • Si le da a los usuarios la opción de no usar HTTPS, probablemente no lo harán, especialmente porque la mayoría de los navegadores usan http: // y no https: // al escribir un dominio en la barra de direcciones.
  • Al implementar tanto una versión segura como una versión insegura, aumenta la superficie de ataque de la conexión. Le da a los atacantes la oportunidad de realizar un ataque de degradación incluso si cree que está utilizando la versión segura.
  • Si redirige cada http: // URL al https: // equivalente, facilita la vida del administrador del servidor y de los motores de búsqueda. Nadie tiene que preocuparse por si las http: // y https: // son equivalentes o apuntan a cosas completamente diferentes, al redirigirse una a otra, queda claro para todos qué URL deben usarse.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.