Bonjour à tous,
J'ai developpé un petit soft serveur/clients en C qui permet
d'echanger des fichiers et de s'envoyer des messages. Tous les clients
passent par le serveur pour communiquer.
Maintenant, je recherche des solutions pour crypter toutes les
communications TCP entre les clients et le serveur. Je developpe sous
Linux debian, j'ai bien sur installé OpenSSL et je compte utiliser ses
libraires pour crypter les données.
Je sais qu'il existe plusieurs types de cryptages pour chiffrer les
communications TCP. Celui que je compte utiliser est le cryptage
symétrique (AES), mais à ce moment là je sais pas du tout comment
faire pour échanger la clé secrète de session.
J'ai vu que Diffie-Hellman pouvait etre une solution. Cependant, il ne
garantie pas l'identité du destinataire et donc est sensible a MIM
attaque.
Il existe aussi une autre solution pour échanger la clé secrètre,
c'est celle qu'utilise SSL. On crypte alors la clé secrète avec du RSA
pour la transmettre. Cette solution m'interesse beaucoups aussi.
J'ai aussi pensé à utiliser une architecture PKI. Le serveur qui relie
les clients serai alors le CA ( authorite de certification ). Au
moment de la connexion, le serveur transmet son certificat auto-signé
au client, le certificat contient la clé publique du serveur. Cette
clé permettra de transemttre la clé symétrique de session. Je demande
donc aux conaisseurs de cryptographie de me donner quelques conseils:
-Quelle solution retenir ?
-Est ce que je peux utiliser directement SSL sans ralentir le debit du
traffic ?
-Comment implémenter de l'AES pour crypter du TCP.
-Est ce que c'est facile d'utiliser les libraires d'OpenSSL pour
réalier tout ca?
-Connaisez vous des livres ou des liens ou je peux trouver quelque
chose de similaire ?
-Que sera l'impact sur les performances des échanges entres
clients/serveur ?
-Quelles sont les solutions pour garantir l'authentification avec DH ?
Arf je pensé que le premier message a ete effacé. Mici pour ta reponse si rapide !! Sinon qu'entends tu par
vérification du certificat du serveur par rapport à ta liste d'AC en local
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer bcps de choses dans mon programme car j'ai mis en place une couche au dessus de la pile socket. Comme ca j'ai des appels simple pour echanger les données entre les utilisateurs. Comme je n'ai pas trop envie de modifier ce travail, je pose la question. Donc apparament c'est possible mais ce n'est pas trés pratique.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour crypter la clé symétrique afin de se l'echanger. DH me semblais aussi pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas à grand chose vu que le premier echange reste toujours sensible à MIM.
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour crypter mes données je risque d'etre confronté à :
- (re)synchronisation - transport ou génération de clés - taille des messages (et padding adéquat) - transmission d'informations off-band (suppose la création d'un canal
pour tes données et d'un autre pour des infos de contrôle) - vérification de l'identité de l'hôte distant
Si j'utilise SSL je dois repenser toute la couche communications de mon programme ( du moins si je passe pas BIO ).
Arf je pensé que le premier message a ete effacé. Mici pour ta
reponse si rapide !!
Sinon qu'entends tu par
vérification du certificat du serveur par rapport à ta liste d'AC en
local
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer
bcps de choses dans mon programme car j'ai mis en place une couche au
dessus de la pile socket. Comme ca j'ai des appels simple pour echanger
les données entre les utilisateurs. Comme je n'ai pas trop envie de
modifier ce travail, je pose la question. Donc apparament c'est
possible mais ce n'est pas trés pratique.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour
crypter la clé symétrique afin de se l'echanger. DH me semblais aussi
pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas
à grand chose vu que le premier echange reste toujours sensible à
MIM.
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour
crypter mes données je risque d'etre confronté à :
- (re)synchronisation
- transport ou génération de clés
- taille des messages (et padding adéquat)
- transmission d'informations off-band (suppose la création d'un
canal
pour tes données et d'un autre pour des infos de contrôle)
- vérification de l'identité de l'hôte distant
Si j'utilise SSL je dois repenser toute la couche communications de
mon programme ( du moins si je passe pas BIO ).
Arf je pensé que le premier message a ete effacé. Mici pour ta reponse si rapide !! Sinon qu'entends tu par
vérification du certificat du serveur par rapport à ta liste d'AC en local
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer bcps de choses dans mon programme car j'ai mis en place une couche au dessus de la pile socket. Comme ca j'ai des appels simple pour echanger les données entre les utilisateurs. Comme je n'ai pas trop envie de modifier ce travail, je pose la question. Donc apparament c'est possible mais ce n'est pas trés pratique.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour crypter la clé symétrique afin de se l'echanger. DH me semblais aussi pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas à grand chose vu que le premier echange reste toujours sensible à MIM.
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour crypter mes données je risque d'etre confronté à :
- (re)synchronisation - transport ou génération de clés - taille des messages (et padding adéquat) - transmission d'informations off-band (suppose la création d'un canal
pour tes données et d'un autre pour des infos de contrôle) - vérification de l'identité de l'hôte distant
Si j'utilise SSL je dois repenser toute la couche communications de mon programme ( du moins si je passe pas BIO ).
Erwann ABALEA
Bonjour,
On Fri, 18 Mar 2005 wrote:
Sinon qu'entends tu par
vérification du certificat du serveur par rapport à ta liste d'AC en local
C'est comme ça que marche le X.509. Ton client a dans sa config une liste de certificats dits d'AC. La confiance accordée dans ces certificats est explicite, et ne vient que du fait qu'ils sont déclarés comme ça. Quand ton client se connecte au serveur, celui-ci renvoit son certificat, et le client devra vérifier ce certificat présenté et s'assurer qu'il y a bien un chaînage correct vers un des certificats d'AC. Si tu décides que ton serveur a un certificat autosigné, pour que cette vérification passe, il faut que ton client considère que le certificat du serveur est un certificat d'AC (ce sera un peu vrai).
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer bcps de choses dans mon programme car j'ai mis en place une couche au dessus de la pile socket. Comme ca j'ai des appels simple pour echanger les données entre les utilisateurs. Comme je n'ai pas trop envie de modifier ce travail, je pose la question. Donc apparament c'est possible mais ce n'est pas trés pratique.
Mouais. A coups de BIO_set_callback(), peut-être, ou alors tu fais du SSL sur un BIO_mem, et tu te débrouilles pour que ton application fasse les transferts qui vont bien, en lisant et écrivant dans ton BIO_mem. Un peu bancal, mais bon.
Sinon, tu oublies OpenSSL, et tu utilises MatrixSSL, qui supporte ce genre de choses.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour crypter la clé symétrique afin de se l'echanger. DH me semblais aussi pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas à grand chose vu que le premier echange reste toujours sensible à MIM.
Non. Si le client et le serveur ont quelque chose en commun (un secret, ou un tiers qui certifie leur identité), alors le MITM ne tient pas, que tu fasses du RSA, du DSS, du DH, de l'AES natif, ...
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour crypter mes données je risque d'etre confronté à :
- (re)synchronisation - transport ou génération de clés - taille des messages (et padding adéquat) - transmission d'informations off-band (suppose la création d'un canal
pour tes données et d'un autre pour des infos de contrôle) - vérification de l'identité de l'hôte distant
Ben oui. Tu veux définir un nouveau protocole, tu es confronté à tout ça, c'est pas magique.
Si j'utilise SSL je dois repenser toute la couche communications de mon programme ( du moins si je passe pas BIO ).
Non. Si tu utilises OpenSSL, tu auras ce genre de problèmes, à moins d'être barbu et de savoir lire les sources d'OpenSSL (auquel cas tu pourras définir ton propre type de BIO pour tes sockets et appliquer un BIO_ssl dessus). Mais si tu trouves une autre bibliothèque que implémente le SSL et te permet d'utiliser facilement tes primitives au dessus des sockets, tu n'auras pas grand chose à changer.
Et même si tu choisis OpenSSL, je suppose que tu as défini des fonctions pour lire et écrire à travers une connexion (pour tenter de faire abstraction du socket), ben tu n'auras que ces 2 fonctions à changer, et OpenSSL permet de faire ça simplement (BIO_read, BIO_write, avec un peu d'initialisation selon tes besoins). Je pense que si tu as fais les choses proprement, appliquer une couche d'OpenSSL dessus ne devrait pas être si difficile que ça.
Nous recherchons une streap-teaseuse confirmée pour animer des dîners dansants en région parisienne. Cette offre est sérieuse. Email pour premier contact : Tél Philippe : 0142458XXX -+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
Bonjour,
On Fri, 18 Mar 2005 skalli14@yahoo.fr wrote:
Sinon qu'entends tu par
vérification du certificat du serveur par rapport à ta liste d'AC en
local
C'est comme ça que marche le X.509. Ton client a dans sa config une liste
de certificats dits d'AC. La confiance accordée dans ces certificats est
explicite, et ne vient que du fait qu'ils sont déclarés comme ça.
Quand ton client se connecte au serveur, celui-ci renvoit son certificat,
et le client devra vérifier ce certificat présenté et s'assurer qu'il y a
bien un chaînage correct vers un des certificats d'AC.
Si tu décides que ton serveur a un certificat autosigné, pour que cette
vérification passe, il faut que ton client considère que le certificat du
serveur est un certificat d'AC (ce sera un peu vrai).
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer
bcps de choses dans mon programme car j'ai mis en place une couche au
dessus de la pile socket. Comme ca j'ai des appels simple pour echanger
les données entre les utilisateurs. Comme je n'ai pas trop envie de
modifier ce travail, je pose la question. Donc apparament c'est
possible mais ce n'est pas trés pratique.
Mouais. A coups de BIO_set_callback(), peut-être, ou alors tu fais du SSL
sur un BIO_mem, et tu te débrouilles pour que ton application fasse les
transferts qui vont bien, en lisant et écrivant dans ton BIO_mem. Un peu
bancal, mais bon.
Sinon, tu oublies OpenSSL, et tu utilises MatrixSSL, qui supporte ce genre
de choses.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour
crypter la clé symétrique afin de se l'echanger. DH me semblais aussi
pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas
à grand chose vu que le premier echange reste toujours sensible à
MIM.
Non. Si le client et le serveur ont quelque chose en commun (un secret, ou
un tiers qui certifie leur identité), alors le MITM ne tient pas, que tu
fasses du RSA, du DSS, du DH, de l'AES natif, ...
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour
crypter mes données je risque d'etre confronté à :
- (re)synchronisation
- transport ou génération de clés
- taille des messages (et padding adéquat)
- transmission d'informations off-band (suppose la création d'un
canal
pour tes données et d'un autre pour des infos de contrôle)
- vérification de l'identité de l'hôte distant
Ben oui. Tu veux définir un nouveau protocole, tu es confronté à tout ça,
c'est pas magique.
Si j'utilise SSL je dois repenser toute la couche communications de
mon programme ( du moins si je passe pas BIO ).
Non. Si tu utilises OpenSSL, tu auras ce genre de problèmes, à moins
d'être barbu et de savoir lire les sources d'OpenSSL (auquel cas tu
pourras définir ton propre type de BIO pour tes sockets et appliquer un
BIO_ssl dessus).
Mais si tu trouves une autre bibliothèque que implémente le SSL et te
permet d'utiliser facilement tes primitives au dessus des sockets, tu
n'auras pas grand chose à changer.
Et même si tu choisis OpenSSL, je suppose que tu as défini des fonctions
pour lire et écrire à travers une connexion (pour tenter de faire
abstraction du socket), ben tu n'auras que ces 2 fonctions à changer, et
OpenSSL permet de faire ça simplement (BIO_read, BIO_write, avec un peu
d'initialisation selon tes besoins). Je pense que si tu as fais les choses
proprement, appliquer une couche d'OpenSSL dessus ne devrait pas être si
difficile que ça.
Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : gxxxx@club-internet.fr Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
vérification du certificat du serveur par rapport à ta liste d'AC en local
C'est comme ça que marche le X.509. Ton client a dans sa config une liste de certificats dits d'AC. La confiance accordée dans ces certificats est explicite, et ne vient que du fait qu'ils sont déclarés comme ça. Quand ton client se connecte au serveur, celui-ci renvoit son certificat, et le client devra vérifier ce certificat présenté et s'assurer qu'il y a bien un chaînage correct vers un des certificats d'AC. Si tu décides que ton serveur a un certificat autosigné, pour que cette vérification passe, il faut que ton client considère que le certificat du serveur est un certificat d'AC (ce sera un peu vrai).
Pour ce qui est d'utiliser BIO, si je fais ce choix, je devrai changer bcps de choses dans mon programme car j'ai mis en place une couche au dessus de la pile socket. Comme ca j'ai des appels simple pour echanger les données entre les utilisateurs. Comme je n'ai pas trop envie de modifier ce travail, je pose la question. Donc apparament c'est possible mais ce n'est pas trés pratique.
Mouais. A coups de BIO_set_callback(), peut-être, ou alors tu fais du SSL sur un BIO_mem, et tu te débrouilles pour que ton application fasse les transferts qui vont bien, en lisant et écrivant dans ton BIO_mem. Un peu bancal, mais bon.
Sinon, tu oublies OpenSSL, et tu utilises MatrixSSL, qui supporte ce genre de choses.
Je revien donc a mon message initiale, qui est d'utiliser le RSA pour crypter la clé symétrique afin de se l'echanger. DH me semblais aussi pas mal, mais il faut l'associer au DSS et je trouve que ca ne sere pas à grand chose vu que le premier echange reste toujours sensible à MIM.
Non. Si le client et le serveur ont quelque chose en commun (un secret, ou un tiers qui certifie leur identité), alors le MITM ne tient pas, que tu fasses du RSA, du DSS, du DH, de l'AES natif, ...
Je suis donc un peu bloquer car si j'utilise le principe de SSL pour crypter mes données je risque d'etre confronté à :
- (re)synchronisation - transport ou génération de clés - taille des messages (et padding adéquat) - transmission d'informations off-band (suppose la création d'un canal
pour tes données et d'un autre pour des infos de contrôle) - vérification de l'identité de l'hôte distant
Ben oui. Tu veux définir un nouveau protocole, tu es confronté à tout ça, c'est pas magique.
Si j'utilise SSL je dois repenser toute la couche communications de mon programme ( du moins si je passe pas BIO ).
Non. Si tu utilises OpenSSL, tu auras ce genre de problèmes, à moins d'être barbu et de savoir lire les sources d'OpenSSL (auquel cas tu pourras définir ton propre type de BIO pour tes sockets et appliquer un BIO_ssl dessus). Mais si tu trouves une autre bibliothèque que implémente le SSL et te permet d'utiliser facilement tes primitives au dessus des sockets, tu n'auras pas grand chose à changer.
Et même si tu choisis OpenSSL, je suppose que tu as défini des fonctions pour lire et écrire à travers une connexion (pour tenter de faire abstraction du socket), ben tu n'auras que ces 2 fonctions à changer, et OpenSSL permet de faire ça simplement (BIO_read, BIO_write, avec un peu d'initialisation selon tes besoins). Je pense que si tu as fais les choses proprement, appliquer une couche d'OpenSSL dessus ne devrait pas être si difficile que ça.
Nous recherchons une streap-teaseuse confirmée pour animer des dîners dansants en région parisienne. Cette offre est sérieuse. Email pour premier contact : Tél Philippe : 0142458XXX -+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
skalli14
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de client/Serveur sur http://www.rtfm.com/sslbook/examples/
Et en regardant le code, les appels BIO vienent apres la création de socket ce qui est trés bon pour mon programme. J'ai toujours pas bien compris à quoi correspondait l'objet BIO, mais je pense que je pourrais l'utiliser sans trop modifier mon code. Il existe meme une fonction SSL qui prend un file descriptor ( socket ) et c'est trés pratique...
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me servir... Enfin, je reste ouvert à toute suggestion
Bon weekend
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de
client/Serveur sur http://www.rtfm.com/sslbook/examples/
Et en regardant le code, les appels BIO vienent apres la création de
socket ce qui est trés bon pour mon programme. J'ai toujours pas bien
compris à quoi correspondait l'objet BIO, mais je pense que je
pourrais l'utiliser sans trop modifier mon code. Il existe meme une
fonction SSL qui prend un file descriptor ( socket ) et c'est trés
pratique...
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me
servir...
Enfin, je reste ouvert à toute suggestion
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de client/Serveur sur http://www.rtfm.com/sslbook/examples/
Et en regardant le code, les appels BIO vienent apres la création de socket ce qui est trés bon pour mon programme. J'ai toujours pas bien compris à quoi correspondait l'objet BIO, mais je pense que je pourrais l'utiliser sans trop modifier mon code. Il existe meme une fonction SSL qui prend un file descriptor ( socket ) et c'est trés pratique...
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me servir... Enfin, je reste ouvert à toute suggestion
Bon weekend
Erwann ABALEA
On Fri, 18 Mar 2005 wrote:
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de client/Serveur sur http://www.rtfm.com/sslbook/examples/
Si tu as les sources d'OpenSSL, il y a beaucoup d'exemples (ré)utilisables.
Et en regardant le code, les appels BIO vienent apres la création de socket ce qui est trés bon pour mon programme. J'ai toujours pas bien
On peut faire comme ça, on peut faire autrement. L'avantage d'une API 'monstrueuse' comme l'est celle d'OpenSSL, c'est que l'adage associé traditionnellement à Perl s'applique aussi ici: "there's more than one way to do it".
compris à quoi correspondait l'objet BIO, mais je pense que je
BIOºsic Input Output. C'est une abstraction. Derrière, tu mets ce que tu veux: SSL, chiffrement, encodage base64, calcul d'empreinte, fichier, mémoire, ... Tu peux en chaîner plusieurs pour réaliser plusieurs opérations, soit parce que tu n'es intéressé que par l'opération finale (par exemple un chiffrement suivi d'un encodage base64 redirigé vers un fichier: 3 BIOs chaînés), soit parce que tu veux plusieurs résultats en même temps (par exemple pour signer un message PKCS#7 avec données non détachées, tu dois calculer l'empreinte et en même temps stocker les données dans ton objet: 2 BIOs).
pourrais l'utiliser sans trop modifier mon code. Il existe meme une fonction SSL qui prend un file descriptor ( socket ) et c'est trés pratique...
Oui. Note que ça ne te permettra pas d'utiliser tes propres wrappers, mais ça reste très simple d'utilisation (contrairement à ce que certains trolleurs souhaitent affirmer :)).
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me servir...
Attention, c'est soit GPL, soit commercial, pas LGPL. Si c'est pour un projet professionnel, c'est à prendre en compte.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je parlais au nom de tous les frjviens, ne joue pas au con... VOUS n'avez pas à détruire NOTRE ng. C'est clair comme ça ou il faut que je te l'explique avec des mots plus faciles encore ? -+- in Guide du Neuneu d'Usenet - Mon niouzegroup à moi ke G -+-
On Fri, 18 Mar 2005 skalli14@yahoo.fr wrote:
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de
client/Serveur sur http://www.rtfm.com/sslbook/examples/
Si tu as les sources d'OpenSSL, il y a beaucoup d'exemples
(ré)utilisables.
Et en regardant le code, les appels BIO vienent apres la création de
socket ce qui est trés bon pour mon programme. J'ai toujours pas bien
On peut faire comme ça, on peut faire autrement. L'avantage d'une API
'monstrueuse' comme l'est celle d'OpenSSL, c'est que l'adage associé
traditionnellement à Perl s'applique aussi ici: "there's more than one
way to do it".
compris à quoi correspondait l'objet BIO, mais je pense que je
BIOºsic Input Output. C'est une abstraction. Derrière, tu mets ce que tu
veux: SSL, chiffrement, encodage base64, calcul d'empreinte, fichier,
mémoire, ... Tu peux en chaîner plusieurs pour réaliser plusieurs
opérations, soit parce que tu n'es intéressé que par l'opération finale
(par exemple un chiffrement suivi d'un encodage base64 redirigé vers un
fichier: 3 BIOs chaînés), soit parce que tu veux plusieurs résultats en
même temps (par exemple pour signer un message PKCS#7 avec données non
détachées, tu dois calculer l'empreinte et en même temps stocker les
données dans ton objet: 2 BIOs).
pourrais l'utiliser sans trop modifier mon code. Il existe meme une
fonction SSL qui prend un file descriptor ( socket ) et c'est trés
pratique...
Oui. Note que ça ne te permettra pas d'utiliser tes propres wrappers, mais
ça reste très simple d'utilisation (contrairement à ce que certains
trolleurs souhaitent affirmer :)).
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me
servir...
Attention, c'est soit GPL, soit commercial, pas LGPL. Si c'est pour un
projet professionnel, c'est à prendre en compte.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je parlais au nom de tous les frjviens, ne joue pas au con... VOUS
n'avez pas à détruire NOTRE ng. C'est clair comme ça ou il faut que je
te l'explique avec des mots plus faciles encore ?
-+- in Guide du Neuneu d'Usenet - Mon niouzegroup à moi ke G -+-
Merci bcps pour toutes ces précisions. J'ai trouvé un exemple de client/Serveur sur http://www.rtfm.com/sslbook/examples/
Si tu as les sources d'OpenSSL, il y a beaucoup d'exemples (ré)utilisables.
Et en regardant le code, les appels BIO vienent apres la création de socket ce qui est trés bon pour mon programme. J'ai toujours pas bien
On peut faire comme ça, on peut faire autrement. L'avantage d'une API 'monstrueuse' comme l'est celle d'OpenSSL, c'est que l'adage associé traditionnellement à Perl s'applique aussi ici: "there's more than one way to do it".
compris à quoi correspondait l'objet BIO, mais je pense que je
BIOºsic Input Output. C'est une abstraction. Derrière, tu mets ce que tu veux: SSL, chiffrement, encodage base64, calcul d'empreinte, fichier, mémoire, ... Tu peux en chaîner plusieurs pour réaliser plusieurs opérations, soit parce que tu n'es intéressé que par l'opération finale (par exemple un chiffrement suivi d'un encodage base64 redirigé vers un fichier: 3 BIOs chaînés), soit parce que tu veux plusieurs résultats en même temps (par exemple pour signer un message PKCS#7 avec données non détachées, tu dois calculer l'empreinte et en même temps stocker les données dans ton objet: 2 BIOs).
pourrais l'utiliser sans trop modifier mon code. Il existe meme une fonction SSL qui prend un file descriptor ( socket ) et c'est trés pratique...
Oui. Note que ça ne te permettra pas d'utiliser tes propres wrappers, mais ça reste très simple d'utilisation (contrairement à ce que certains trolleurs souhaitent affirmer :)).
Entre temps, je vais aller voir du coté de MatrixSSL si ca peut me servir...
Attention, c'est soit GPL, soit commercial, pas LGPL. Si c'est pour un projet professionnel, c'est à prendre en compte.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je parlais au nom de tous les frjviens, ne joue pas au con... VOUS n'avez pas à détruire NOTRE ng. C'est clair comme ça ou il faut que je te l'explique avec des mots plus faciles encore ? -+- in Guide du Neuneu d'Usenet - Mon niouzegroup à moi ke G -+-
Vincent Bernat
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers 11:42, Erwann ABALEA disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de certificats côté client. La modif est peut-être triviale, je ne me suis pas penché là-dessus. -- BOFH excuse #380: Operators killed when huge stack of backup tapes fell over.
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers
11:42, Erwann ABALEA <erwann@abalea.com> disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres
projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être
suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu
de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de
certificats côté client. La modif est peut-être triviale, je ne me
suis pas penché là-dessus.
--
BOFH excuse #380:
Operators killed when huge stack of backup tapes fell over.
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers 11:42, Erwann ABALEA disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de certificats côté client. La modif est peut-être triviale, je ne me suis pas penché là-dessus. -- BOFH excuse #380: Operators killed when huge stack of backup tapes fell over.
Erwann ABALEA
On Mon, 21 Mar 2005, Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers 11:42, Erwann ABALEA disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de certificats côté client. La modif est peut-être triviale, je ne me suis pas penché là-dessus.
Exact. Il faut bien qu'il leur reste quelque chose pour leur version commerciale... :) De mémoire (à vérifier), je crois que la version GPL ne fait pas d'AES, et que la version commerciale apporte un client SSH en ligne de commande.
A part les certificats client, il est probable que le support des extensions X.509 soit limité. Rien de magique, pour faire tenir ça dans 50k de code, faut couper...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : Guide du Neuneu d'Usenet - Bien museler son neuneu -+-
On Mon, 21 Mar 2005, Vincent Bernat wrote:
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers
11:42, Erwann ABALEA <erwann@abalea.com> disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres
projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être
suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu
de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de
certificats côté client. La modif est peut-être triviale, je ne me
suis pas penché là-dessus.
Exact. Il faut bien qu'il leur reste quelque chose pour leur version
commerciale... :)
De mémoire (à vérifier), je crois que la version GPL ne fait pas d'AES, et
que la version commerciale apporte un client SSH en ligne de commande.
A part les certificats client, il est probable que le support des
extensions X.509 soit limité. Rien de magique, pour faire tenir ça dans
50k de code, faut couper...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
"Les neu^H^H^H connectés"?? Peux-tu nous en dire plus.
Autant dire que l'on veut muselé les minorités sous des prétexte
falacieux avec des méthodes dignes de la Française des jeux!!
-+- SM in : Guide du Neuneu d'Usenet - Bien museler son neuneu -+-
OoO En cette fin de matinée radieuse du vendredi 18 mars 2005, vers 11:42, Erwann ABALEA disait:
Justement, je demandais si quelqu'un avait regardé GnuTLS. Les autres projets dénoncés par Freshmeat ont l'air bien jeunes.
Il y a MatrixSSL qui existe. Léger, GPL ou commercial, ça peut être suffisant pour l'OP. J'ai envisagé de l'utiliser sur une machine avec peu de mémoire, mais bon, manque de temps, toussa, ...
Le gros problème de la version GPL est que tu ne peux pas utiliser de certificats côté client. La modif est peut-être triviale, je ne me suis pas penché là-dessus.
Exact. Il faut bien qu'il leur reste quelque chose pour leur version commerciale... :) De mémoire (à vérifier), je crois que la version GPL ne fait pas d'AES, et que la version commerciale apporte un client SSH en ligne de commande.
A part les certificats client, il est probable que le support des extensions X.509 soit limité. Rien de magique, pour faire tenir ça dans 50k de code, faut couper...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : Guide du Neuneu d'Usenet - Bien museler son neuneu -+-
