Uso de HTTPS en Java sin cifrado

Question

Estamos buscando una solución que nos permita usar HTTPS sin cifrado. ¿Por qué? Aquí está la historia:

Nuestro producto (instalado en los clientes) se conecta a nuestros servidores para buscar actualizaciones, publicar información, etc. Queremos que el producto verifique que esté conectado al servidor (y no a un impostor) antes de publicarlo datos. También debemos asegurarnos de que no haya ataques man-in-the-middle (es decir, que el contenido deba estar firmado, etc.). Sin embargo, nuestros clientes requieren que puedan oler el tráfico (Wireshark, tcpdump, etc.) y ver el contenido de la transacción completa. Esto es por razones de cumplimiento y seguridad.

Nuestro producto está escrito en Java, por cierto.

¿Alguna idea?

ACTUALIZACIÓN: discúlpenme si no estoy usando la forma correcta para responder a las respuestas, soy bastante nuevo en este sitio.

Antes que nada, ¡gracias por sus respuestas rápidas!

Nuestra razón para investigar la posibilidad de HTTPS es porque no queremos inventar un nuevo protocolo aquí. No se trata solo de la cantidad de trabajo, sino también del hecho de que inventar su propio protocolo de seguridad (aunque solo sea para firmar) generalmente se considera una mala práctica. Estamos tratando de obtener las ventajas de HTTPS para autenticar el servidor (lo que es importante, este servidor también sirve código ejecutable que puede ser bastante grande; no queremos que nadie sirva malware o DoSing a nuestros clientes con datos grandes que solo después de recibir la totalidad el sistema descubrirá que es malo) y garantizará que no se produzca MITM (la firma de los mensajes). No nos importa si alguien evelap en el tráfico porque nunca contiene algo considerado confidencial. Además, no es necesario que sea fácil leer los contenidos en Wireshark, solo es posible para que los auditores puedan hacerlo.

@Nate Zaugg - no, esto no es una broma. En realidad, es sorprendente que los proveedores usen hoy HTTPS con encriptación y no reciban mucha reacción de los clientes con estrictos problemas de cumplimiento.

@erickson - La primera solución con los trajes de cifrado NULL parece interesante, la investigaremos. La segunda solución requerirá un conjunto de claves para cada cliente, no algo que nos gustaría administrar.

@ZZ Coder - ¿Quiere decir que con cifras nulas no será posible ver el contenido en Wireshark?

Answer 1

Existen "cifrados" SSL sin cifrado, y todas las versiones del proveedor Sun JSSE admiten SSL_RSA_WITH_NULL_SHA. Sin embargo, todos los datos de la aplicación aún están envueltos en registros SSL (para transportar el MAC que brinda protección de integridad, etc.), de modo que al mirarlo en Wireshark, verá estas estructuras.

O bien, siempre que no utilice efímera Diffie-Hellman (una de las DHE_XXX series de cifrado), puede darle a Wireshark la clave privada del servidor y descifrará una sesión SSL. Si bien este es un trabajo adicional, no impone ningún requisito inusual en el servidor o cliente para admitir los conjuntos de cifrado descifrados poco utilizados.

Answer 2

Si solo necesita firmar, ¿por qué no puede simplemente firmar cada respuesta con una clave privada (poniendo la firma en un encabezado) y verificarla con una clave pública en el cliente, pero no usar HTTPS en absoluto? Siempre y cuando su clave privada permanezca secreta y usted elija un algoritmo de firma apropiado, esto evitará manipular el cuerpo de la respuesta, pero sin mantener ese cuerpo en secreto.

Answer 3

Puede intentar usar las cifras NULL (1 y 2) pero la mayoría de los servidores están configurados para no aceptar las cifras débiles. Por supuesto, estas 2 cifras son las más débiles.

Incluso la carga útil estará en texto sin cifrar, todavía está envuelta dentro del marco SSL, por lo que la mayoría del descifrado de paquetes comunes no funciona.

Answer 4

Estoy de acuerdo con @Jon Skeet: no deberías tratar de utilizar un HTTPS paralizado, en su lugar solo debes firmar tus respuestas. Puede ver algunos de los documentos de Amazon's S3 para obtener un buen ejemplo de un modelo de seguridad robusto, pero bastante sencillo.

En resumen, la idea básica es tener algún tipo de clave secreta, anexarla y una marca de tiempo a su mensaje y hash eso. Envíe el hash y la fecha (pero no el secreto, obviamente) junto con su mensaje al servidor. Luego, su servidor verifica que la fecha esté lo suficientemente cerca como para confiar (digamos 15 minutos) y mezcla la solicitud, la fecha y la clave secreta que tiene registrada. Si obtiene el mismo hash, entonces un recurso confiable generó la solicitud y el servidor puede continuar de manera segura.

Obviamente, esto no está a salvo de la inhalación de hombre en el medio (que parece estar bien con), pero evitará que un MITM cambie o cree solicitudes falsas.

Answer 5

¿No debería cada cliente tener una clave distinta de todos modos? de lo contrario, ¿cómo sabe su servidor quién está publicando? al servidor no le importa a ningún hombre en el medio?

si cada cliente tiene una clave, como una contraseña simple, que el servidor conoce, la clave se puede usar como una sal con una función hash para firmar solicitudes/respuestas.

Answer 6

Existen alternativas que permiten delimitar el tráfico para que pueda leerse. Netronome es solo un ejemplo. Para obtener detalles, consulte http://werebuild.telecomix.org/w/images/2/25/Netwitness-SSL-Decryption.pdf