La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Logiciels => Discussion démarrée par: manoaratefy le 30 mai 2016 à 16:24:44
-
Bonjour,
Voilà, j'ai un petit soucis. J'ai besoin d'alléger le trafic sortant sur mon réseau. Car en effet, près de 80% sont des fichiers statiques qui sont stockés sur mon VPS. Voilà donc, je cherche à faire comme un CDN. Sauf qu'ici, je ne veux pas changer de protocole.
Pour contrôler la cache, je voudrais comme par exemple les 50 Go de fichiers statiques les plus sollicités sont stockés 7 jours dans mon serveur.
J'ai pensé à NGINX qui me semble parfait pour faire un Reverse Proxy, mais l'installer chez moi et en faire pour les principaux sites que j'utilise, je ne l'ai encore jamais fait.
Quelqu'un a-t-il une idée ou une proposition ?
Merci d'avance pour vos coups de pouces.
-
C'est bien du trafic http ? (il faut oublier un proxy sur du trafic https)
-
Oui, du http. Et je sais bien que c'est impossible en HTTPS.
-
J'ai besoin d'alléger le trafic sortant sur mon réseau. Car en effet, près de 80% sont des fichiers statiques qui sont stockés sur mon VPS.
Le serveur en question renvoie-t-il les bonnes entêtes HTTP pour une utilisation efficace du cache ? (Cache, Expires, ETag)
Il faut commencer par là, le cache des navigateurs est quand même très efficace.
C'est bien du trafic http ? (il faut oublier un proxy sur du trafic https)
Je dirais oui et non :)
Rajouter un proxy qui fait du cache sur du HTTPS implique de faire un vilain MITM, mais ça se fait : il suffit d'ajouter le certificat utilisé par le proxy pour re-signer les requêtes dans le "Trust store" de chaque machine.
Je déconseille de le faire, mais c'est quand même possible (Squid + SSLBump fait ça par exemple).
-
Bonjour,
Je pense que je pourrai apporter les modifications nécessaires sur le serveur vu que c'est moi qui a développé l'application.
-
Bonjour!
Après presque un an, je viens de me remettre sur le projet et j'ai réussi pour le HTTP avec NGINX. Cependant, le projet a quelque peu changé car maintenant je suis aussi intéressé à mettre en cache des sites web que je n'ai pas de contrôle. Néanmoins, en HTTP, ça marche toujours. Mais vous m'avez fait comprendre qu'on peut aussi le faire sur HTTPS et je suis curieux de savoir comment faire.
-
Il faut que le proxy casse le chiffrement.
Cela nécessite de maîtriser les clients, en y installant la clé du cache.
De nombreux anti-virus font ça pour analyser le trafic https mais cela entraîne des risques très importants si le proxy est corrompu ou si il ne vérifie pas lui même correctement les certificats, pour éviter un man in the middle en amont de ton réseau.
Bref, je déconseille.
-
Mais vous m'avez fait comprendre qu'on peut aussi le faire sur HTTPS et je suis curieux de savoir comment faire.
Tu peux tout à fait faire du proxying HTTPS, à la seule condition que tu maitrises entièrement les équipements de ton parc.
En effet, tu vas devoir resigner avec ton propre certificat les sites consultés, il faudra donc pousser ton propre certifs sur les machines clientes (pour qu'elles ne bronchent pas parce qu'elles ne connaissent pas le certif sinon). Cela se fait pas mal en entreprise (tu maitrises ton réseau, du proxy aux clients, donc c'est nickel) et les employés n'y voient que du feu ;)
-
Oui, je maîtrise la totalité des hôtes. D'ailleurs, une grande partie des hôtes sont connectés à l'Active Directory que j'ai mis en place.
Donc, me faut-il un certificat SSL auto-signé à chaque nouveau site que je veux mettre en cache ?
-
Oui, je maîtrise la totalité des hôtes. D'ailleurs, une grande partie des hôtes sont connectés à l'Active Directory que j'ai mis en place.
Donc, me faut-il un certificat SSL auto-signé à chaque nouveau site que je veux mettre en cache ?
Oky super, ce sera simple de déployer alors.
Au sujet des certifs, ça dépend si tu veux te faire chier ou non :)
Le plus simple, c'est de configurer tes navigateurs (Internet Explorer en active directory) pour qu'ils ne bronchent pas si le certif n'est pas bon.
Le plus propre, c'est de créer ton propre certificat "racine", de le pousser sur les postes clients, et de configurer ton proxy pour refaire un cert par site avec le cert racine que tu viens de créer. Comme ça, tous les sites auront un beau cadenas vert :)
-
Le plus simple, c'est de configurer tes navigateurs (Internet Explorer en active directory) pour qu'ils ne bronchent pas si le certif n'est pas bon.
Par pitié, ne jamais proposer de telles solutions, même si elles existent !
Pour en revenir au sujet, faut bien se rappeler HTTPS est un élèment fondamental de la sécurité du Web, et il faut peut-être en mesurer les conséquences avant de tout casser sur son propre réseau. Lorsqu'un proxy intercepte et déchiffre un flux HTTPS (et le modifie potentiellement), l'intégrité et le chaîne de confiance avec l'hôte originel sont rompues.
Par ailleurs, il y a de très, très fortes chances que ton proxy affaiblisse la sécurité, soit en ne validant pas correctement les certificats (coucou les antivirus), soit en ne supportant que des versions anciennes des protocoles (cf : https://jhalderm.com/pub/papers/interception-ndss17.pdf)
C'est pour ça qu'ajourd'hui, on ne recommande pas d'intercepter les flux HTTPS, explications du CERT/CC (https://www.us-cert.gov/ncas/alerts/TA17-075A), et même de l'ANSSI (https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/), qui recommande de bien mesurer les risques introduits par de telles pratiques.
Bref, je ne sais pas quel est exactement le contexte ici, mais avant de me lancer dans la décryption du HTTPS, je commencerais par mesurer le trafic sortant HTTP et HTTPS, puis mettre en place un bon vieux proxy+cache HTTP, sans déchiffrement du HTTPS, et observer les gains.
C'est certain que tous les grands du Web (Facebook, Google, ...) sont en HTTPS et ont "de grosses apps", avec beaucoup d'assets statiques, mais ils gèrent aussi très bien les règles de cache au niveau des clients. Et le contenu "par utilisateur" ne bénéficierait pas d'un hypothétique proxy-cache HTTPS.
-
Rappel : manoaratefy est à Madagascar, un pays ou la bande passante est chère et ou les accès sont lents
-
Oui, j'avais vu. Mais ce que je voulais dire, c'est qu'un bon vieux cache HTTP (à base de Squid ou autre) est relativement facile à mettre en place (pas de config des clients par exemple) et apportera déjà un certain gain non négligeable. Avant de se lancer dans du HTTPS, qui me semble plus compliqué et plus risqué, ça me semble une première étape qui vaut le coup.
-
Si tu ne cache pas Google, l'intéret est limité, non ?
-
J'ai bien peur que le gain en HTTP soit trop peu significative. Bon, ce n'est qu'une supposition vu que je n'ai pas d'outil statistique à ma disposition. D'ailleurs, je bricole quelques programmes pour uploader l'historique vers une base de données MySQL pour générer les statistiques requises.
En même temps, j'ai découvert que les mises à jours Windows échangés valent plusieurs centaines de gigaoctets. Donc, je mets WSUS pour économiser encore plus.
-
Si tu ne cache pas Google, l'intéret est limité, non ?
Ben c'est dur à dire sans savoir quelle utilisation est faite de la bande passante :)
Mais une fois de plus, encore faut-il que les URLs soient cacheables... Les URL de playback sur Youtube par exemple sont en Cache-Control: private donc exit la mise en cache au niveau d'un proxy... (du moins en théorie).
Pour toutes les applications/sites où l'utilisateur est authentifié : soit ce sont des URLs propres à l'utilisateur, donc aucun intérêt à les conserver dans un cache public, soit ce sont des URLs d'assets statiques propres à une application (genre Google Docs), et on peut raisonnablement penser qu'elles sont correctement mises en cache par les navigateurs.
Y'a de gros gains à attendre dans tous les sites de news/media en HTTP simple, qui pour la plupart renvoient des bons headers de cache sur la plupart des assets statiques.
Et gros +1 pour WSUS, ça marche bien comme truc.
Si tu as des clients Windows 10 dans ton parc que tu ne mets pas sur ton AD, vérifie que la Windows Update Delivery Optimization est bien activée sur le réseau local, ça leur permet de s'échanger des mises à jour entre eux sans passer par ton serveur WSUS s'ils ne sont pas dans l'AD.
-
Si tu as des clients Windows 10 dans ton parc que tu ne mets pas sur ton AD, vérifie que la Windows Update Delivery Optimization est bien activée sur le réseau local, ça leur permet de s'échanger des mises à jour entre eux sans passer par ton serveur WSUS s'ils ne sont pas dans l'AD.
Effectivement, j'ai quelques clients qui ne sont pas sur mon AD et que je ne peux pas contrôler. Serait-il possible de limiter la bande passante pour ces clients ? Vu que mon routeur ne dispose pas de QoS ...
-
Par pitié, ne jamais proposer de telles solutions, même si elles existent !
(...)
Bref, je ne sais pas quel est exactement le contexte ici,
Ah. Bah pourtant, le contexte est très clair, regarde bien le titre du sujet : "Avoir un serveur cache pour le web chez soi". Il est chez lui, dans sa boîte, il fait ce qu'il veut quand même :)
J'ai bossé quelques temps pour un grand groupe bancaire, bah pareil, les certifs étaient tous trafiqués. C'est quelque chose qui est répandu dans les grosses boîtes pour s'assurer que les gens font ce pour quoi ils sont payés, pas de quoi en faire un drame :)
J'ai bien peur que le gain en HTTP soit trop peu significative.
Fait un override de ton côté, et pousser l'expiration des assets (tout ce qui est images, css et js, pas les pages hein !) à plus d'un mois, là tu devrais bien le sentir.
-
Ah. Bah pourtant, le contexte est très clair, regarde bien le titre du sujet : "Avoir un serveur cache pour le web chez soi". Il est chez lui, dans sa boîte, il fait ce qu'il veut quand même :)
J'ai bossé quelques temps pour un grand groupe bancaire, bah pareil, les certifs étaient tous trafiqués. C'est quelque chose qui est répandu dans les grosses boîtes pour s'assurer que les gens font ce pour quoi ils sont payés, pas de quoi en faire un drame :)
Quand c'est fait correctement, et que le proxy valide correctement la validité de la chaîne du certificat avant de resigner avec son propre certificat, ça ne pose aucun problème. Beaucoup de grosses boîtes font ça malheureusement... (Ca pose quand même un certain nombre de problèmes concrets, cf les produits BlueCoat quand TLS 1.3 a été testé dans Google Chrome...)
C'était ça en fait qui m'a fait un peu bondir : :)
Le plus simple, c'est de configurer tes navigateurs (Internet Explorer en active directory) pour qu'ils ne bronchent pas si le certif n'est pas bon.
-
Quand c'est fait correctement, et que le proxy valide correctement la validité de la chaîne du certificat avant de resigner avec son propre certificat, ça ne pose aucun problème.
Pour la consultation de sites web oui.
Par contre, mais c'est un peu hors sujet, un proxy HTTPS casse obligatoirement toutes les applications "lourdes" ainsi que toutes les applications sur smartphone qui communiquent vers l'extérieur en HTTPS et font du SSL pinning (elles sont de plus en plus nombreuses), et ce même en installant le certificat du proxy sur l'équipement qui fait tourner l'app en question.