2009-12-18 22 views
7

¿Es posible enviar un mensaje a través de https que no está encriptado? Por ejemplo, ¿se requiere que ocurra la validación y autorización del certificado, pero no se encriptan los datos reales que se envían a través del socket?Protocolo SSL no cifrado?

+0

Tengo curiosidad de cómo se usaría esto? ¿Por qué no usar un método alternativo de autenticación? Para mí, parece que eso es todo lo que quieres, la autenticación de un host ... válido? * encogerse de hombros * – Jakub

+0

La pregunta no tiene sentido, ya que https es una versión segura de http que se ejecuta en el puerto estándar 443. El estándar dicta que todo el cifrado y la autorización/autenticación de certificados se aplican a este protocolo https. Y de todos modos, cualquier mensaje enviado a través de https está encriptado. ¿Puedes aclarar lo que estás tratando de hacer? – t0mm13b

+2

Ah, de hecho, no quiero usar esto. Solo quiero asegurarme de que si uso el protocolo https, no tengo que decirle al servidor que lo encripte.De esta forma puedo confiar en que los datos estén encriptados si utilizo https. – bkritzer

Respuesta

20

Sí, TLS y SSL son compatibles con los modos "sin cifrado". Si el cliente y el servidor en cuestión están configurados para habilitarse es un problema aparte.

Es posible, aunque poco probable, que un servidor pueda habilitar uno de estos conjuntos de cifrado de forma predeterminada. Lo que es más probable es que un servidor habilite suites de cifrado débiles (como las suites basadas en DES de "exportación") por defecto. Es por eso que debe revisar cuidadosamente la lista blanca del servidor de conjuntos de cifrado, y leave only a few trusted, widely-supported algorithms.

Puede usar el conjunto de cifrado TLS_RSA_WITH_NULL_SHA, entre otros, para proteger la autenticidad e integridad del tráfico, sin cifrado.

El "RSA" en este caso se refiere al algoritmo de intercambio de claves, mientras que "SHA" se refiere al algoritmo de autenticación de mensajes utilizado para proteger el tráfico contra la alteración. "NULO" es el algoritmo de encriptación o, en este caso, la falta de encriptación.

Es importante darse cuenta de que el tráfico, aunque no está encriptado, se incluye en los registros SSL. El cliente y el servidor deben estar habilitados para SSL.

Si está buscando una solución de reducción donde algunos datos se intercambian a través de SSL, entonces SSL se apaga pero el tráfico de la aplicación continúa, eso también es posible, pero tenga en cuenta que no ofrece absolutamente ninguna seguridad para el texto sin formato tráfico; puede ser manipulado por un atacante. Por lo tanto, por ejemplo, autenticarse con SSL, luego pasar a un protocolo "in-the-clear" para recibir comandos que usan la autenticación negociada a través de SSL sería inseguro.

+0

Hola, tengo alguna pregunta sobre openssl, ¿le gustaría echar un vistazo con la siguiente dirección? http://stackoverflow.com/questions/2542156/openssl-ssl-encryption – deddihp

-3

No, el protocolo no permite eso.

Una solución que podría hacer es conectarse a través de https, verificar la conexión y luego desconectar las conexiones subsiguientes a HTTP con una cookie de sesión. Sin esa cookie, redirija a https para que el cliente siempre se conecte.

Esto puede que no sea relevante para usted, por lo tanto, si proporciona más información sobre el problema que está tratando de resolver, podríamos ayudarlo.

-1

Creo que puedes.

pero sería estúpido, perderá el sentido de la autenticación y se expondrá a los atacantes que pueden interceptar y alterar sus paquetes.

+4

La privacidad y la integridad son dos cosas diferentes. Puedes usar TLS sin privacidad; los atacantes podrían leer tus paquetes, pero sabrías si alteraron un paquete. – erickson

+0

@erickson No sé SSL y sus hijos son lo suficientemente buenos, pero ¿por qué querrías usar hash criptográfico en tus datos de tránsito y no simplemente encriptarlo? –

+0

No he tenido una aplicación para mí. Solo estaba señalando que SSL puede proteger contra la alteración de paquetes sin proporcionar privacidad, y el simple cifrado no es suficiente para evitar la alteración de los paquetes. – erickson

5

Las especificaciones SSL/TLS definen un "cifrado NULO" que puede usar para esto. La mayoría de los programas cliente y servidor lo desactivan por razones obvias.

Sin embargo, si está escribiendo su propio software, puede convencer a su biblioteca para que lo negocie.

Cuestiones relacionadas