Pregunta ¿Es malo redirigir http a https?


Acabo de instalar un certificado SSL en mi servidor.

Luego, configuró una redirección para todo el tráfico en mi dominio en el Puerto 80 para redirigirlo al Puerto 443.

En otras palabras, toda mi http://example.com el tráfico ahora se redirige a la adecuada https://example.com Versión de la página.

La redirección se realiza en mi archivo de hosts virtuales de Apache con algo como esto ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Mi pregunta es, ¿hay algún inconveniente en el uso de SSL?

Dado que esto no es un Redireccionamiento 301, ¿perderé el enlace / ranking en los motores de búsqueda al cambiar a https?

Aprecio la ayuda. Siempre quise configurar SSL en un servidor, solo por la práctica de hacerlo, y finalmente decidí hacerlo esta noche. Parece que funciona bien hasta ahora, pero no estoy seguro de si es una buena idea usar esto en todas las páginas. Mi sitio no es comercio electrónico y no maneja datos confidenciales; Es principalmente por el aspecto y la emoción de instalarlo para aprender.


NÚMERO ACTUALIZADO

Extrañamente, Bing crea esta captura de pantalla desde mi sitio ahora que usa HTTPS en todas partes ...

enter image description here 


245
2018-01-28 00:12


origen


[WTF - No puedo agregar respuesta (aunque parece que tengo suficiente reputación).] Mi respuesta sería (en parte) que A VECES ES MALO. Considere pasar una COOKIE o una clave API en un GET sobre HTTP. Si su sitio redirige las solicitudes HTTP a las solicitudes HTTPS, estas llamadas funcionarán, pero la COOKIE o la Clave de la API se transmitirán de forma clara. Algunas API desactivan HTTP, un enfoque más robusto, sin HTTP, por lo que ni siquiera puede hacerlo funcionar a menos que use HTTPS. Ejemplo: "Todas las solicitudes de API se deben realizar a través de HTTPS. Las llamadas realizadas a través de HTTP sin formato fallarán" desde stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - la alternativa es que el toda la cosa sucede a través de HTTP sin HTTPS en absoluto. ¿Cómo es eso mejor? - Mark Henderson♦
@BenCrowell, eso es porque un portal cautivo se parece mucho a una sslstripataque de redireccionamiento de estilo (ambos son secuestros de solicitud de hombre en el medio) por lo que HSTS- Los navegadores de Windows los bloquearán a ambos. - Jeffrey Hantin
tenga en cuenta que usar https significa que todo lo que incluya también debe ser https o puede que no se cargue, por ejemplo, cargue jQuery usando src="://example.com/jquery.js" - note la falta de http o https por lo que el navegador carga el apropiado. Tuve una pesadilla tratando de conseguir que algunas cosas de Amazon incrustadas se cargaran correctamente, ya que la API (cargada a través de https) produjo enlaces http, lo que significa que no funcionaron correctamente hasta que encontré el parámetro no documentado para alternar enlaces https - Basic
Jason tu actualización debería ser una nueva pregunta, probablemente en Webmasters ya que no está relacionado (técnicamente) con su pregunta original. Pero es probable que sus hojas de estilo provengan de un dominio inseguro. - Mark Henderson♦


Respuestas:


los [R] bandera en sí misma es una 302 redirección (Moved Temporarily). Si realmente desea que la gente use la versión HTTPS de su sitio (sugerencia: usted lo hace), entonces debería usar [R=301] Para una redirección permanente:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

UNA 301 mantiene todos tus google-fu y pageranks ganados con esfuerzo intacto. Asegurarse mod_rewrite está habilitado:

a2enmod rewrite

Para responder a su pregunta exacta:

¿Es malo redirigir http a https?

Infierno no Es muy bueno.


309
2018-01-28 00:27



Gracias por la información, mi jefe me está diciendo que la razón por la que solo ejecuta https en ciertas páginas de su sitio es que utiliza muchos más recursos de servidor para ejecutarlo en cada página. ¿Sabes algo sobre eso o si eso es verdad? - JasonDavis
@jasondavis Solo si no le dedicas unos minutos a optimizarlo. - Michael Hampton♦
"usa muchos más recursos de servidor para ejecutarlo en cada página". Las CPU modernas tienen características de aceleración de cifrado que hacen que SSL sea casi gratis. No te preocupes por los gastos generales. - Adam Davis
@AdamDavis El algoritmo de cifrado puede ser ligero, pero todavía existe la sobrecarga del protocolo de enlace. Además, HTTPS evita que los proxies HTTP almacenen en caché su contenido. En más En los casos, la sobrecarga de HTTPS es mínima y vale la pena, pero tenga cuidado con la generalización excesiva. - 200_success
Elimina el almacenamiento en caché compartido, que es útil para los patrones de uso de algunos sitios y, a menudo, protege poco (¿es importante que la gente sepa que visitó el sitio, pero no los detalles de lo que hizo? Esa es la única situación en la que SSL es útil). La principal ventaja de SSL en cada recurso no es que necesite "asegurar", por ejemplo. personas que miran "acerca de nosotros", pero que no puede cometer errores y dejar de usarlo en un caso en el que debería hacerlo. - Jon Hanna


Si bien apoyo la idea de sitios solo SSL, diría que un inconveniente son los gastos generales en función del diseño de su sitio. Quiero decir, por ejemplo, si está sirviendo muchas imágenes individuales en etiquetas img, esto podría hacer que su sitio se ejecute mucho más lento. Recomendaría a cualquier persona que utilice servidores solo SSL para asegurarse de que funcionan en lo siguiente.

  1. Revise todo el sitio para ver los enlaces internos y asegúrese de que todos estén usando HTTPS si especifica su propio nombre de dominio en los enlaces, de modo que no esté causando sus propios redireccionamientos.
  2. Actualiza tu <meta property="og:url" para utilizar la versión https de tu dominio.
  3. Si utiliza <base href= actualice nuevamente para usar HTTPS.
  4. Instalar Protocolo SPDY si es posible
  5. Asegúrese de usar sprites de imagen CSS cuando sea posible, para reducir el número de solicitudes.
  6. Actualice sus sitemaps para indicar el estado de https, de modo que las arañas con el tiempo aprendan este cambio.
  7. Cambia las preferencias del motor de búsqueda como Google Webmaster Tools para preferir HTTPS
  8. Siempre que sea posible, descargue cualquier medio táctico en servidores HTTPS CDN.

Si se aborda lo anterior, entonces dudo que tengas muchos problemas.


49
2018-01-28 02:08



SPDY es una buena sugerencia; Incluso parece que hay un módulo añadiendo soporte SPDY a Apache 2.x. - Calrion
Usando "//yourserver.com/some-uri" en lugar de "yourserver.com/some-uri"resuelve el problema (1) porque el navegador seleccionará el esquema apropiado (http o https) dependiendo del esquema con el que se cargó la página. - MauganRa
@MauganRa A menos que, por supuesto, sea un enlace de la página de artículos http a la página de inicio de sesión https, por ejemplo. - Mołot
Google ve la URL que alguien está visitando a través de Referer encabezamiento. Por ejemplo, este sitio utiliza jQuery del CDN de Google y mi navegador envía una solicitud a Google cada vez que recargo el sitio. Por lo tanto un Referer El encabezado también se envía a Google, que se establece en la URL de este sitio. Por lo tanto, Google puede rastrear los sitios que visito durante el tiempo en que mi dirección IP no cambia (y si uso un servicio de Google durante este tiempo, Google también puede conectar esta información con mi cuenta de Google). - Stephan Kulla
Para 1) Acabo de hacer una búsqueda y reemplazo en mi base de datos MySQL de http a https ... Estoy usando WordPress, por lo que es muy fácil actualizar cientos de enlaces. - JasonDavis


Si ha configurado https, debería usarlo en cualquier parte del sitio. Evitará el riesgo de problemas de contenido mixto y, si cuenta con las herramientas necesarias, ¿por qué no proteger todo el sitio?

En cuanto a la redirección de http a https, la respuesta no es tan simple.

La redirección lo hará mucho más fácil para sus usuarios, solo escriben en whateversite.com y se redirigen a https.

Pero. ¿Qué pasa si el usuario a veces se encuentra en una red no segura (o está cerca de Troy Hunt y su piña)? Entonces el usuario solicitará http://whateversite.com De la vieja costumbre. Eso es http. Eso puede ser comprometido. El redireccionamiento podría apuntar a https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. Para un usuario ordinario se vería bastante legítimo. Pero el tráfico puede ser interceptado.

Por lo tanto, tenemos dos requisitos que compiten aquí: ser fáciles de usar y estar seguros. Afortunadamente, hay un remedio llamado Encabezado HSTS. Con él se puede habilitar la redirección. El navegador pasará al sitio seguro, pero gracias al encabezado de HSTS también lo recordará. Cuando el usuario escribe en whateversite.com sentado en esa red no segura, el navegador irá a https de inmediato, sin saltar a través de la redirección a través de http. A menos que trate con datos muy confidenciales, creo que es una compensación justa entre la seguridad y la facilidad de uso para la mayoría de los sitios. (Cuando configuré recientemente una aplicación que maneja registros médicos, fui a todos los https sin una redirección). Desafortunadamente, Internet Explorer no tiene soporte para HSTS (fuente), por lo que si su público objetivo está utilizando principalmente IE y los datos son confidenciales, es posible que desee desactivar las redirecciones.

Entonces, si no está apuntando a usuarios de IE, siga adelante y use la redirección, pero habilite también el encabezado HSTS.


38
2018-01-28 07:40



Más personas necesitan prestar atención a esto también. Otra cosa es que las personas asumen que están seguras porque el punto final es HTTPS, ignorando el hecho de que toda la información enviada a la página en GET o POST está en texto simple. - Velox
@Velox: no creo que la implicación de "las personas supongan que están seguras porque el punto final es HTTPS, ignorando el hecho de que toda la información enviada a la página en GET o POST está en texto simple" es bastante precisa. Si bien hay algunos errores, los parámetros de consulta GET no viajan en claro durante el transporte a través de HTTPS. Ver por ejemplo: stackoverflow.com/questions/323200/… Las cargas útiles de POST también están protegidas, mientras que tampoco son vulnerables al registro y los encabezados de referencia. - codingoutloud
@codingoutloud Ese es mi punto. A través de HTTPS están cifrados, pero en la solicitud inicial a la página HTTP no lo estaban. - Velox
@Velox: si todo el sitio está redirigiendo a HTTPS, es poco probable que se envíen parámetros GET antes de que HTTPS se active (y todo seguirá en HTTPS después de ese punto). Todavía hay una solicitud inicial a la que se enviarán cookies, que puede remediarse con HSTS ... y una pequeña ventana de ataque para SSLStrip, que posiblemente podría ser derrotada por JavaScript, pero esa es una carrera armamentista propia. - Brilliand
@Brilliand Fair point, pero un punto débil en seguridad hace que todo sea débil. Siempre vale la pena considerarlo. - Velox


No hay nada de malo en esto, y de hecho es la mejor práctica (para sitios que debería ser servido sobre una conexión segura). De hecho, lo que estás haciendo es bastante similar a la configuración que estoy usando:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

los 301 código de estado indica un permanente redirigir, indicando a los clientes capaces que utilicen la URL segura para futuras conexiones (por ejemplo, actualizar el marcador).

Si solo servirá el sitio a través de TLS / SSL, recomendaría una directiva adicional para habilitar HTTP Seguridad estricta del transporte (HSTS) en su seguro anfitrión virtual:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Este encabezado instruye a los clientes capaces (la mayoría de ellos en estos días, creo) que deberían solo usa HTTPS con el dominio proporcionado (secure.example.com, en este caso) para la próxima 1234 segundos. los ; includeSubdomains la porción es Opcional e indica que la directiva se aplica no solo al dominio actual, sino a cualquier otro debajo de él (por ejemplo, alpha.secure.example.com). Tenga en cuenta que el encabezado HSTS es solamente aceptado por los navegadores cuando se sirve a través de una conexión SSL / TLS!

Para probar la configuración de su servidor con las mejores prácticas actuales, un buen recurso gratuito es Prueba del servidor SSL de Qualys Servicio; Tendría como objetivo obtener al menos una A- (no se puede obtener más que eso con Apache 2.2 debido a la falta de soporte para la criptografía de curva elíptica).


22
2018-01-28 02:20



Debería añadir, enviando el encabezado. Strict-Transport-Security: max-age=0 anulará cualquier directiva anterior; como siempre, este debe se enviará a través de HTTPS para ser aceptado, pero es una forma útil de cancelar cosas si decide que también necesita usar HTTP en el dominio. - Calrion


Guauu ! redirigir HTTP a HTTPS es algo muy bueno y no puedo ver ningún inconveniente para eso.

Solo asegúrese de que sus clientes tengan la CA correcta para evitar advertencias no fáciles de usar sobre el certificado en el navegador.

Además, la forma en que ha configurado Apache para redirigir a HTTPS parece estar bien.


5
2018-01-28 00:35





¿Es malo redirigir http a https?

No, en absoluto. En realidad, es una buena cosa que hacer!

En redirecciones:

Podría ser más eficiente, por eliminando completamente las reescrituras. Aquí está mi configuración en una situación similar ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS no es exactamente infalible. Por supuesto, normalmente forzar HTTPS es algo bueno. Evita que los delincuentes normales hagan algo malo a sus usuarios.

Pero recuerde verificar sus configuraciones SSL como la configuración de SSLCiphers. Deshabilita cosas como RC4 crypto, el protocolo SSLv2 y SSLv3. Además, debes averiguar si las bibliotecas de sistemas criptográficos de tu sistema son compatibles con TLS1.2 (que es lo que quieres tener))

Encienda SSL, es una buena cosa.


4
2018-01-28 07:43



La entropía no se agota (Al menos si estás defendiendo contra atacantes terrestres. más bien que haciendo vudú). O comienzas con una entropía insuficiente y no puedes hacer nada que requiera aleatoriedad, o comienzas con una entropía suficiente y sigues teniendo la entropía suficiente sin importar cuánta aleatoriedad generes. - Gilles
Lo siento, qué? Hay una serie de operaciones en Linux que insisten en una entropía fuerte derivada del hardware en lugar de una entropía probablemente suficientemente buena basada en PRNG, y estas pueden bloquearse si la profundidad de la piscina es baja. Es ciertamente posible comenzar con la entropía suficiente en un sistema Linux, pero mediante el uso excesivo para drenar el grupo, causando el bloqueo de algunas operaciones. - MadHatter


Personalmente estoy a favor del uso de SSL para asegurar las conexiones en la web, sin embargo, creo que el punto que todas las demás respuestas aquí han pasado por alto es que no todos los dispositivos y piezas de software capaces de una conexión HTTP podrán usar SSL. por lo tanto, consideraría proporcionar alguna forma para que los usuarios lo eviten si no es compatible con ellos. También es posible que las personas en algunos países donde la tecnología de encriptación es ilegal no puedan acceder a su sitio. Consideraría agregar una página de destino sin cifrar con un enlace para forzar la versión insegura del sitio, pero a menos que un usuario seleccione específicamente qué hacer como usted dijo y simplemente reenviarlos a la versión HTTPS.


3
2018-01-28 10:13



Un problema con soluciones como tener una página de aterrizaje simple de HTTP, incluso si está correctamente separada, es que esta página está abierta a manipulación. Es decir, no hay ninguna garantía real de que el enlace para la versión HTTPS del sitio se entregue intacto a los visitantes. - Håkan Lindqvist


Éstos son algunos de los problemas generales de la pincelada:

  • MITM / SSLSTRIP: Esta es una gran advertencia. Si vas a servir tu sitio a través de HTTPS, luego deshabilite HTTP en el sitio. De lo contrario, deja a sus usuarios abiertos a varios ataques de intermediarios, incluido SSLSTRIP, que interceptarán las solicitudes y los servirán silenciosamente a través de HTTP, insertando su propio script de malware en la transmisión. Si el usuario no se da cuenta, entonces lo harán. pensar Su sesión es segura cuando en realidad no lo es.

    • Sin embargo, el problema con esto es que si su sitio es un sitio público y simplemente deshabilita HTTP, puede perder una gran cantidad de visitantes. Probablemente ni siquiera ocurrir a ellos para probar HTTPS si el sitio no se carga con HTTP.
  • Si su sitio requiere un inicio de sesión seguro, entonces toda la sesión del usuario debe estar protegida. No se autentique a través de HTTPS, luego redirija al usuario a HTTP. Si lo hace, nuevamente, dejará a sus usuarios vulnerables a los ataques MITM. El enfoque estándar para la autenticación en estos días es autenticar una vez, luego pasar un token de autenticación de un lado a otro (en una cookie). Pero si se autentica a través de HTTPS y luego se redirecciona a HTTP, entonces un hombre en el medio puede interceptar esa cookie y usar el sitio como si fuera su usuario autenticado, sin tener en cuenta su seguridad.

  • Los problemas de "rendimiento" con HTTPS están, para todos los propósitos prácticos, limitados al protocolo de enlace involucrado en la creación de una nueva conexión. Haga lo que pueda para minimizar la necesidad de múltiples conexiones HTTPS desde una URL y estará millas por delante. Y eso es francamente cierto incluso si está sirviendo su contenido a través de HTTP. Si lees SPDY, te darás cuenta de que todo lo que hace está orientado a tratar de servir todo el contenido desde una única URL a través de una sola conexión. Sí, el uso de HTTPS afecta el almacenamiento en caché. Pero, ¿cuántos sitios web son solo contenido estático y almacenable en la actualidad? Es probable que obtenga más por su dinero utilizando el almacenamiento en caché en su servidor web para minimizar las consultas de base de datos redundantes que recuperan datos sin cambios una y otra vez, y evitan que las rutas de código caras se ejecuten con más frecuencia de la necesaria.


3
2018-04-19 10:43



Lo que puedes hacer para abordar realmente sslstrip es utilizar HSTS (preferiblemente Obtenga su configuración de HSTS precargada). Ya sea que acepte solicitudes a través de HTTP simple o no, en realidad no importa en este aspecto, un MITM puede responder a través de HTTP simple (posiblemente mediante proxy a su sitio HTTPS) incluso si solo acepta solicitudes HTTPS. - Håkan Lindqvist
@ HåkanLindqvist ¿Realmente gané un voto negativo de ti? ¿He dado malos consejos o buenos consejos con respecto a no autenticarme a través de HTTPS y luego cambiar a HTTP por el resto de la sesión? ¿Brindé malos consejos con respecto a los mitos de desempeño de HTTPS? Además, si el cliente intenta conectarse inicialmente mediante HTTPS, el MITM no puede interceptar y responder sin activar una alerta en el navegador, porque su certificado no coincidirá a menos que tenga un certificado robado o falsificado con éxito. Por otro lado, si el sitio acepta una conexión HTTP, la intercepción es más fácil. De cualquier manera, HTTPS eleva el listón. - Craig
.. y, por supuesto, estoy totalmente de acuerdo con el uso de HSTS. - Craig
Mi problema con la respuesta es el primer elemento de la lista que dice abordar sslstrip mientras que en realidad no lo hace (hablando de mitos). A lo que intentaba llegar en mi comentario inicial es que si tienes un MITM activo (que es lo que necesitas para sslstrip en primer lugar), el atacante puede ser esencialmente "el sitio" desde la perspectiva del cliente; es el atacante el que decide si desea aceptar conexiones HTTP simples del cliente, cómo se comporta su servidor web real en ese sentido, no afecta lo que el atacante puede o hará. - Håkan Lindqvist
@ HåkanLindqvist Excepto que si el visitante intenta intencionalmente conectarse con HTTPS, el atacante no puede satisfacer esa solicitud sin lanzar banderas en el navegador, a menos que haya logrado robar un certificado de servidor o, de alguna manera, forjar uno, lo cual tendría que hacer para cambiar la conexión a HTTP. HTTPS todavía Sube la barra. Por supuesto, si el visitante realiza el intento de conexión inicial a través de HTTP, todas las apuestas están completamente desactivadas. - Craig


Esta no es técnicamente una respuesta a su pregunta original, pero si usa la extensión de Google Chrome HTTPSEverywhere (estoy seguro de que existen extensiones similares en otros navegadores), la extensión redirige automáticamente los sitios con HTTP al mismo sitio con HTTPS. Lo he estado usando por un tiempo, y no he tenido ningún problema (excepto quizás la ralentización, pero no he probado eso). HTTPS En cualquier lugar se pueden cambiar ciertas reglas en el lado del servidor, pero como no he hecho mucho en esa área, no estoy seguro de los detalles exactos.

Volviendo a su pregunta real, si usa algo como HTTPSEverywhere, hay incluso menos incentivos para usar solo HTTP, aunque creo que es difícil establecer las reglas correctas para cuando las necesite.


1
2018-01-28 04:27





El único inconveniente técnico de HTTPS sobre HTTP es que computacionalmente es más costoso procesar solicitudes HTTPS que HTTP simple.

Sin embargo, dado que la mayoría de los servidores modernos tienen CPU de alta potencia, este impacto suele ser insignificante a menos que se encuentre en niveles de tráfico extremadamente altos, momento en el que es más probable que utilice balanceadores de carga de todos modos

Con el advenimiento de protocolos como SPDY que requieren SSL / TLS para funcionar, esto contrarresta la sobrecarga computacional mencionada al proporcionar mejoras significativas en el rendimiento con respecto a múltiples solicitudes y obtener activos para el cliente más rápido en general.


1
2018-01-29 11:55



El problema con el rendimiento de HTTPS es que establecer una nueva conexión es más costoso porque involucra más viajes de ida y vuelta y porque el cifrado / descifrado asimétrico es mucho más caro que el cifrado / descifrado simétrico. Una vez que el protocolo de enlace de conexión establece una clave de cifrado simétrica compartida, la sobrecarga continua es virtualmente irrelevante (muy pequeña). Si lees sobre SPDY, verás que el objetivo de todas las cosas sofisticadas que hace es esencialmente servir todo el contenido de una URL a través de una sola conexión, mitigando la sobrecarga de la conexión. - Craig