¿Los datos GET también están encriptados en HTTPS?

Respuestas:

146

Toda la solicitud está encriptada, incluida la URL e incluso el comando ( GET). Lo único que puede obtener una parte interviniente, como un servidor proxy, es la dirección y el puerto de destino.

Sin embargo, tenga en cuenta que el paquete Client Hello de un protocolo de enlace TLS puede anunciar el nombre de dominio completo en texto sin formato a través de la extensión SNI (gracias @hafichuk), que es utilizado por todos los navegadores principales modernos, aunque algunos solo en sistemas operativos más nuevos.

EDITAR: (Dado que esto me dio una insignia de "Buena respuesta", creo que debería responder a toda la pregunta ...)

Toda la respuesta también está encriptada; los proxies no pueden interceptar ninguna parte de ella.

Google ofrece búsquedas y otro contenido a través de https porque no todo es público, y es posible que también desee ocultar parte del contenido público de un MITM . En cualquier caso, es mejor dejar que Google responda por sí mismo .

— Marcelo Cantos
fuente
2
Estoy un poco descontento con la afirmación de que la URL está encriptada. ¿No se considera el nombre de host como parte de la URL? Si es así, la afirmación es incorrecta. No hay forma de ocultar el nombre de host / dirección IP del ISP / servidor proxy de la misma manera que no puede ocultar la dirección de destino mientras envía correo físico.
— Abhishek Anand
1
@Abhishek: el nombre de host no está presente en el encabezado TCP / IP. Cubro las direcciones IP en mi respuesta.
— Marcelo Cantos
El dominio no está encriptado. Esto es para admitir hosts virtuales basados ​​en nombres (frente a IP basados). @MarceloCantos es completamente correcto que el resto de la URL (es decir, el GETcomando) está encriptada. Esto está cubierto en RFC 4366
— hafichuk
@hafichuk: Gracias por eso. No me di cuenta de que TLS podía anunciar el fqdn. La última vez que intenté configurar un multiservidor https (hace varios años, lo admito), parecía imposible con una sola ip.
— Marcelo Cantos
Adición realmente importante al TLS que contiene el nombre de dominio: no olvide la solicitud DNS de texto sin formato que también incluye el nombre de dominio. Es probable que alguien que pueda ver su tráfico HTTPS encriptado también pueda ver sus solicitudes de DNS.
— Tim G
63

La URL en sí está encriptada, por lo que los parámetros en la cadena de consulta no viajan sin formato a través del cable.

Sin embargo, tenga en cuenta que las URL que incluyen los datos GET a menudo son registradas por el servidor web, mientras que los datos POST rara vez lo son. Entonces, si planeas hacer algo así /login/?username=john&password=doe, entonces no lo hagas; use una POST en su lugar.

— Thomas
fuente
2
+1 gracias. Esto está en mi propio servidor físico, por lo que no estoy demasiado preocupado por los registros, pero es una buena consideración para cualquiera que esté considerando esto en un entorno de alojamiento compartido. También es importante tener en cuenta porque transferiré los números de tarjeta de crédito de esta manera, y definitivamente no
— querré
3
Realmente no importa que sea tu propia caja. Tampoco quiere que nadie más que lo posea (es decir, hackers malvados) vea esas contraseñas en texto plano. O esos números CC (suponiendo que tampoco los esté almacenando en otro lugar).
— Thomas
1
Debe colocarlos en el cuerpo POST, no en la cadena de consulta de URL.
— Thomas
1
¿Teme que wbeserver tenga menos restricciones en el acceso a sus registros que en el acceso a los datos del sitio web (DB, archivo, etc.)? En mi humilde opinión, siempre que los datos accedan de forma segura al servidor web, todo está bien. las únicas personas que tienen acceso al servidor web deben considerarse confiables porque si no lo son, no les impedirá leer los datos de una manera u otra.
— Serge Profafilecebook
1
Cuando las contraseñas se envían a través de GET y se registran en el registro de acceso, NO se cifran. Creo que ese es el mayor problema. Tener contraseñas hash en la base de datos no importa si puede buscarlas en el registro de acceso del servidor web. Deben estar en hash en la base de datos, si no lo están, corríjalo.
— Steen Schütt
21

HTTPS Establece una conexión SSL subyacente antes de transferir cualquier dato HTTP. Esto garantiza que todos los datos de URL (con la excepción del nombre de host, que se utiliza para establecer la conexión) se transporten únicamente dentro de esta conexión cifrada y estén protegidos de ataques de intermediarios de la misma manera que cualquier dato HTTPS.

Lo anterior es parte de una respuesta MUY completa de Google Answers que se encuentra aquí:

http://answers.google.com/answers/threadview/id/758002.html#answer

— DVK
fuente
6

Todo está encriptado, pero debe recordar que su consulta permanecerá en los registros del servidor y será accesible para varios analizadores de registros, etc. (que generalmente no es el caso con la solicitud POST).

— Devolución de llamada de Eugene Mayevski
fuente
1
que servidores accesible para quien?
— Jader Dias el
2
@Jader para los administradores de esos servidores al menos y para los hackers. Con la solicitud POST, la información no permanece en los registros, por lo que a menos que se registre explícitamente, no hay ningún problema con los registros. Las consultas GET permanecen en los registros y si sucede lo que sea que ocurra con el registro (o el administrador decide usar estos registros para cualquier actividad incorrecta), está en problemas.
— Devolución de llamada de Eugene Mayevski el
4

La conexión se encripta antes de que se transmita la solicitud. Entonces, sí, la solicitud también está encriptada, incluida la cadena de consulta.

— cHao
fuente
4

Sí, es seguro SSL encripta todo.

Extracto de la solicitud POST:

POST /foo HTTP/1.1
... some other headers

Extracto de la solicitud GET:

GET /foo?a=b HTTP/1.1
... some other headers

En ambos casos, todo lo que se envía en el socket está encriptado. El hecho de que el cliente vea parámetros en su navegador durante una solicitud GET no significa que un hombre en el medio vería lo mismo.

— Darin Dimitrov
fuente
4

Me conecté a través de HTTPS a un sitio web y pasé un montón de parámetros GET. Luego usé wireshark para oler la red. Al usar HTTP, la URL se envía sin cifrar, lo que significa que puedo ver fácilmente todos los parámetros GET en la URL. Usando HTTPS, todo está encriptado y ni siquiera puedo ver qué paquete es el comando GET, ¡mucho menos su contenido!

— Jeff Lamb
fuente
3

El SSL tiene lugar antes del análisis del encabezado, esto significa:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Una solicitud se parece a esto (no puedo recordar la sintaxis exacta, pero debería estar lo suficientemente cerca):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

Esta es también la razón por la cual tener diferentes certificados SSL para varios hosts en la misma IP es problemático, el nombre de host solicitado no se conoce hasta el descifrado.

— Morfildur
fuente
1
El HTTP/1.1viene al final de la primera línea.
— Marcelo Cantos
@ Marcelos Cantos: Gracias, ha pasado un tiempo desde que tuve que escribir solicitudes HTTP a mano.
— Morfildur
0

La solicitud GET se cifra cuando se usa HTTPS; de hecho, esta es la razón por la cual los sitios web seguros deben tener una dirección IP única; no hay forma de obtener el nombre de host (o directorio virtual) deseado de la solicitud hasta después de que se haya descifrado.

— Michael Burr
fuente
JFYI: hay una extensión TLS que permite al cliente especificar el nombre del host y, por lo tanto, el servidor puede elegir el certificado correspondiente.
— Devolución de llamada de Eugene Mayevski el
@ Eugene: Gracias. Soy consciente de la extensión TLS, pero solo en el sentido más amplio de la conciencia. No sé nada de los detalles ni de qué tan ampliamente podría (o no) estar en uso real.
— Michael Burr
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.