OpenSSL vs CURL

[Kaxperday]

Buenas,

OpenSSL ofrece conexiones SSL y además tiene una suite de cifrado muy buena quizás la mejor librería de cifrado que haya, sus librerías estáticas son 2: libeay32.lib (13.405kbs) ssleay32.lib (2.232kbs).

Mientras que CURL ofrece conexiones para muchos protocolos con SSL pero nada de cifrado, su librería estática libcurl.lib pesa 1.613kb.

Todas las librerías de las que hablo son para versiones release.

Pero, ¿Por qué opción decantarse si utilizamos cifrado en nuestro programa?.

¿Y para conexiones sin texto plano, que pesará menos conexiones con la WINAPI o con CURL?.

Saludos.

[kub0x]

Buenas,

OpenSSL ofrece conexiones SSL y además tiene una suite de cifrado muy buena quizás la mejor librería de cifrado que haya, sus librerías estáticas son 2: libeay32.lib (13.405kbs) ssleay32.lib (2.232kbs).

Mientras que CURL ofrece conexiones para muchos protocolos con SSL pero nada de cifrado, su librería estática libcurl.lib pesa 1.613kb.

Todas las librerías de las que hablo son para versiones release.

Pero, ¿Por qué opción decantarse si utilizamos cifrado en nuestro programa?.

¿Y para conexiones sin texto plano, que pesará menos conexiones con la WINAPI o con CURL?.

Saludos.

Depende. OpenSSL si quieres implementar un servidor que utilice una suite criptográfica segura, o bien, CURL si simplemente quieres desarrollar un cliente que realice conexiones SSL/TLS remotas.

Supongo que para plaintext CURL, además de que es open src.

Saludos!

[AlbertoBSD]

He programado con la API de CURL y funciona bien tiene soporte para distintos protocolos y automaticamente negocia la conexión con el mejor cifrado disponible en su API, la he usado para programar un bot de telegram y maneja bien las conexiones a https de la api de Telegram

Segun la pagina:
https://curl.haxx.se/libcurl/c/libcurl-tutorial.html

libcurl can be built and customized in many ways. One of the things that varies from different libraries and builds is the support for SSL-based transfers, like HTTPS and FTPS. If a supported SSL library was detected properly at build-time, libcurl will be built with SSL support. To figure out if an installed libcurl has been built with SSL support enabled, use 'curl-config' like this:
$ curl-config --feature
And if SSL is supported, the keyword 'SSL' will be written to stdout, possibly together with a few other features that could be either on or off on for different libcurls.

Realmente no se que nivel de seguridad quierad pero si lo que estas planteando es facilitarte la vida con las diferentes conexiones y protocolos recomiendo ampliamente libcurl


Saludos

[Kaxperday]

Hola gracias por las respuestas,

Para plaintext si puedes usar solo sockets supongo que será mejor que cualquier librería, respecto a eficiencia de código y peso.

En mi caso mi proyecto usa conexiones SSL, pero también quiero usar funciones de cifrado como 3DES, podría matar dos pájaros de un tiro con OpenSSL, pero el peso del ejecutable sería mucho mayor, y no me interesa.

CURL entonces lo usaré fijo, y para cifrar ¿conocéis algun cifrado con la winapi?, me refiero a cifrados que usen CBC que es el más seguro, ¿no kubox? XD, aunque para enviar datos por HTTP quizás lo mejor sea RC4 que es simple y ligero aunque menos seguro.

Pues la idea es intercambiar datos entre cliente y server de manera cifrada y segura, podrán ver las cabeceras, pero el body que vaya cifrado punto a punto, no se por cual decantarme.

No se si se podrá hacer ahí algún juego con RSA, pero molaría bastante. En plan pasarle la pública al cliente y descifrar con la privada (y si sin CAs la seguridad es de risa pero mejor que  nada).

De todas maneras.. los CAs son entidades de terceros que validan servidores HTTPs entre otras cosas, esas CAs supongo que serán servidores, esos servidores supongo que tendrán un dominio, si hacemos DNS spoofing a ese dominio, no podremos dar validez a cecrtificados falsos? (y si esto se va algo de tema) XD, yo creo que es posible.

Saludos.

[AlbertoBSD]

Tambien he programado algunos clientes y servidores simples pero con cifrado como la planteas la idea seria combinar libCurl y alguna libreria criptogradica como libgcrypt, desconozco el Peso de la libreria asi como lo mencionas estatica

https://www.gnu.org/software/libgcrypt/

Puedes con dicha libreria programar cuan cual metodo de cifrado ya sea simetrico o asimetrico.

RSA es muy pesado para comunicaciones cliente y servidor, pero podrias basarte en lo que hacen los demas programas como el Whatsapp u otros seria que cada cliente genere su par de llaves y con eso solo cifren la clave que se usara para alguno de los otros metdoso de cifrado simetrico como AES256 o el que gustes usar.

mas sobre ese tema.

https://foro.elhacker.net/criptografia/whatsapp_criptografia_endtoend-t450526.0.html

Saludos

[kub0x]

Te detallo el criptosistema que deberías implementar (todo ello con OpenSSL):

Para realizar una conexión segura debes cumplir con la autenticación, integridad y confidencialidad. El tema es que la crypto simétrica (AES,TDES,RC4 etc) se ocupa de la integridad y la confidencialidad, pero la autenticación en internet sólo se logra compartiendo una clave simétrica que ambos dos conoceís, para ello debes usar certificados x509v3 o una estrategia mejor, el key pinning (ya que sólo tendrás un certificado).

¿Y que es el key pinning? Bueno empresas como google, yahoo, microsoft etc tienen docenas de certificados para sus dominios y subdominios. En tal caso la verificación de certificados tiene sentido, pero en el tuyo, siempre enviarás el mismo certificado, así que es mejor hardcodear/bindear/pinear la clave en el equipo del cliente, y así no tienes que enviar ningún certificado. Hazme caso, lo mejor en internet es de antemano saber la clave del otro, al estilo SSH.

¿RSA, DSA, ECDSA, ECDHE, PRF wtf is this? Bueno, en tu protocolo tendrás que utilizar una suite criptográfica que provea de los tres principios citados arriba. El más simple es usar RSA para intercambiar la clave de sesión, ahi con la PRF se deriva la master key y luego con la misma PRF la clave de sesión y de integridad. Vamos que si no te quieres complicar emplea RSA para negociar la clave AES_CTR. Cifrar con CBC es seguro también teniendo en cuenta el padding, bueno OpenSSL ya la cagó hace tiempo con esto, supongo que usar CBC no implica riesgo, me gusta mas GCM porque es como usar un algoritmo MAC de integridad todo en uno.

Personalmente te recomiendo TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256. Donde ECDHE (Eliptic curve diffie hellman) es el algoritmo de key exchange, RSA es el algoritmo de verificación de la firma digital sobre los parametros ECDHE, AES 256 GCM (Galois counter mode) es el algoritmo de cifrado simétrico que ya provee de integridad y SHA256 como PRF (Pseudo Random Permutation). La PRF se usará en el campo Finished del TLS Handshake para verificar que no hay MITM.

Con este sistema obviamente dependerías de la lib OpenSSL, pero teoricamente es 100% seguro, por el momento.

Saludos!

EDIT: El tema debería moverse a Criptografía.