Pas mal les articles, c'est sympa :)
Je dev un projet d'OS (miniPhi) assez important sous licence GPLv3, je fais un peu de pub ici si il y a du monde chaud pour m'aider un peu !
Actuellement l'OS fonctionne sur les MCU texas instrument MSP430 mais j'ai commencé le portage pour STM32 et du coup c'est du taff :)
En fait je rend disponible les drivers que je développe pour mes besoins. Allez faire un tour dans le répertoire drivers/. Du coup ils sont portables pour n'importe quelle archi.
J'ai fait au mieux pour la doc donc un ptit coup de doxygen dans le répertoire root et on voit pas mal de truc
Je ne pense pas créer un "SPOF", peut être en ajouter … donc ca devient plus un "point of failure" ;) Les architectures traditionnelle ne sont en général pas super super safe ….
Je dirais qu'au contraire en faisant du MITM on peut trouver qui a été compromis dans le réseau.
L'utilisation de javascript permet aussi de réduire le risque de vulnérabilité dans gatejs
En gros pour le SSL une liste officielle est consolidée dans le navigateur. Ce sont les les CA qui servent à signer les clés régulières pour nos domaines. Il y a donc du Verisign, THAWTE ou encore Comodo .. ceux qui sont autorisés à signer nos certificats.
Si je veux intercepter du SSL il suffi de:
- de créer une clés
- de la signer avec mon CA
- de configurer le CA + ma clés dans gatejs
- d'installer le CA sur le device et le tour et joué
Sauf que dans certain cas, le CA de confiance est codé en dur dans l'application. Cela a pour effet de bloquer la connexion puisque le CA et CRT ne sont pas les mêmes qu'annoncés. C'est une "sécurité" de l'application pour éviter ce genre d'interception.
Non on ne peut pas dire qu'il soit obsolète ou en court d'abandon.
C'est juste un doublon avec quelques chose qui existe déjà Last-Modified If-Modified-Since… Mais qui ne décline pas une ressource précise (ce que fait ETag). Je vais essayé de le faire que quand le ETag me semble louche ;))
Oui NGINX fait le mail Squid fait aussi le FTP ou le Gopher..
Je pense que la prochaine feature de gate sera un serveur DNS.
Le proxy mail est assez simple à réaliser, je vais regarder ce que je peux faire.
J'aimerais aussi intégrer un serveurs Web complet dans gate… qui pourrait supporter pas mal de feature Apache pour migrer plus facilement…
C'est la seule chose "complexe" à comprendre en JS. Une fois passé cette étape tu verras que le scope des variables est de toute puissance. C'est pour moi la chose la plus puissante dans JS :)
Sur linuxfr, je me serais attendu, justement, à ce que ce soit développé, ce serait justement l'un des points les plus importants, les raisons et la façon dont cela a été fait. Le pourquoi du comment et toute l'histoire.
BinarySEC est une société spécialisée en sécurité informatique. Elle a été fondée en 2007, initialement nous avions développé un outils de protection des binaires pour prévenir une bonne partie des types de buffer overflow existants. Cependant après quelques mois nous nous sommes aperçu que cela serait complexe à vendre et surtout à maintenir.
Aussi nous avions remarqué que les attaques les plus violentes et les plus répandues passent par HTTP et là malheureusement l'outil de détection de BOF ne servait pas à grand chose.
Alors j'ai décidé à l'époque de penser un nouveau système de protection des sites Internet. Il fallait quelque chose de simple donc en opposition totale avec mod_security etc… J'ai donc pensé un système de corrélation sous forme d'IA faible et cela a permis d'éliminer le risque de faux positifs à hauteur de 90%.
La première implémentation était un module Apache mais rapidement on nous a demandé une solution en proxy (reverse). À l'époque il n'y avait vraiment que nginx comme solution fiable au reverse proxy, exit squid, varnish et… Apache.
Nous avons donc implémenté l'interface serveur sur nginx et nous avons été très satisfait des performances de ce soft. Parallèlement nous auditions nginx et c'est à ce moment que nous nous sommes dit qu'il fallait vraiment revoir cela. Inutile de me demander des résultats précis, je vais juste vous dire que nous avons évité plusieurs buffer overflow en production de justesse et sincèrement pour un produit de sécurité ce n'était pas vraiment acceptable…
Parallèlement on nous a aussi demandé des solutions forward squid based où là encore nous avons eu quelques frayeurs.
Malheureusement à cette époque nodejs & v8 n'était pas encore stable/fiable pour pouvoir effectuer les opérations nécessaires aux applications reverse & forward proxy. Mais j'avais immédiatement détecté que ce serait le moyen le plus safe d'effectuer des opérations de proxy (ou de serveur) dans le futur. Voir même plus. Mais je ne détaillerais ici.
Il faut bien comprendre que tout cela est possible grâce à v8 qui correspond à une vraie révolution en matière d'informatique technique. Sans cela gatejs n'aurait pas d’intérêt… Pour la faire simpliste, v8 compile du JS en assembleur. nodejs en lui même est très simple et correspond pour ma part à un preloader, il est lui même codé à 70% en JS.
Bref, j'ai estimé que pour pouvoir augmenter la sécurité il fallait absolument réduire la verbosité d'un langage. Actuellement j'estime prendre bien moins de risque avec gatejs et je n'ai aucune limite à la réalisation de plugins.
Reste maintenant les risques de sécurité liés à la logique de design mais là encore c'est plus complexe avec le JS simplement parce que ce n'est pas(plus) un simple langage de scripting accessible à monsieur tout le monde, ce n'est pas PHP et il aura du mal à le remplacer du simple fait qu'il faut plus de compétences pour coder en JS. Un expert qui prend en main Javascript a ses sens en ébullitions :) À l'inverse un kiddy aura du mal.
Pour le choix de l'open source, c'est un peu complexe à détailler ici mais il remonte à bien longtemps et il a fallu convaincre des personnes. Je pense que c'est un gage de confiance et d'assurance dans mon secteur. Compliqué pour ma petite société de convaincre à passer sur des solutions closed sources inconnues. J'espere que cela fera évoluer les choses. Je crois vraiment au modèle économique open source. Je crois que c'est l'avenir. Le problème est qu'il n'y a pas d'école et que tout le monde joue un peu l'empirisme. C'est là mon dilemme.
Mais j'ai beau cherché dans le wiki ou dans le README, il n'y a pas de direction pour la façon de contribuer.
On utilise Github massivement, donc fork + pull request. On est pas très au point sur les détails à préciser. Si vous avez des conseils sur la forme je suis preneur !
Donc c'est libre (on a le droit de forké) mais ça reste fermé ?
Non non ! Nous sommes dans le cadre de la GPLv3 et les contributions doivent simplement prendre la voie du workflow de Github et très sincèrement j’espère qu'il y aura d'autres contributeurs
En me relisant, je me rends compte que c'est un peu aigri, mais je ne sais pas le tourner de manière différente, désolé. Je m'intéresse surtout aux raisons qui poussent une entreprise à rendre un projet libre :
Pour répondre de manière fermée je dirais : publicité sur le savoir-faire, rendu à la communauté et manque de personnel
Je pense donner quelques indices plus haut.
Je crois que tout projet open source doit, d'une manière ou d'une autre, avoir une équipe core qu'il rémunère pour assurer la continuité professionnel du projet. Certain utilise le don d'autre le service ou encore la licence duel.
Je crois beaucoup à la licence duel pour le cas de gatejs où un support pro serait proposé ou encore une garantie sur le fonctionnement (exclue de la GPL) mais aussi des développements spécifiques.
Vous supportez le caching des requètes partielles utilisant le header "Range" ?
Oui mais nous ne reconstruisons pas le fichier, malheureusement.
Les cas de range sont très complexe mais pas impossible à gérer.
Le problème majeur dans le caching en mode chunk est la performance nécessaire à la gestion de ce dernier.
Si les ranges sont les mêmes alors gatejs ajoutera le Range dans l'url (via le store) pour cacher le chunk.
Gatejs pourrait être intéressant mais j'ai du mal à comprendre ce qu'il fait précisément et pourquoi il serait mieux que les autres solutions citées (ou haproxy dont la version 1.5 vient juste de sortir).
gatejs est un bundle complet de proxy(ing) HTTP, en ce sens il regroupe des fonctionnalités de plusieurs soft tel que nginx ou squid.
Je ne me suis pas posé la question par rapport à haproxy, mais je pense qu’au-delà des performances la flexibilité ira au bénéfice de gatejs.
Ce serait possible d'avoir un cas d'usage ? J'ai un peu regardé les exemples sur le wiki mais j'ai l'impression que je pourrais faire tout aussi bien avec les autres outils.
Les cas sont multiple mais globalement avoir des requêtes HTTP modifiables qui passent par du Javascript facilite énormément les taches de debug ou d'audit
Pour exemple, pour optimiser le cache il est essentiel de pouvoir regrouper les urls entre elles. Pour être encore plus précis, Grooveshark par exemple délivre les musiques via un système de post HTTP qui empêche pratiquement n'importe quel proxy de cacher cette données (la musique).
gatejs embarque un opcode store qui et comparable au vieux store_url de squid (qui n'est plus disponible maintenant) et qui été fort utile pour regrouper les URLs, cependant même lui ne permet pas de faire cette opération.
Va voir ça http://pastebin.com/3J7jaVmB cet exemple est pour moi le plus parlant en matière de flexibilité. J'estime qu'il est pas possible de faire plus simple pour le moment tout en aillant des performances et sans risque sécurité.
Dans le wiki, ce sont des modules nodejs avec une fonction qui renvoie un objet JavaScript. J'ai du mal à voir l'intérêt de cette approche. Ça va fait plus de bruit que juste un bout de JSON, mais sans permettre d'aller chercher des bouts de cette configuration dans un fichier, une base de données, une API Rest (il faudrait de l'asynchrone pour ça).
je ne comprend pas ce que tu dis :( Nous utilisons nodejs comme preloader à v8. Nos modules sont développés pour v8 et chargés par nodejs.
Pour la prise en charge de SSL, est-ce que cela inclut les trucs sympas comme le Forward Secrecy ou l'OCSP stapling ? Quelle est la bibliothèque SSL utilisée ? OpenSSL ? GnuTLS ?
Oui le PFS est supporté, il faut simplement lui demander d’honorer l'ordre d'utilisation des cyphers et de spécifier ECDHE. OpenSSL, mais on a rien senti de heartbleed car il est embarqué en static dans nodejs.
Sur la même machine ? Comment se répartissent-ils le boulot ?
Oui, j'aime dire que chaque processes est atomique à lui même, il n'y a aucun lock ni threads. Les processes communiques entre eux via un système IPC (qui s'étend au réseau via NPC). Tien tu veux voir le système IPC ? https://github.com/binarysec/gate/blob/master/src/lib/core/js/ipc.js il est intéressant d'aller voir celui de nginx ou apache…
Bonne question, nous faisons des tests permanent mais non structurés. Cependant le premier test à réaliser serait de prendre une image caché par nginx & gatejs puis de mesurer le nombre requêtes par secondes. À ce test et avec un nombre de 100 connexions concurrentes nginx est plus performant (~2,5x) cependant la donne change quand on monte en nombre de connexions concurrentes nginx dérouille rapidement (à partir de 10 000) ce qui n'est le cas de gatejs.
Gatejs est clairement plus asynchrone que nginx ce qui pourrait expliquer cela.
Nous avons une production qui utilise gatejs et qui handle 250 000 connexions actives.
Aussi l'écart de traitement des requêtes via gatejs est largement plus stable qu'avec nginx.
Autant ne pas parler de Squid qui est complètement hors course.
Des tests plus poussés doivent être réalisés mais il nous manque de ressources actuellement pour pouvoir le faire dans les règles de l'art.
# Yup
Posté par Michael Vergoz . En réponse à la dépêche Écrire son OS - Partie 2 : configurer ses outils. Évalué à 1.
Salut à tous
Pas mal les articles, c'est sympa :)
Je dev un projet d'OS (miniPhi) assez important sous licence GPLv3, je fais un peu de pub ici si il y a du monde chaud pour m'aider un peu !
Actuellement l'OS fonctionne sur les MCU texas instrument MSP430 mais j'ai commencé le portage pour STM32 et du coup c'est du taff :)
En fait je rend disponible les drivers que je développe pour mes besoins. Allez faire un tour dans le répertoire drivers/. Du coup ils sont portables pour n'importe quelle archi.
J'ai fait au mieux pour la doc donc un ptit coup de doxygen dans le répertoire root et on voit pas mal de truc
https://github.com/mykiimike/miniPhi
+++
mykii
[^] # Re: Interception ssl
Posté par Michael Vergoz . En réponse à la dépêche gateGhost: Traque-moi si tu peux. Évalué à 2.
Aris a raison ;]
[^] # Re: ETag Obsolète
Posté par Michael Vergoz . En réponse à la dépêche gateGhost: Traque-moi si tu peux. Évalué à 2.
Malheureusement tu ne pourras pas empêcher une personne d'utiliser des filtres. Pourquoi ne pas te baser sur Last-Modified ?
[^] # Re: Interception ssl
Posté par Michael Vergoz . En réponse à la dépêche gateGhost: Traque-moi si tu peux. Évalué à 1.
Je ne pense pas créer un "SPOF", peut être en ajouter … donc ca devient plus un "point of failure" ;) Les architectures traditionnelle ne sont en général pas super super safe ….
Je dirais qu'au contraire en faisant du MITM on peut trouver qui a été compromis dans le réseau.
L'utilisation de javascript permet aussi de réduire le risque de vulnérabilité dans gatejs
[^] # Re: Interception ssl
Posté par Michael Vergoz . En réponse à la dépêche gateGhost: Traque-moi si tu peux. Évalué à 2. Dernière modification le 03 juillet 2014 à 12:18.
En gros pour le SSL une liste officielle est consolidée dans le navigateur. Ce sont les les CA qui servent à signer les clés régulières pour nos domaines. Il y a donc du Verisign, THAWTE ou encore Comodo .. ceux qui sont autorisés à signer nos certificats.
Si je veux intercepter du SSL il suffi de:
- de créer une clés
- de la signer avec mon CA
- de configurer le CA + ma clés dans gatejs
- d'installer le CA sur le device et le tour et joué
Sauf que dans certain cas, le CA de confiance est codé en dur dans l'application. Cela a pour effet de bloquer la connexion puisque le CA et CRT ne sont pas les mêmes qu'annoncés. C'est une "sécurité" de l'application pour éviter ce genre d'interception.
[^] # Re: ETag Obsolète
Posté par Michael Vergoz . En réponse à la dépêche gateGhost: Traque-moi si tu peux. Évalué à 3.
Non on ne peut pas dire qu'il soit obsolète ou en court d'abandon.
C'est juste un doublon avec quelques chose qui existe déjà Last-Modified If-Modified-Since… Mais qui ne décline pas une ressource précise (ce que fait ETag). Je vais essayé de le faire que quand le ETag me semble louche ;))
[^] # Re: Ouvert, libre et contribution
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 2.
Oui NGINX fait le mail Squid fait aussi le FTP ou le Gopher..
Je pense que la prochaine feature de gate sera un serveur DNS.
Le proxy mail est assez simple à réaliser, je vais regarder ce que je peux faire.
J'aimerais aussi intégrer un serveurs Web complet dans gate… qui pourrait supporter pas mal de feature Apache pour migrer plus facilement…
[^] # Re: Enfin un choix raisonnable
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à -1.
C'est la seule chose "complexe" à comprendre en JS. Une fois passé cette étape tu verras que le scope des variables est de toute puissance. C'est pour moi la chose la plus puissante dans JS :)
[^] # Re: Ouvert, libre et contribution
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 10.
BinarySEC est une société spécialisée en sécurité informatique. Elle a été fondée en 2007, initialement nous avions développé un outils de protection des binaires pour prévenir une bonne partie des types de buffer overflow existants. Cependant après quelques mois nous nous sommes aperçu que cela serait complexe à vendre et surtout à maintenir.
Aussi nous avions remarqué que les attaques les plus violentes et les plus répandues passent par HTTP et là malheureusement l'outil de détection de BOF ne servait pas à grand chose.
Alors j'ai décidé à l'époque de penser un nouveau système de protection des sites Internet. Il fallait quelque chose de simple donc en opposition totale avec mod_security etc… J'ai donc pensé un système de corrélation sous forme d'IA faible et cela a permis d'éliminer le risque de faux positifs à hauteur de 90%.
La première implémentation était un module Apache mais rapidement on nous a demandé une solution en proxy (reverse). À l'époque il n'y avait vraiment que nginx comme solution fiable au reverse proxy, exit squid, varnish et… Apache.
Nous avons donc implémenté l'interface serveur sur nginx et nous avons été très satisfait des performances de ce soft. Parallèlement nous auditions nginx et c'est à ce moment que nous nous sommes dit qu'il fallait vraiment revoir cela. Inutile de me demander des résultats précis, je vais juste vous dire que nous avons évité plusieurs buffer overflow en production de justesse et sincèrement pour un produit de sécurité ce n'était pas vraiment acceptable…
Parallèlement on nous a aussi demandé des solutions forward squid based où là encore nous avons eu quelques frayeurs.
Malheureusement à cette époque nodejs & v8 n'était pas encore stable/fiable pour pouvoir effectuer les opérations nécessaires aux applications reverse & forward proxy. Mais j'avais immédiatement détecté que ce serait le moyen le plus safe d'effectuer des opérations de proxy (ou de serveur) dans le futur. Voir même plus. Mais je ne détaillerais ici.
J'adore ce lien http://bellard.org/jslinux/
Il faut bien comprendre que tout cela est possible grâce à v8 qui correspond à une vraie révolution en matière d'informatique technique. Sans cela gatejs n'aurait pas d’intérêt… Pour la faire simpliste, v8 compile du JS en assembleur. nodejs en lui même est très simple et correspond pour ma part à un preloader, il est lui même codé à 70% en JS.
Bref, j'ai estimé que pour pouvoir augmenter la sécurité il fallait absolument réduire la verbosité d'un langage. Actuellement j'estime prendre bien moins de risque avec gatejs et je n'ai aucune limite à la réalisation de plugins.
Reste maintenant les risques de sécurité liés à la logique de design mais là encore c'est plus complexe avec le JS simplement parce que ce n'est pas(plus) un simple langage de scripting accessible à monsieur tout le monde, ce n'est pas PHP et il aura du mal à le remplacer du simple fait qu'il faut plus de compétences pour coder en JS. Un expert qui prend en main Javascript a ses sens en ébullitions :) À l'inverse un kiddy aura du mal.
Pour le choix de l'open source, c'est un peu complexe à détailler ici mais il remonte à bien longtemps et il a fallu convaincre des personnes. Je pense que c'est un gage de confiance et d'assurance dans mon secteur. Compliqué pour ma petite société de convaincre à passer sur des solutions closed sources inconnues. J'espere que cela fera évoluer les choses. Je crois vraiment au modèle économique open source. Je crois que c'est l'avenir. Le problème est qu'il n'y a pas d'école et que tout le monde joue un peu l'empirisme. C'est là mon dilemme.
On utilise Github massivement, donc fork + pull request. On est pas très au point sur les détails à préciser. Si vous avez des conseils sur la forme je suis preneur !
Non non ! Nous sommes dans le cadre de la GPLv3 et les contributions doivent simplement prendre la voie du workflow de Github et très sincèrement j’espère qu'il y aura d'autres contributeurs
Pour répondre de manière fermée je dirais : publicité sur le savoir-faire, rendu à la communauté et manque de personnel
Je pense donner quelques indices plus haut.
Je crois que tout projet open source doit, d'une manière ou d'une autre, avoir une équipe core qu'il rémunère pour assurer la continuité professionnel du projet. Certain utilise le don d'autre le service ou encore la licence duel.
Je crois beaucoup à la licence duel pour le cas de gatejs où un support pro serait proposé ou encore une garantie sur le fonctionnement (exclue de la GPL) mais aussi des développements spécifiques.
[^] # Re: Support du caching par chunk ?
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 2.
Oui mais nous ne reconstruisons pas le fichier, malheureusement.
Les cas de range sont très complexe mais pas impossible à gérer.
Le problème majeur dans le caching en mode chunk est la performance nécessaire à la gestion de ce dernier.
Si les ranges sont les mêmes alors gatejs ajoutera le Range dans l'url (via le store) pour cacher le chunk.
[^] # Re: Quelques questions
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 6. Dernière modification le 20 juin 2014 à 18:37.
gatejs est un bundle complet de proxy(ing) HTTP, en ce sens il regroupe des fonctionnalités de plusieurs soft tel que nginx ou squid.
Je ne me suis pas posé la question par rapport à haproxy, mais je pense qu’au-delà des performances la flexibilité ira au bénéfice de gatejs.
Les cas sont multiple mais globalement avoir des requêtes HTTP modifiables qui passent par du Javascript facilite énormément les taches de debug ou d'audit
Pour exemple, pour optimiser le cache il est essentiel de pouvoir regrouper les urls entre elles. Pour être encore plus précis, Grooveshark par exemple délivre les musiques via un système de post HTTP qui empêche pratiquement n'importe quel proxy de cacher cette données (la musique).
gatejs embarque un opcode store qui et comparable au vieux store_url de squid (qui n'est plus disponible maintenant) et qui été fort utile pour regrouper les URLs, cependant même lui ne permet pas de faire cette opération.
Va voir ça http://pastebin.com/3J7jaVmB cet exemple est pour moi le plus parlant en matière de flexibilité. J'estime qu'il est pas possible de faire plus simple pour le moment tout en aillant des performances et sans risque sécurité.
je ne comprend pas ce que tu dis :( Nous utilisons nodejs comme preloader à v8. Nos modules sont développés pour v8 et chargés par nodejs.
Oui le PFS est supporté, il faut simplement lui demander d’honorer l'ordre d'utilisation des cyphers et de spécifier ECDHE. OpenSSL, mais on a rien senti de heartbleed car il est embarqué en static dans nodejs.
À ca : https://github.com/binarysec/gate/blob/master/src/lib/http/js/pipeForward/headers.js
Et tu l'utilises comme ça dans un pipeline : https://github.com/binarysec/gate/wiki/OpcodeHeaders
Oui, j'aime dire que chaque processes est atomique à lui même, il n'y a aucun lock ni threads. Les processes communiques entre eux via un système IPC (qui s'étend au réseau via NPC). Tien tu veux voir le système IPC ? https://github.com/binarysec/gate/blob/master/src/lib/core/js/ipc.js il est intéressant d'aller voir celui de nginx ou apache…
[^] # Re: Références
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 0.
On va essayé d'organiser ça ;)
[^] # Re: Mmrffff
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 0.
Faudra le repost …. je ne suis pas un expert de la comm.. :]
[^] # Re: Références
Posté par Michael Vergoz . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 7.
Bonne question, nous faisons des tests permanent mais non structurés. Cependant le premier test à réaliser serait de prendre une image caché par nginx & gatejs puis de mesurer le nombre requêtes par secondes. À ce test et avec un nombre de 100 connexions concurrentes nginx est plus performant (~2,5x) cependant la donne change quand on monte en nombre de connexions concurrentes nginx dérouille rapidement (à partir de 10 000) ce qui n'est le cas de gatejs.
Gatejs est clairement plus asynchrone que nginx ce qui pourrait expliquer cela.
Nous avons une production qui utilise gatejs et qui handle 250 000 connexions actives.
Aussi l'écart de traitement des requêtes via gatejs est largement plus stable qu'avec nginx.
Autant ne pas parler de Squid qui est complètement hors course.
Des tests plus poussés doivent être réalisés mais il nous manque de ressources actuellement pour pouvoir le faire dans les règles de l'art.