performance - hostgator - let''s encrypt wordpress

¿Dónde debería habilitar SSL? (11)

Mi último par de proyectos han involucrado sitios web que venden un producto / servicio y requieren un proceso de ''pago y envío'' en el que los usuarios ingresan la información de su tarjeta de crédito y tal. Obviamente obtuvimos certificados SSL por la seguridad del mismo, además de brindar tranquilidad a los clientes. Sin embargo, estoy un poco despistado en cuanto a las sutilezas de la misma, y lo más importante, en cuanto a qué partes del sitio web deben ''usar'' el certificado.

Por ejemplo, he estado en sitios web donde, en el momento en que accedes a la página principal, ingresas a https, en su mayoría sitios bancarios, y luego hay sitios web en los que solo ingresas a https cuando finalmente estás saliendo. ¿Es excesivo hacer que todo el sitio web se ejecute a través de https si no se ocupa de algo en el nivel de la banca? ¿Debo hacer solo la página de pago https? ¿Cuál es el impacto en el rendimiento?

Creo que una buena regla empírica es forzar SSL en cualquier lugar donde posiblemente se transmita información sensible. Por ejemplo: soy miembro de Wescom Credit Union. Hay una sección en la página principal que me permite iniciar sesión en mi cuenta bancaria en línea. Por lo tanto, la página raíz fuerza SSL.

Piénselo de esta manera: ¿se transmitirá información sensible y privada? En caso afirmativo, habilite SSL. Por lo demás, deberías estar bien.

El SSL es bastante intensivo desde el punto de vista computacional y, si es posible, no debe usarse para transmitir grandes cantidades de datos. Por lo tanto, sería mejor habilitarlo en la etapa de pago donde el usuario estaría transmitiendo información sensible.

En general, cada vez que está transmitiendo datos confidenciales o personales, debe usar SSL; por ejemplo, agregar un artículo a una canasta probablemente no necesite SSL, iniciar sesión con su nombre de usuario / contraseña o ingresar sus datos CC debe estar encriptado.

En nuestra organización tenemos tres clasificaciones de aplicaciones:

Impacto empresarial bajo: sin PII, almacenamiento de texto sin formato, transmisión de texto sin cifrado, sin restricciones de acceso.
Impacto de la mediana empresa: PII no transaccional, por ejemplo, dirección de correo electrónico. almacenamiento de texto sin cifrar, SSL del centro de datos al cliente, texto sin cifrar en el centro de datos, acceso limitado al almacenamiento.
Alto impacto empresarial: datos transaccionales, por ejemplo, SSN, tarjeta de crédito, etc. SSL dentro y fuera del centro de datos. Almacenamiento cifrado y auditado. Aplicaciones auditadas.

Utilizamos estos criterios para determinar la partición de los datos y qué aspectos del sitio requieren SSL. El cálculo de SSL se realiza en el servidor o mediante aceleradores como Netscaler. A medida que aumenta el nivel de PII, también aumenta la complejidad de la auditoría y el modelado de amenazas.

Como se puede imaginar, preferimos hacer aplicaciones LBI.

Si el sitio es para uso público, probablemente debas colocar las partes públicas en HTTP. Esto hace las cosas más fáciles y más eficientes para arañas y usuarios casuales. Las solicitudes HTTP son mucho más rápidas de iniciar que HTTPS y esto es muy obvio, especialmente en sitios con muchas imágenes.

Los navegadores también a veces tienen una política de caché diferente para HTTPS que HTTP.

Pero está bien ponerlos en HTTPS tan pronto como inician sesión, o justo antes. En el punto en que el sitio se personaliza y no es anónimo, puede ser HTTPS a partir de ese momento.

Es una mejor idea usar HTTPS para la página de inicio de sesión y otras formas, ya que da el uso del candado antes de ingresar su información, lo que los hace sentir mejor.

Solo redirijo mis sitios a SSL cuando requiere que el usuario ingrese información sensible. Con un carrito de compras tan pronto como tengan que completar una página con su información personal o detalles de su tarjeta de crédito, los redirigiré a una página SSL. Para el resto del sitio probablemente no sea necesario, si solo están viendo información / productos en su sitio de comercio.

Yo personalmente voy con "SSL from go to woe".

Si su usuario nunca ingresa un número de tarjeta de crédito, seguro, no SSL.

Pero existe una posible fuga de seguridad inherente de la reproducción de cookies.

El usuario visita el sitio y se le asigna una cookie.
El usuario navega por el sitio y agrega datos al carrito (usando cookies)
El usuario procede a la página de pago utilizando una cookie.

Aquí hay un problema, especialmente si tiene que manejar la negociación de pago usted mismo.

Debe transmitir información desde el dominio no seguro al dominio seguro y viceversa, sin garantías de protección.

Si haces algo tonto como compartir la misma cookie sin seguridad como lo haces con la seguridad, es posible que algunos navegadores (con razón) simplemente dejen caer la cookie por completo (Safari) en aras de la seguridad, porque si alguien huele esa cookie abiertamente , pueden forjarlo y usarlo en el modo seguro, degradando su maravillosa seguridad SSL a 0, y si los detalles de la Tarjeta llegan a almacenarse temporalmente en la sesión, tiene una fuga peligrosa esperando a suceder.

Si no puede estar seguro de que su software no es propenso a estas debilidades, sugeriría SSL desde el principio, por lo que su cookie inicial se transmite de manera segura.

Yo también usaría HTTPS todo el camino. Esto no tiene un gran impacto en el rendimiento (ya que la caché del navegador es la clave simétrica negociada después de la primera conexión) y protege contra el olfateo.

El olfateo estaba a punto de desaparecer debido a las redes cableadas completamente conmutadas, donde tendrías que trabajar mucho más para capturar el tráfico de los demás (en oposición a las redes que usan concentradores), pero está en camino de regreso debido a las redes inalámbricas, que crean un El medio de difusión una vez más permite un secuestro fácil de la sesión, a menos que el tráfico esté encriptado.

Siempre lo hice en todo el sitio web.

Kent lo clavó. Solo quiero hacer un comentario rápido: Amazon lo hace bien, creo. http para la mayoría del sitio, pero cuando llega el momento de finalizar la compra, debe iniciar sesión nuevamente (oneclick es un poco diferente), probablemente haya una cookie diferente en ese momento. Creo que otros comentarios dicen lo mismo, pero solo quería dar un ejemplo concreto.

Hay una desventaja importante en un sitio https completo y no es la velocidad (eso está bien).

Será muy difícil ejecutar Youtube, cuadros "Me gusta", etc. sin la advertencia insegura.

Estamos ejecutando un sitio web seguro de todas las fuerzas y compramos durante dos años y esta es la mayor desventaja. Logramos que Youtube funcione ahora, pero el "Agregar esto" sigue siendo un gran desafío. Y si cambian algo al protocolo, es posible que todas nuestras películas de Youtube estén en blanco ...