Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Journal : Hardcore mouling en environnement hostile

Posté par L (page perso, ) le 23 février 2008

En plein développement de la prochaine révolution informatique de ce troisième millénaire nommée GCoinCoin, The Next Generation Hardcore Mouling Agent, j'étais penché comme la tour de Pise sur le support de HTTPS dans GCoinCoin pour implémenter le Secure Hardcore Mouling le plus efficace afin de survivre dans les environnements les plus hostiles. Alors que j'étais fatigué et que j'allais m'écrouler lamentable comme les deux tours du WTC, voilà-t-il pas que je me rends compte soudainement que HTTPS n'est rien d'autre d'un dialogue HTTP encapsulé dans une connexion SSL/TLS. Ça m'a profondément choqué, j'étais abasourdi : comment peut-on permettre une chose aussi simple en février 2008 ? En janvier ou en mars 2008, passe encore, mais en février 2008, rendez-vous compte ! Je ne comprends pas. Bref, là n'est pas le débat de toute façon ...

Donc suite à cette trouvaille, pif, paf, pouf, tout s'enchaîne à une vitesse aussi allaitante que les nibards nus de Valérie Bègue nue sur la plage : je prends les informations au fin fond de ma mémoire, j'analyse, je synthétise, j'agrège, et finalement, je résulte ! Qui dit SSL/TLS, dit STunnel, un fabuleux outil qui permet de rediriger en cryptant via SSL/TLS un flux réseau. Avec STunnel, n'importe quel Mouling Agent ne supportant pas HTTPS permet tout de même de hardcore-mouler en milieu hostile pour assurer la survie de la moule !

Mise en situation. Soit une moule M qui veut hardcore-mouler sur les deux seules tribunes actuelles qui permettent de survivre en environnement hostile : 1) la tribune d'identifiant "dlfp" accessible en HTTPS via dlfp.org:443 et 2) la tribune d'identifiant "jplop" accessible en HTTPS via tifauv.homeip.net:8443 Grâce à ces informations top-moulesques, il suffit de créer un petit fichier hardcore-mouling.conf qu'on donnera à miamer à STunnel et dont voici le contenu utile et nécessaire :

; hardcore-mouling.conf
; Efficient Hardcore Mouling With STunnel
; Provided by GCoinCoin International LTD GmBh Inc.

; stunnel ne se détachera pas du terminal et ne passera
; pas en mode démoniaque. j'aime bien me rappeler qu'une
; commande tourne et je préfère avoir ses messages sur 
; la console qu'inonder mes logs, surtout quand la
; commande est lancée pour être aussi bavarde qu'une
; femme.
foreground = yes
pid = /tmp/stunnel.pid
; Au début, ça ne fait pas de mal d'avoir autant d'infos
; que possible pour tracer les éventuels problèmes. 
; Ensuite, commentez cette ligne.
debug = 7
; Notez qu'on force à TLSv1 sans quoi STunnel utilise
; SSLv3 qui merdoit ici et là. De source bien informée,
; on me signale que c'est probablement la faute à
; Jérôme Kerviel. À suivre.
sslVersion = TLSv1
; Pour ne pas avoir de compression, commentez la
; ligne suivante :
compression = zlib

; On nomme les tunnels avec les identifiant des tribunes
; dans les Mouling Agent : ces [noms] sont utilisés
; par stunnel pour les messages d'infos et d'erreur :
; c'est pas inutile de garder la correspondance 
; quand on a plusieurs tunnels :)

[dlfp] 
client = yes
accept = localhost:4200
connect = linuxfr.org:443
TIMEOUTclose = 0

[jplop]
client = yes
accept = localhost:4201
connect = tifauv.homeip.net:8443
TIMEOUTclose = 0

Ensuite, vous lancez l'exécutable STunnel via la commande :

stunnel hardcore-mouling.conf

Et enfin, vous créez une tribune "dlfp" dans votre Mouling Agent dont l'hôte est "localhost" et le port 4200 (bref, ce que vous avez mis/choisi dans la section [dlfp] de votre hardcore-mouling.conf) et une tribune "jplop" dont l'hôte est "localhost" et le port 4201. Et voilà, à vous les joies du Secure Hardcore Mouling en milieu hostile ! Notez que ça devrait fonctionner avec pyc² et wmc², et que ça juste travaille sous Linux et Win32 avec ce fabuleux Mouling Agent qu'est GCoinCoin qui devrait sortir la tête bientôt.

Pour les utilisateurschanceux de cette fabuleuse distribution GNU/Linux qu'est Ubuntu, utilisez la commande stunnel4 disponible via le paquetage stunnel4 et non pas le script stunnel. Pour les autres distributions, assurez-vous d'utiliser la commande stunnel appropriée qui DOIT être l'exécutable guenuine de STunnel, et non pas un wrapper-script à la noix de pécan comme savent le faire les distributions qui forkent à tout va les logiciels sous prétexte d'intégration (n'hésitez pas à utiliser la commande file /chemin/vers/ledit/stunnel pour vous assurer qu'il s'agit d'un exécutable ELF et non pas un script PERL ou SH).

Pour plus de renseignement sur le fichier de configuration de STunnel, consultez sa fabuleuse documentation :

-> http://www.stunnel.org/faq/stunnel.html#configuration_file

Notez que cette configuration ne vérifie pas le certificat : je publierai ultérieurement un autre journal sur la possibilité d'utiliser un certificat local pour valider l'authenticité de chaque tunnel TLSv1, mais pour l'instant, je rame comme un bureau GNOME. Si quelqu'un a une solution qui marche et qu'il a testé de lui-même (parce que bon si c'est pour me ressortir ce qu'il a lu dans la documentation de STunnel et que j'ai lue 42 fois, non merci), je suis preneur : pour l'instant, j'ai réussi à récupérer les certificats *.pem des sites (merci à mortimer< pour le plugin Firefox Cert Viewer Plus) mais l'utilisation pour chaque tunnel des directives cert=/chemin/vers/fichier.pem et verify=3 (pour une vérification locale du certificat) ne fonctionne pas.

Voilà, j'ai presque tout dit. Sinon GCoinCoin avance. Pour l'instant, il supporte les proxies HTTP sans authentification ou avec identification Basic, mais pas avec l'identification Digest vu qu'aucune moule ne semble avoir ce besoin. Je suis actuellement en train d'implémenter le Socks4/4a et peut-être Socks5 si des moules manifestent ce besoin. Donc aux moules qui hardcore-moulent ou veulent hardcore-mouler derrière un proxy, merci de profiter de ce journal pour me dire quel type de proxy vous utilisez (HTTP avec/sans authentification Basic/Digest, Proxy Socks4/4a/5).

Voilà, je rends l'antenne : merci de votre attention et à vous les studios _o/

> Lire le journal (9 commentaires, moyenne: 4,4).  

Vous avez demandé le commentaire #908973.

well

Posté par mortimer () le 28/02/2008 à 23:06. (lien). Évalué à 2.

ça juste marche chez moi aussi, mais n'étant pas hardcore-mouleur, j'ai testé avec firefox.
Il est d'ailleurs surprenant de constater que la redirection (linuxfr.org -> linuxfr.org/pub/) ne fonctionne pas et sort un obscur code d'erreur -12263 sur linuxfr, et un timeout chez Tif. Le https serait-il un peu plus que du simple http sur une connexion ssl ?

A part ça, je n'ai pas trop compris ce que tu voulais obtenir avec la directive cert=... de stunnel. D'après ce que je comprends de la doc de stunnel, cette directive sert à spécifier un certificat pour faire une authentification cliente. Or, ni linuxfr, ni tifauv ne la demandent (ça serait pourtant une killer-feature, ça, l'authentification des moules par certificat...).

  • [^]Re: well

    Posté par L (page perso, ) le 29/02/2008 à 12:39. (lien). Évalué à 2.

    « ça juste marche chez moi aussi, mais n'étant pas hardcore-mouleur, j'ai testé avec firefox.
    Il est d'ailleurs surprenant de constater que la redirection (linuxfr.org -> linuxfr.org/pub/) ne fonctionne pas et sort un obscur code d'erreur -12263 sur linuxfr, et un timeout chez Tif. Le https serait-il un peu plus que du simple http sur une connexion ssl ?
    »

    En fait, ça fonctionne avec LinuxFr et Tifounet ... par chance :) En effet, ce que je ne précise pas pour ne pas tomber dans le trop-technique inutile, c'est que si le client HTTP utilisant le tunnel n'est pas conscient que ses requêtes transitent par un tunnel, dans le cas de plusieurs VirtualHost distingué par le hostname sur la même adresse IP, lesdits clients enverraient leur requêtes HTTP avec un "Host: localhost" et la résolution du VirtualHost ne fonctionnerait pas.

    Pour GCoinCoin, il y a un mode "tunnel" ou GCoinCoin se connecte au niveau TCP à STunnel localhost:port tout en envoyant les requêtes HTTP avec le bon "Host:" comme si il se connectait directement au site. pyc² et wmc² ne font pas cela et ça pourrait merder sur certaines tribunes HTTPS (mais bon, pour l'instant à part LinuxFr et Tifauv, il me semble qu'il n'y en ait pas d'autres).

    « A part ça, je n'ai pas trop compris ce que tu voulais obtenir avec la directive cert=... de stunnel. D'après ce que je comprends de la doc de stunnel, cette directive sert à spécifier un certificat pour faire une authentification cliente. Or, ni linuxfr, ni tifauv ne la demandent (ça serait pourtant une killer-feature, ça, l'authentification des moules par certificat...). »

    L'idée, c'est d'importer le certifcat de DLFP en fichier .pem depuis Firefox et de faire vérifier par stunnel à la connection que le certificat renvoyé par le serveur correspond à celui reçu antérieurement. Enfin, je ne connais pas assez le fonctionnement réel de HTTPS avec les cerifcats et je suis preneur de toute information me permettant d'améliorer mes connaissances sur le sujet :)

    • [^]Re: well

      Posté par Olivier Serve (Jabber id, page perso, ) le 29/02/2008 à 20:55. (lien). Évalué à 5.

      Un petit rappel sur les certificats d'abord.

      = 1. Certificats =
      SSL repose sur des bi-clés :
      - une clé privée utilisée pour déchiffrer ou signer ;
      - une clé publique associée qui permet de chiffrer ou vérifier une signature.

      Une clé publique seule n'identifie rien du tout. C'est pour cela qu'on les distribue dans un certificat. Un certificat lie une identité à une clé publique. On y trouve :
      - l'identité du sujet du certificat (personne, site web...) ;
      - la clé publique ;
      - les dates de validité ;
      - une signature par une autorité de confiance ;
      - des trucs en plus (restrictions d'utilisation, photos, adresse mail)...
      La clé privée associée doit être conservée au chaud et jamais divulguée. Un certificat par contre peut être distribué sans problème, il est fait pour ça.

      Un certificat auto-signé n'est pas signé par une autorité externe mais par lui-même. C'est pratique pour les tests, mais pas vraiment en prod. C'est comme arriver dans un aéroport avec un passeport disant "Je certifie que je suis moi !". C'est le meilleur moyen de se faire refouler.

      = 2. SSL =
      Bien, passons maintenant à SSL. SSL dispose de 2 modes :
      1. authent serveur uniquement (le plus utilisé) ;
      2. authent mutuelle.

      == 2.1 SSL serveur ==
      Seul le serveur possède un certificat. Lors de la négociation SSL, le client vérifie que le certificat du serveur est signé par une autorité de confiance. Dans le cas des 2 tribunes citées ici, ce sont les certificats des autorités class1 et class3 de CACert.org.

      Il y a également une histoire de preuve de possession qui permet au serveur de justifier qu'il possède bien la clé privée associée au certificat.

      En bref : le client authentifie le serveur. C'est tout. C'est le mode utilisé en grande majorité sur les sites web (paiement en ligne notamment).

      == 2.2 SSL complet ==
      Là, les 2 parties (client et serveur) possèdent un certificat. Chacun a également une liste des autorités reconnues. De même que précédemment, le client authentifie le serveur ; mais en plus, le serveur authentifie le client.
      Ça permet au serveur de savoir qui lui parle immédiatement. Et c'est autrement plus sûr qu'une authent HTTP Basic...

      Voilà voilà, j'ai sans doute oublié des choses, mais une partie d'ETQW m'attends...