Añadir soporte SSL para TCP existente y código UDP?

Question

Esta es mi pregunta.

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

¿Cuál es el muy forma más fácil de añadir soporte SSL para ambas partes con el fin de asegurar la comunicación, sin destripar por completo el protocolo existente?

Es una aplicación de VoIP que utiliza una combinación de UDP y TCP para establecer inicialmente la conexión y hacer cosas túnel del puerto, y luego utiliza UDP para los datos de streaming.

He tenido un montón de problemas en el pasado con la creación de los certificados de seguridad desde el principio que eran necesarios para obtener este material de trabajo.

vigente Código ejemplo de trabajo sería ideal.

Gracias!

Answer 1

SSL es muy complejo , por lo que vamos a querer utilizar una biblioteca.

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

---

Responder 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 dispone de funciones simples que llaman a los métodos de Winsock o hembra para enviar / recibir ints, strings, etc. continuación, sólo tiene que volver a escribir las entrañas de esas funciones. Y, por supuesto, cambiar el código que configura el zócalo, para empezar.

Por otro lado, si usted está llamando directamente a las funciones de Winsock / socket entonces es probable que quieren incluir funciones que tienen una semántica similar pero enviar los datos cifrados, y reemplazar su Winsock llama con esas funciones.

Sin embargo, es posible que desee considerar el cambio a algo así como Google Protocol Buffers o < a href = "http://wiki.apache.org/thrift/" rel = "nofollow noreferrer"> Apache Thrift (también conocido como Facebook Thrift). documentación Protocol Buffers de Google dice: "Antes de búferes de protocolo, hubo un formato para solicitudes y respuestas que utilizan mano de clasificación / unmarshalling de peticiones y respuestas, y que apoyaron una serie de versiones del protocolo. Esto dio lugar a un código muy feo. ... "

Actualmente se encuentra en la fase de clasificación mano / unmarshalling. Se puede trabajar, y de hecho un proyecto de trabajo en sí utiliza este método. Pero es mucho más agradable a dejar eso a una biblioteca; especialmente una biblioteca que ya ha pensado un poco en actualizar el software en el futuro.

Si usted va esta ruta podrás configurar las conexiones de red con una biblioteca SSL, y luego se le empuja su Thrift / datos de búfer de protocolo sobre esas conexiones. Eso es. Esta consiste en una amplia refactorización, pero usted va a terminar con menos código de mantener. Cuando presentamos Protocol Buffers en el código base de ese proyecto que he mencionado, hemos sido capaces de deshacerse de alrededor de 300 líneas de cálculo de referencias / Código demarshalling.

Answer 2

Recomiendo el uso de GnuTLS tanto en el cliente y el servidor, sólo para la conexión TCP. Olvidarse de los datos UDP por ahora. La documentación GnuTLS tiene código ejemplo para la escritura de los clientes y los servidores. Por favor entender que al menos el lado del servidor (por lo general el respondedor TCP) debe tener un certificado; el lado del cliente puede trabajar con identificación anónima (aunque hay incluso un ejemplo sin certificado de servidor, utilizando sólo el intercambio de claves DH - lo que permitiría ataques man-in-the-middle).

En general, es probable que usted tendrá que entender los principios de SSL, no importa lo que la biblioteca que utiliza. alternativas de la biblioteca son OpenSSL (Unix y Windows) y SChannel (sólo Windows).

Answer 3

¿Has probado el soporte SSL en Boost.Asio o ACE ? Ambos utilizan OpenSSL bajo el capó, y proporcionan abstracciones similares para TCP, UDP y SSL. Código de la muestra está disponible tanto en las distribuciones Boost.Asio y ACE.

Una cosa que puede que tenga que tener en cuenta es que SSL está orientado a registros en lugar de la corriente orientada-(TCP y UDP). Esto puede afectar la manera de eventos múltiplex ya que debe, por ejemplo, leer el registro completo SSL antes de llamar a una operación de lectura completa.

Answer 4

Para ayudar a manejar esto con ningún cambio en la aplicación del yo puede que desee ver en el proyecto stunnel ( http: // www.stunnel.org/ ). No creo que se encargará de la UDP para usted sin embargo.

Answer 5

El yaSSL y bibliotecas SSL CyaSSL incrustado / TLS han funcionado bien para mí en el pasado. Al estar dirigido a los sistemas integrados, que están optimizadas para la velocidad y 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 apoyan los estándares de la industria más actuales (hasta TLS 1.2), ofrecen algunas características interesantes, tales como cifras de la corriente, y son de doble bajo la licencia GPLv2 y para uso comercial (si necesita soporte comercial).

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

Product Page: http://yassl.com/yaSSL/Products.html

Saludos, Chris