2009-07-09 26 views
12

Aquí está mi pregunta.¿Agregar soporte SSL al código TCP y UDP existente?

Ahora mismo tengo una aplicación de servidor Linux (escrito en C++ - GCC) (. Visual Studio 9, Qt 4.5) que se comunica con la aplicación cliente de Windows C++

¿Cuál es el manera más fácil de añadir Soporte SSL para ambas partes para asegurar la comunicación, sin destripar por completo el protocolo existente.

Es una aplicación VOIP que usa una combinación de UDP y TCP para configurar inicialmente la conexión y hacer cosas de túnel de puertos, y luego usa UDP para los datos de transmisión.

He tenido muchos problemas en el pasado con la creación de certificados de seguridad desde cero que eran necesarios para que todo esto funcione.

El código de ejemplo de trabajo existente sería ideal.

Gracias!

Respuesta

11

SSL is very complex, por lo que querrá utilizar una biblioteca.

Hay varias opciones, tales como Keyczar, Botan, cryptlib, etc. Todas y cada una de esas bibliotecas (o las bibliotecas sugeridos por otros, como Boost.Asio o OpenSSL) tendrán código de ejemplo para esto.


Respondiendo a la segunda pregunta (¿cómo integrar una biblioteca en el código existente sin causar demasiado dolor): que va a depender de su código actual. Si ya tiene funciones simples que llaman a los métodos Winsock o socket para enviar/recibir int s, strings, etc., solo necesita volver a escribir las agallas de esas funciones. Y, por supuesto, cambie el código que establece el socket para comenzar.

Por otro lado, si está llamando directamente a las funciones de Winsock/socket entonces probablemente quiera escribir funciones que tengan una semántica similar pero envíen los datos encriptados, y reemplace sus llamadas de Winsock con esas funciones.

Sin embargo, es posible que desee considerar cambiar a algo como Google Protocol Buffers o Apache Thrift (a.k. a Facebook Thrift). La documentación de Buffers de Protocolo de Google dice: "Antes de los búferes de protocolo, había un formato para solicitudes y respuestas que utilizaban orquestación/desasignación de solicitudes y respuestas, y que admitía varias versiones del protocolo. Esto dio como resultado un código muy desagradable. ... "

Actualmente se encuentra en la fase de concentración/desasignación de manos. Puede funcionar, y de hecho, un proyecto en el que trabajo utiliza este método. Pero es mucho mejor dejar eso en una biblioteca; especialmente una biblioteca que ya ha pensado en actualizar el software en el futuro.

Si sigue esta ruta, configurará sus conexiones de red con una biblioteca SSL y luego transferirá sus datos Thrift/Protocol Buffer a través de esas conexiones. Eso es. Implica una refacturación extensa, pero terminarás con menos código para mantener. Cuando introdujimos Buffers de Protocolo en la base de código de ese proyecto que mencioné, pudimos deshacernos de aproximadamente 300 líneas de código de clasificación/demarshalling.

+0

Hola, Max, Gracias por los detalles adicionales. (Quizás mi pregunta original no estaba redactada con claridad). Su respuesta agrega la información que me da. Tengo un proceso bastante feo, codificado a mano y basado en un socket en el código que hace una especie de "handshake" con el servidor, y específicamente configura el túnel del puerto UDP. El resto del código de red se abstrae en las funciones auxiliares de tipo "SendXMLViaTCPAndWaitForResponse()". Solo morder la bala no debería ser tan difícil, debería implicar poca recodificación más allá de los efectos de ayuda. Gracias de nuevo por clavar esto. –

4

Recomiendo usar GnuTLS tanto en el lado del cliente como del servidor, solo para la conexión TCP. Olvídate de los datos UDP por ahora. La documentación de GnuTLS tiene example code para escribir clientes y servidores. Por favor, comprenda que al menos el lado del servidor (generalmente el respondedor TCP) necesita tener un certificado; el lado del cliente puede trabajar con identificación anónima (aunque hay incluso un ejemplo sin certificado de servidor, que usa solo intercambio de claves DH, lo que permitiría ataques de hombre en el medio).

En general, es probable que tenga que comprender los principios de SSL, independientemente de la biblioteca que utilice. Las alternativas de la biblioteca son OpenSSL (tanto Unix como Windows) y SChannel (solo Windows).

2

¿Has probado la compatibilidad con SSL en Boost.Asio o ACE? Ambos usan OpenSSL debajo del capó y proporcionan abstracciones similares para TCP, UDP y SSL. El código de muestra está disponible en las distribuciones de Boost.Asio y ACE.

Una cosa que debe tener en cuenta es que SSL está orientado a registros en lugar de orientado a flujos (tanto TCP como UDP). Esto puede afectar la forma en que multiplexa los eventos, ya que debe, por ejemplo, leer el registro SSL completo antes de poder completar una operación de lectura.

2

Para ayudar a manejar esto sin cambios en la aplicación, es posible que desee ver el proyecto de stunnel (http://www.stunnel.org/). Sin embargo, no creo que maneje el UDP por ti.

2

Las bibliotecas SSL/TLS integradas yaSSL y CyaSSL me han funcionado en el pasado. Al estar dirigidos a los sistemas integrados, están optimizados tanto para la velocidad como para el tamaño. yaSSL está escrito en C++ y CyaSSL está escrito en C. En comparación, CyaSSL puede ser hasta 20 veces más pequeño que OpenSSL.

Ambos soportan los estándares más actuales de la industria (hasta TLS 1.2), ofrecen algunas características geniales como cifrado de flujo, y tienen doble licencia bajo licencia GPLv2 y comercial (si necesita soporte comercial).

Ellos tienen un tutorial de SSL, lo que afecta a la adición de CyaSSL en el código preexistente, así: http://www.yassl.com/yaSSL/Docs-cyassl-manual-11-ssl-tutorial.html

producto página: http://yassl.com/yaSSL/Products.html

Saludos,
Chris

+0

Hola Chris, gracias por la respuesta. Desafortunadamente, ha pasado más de un año desde mi publicación, y el cliente canceló el proyecto y me echó del proyecto hace un par de semanas. –

+0

Triste de escuchar. Me di cuenta de que había pasado mucho tiempo desde su publicación, pero pensé que al menos lo publicaría como referencia futura. – Chrisc

Cuestiones relacionadas