¿Se debe usar http para https iniciar sesión en las páginas siguientes?

Question

He visto muchos hilos en SO y sugieren que la contraseña no se puede transferir de forma segura sin SSL. Así que supongo que he https página de inicio de sesión, pero

1. ¿Debo cambiar de nuevo a http después de usuario ha sido autenticado a través de HTTPS (suponiendo que no hay información sensible se envía a través después de inicio de sesión)? ¿Porque podría cargar la página un poco más rápido?

2. ¿Crearía gastos adicionales en términos de desarrollo (con Zend Framework)? Como mantener diferentes estructuras de directorios y todo eso.

Answer 1

1. Si los datos no es sensible que podría cambiar de nuevo a http después de la autenticación de usuarios para obtener un pequeño beneficio velocidad. Debe recordar cambiar a https nuevamente si aparece algún tipo de datos confidenciales en el sitio (como el perfil de usuario o similar). En realidad, puede ser más fácil tener toda la sesión siempre encriptada para que no tenga que preocuparse por activar y desactivar el cifrado, según el contenido de la página.

2. SSL es transparente para los desarrolladores, usted crea su aplicación exactamente igual que para un servidor no seguro. Necesita tener un certificado SSL que pueda comprar o generar usted mismo y configurar su servidor para manejarlo. Luego, dependiendo del protocolo (http o https), su sesión será o no encriptada automáticamente. Por lo tanto, se trata de establecer enlaces https: // correctos para páginas en las que necesita un cifrado y enlaces http: // estándar para otras páginas.

Answer 2

1. Sí, se puede cambiar de nuevo a http después de la transferencia contraseña de usuario. No es necesario editar todo el contenido cuando no contiene datos confidenciales. Cuando ha encriptado TODOS los sitios: el servidor necesita criptar todos los datos y su servidor tiene el peor rendimiento que sin criptación.

Answer 3

El tiempo de toma para una conexión SSL para cifrar y descifrar (después de que se haya inicializado) es insignificante en comparación con el tiempo que se necesita para transferir los datos. Entonces no, no se cargará "un poco" más rápido, incluso.

Las carpetas adicionales dependen de su servidor, no de su marco. Si su servidor enruta todas las solicitudes https a través de la carpeta/httpsdocs o algo así, puede poner .htaccess en ella, que lo redirige a la carpeta/httpdocs.

Answer 4

VolkerK tiene razón, pero su respuesta se equivoca por el lado de la precaución. La sesión puede verse comprometida por todo tipo de métodos. Hay formas de evitar esto (por ejemplo, utilizar un lado del cliente de javascript en caché para generar hash frente a una sal fija de un desafío generado con cada página) pero son desordenados. Con mucho, la solución más simple es usar siempre SSL. Sin embargo, podría considerar usar la autenticación resumida combinada con una cookie de sesión.

Tor Valamo está equivocado. Actualmente, el ancho de banda es muy barato, sin embargo, lo que es difícil de lograr es eliminar la latencia, y la latencia es el principal determinante de la velocidad de transferencia HTTP (donde la mayoría del contenido es relativamente pequeño). Para una solicitud HTTP, hay al menos 2 viajes redondos al servidor: el protocolo de enlace TCP y luego la Solicitud/respuesta. Varía según el tamaño de los archivos y otras consideraciones, pero normalmente la latencia de ida y vuelta representa el 50-70% del tiempo transcurrido para obtener un objeto.

El uso de Keep-Alives elimina uno de los viajes de ida y vuelta y mejora mucho el rendimiento.

Con SSL, se requiere al menos un viaje de ida y vuelta adicional (para la reanudación de una sesión SSL existente) y más de uno para la negociación inicial de SSL. El verdadero asesino es que la implementación no estándar de SSL de Microsoft significa que no puede usar keep-alives desde otra cosa que no sea MSIIS cuando habla con un cliente de MSIE (consulte los documentos de mod_ssl para obtener más información).