from - ¿Están las URL de HTTPS encriptadas?
jquery ajax http over https (12)
¿Están todas las URL cifradas cuando se usa el cifrado TLS / SSL (HTTPS)? Me gustaría saber porque quiero que todos los datos de URL se oculten al usar TLS / SSL (HTTPS).
Si TLS / SSL le proporciona un cifrado total de URL, no tengo que preocuparme por ocultar información confidencial de las URL.
Además, si está creando una API ReSTful, la filtración del navegador y los problemas del referente de http se mitigan, ya que es posible que el cliente no sea un navegador y que no haya personas haciendo clic en los enlaces.
Si este es el caso, recomendaría el inicio de sesión de oAuth2 para obtener un token de portador. En cuyo caso, los únicos datos confidenciales serían las credenciales iniciales ... que probablemente deberían estar en una solicitud posterior de todos modos
Aunque ya hay algunas buenas respuestas aquí, la mayoría de ellas se centran en la navegación del navegador. Estoy escribiendo esto en 2018 y probablemente alguien quiera saber sobre la seguridad de las aplicaciones móviles.
Para aplicaciones móviles , si controla ambos extremos de la aplicación (servidor y aplicación), siempre que use HTTPS , estará seguro . iOS o Android verificarán el certificado y mitigarán posibles ataques MiM (ese sería el único punto débil en todo esto). Puede enviar datos confidenciales a través de conexiones HTTPS que se cifrarán durante el transporte . Solo su aplicación y el servidor conocerán los parámetros enviados a través de https.
El único "quizás" aquí sería si el cliente o el servidor están infectados con software malintencionado que puede ver los datos antes de que se envuelvan en https. Pero si alguien está infectado con este tipo de software, tendrá acceso a los datos, sin importar lo que use para transportarlos.
Dado que nadie proporcionó una captura de alambre, aquí hay uno.
El nombre del servidor (la parte del dominio de la URL) se presenta en el paquete ClientHello , en texto sin formato .
A continuación se muestra una solicitud de navegador para:
https://i.stack.imgur.com/path/?some=parameters&go=here
Consulte esta respuesta para obtener más información sobre los campos de la versión TLS (hay 3 de ellos, no versiones, campos que contienen un número de versión).
Desde https://www.ietf.org/rfc/rfc3546.txt :
3.1. Indicación del nombre del servidor
[TLS] no proporciona un mecanismo para que un cliente le diga a un servidor el nombre del servidor con el que se está contactando. Puede ser conveniente que los clientes proporcionen esta información para facilitar las conexiones seguras a los servidores que alojan múltiples servidores "virtuales" en una única dirección de red subyacente.
Para proporcionar el nombre del servidor, los clientes PUEDEN incluir una extensión de tipo "nombre_servidor" en el hola del cliente (ampliado).
En breve:
El FQDN (la parte del dominio de la URL) PUEDE transmitirse de forma clara dentro del paquete de
ClientHellosi se usa la extensión SNIEl resto de la URL (
/path/?some=parameters&go=hereClientHello/path/?some=parameters&go=here) no tiene nada que ver conClientHelloya que la URL de la solicitud es una cosa HTTP (OSI Layer 7), por lo tanto, nunca aparecerá en un protocolo de enlace TLS (Layer 4 o 5). Eso vendrá más adelante en una solicitudGET /path/?some=parameters&go=here HTTP/1.1HTTPGET /path/?some=parameters&go=here HTTP/1.1, DESPUÉS de que se establezca el canal TLS seguro .
RESUMEN EJECUTIVO
El nombre de dominio PUEDE ser transmitido en claro (si la extensión SNI se usa en el protocolo de enlace TLS) pero la URL (ruta y parámetros) siempre está cifrada.
Enlace a mi respuesta en una pregunta duplicada . La URL no solo está disponible en el historial de los navegadores, sino también en los registros del lado del servidor, sino que también se envía como el encabezado del Referente HTTP que, si utiliza contenido de terceros, expone la URL a fuentes fuera de su control.
Estoy de acuerdo con las respuestas anteriores:
Para ser explícito:
Con TLS, la primera parte de la URL ( https://www.example.com/ ) aún está visible a medida que se crea la conexión. La segunda parte (/ herearemygetparameters / 1/2/3/4) está protegida por TLS.
Sin embargo, hay una serie de razones por las que no debe colocar parámetros en la solicitud GET.
Primero, como ya lo mencionaron otros: - filtración a través de la barra de direcciones del navegador - filtración a través del historial
Además, tiene una filtración de URL a través del http referer: el usuario ve el sitio A en TLS, luego hace clic en un enlace al sitio B. Si ambos sitios están en TLS, la solicitud al sitio B contendrá la URL completa del sitio A en El parámetro de referencia de la solicitud. Y el administrador del sitio B puede recuperarlo de los archivos de registro del servidor B.)
No siempre se puede contar con la privacidad de la URL completa tampoco. Por ejemplo, como ocurre a veces en las redes empresariales, los dispositivos provistos como la PC de su empresa están configurados con un certificado raíz "confiable" adicional para que su navegador pueda confiar silenciosamente en una inspección por proxy (man-in-the-middle) del tráfico https . Esto significa que la URL completa está expuesta para su inspección. Esto generalmente se guarda en un registro.
Además, sus contraseñas también están expuestas y probablemente registradas, y esta es otra razón para usar contraseñas de un solo uso o para cambiarlas con frecuencia.
Finalmente, el contenido de la solicitud y la respuesta también se expone si no está cifrado.
Un ejemplo de la configuración de inspección se describe aquí en Checkpoint . Un viejo "cibercafé" que usa las PC suministradas también puede configurarse de esta manera.
Sí, la conexión SSL se encuentra entre la capa TCP y la capa HTTP. El cliente y el servidor primero establecen una conexión TCP encriptada segura (a través del protocolo SSL / TLS) y luego el cliente enviará la solicitud HTTP (GET, POST, DELETE ...) a través de esa conexión TCP encriptada.
Si y no.
La parte de la dirección del servidor NO está cifrada, ya que se utiliza para configurar la conexión.
Esto puede cambiar en el futuro con SNI y DNS cifrados, pero a partir de 2018, ambas tecnologías no se usan comúnmente.
La ruta, cadena de consulta, etc. están encriptadas.
Nota para las solicitudes GET, el usuario aún podrá cortar y pegar la URL de la barra de ubicación, y probablemente no querrá poner información confidencial allí que pueda ser vista por cualquiera que esté mirando la pantalla.
Toda la solicitud y respuesta está encriptada, incluida la URL.
Tenga en cuenta que cuando utiliza un Proxy HTTP, conoce la dirección (dominio) del servidor de destino, pero no conoce la ruta solicitada en este servidor (es decir, la solicitud y la respuesta siempre están cifradas).
Un tercero que monitorea el tráfico también puede determinar la página visitada al examinar su tráfico y compararlo con el tráfico que otro usuario tiene cuando visita el sitio. Por ejemplo, si había 2 páginas solo en un sitio, una mucho más grande que la otra, entonces la comparación del tamaño de la transferencia de datos diría qué página visitó. Existen formas en que esto podría ocultarse a terceros, pero no son el comportamiento normal del servidor o del navegador. Consulte, por ejemplo, este documento de SciRate, https://scirate.com/arxiv/1403.0297 .
En general, otras respuestas son correctas, aunque prácticamente este documento muestra que las páginas visitadas (es decir, la URL) se pueden determinar con bastante eficacia.
Una adición a la útil respuesta de Marc Novakowski: la URL se almacena en los registros del servidor (por ejemplo, en / etc / httpd / logs / ssl_access_log), por lo que si no desea que el servidor mantenga la información durante más tiempo Término, no lo pongas en la URL.