2010-04-26 9 views
211

Tengo una pregunta sobre las credenciales de autenticación HTTPS y HTTP.Credenciales de autenticación básica de HTTP pasadas en URL y cifrado

Supongamos que asegurar una URL con autenticación HTTP:

<Directory /var/www/webcallback> 
AuthType Basic 
AuthName "Restricted Area" 
AuthUserFile /var/www/passwd/passwords 
Require user gooduser 
</Directory> 

entonces tener acceso a esa URL desde un sistema remoto a través de HTTPS, pasando las credenciales en la URL:

https://gooduser:[email protected]/webcallback?foo=bar 

¿El nombre de usuario y la contraseña se cifrará SSL automáticamente? ¿Es lo mismo para GET y POST? Me está costando encontrar una fuente creíble con esta información.

+1

relacionadas: [nombre de usuario y contraseña en https url] (http://stackoverflow.com/questions/4980912/username-and-password-in-https-url) –

Respuesta

201

¿El nombre de usuario y la contraseña se cifrarán SSL automáticamente? Es lo mismo para GET y POSTs

Sí, sí sí.

Toda la comunicación (salvo la búsqueda de DNS si la dirección IP del nombre de host no está almacenada en la memoria caché) se cifra cuando se usa SSL.

+23

1. Los GET y POST, incluida la URL, están encriptados. Solo agregaré: las herramientas como Firebug y Tamper pueden mostrar los resultados no cifrados * solo porque * forman parte del navegador y, por lo tanto, pueden interceptar la solicitud antes de que se encripte. Una vez enviado por el cable, todo está encriptado. –

+18

Para ser claros, todo menos el dominio está encriptado. Si alguien se tropieza con esto y quiere una respuesta más detallada, consulte http://answers.google.com/answers/threadview/id/758002.html – rcourtna

+7

. Para mayor información, "[Internet Explorer no admite nombres de usuario ni contraseñas en direcciones de sitios web (URL HTTP o HTTPS)] (http://support.microsoft.com/kb/834489/en-us) " Parece que solo las versiones de Internet Explorer 3.0 a 6.0 admite la siguiente sintaxis para URL HTTP o HTTPS: http (s): // nombre de usuario: contraseñ[email protected]/resource.ext Nota: Este cambio en el comportamiento predeterminado no afecta a otros protocolos. Por ejemplo, aún puede incluir información de usuario en una URL de FTP después de instalar la actualización de seguridad 832894. – Luke

-7

No necesariamente cierto. Se cifrará en el cable, sin embargo, sigue en los registros texto sin formato

+16

¿Qué servidor web registra el nombre de usuario y las contraseñas de las solicitudes? Eso sería un infierno de un servidor web inseguro. –

+0

Sí, esto simplemente no es cierto. Probablemente sea posible indicar a apache que registre esta información, pero ciertamente no lo hace de manera predeterminada. – DougW

+24

@Brandon probablemente pensó "en URL" en la cadena de consulta (p. Ej.,? User = bob & pw = 123hackmeplz). Eso podría terminar en los registros del servidor. –

16

Sí, se cifrará.

Lo comprenderá si simplemente comprueba lo que sucede detrás de escena.

  1. El navegador o la aplicación desglosará primero la dirección URL e intentará obtener la dirección IP del host mediante una consulta DNS. es decir: se realizará una solicitud DNS para encontrar la dirección IP del dominio (www.example.com). Tenga en cuenta que no se enviará ninguna otra información a través de esta solicitud.
  2. El navegador o la aplicación iniciarán una conexión SSL con la dirección IP recibida de la solicitud DNS. Los certificados se intercambiarán y esto sucede en el nivel de transporte. No se transferirá información de nivel de aplicación en este punto. Recuerde que la autenticación básica es parte de HTTP y HTTP es un protocolo de nivel de aplicación. No es una tarea de capa de transporte.
  3. Después de establecer la conexión SSL, ahora los datos necesarios se transmitirán al servidor. es decir: la ruta o la URL, los parámetros y el nombre de usuario y la contraseña de autenticación básica.
Cuestiones relacionadas