Clairement, cela ne peut pas être utilisé pour surfer le web car l'utilisateur ne va pas réécrire toutes les URL.
Exactement c'est pour le système de CI.
D'autre part, le changement de domaine brise un certain nombre de mécanisme sécurités.
Oui et non car KissCache va :
1/ valider les certificats SSL
2/ le client s’adresse explicitement à l'instance KissCache donc fait explicitement confiance à cette instance.
Pour faire la même chose avec un proxy, il faut :
1/ créer un certificat racine
2/ l'installer sur chaque client
3/ forger des certificats pour chaque domaine demandé
Le client fait donc entièrement confiance au proxy qui va forger des certificats pour linuxfr.org par exemple.
Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy. Un attaquant qui prend le contrôle du proxy peut alors mettre en place un MitM sans aucun problème avec l'intégralité des domaines.
Qu'est-ce que "au même moment" ? Cela ne me paraît pas se produire souvent...
Dans un système de validation où plusieurs job sont lancé en parallèle avec les même artefacts cela arrive absolument tout les jours.
Dans notre cas, LKFT va valider chaque RC du noyaux linux sur 6 types de machines en lançant pour chaque type une dizaine de job différent. Sachant que nous avons au minimum 4 machine de chaque type, LAVA va nécessairement faire tourner des jobs en parallèle et donc utiliser les même artefacts au même moment.
[^] # Re: usage ?
Posté par Rémi Duraffort (site web personnel) . En réponse à la dépêche KissCache un service de mise en cache KISS. Évalué à 3.
voir "Cas d’usage" dans l'article.
Exactement c'est pour le système de CI.
Oui et non car KissCache va :
1/ valider les certificats SSL
2/ le client s’adresse explicitement à l'instance KissCache donc fait explicitement confiance à cette instance.
Pour faire la même chose avec un proxy, il faut :
1/ créer un certificat racine
2/ l'installer sur chaque client
3/ forger des certificats pour chaque domaine demandé
Le client fait donc entièrement confiance au proxy qui va forger des certificats pour linuxfr.org par exemple.
Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy. Un attaquant qui prend le contrôle du proxy peut alors mettre en place un MitM sans aucun problème avec l'intégralité des domaines.
Dans notre cas, LKFT va valider chaque RC du noyaux linux sur 6 types de machines en lançant pour chaque type une dizaine de job différent. Sachant que nous avons au minimum 4 machine de chaque type, LAVA va nécessairement faire tourner des jobs en parallèle et donc utiliser les même artefacts au même moment.