Le projet debian a annoncé la fin du service FTP pour ses dépôts au 1er novembre 2017 (https://www.debian.org/News/2017/20170425). Les raisons avancées sont :
- les serveurs FTP ne prennent pas en charge la mise en cache et l'accélération ;
- l'implémentation de la plupart des logiciels a stagné et ceux-ci sont difficiles à utiliser et à configurer ;
- l'utilisation des serveurs FTP est plutôt faible puisque notre propre installateur n'offre pas depuis dix ans FTP comme moyen d'accès aux miroirs ;
- le protocole est peu efficace et demande l'ajout de bidouillages compliqués pour les pare-feu et les démons de répartition de charge.
Il vous reste 6 mois pour mettre à jour vous sources.list :)
# HTTP remplacent ?
Posté par Mimoza . Évalué à 4.
Je dit «remplacent» mais c'est la solution par défaut …
Ne serait il pas intéressant de pousser des solutions comme «apt-p2p» ? Bon c'est vrai le dernier point soulevé resterait.
[^] # Re: HTTP remplacent ?
Posté par MTux . Évalué à -5.
On est pas chez Microsoft…
Par contre j'aimerai que https par défaut.
[^] # Re: HTTP remplacent ?
Posté par Pol' uX (site web personnel) . Évalué à 9.
Pour quelle raison ? L'apport de https semble assez faible. Les paquets Debian étant signés gpg par leur mainteneurs, la préservation de leur intégrité est indépendante du protocole comme du pigeon par lequel ils ont été acheminés.
Adhérer à l'April, ça vous tente ?
[^] # Re: HTTP remplacent ?
Posté par Memiks (site web personnel) . Évalué à 7.
Du coup raison de plus de pousser apt-p2p du moment que le protocole de récupération / vérification des clés GPG est sur lui.
[^] # Re: HTTP remplacent ?
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 4.
Deux cas d'usage me semblent aller contre apt-p2p par défaut :
- les connexions Internet limités en quantité de données (hors-forfait ou blocage de connexion) ;
- les réseaux locaux d'entreprise (contrôle des flux).
[^] # Re: HTTP remplacent ?
Posté par Sufflope (site web personnel) . Évalué à -2.
Eh bah tu désactiveras l'option sources P2P, si t'en es pas capable fallait se demander si Debian c'est bien pour toi. Pour les gens dans des pays défavorisés qui n'ont pas accès à mieux comme offres internet, on peut imaginer une option explicite à l'installation "activer le téléchargement P2P ? attention, consomme de la data !". C'est hyper classique comme option sur les applis smartphones, et donc je pense que les gens pour qui c'est vraiment un problème y sont bien sensibilisés.
Eh bah pareil y a qu'à désactiver les sources, encore plus facile en environnement contrôlé.
[^] # Re: HTTP remplacent ?
Posté par Maclag . Évalué à 5.
Tu sais que tu parles de l'Amérique du Nord, là?
Dans une orga internationale, je ne serais pas surpris que le bridage du volume de données soit considéré comme une normalité et pas une exception. Ça influence les choix!
[^] # Re: HTTP remplacent ?
Posté par Crao . Évalué à 5.
Confidentialité ? Ça éviterait à un attaquant de savoir quels paquets sont téléchargés.
De plus les iso sont toujours téléchargés en http, au niveau sécurité ça ne vaut rien.
[^] # Re: HTTP remplacent ?
Posté par Adrien . Évalué à 3.
Pour les aspects confidentialité/sécurité, il me semble qu'utiliser tor est préférable à du simple HTTPS. Ça tombe bien c'est possible très simplement :
https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html
[^] # Re: HTTP remplacent ?
Posté par RyDroid . Évalué à 3.
Sans HTTPS, il faut avoir confiance dans le noeud de sortie, à part pour les services onion. Tor n'est donc pas nécessairement meilleur que HTTPS, dans l'usage actuel il est bien plus souvent complémentaire.
[^] # Re: HTTP remplacent ?
Posté par Parleur . Évalué à 4.
D'ailleurs, il y a nois-oignons.net qui a fait de chouettes affiches pour indiquer la complémentarité de Tor et HTTPS : https://nos-oignons.net/Diffusez/nos-oignons-affiche-tor-et-https-201406-fr.pdf
[^] # Re: HTTP remplacent ?
Posté par Bisaloo . Évalué à 3.
C'est indiqué en bas des affiches de nos-oignons.net (en accord avec la licence CC-by) mais ça vient de l'EFF à la base :
https://www.eff.org/pages/tor-and-https
(en anglais)
[^] # Re: HTTP remplacent ?
Posté par Adrien . Évalué à 7.
Ça tombe bien, le lien que je donne fournit… un service onion !
Donc pour résumer : Tor permet tout ce que HTTPS permet, mais il est plus performant pour masquer à un attaquant que tu télécharges les mises à jour Debian du jour, et il ne se base pas sur des autorités de certification.
D'où mon commentaire, d'un point de vue sécurité je ne vois pas vraiment l'intérêt de HTTPS sachant qu'un service TOR existe déjà. D'un point de vue performance, effectivement la mise à jour par TOR est plus lente.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 4.
Tu le dis : HTTPS est plus performant.
Et tous les admin n'ont pas forcément envie d'autoriser du tor.
[^] # Re: HTTP remplacent ?
Posté par Anonyme . Évalué à -6.
Mauvais admin, changer admin.
[^] # Re: HTTP remplacent ?
Posté par Parleur . Évalué à 2.
Ya un autre inconvénient potentiel à l'utilisation de services cachés, d'ailleurs.
http://www.hackerfactor.com/blog/index.php?/archives/762-Attacked-Over-Tor.html
[^] # Re: HTTP remplacent ?
Posté par NicolasP . Évalué à 10.
En 2017, il faut inverser le raisonnement. On ne devrait plus avoir à justifier l'usage du HTTPS qui devrait être le choix par défaut. Au contraire, c'est quand on propose du HTTP qu'il faut le justifier.
HTTPS propose plus que l'intégrité de la réponse du serveur. Il y a la confidentialité comme abordé dans un autre commentaire, mais aussi l'intégrité de la requête du client. Est-ce que par exemple, un attaquant ne pourrait pas forcer un downgrade de la version d'un paquet ? Au lieu de télécharger la version N sur un serveur de Debian, le client se retrouve à télécharger la version N-1 qui contient des failles de sécurité sur le serveur de l'attaquant. Cette version N-1 ayant été "légitime" en son temps, elle aussi est signée.
Il y a peut-être des mécanismes dans Debian qui protège de ça, mais clairement la signature GPG à elle toute seule n'est pas suffisante pour se dire que le HTTP c'est sécurisé.
[^] # Re: HTTP remplacent ?
Posté par Romeo . Évalué à 6.
Quand on voit aux USA les projets pour vendre ton historique internet, le HTTPS n'est plus option.
HTTPS n'est peut-être pas la solution parfaite, mais c'est déjà une avancée autant miser dessus.
[^] # Re: HTTP remplacent ?
Posté par steph1978 . Évalué à 4.
HTTPS est loin de te protéger de ce type de traking:
Je dirais que la valeur marchande du HTTP et du HTTPS est semblable.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 6.
Sauf que s'il y a une faille dans APT, on pourrait faire installer des paquets APT modifiés.
Bien sûr, c'est impossible… ah bah en fait, si, c'est même déjà arrivé : https://www.ubuntu.com/usn/usn-3156-1/
Bref, ce sont deux sécurité qui sont totalement indépendantes et qui permettent (entre autres) la même chose (empêcher la corruption de paquets lors du transfert) : cela permet de pallier une faille sur l'une des deux sécurités.
[^] # Re: HTTP remplacent ?
Posté par Sufflope (site web personnel) . Évalué à 9.
C'est quoi ce délire ? Quel rapport ? Et justement, au contraire, si des structures peuvent tirer parti d'une distribution en P2P pour réduire leurs coûts d'infra, c'est bien les projets libres qui tirent le diable par la queue, plus que les boites avec des PIB d'états en cash…
[^] # Re: HTTP remplacent ?
Posté par Renault (site web personnel) . Évalué à 8.
Le rapport est que par défaut Windows 10 active le P2P pour partager ses mises à jour du système.
[^] # Re: HTTP remplacent ?
Posté par xcomcmdr . Évalué à 3.
Et en quoi est-ce une mauvaise chose ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: HTTP remplacent ?
Posté par Kerro . Évalué à 9.
Pour un produit payant, je trouve que c'est vraiment limite de le mettre par défaut (en diffusion sur le LAN c'est une bonne idée, mais pas pour utiliser ma bande passante).
En plus c'est hyper mal implémenté chez Microsoft puisque la moindre mise à jour sature totalement la bande passante de n'importe quelle liaison ADSL. Ça m'arrange, je facture lorsqu'une personne appelle au secours, mais c'est clairement mal fait.
Pour Debian je trouve que c'est une très bonne idée.
Reste à voir le résultat sur la bande passante, la mémoire, etc. Mais j'ai un a priori positif.
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Un truc cool avec HTTP c’est qu’un simple proxy (transparent? ) avec quelques règles pour les fichiers provenant d’
archives.debian.orgest hyper pratique (c’est probablement pourquoi les antivirus distribuent souvent leurs bases en HTTP, c’est très facile à mettre en cache).Bon au boulot j’ai un miroir Debian complet donc j’ai pas besoin d’un proxy cache pour ça et je pourrai utiliser https pour synchroniser le miroir, mais j’utilise un proxy-cache pour d’autres services similaires (d’où ma supposition que si ces services restent en HTTP, c’est pour me le permettre).
J’imagine que certains gros opérateurs n’hésitent pas à mettre en cache ce genre de chose (mises à jour windows, mises à jour antivirus) pour réduire les coûts de peering.
Un bon exemple sont les miroirs que fournissent certains opérateurs/fournisseurs, comme le miroir
mirrors.online.netpour les clients dédibox oudebian.mirrors.ovh.netpour les clients ovh, ainsi que tous les miroirs d’universités. Dans ce cas, utiliser https n’a pas beaucoup de sens (excepté dissimuler à un voisin quels paquets tu télécharges) car le protocole apt vérifie l’intégrité et la légitimité du paquet indépendamment du miroir obscure qui t’as fourni. Pour revenir à cet exemple demirrors.online.net, en plus de fournir un miroir complet à leur client, je ne serai pas étonné qu’ils placent un gros proxy cache dans chacun de leur datacenters.Bref, https pourquoi pas (ça dissimulera quel paquet tu télécharges, mais pas vraiment que tu télécharges un paquet), y a un besoin pour ça, mais il y a bien un univers qui va utiliser HTTP encore longtemps, c’est la distribution de paquet (distribution, antivirus…). Le problème du peer-to-peer c’est que tu ne contrôle pas vraiment le peering, alors que monter un miroir de ton côté d’un lien problématique est très facile.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 4.
C'est moi, ou c'est complètement délirant de télécharger une base de virus via http?
Je suis le méchant, je te mitma, et je te sert la base de virus pas mise à jour depuis 6 mois, pendant ce temps je te poutre avec un virus sorti la semaine dernière.
J'ai plutôt envie de demander quelle est la raison en 2017 de préférer http à https?
Quel est le gain? Temps CPU passer à déchiffrer? Ca va, faut pas deconner quand même….
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 5.
Tu crée comment la signature de la base ? Parce que fournir celle de la semaine dernière ne te suffira pas, l'antivirus va crier qu'il n'arrive pas à mettre à jour sa base de virus.
Si tu lis le commentaire au quel tu répond : pour la capacité de mise en base des paquets sans avoir à créer un miroir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 1.
Tu sert le fichier de la semaine dernière?
Tintercepte le transfert de la semaine passée avec ton proxy local, et tu sert exactement la même base pendant des semaines. Les signatures passent, le client est content, et pense être à jour.
???
Ca veut dire quoi?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 6.
Tu casse donc la signature numérique donc le client refusera d'en faire quoi que ce soit.
Que tu peux avoir un proxy http pour ne télécharger qu'une seule fois chaque paquet au sein d'un réseau local, c'est très facile à mettre en place et sa consomme bien moins de disque de maintenir un miroir (ça réduit aussi plus drastiquement le peering).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 4.
Non, tu sert le même fichier, verbatim. La signature est toujours valide.
Si je te sert le libc-6.42.deb alors que libc-6.43.deb est sorti y'a 2 jours, la signature de 6.42 est plus valable?
Tout marchera très bien, c'est juste que t'es pas au courant que 6.43 est sorti.
Tes clients ont pas forcément d'utiliser ton proxy http pour tout leur traffic http. Et s'il faut leur demander de mettre le proxy en place uniquement pour apt, Ben tu peux aussi leur demander d'utiliser ton miroir local qui fait du lazy loading (sert depuis un cache local si dispo, sinon relai upstream).
Et donc, les mecs d'ovh sont pas foutu de router debian.ovh.com vers noeud local au datacenter dans leur propre datacenter, et ne sont pas non plus foutu de mettre en place le cert qui va bien?
Ou de tout simplement créer leur images avec par défaut "Debian.datacentername.ovh.com" comme source de paquet?
Ton réseau local qui va avoir des gains considérables la dessus est pas foutu de déployer un squid, et demander aux gens d'utiliser Debian.monreseau.com?
J'ai vraiment du mal à voir l'intérêt, excuse moi.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 3.
Et s'il y a une faille dans la vérification de la signature ?
Le problème est arrivé avec Ubuntu (cf. plus haut), c'est exactement la même chose. C'est un peu le principe de la défense en profondeur…
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 3.
Et s'il y a une faille dans ta bibliothèque TLS ? Non je rigole ça n'arrive jamais…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 2.
D'où l'idée de multiplier les couches de sécurité : une seule faille dans l'un des composants n'est pas suffisante, il faut une faille dans chaque composant de sécurité simultanément. D'où le principe de défense en profondeur, avec plusieurs lignes de défense concentriques.
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 1.
Nan, mais laisse tomber.
Dans 1 heures ils vont venir t'explique a quel point c'est crucial d'utiliser HTTPS absolument partout et tout chiffrer de bout en bout, mais pour la source de confiance de software qui tourne sur leur machine, limite le monde va s'arrêter si on met ca derriere du HTTPS, il faut absolument tout passer en clair.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 4.
De manière générale : non, la multiplication des couches n'entraîne pas de facto une meilleure résistance aux failles, notamment aux failles logiciels.
Ici par exemple ça n'est pas le cas. https s'attaque a une classe de problème différente de la gestion de la signature des paquets et ça même ceux qui prônent https le disent : https ne remplace pas la signature. Donc si tu as une faille dans gpg t'es mort avec ou sans TLS.
Il faudrait une seconde signature pour limiter les risques qui soit implémenté par une autre bibliothèque et qui repose sur d'autres algorithmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 3.
Si, au moins partiellement : si tu as une faille dans la signature GPG (ce qui était justement le cas, cf. le lien supra), il suffit de faire du MITM pour infecter l'ordinateur. Avec du HTTPS, ce n'est plus possible : il faut soit casser le HTTPS, soit récupérer un certificat valide, soit trouer le serveur.
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 4.
Ou se faire faire un certificat par une autorité qui fait mal son boulot. C'est presque courant, hein ?
Le système des CA est LA faille de TLS et la bibliothèque TLS que tu utilise n'y peu rien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par flan (site web personnel) . Évalué à 3. Dernière modification le 11 mai 2017 à 22:25.
C'est exactement ce que je dis (« soit récupérer un certificat valide »), ce qui peut être compliqué si tu restreints la liste des AC acceptées ;)
À nouveau, tout comme Groumly, je n'ai jamais prétendu que le HTTPS était suffisant en soi ; simplement que ça apporte de la sécurité supplémentaire et qu'à ce titre, c'est une mauvaise idée de s'en passer.
[^] # Re: HTTP remplacent ?
Posté par gouttegd . Évalué à 4.
Je ne sais pas quelles sont les pratiques des antivirus, mais il me semblerait logique que les données signées incluent, notamment, la date de signature. Si la signature est faite avec OpenPGP, c’est même obligatoire (RFC 4880, §5.2.3.4 : les données signées DOIVENT inclure un paquet Signature Creation Time).
Du coup, si le client demande une mise à jour le 1er avril 2017, et reçoit un fichier dont la signature est datée du 1er novembre 2016, il a quand même de quoi se douter de quelque chose…
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 3.
Quelle est la grace period?
Qu'est ce qu'il se passe si mon horloge locale est complètement désynchro, genre 2 mois dans le passé?
Qu'il y ait des checks d'intégrité sur la base, ok, cool, mais pourquoi diable est ce qu'on se passerait d'authentifier le serveur à qui on parle?
Qu'est ce qu'on gagne en pratique, à part laisser pinpin monter un proxy transparent en carton, et qui diable de sérieux voudrait faire ca en premier lieu?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par gouttegd . Évalué à 1.
« Qui diable de sérieux voudrait faire ça en premier lieu ? »
Une telle désynchronisation t’expose à pas mal de problèmes indépendamment des mises à jour de ton antivirus. Notamment, vis-à-vis des périodes de validité des certificats X.509 (et dans une moindre mesure les signatures DNSSEC, mais comme rares sont ceux qui signent leur zone et encore plus rares sont ceux qui vérifient les signatures, je reconnais que c’est moins gênant).
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 5.
Ok, un drift de 2 mois c'est abusé, mais une horloge décale d'un jour où deux, c'est pas complètement dingue non plus, tout en restant problématique, un jour ou deux pour exploiter, c'est pas rien.
La vraie question est pourquoi faire du proxy http à la rache quand monter un lazy mirror représente pas vraiment plus de travail et élimine un problème de l'architecture?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par claudex . Évalué à 5.
Tu vas avoir des blagues avec HTTPS aussi surtout depuis Let's encrypt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 6. Dernière modification le 10 mai 2017 à 11:43.
Essaies avec Debian, juste un peu pour voir.
Les paquets ont une durée de vie limitée, et
Acquire::Check-Valid-Until "true";est l’option par défaut (ne permet pas l’installation de paquets anciens).Tous les paquets du dépôt sécurité ont une durée de vie assez courte, donc les seuls utilisateurs que tu arriveras à feinter sont ceux qui n’utilisent pas le dépôt sécurité, autant dire qu’ils n’ont pas besoin de toi pour avoir des problèmes.
Bref, tout ça a été très bien pensé pour ne pas avoir besoin de sécuriser le protocole de distribution, c’est justement pour cela que tu peux utiliser les yeux fermés le dépôt de ton hébergeur, de ton fournisseur d’accès, ou de ton université, parce qu’ils ne font qu’héberger des fichiers qu’ils ne peuvent pas forger. Le protocole de distribution garantie l’intégrité des fichiers et la légitimité de ces fichiers même transportés sur une clé USB tenue dans la gueule d’un fox terrier (façon Tintin au Tibet 2017).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Ajout: quand tu installes une Debian sur un dédié chez Online ou chez OVH, ils te mettent leur dépôt de paquet, mais ils mettent toujours le dépôt sécurité de chez Debian, pas le leur, donc même le « drift de quelques jours » n’est pas une réalité.
Il est possible de créer un miroir du dépôt sécurité (c’est un dépôt comme un autre) mais je n’en ai jamais rencontré autrement qu’à l’intérieur d’un réseau d’entreprise, tous les fournisseurs que j’ai vu qui proposaient des miroirs Debian publics faisaient en sorte que leur client utilise le dépôt sécurité de Debian sans miroir (ce qui leur laisse le loisir de faire du cache avec un proxy transparent, de toute manière).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par claudex . Évalué à 3.
Si tu mitm, avec du HTTPS, tu empêche la connexion au serveur, et donc la mise à jour de base et le résultat est le même.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 2.
On est en droit de penser que le client va gueuler quand il va voir qu'il parle à un hôte qu'il ne peut pas authentifier, non?
Alors, oui, tu peux recréer une authentification d'hôte par dessus http, au niveau applicatif, mais va falloir m'expliquer la logique…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par claudex . Évalué à 4.
Avoir du caching au niveau des proxy.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 3.
Oui, c'est précisément ce qu'on cherche à éviter, les caches pas à jour ;-)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par kantien . Évalué à 3. Dernière modification le 10 mai 2017 à 12:49.
Elle est intéressante votre discussions. En cherchant un peu, je suis tombé sur une étude (ancienne vu le sujet, elle date de 2008) qui testait la sécurité de différents gestionnaires de paquets et les méthodes de distribution : A Look In the Mirror: Attacks on Package Managers. Je n'ai pas eu le temps de la lire en détail, mais en conclusion il pointe bien un problème sur le HTTP / HTTPS :
Apparemment, l'étude consistait à montrer comment on pouvait créer un miroir malicieux. Si quelqu'un a le courage de regarder plus en profondeur l'étude et voir si certains éléments sont toujours d'actualité…
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 3.
Autant que lorsque la signature de la base est cassée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Pas du tout, comme pour les .deb, les fichiers sont signés par le distributeur avant d’être mis dans la nature, et vérifiés par le client après téléchargement. Ça signifie juste que l’éditeur antivirus n’a aucune confiance dans le protocole de distribution et qu’il s’est donné les moyens de ne pas avoir à sécuriser le transfert. C’est plutôt bon signe en fait, ça signifie que même https n’est pas considéré comme une sécurité suffisante et que le protocole de distribution a été pensé en conséquence.
Comme pour les .deb, les fichiers sont signés par paquet ou par fichier, peu importe le média de distribution, que ce soit un pigeon ou un CD gravé, ou une clé USB.
Ton installeur Debian il peut vérifier la légitimité d’un paquet trouvé sur un CD, l’antivirus il peut faire pareil si tu apportes une mise à jour de la base via un support physique parce que t’as dû complètement déconnecté l’ordinateur du réseau par précaution.
Si l’antivirus ne pouvait pas garantir la légitimité d’un paquet autrement que par le canal de distribution, j’aurai grave peur.
D’ailleurs, l’éditeur antivirus peut très bien se faire cracker son serveur, si le pirate place de fausses définitions de virus (dans le but de provoquer un déni de service en déclarant comme nuisance des fichiers critiques), le client n’utilisera pas ces fausses définitions, car elles ne seront pas correctement signées. Contrairement au serveur web https qui doit posséder la clé privée sur le serveur, la clé privés qui signe les définitions de virus sont à la maison, chez l’éditeur, et pas sur une machine en vrac sur le net.
Idem pour Debian : t’auras beau t’introduire sur un miroir et voler la clé privée pour la connexion https, tu pourras pas signer un paquet, donc les utilisateurs n’installeront pas tes paquets vérolés, même si tu arrives à spoofer complètement la connexion https parce que t’as choppé la clé privée du serveur : tu n’as pas la clé privé des paquets.
Bref, non, télécharger une base de virus par http n’est pas délirant si le protocole de distribution est conçu pour ne pas faire confiance au média.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 6.
La question est pas de zapper les signatures, la question est d'éviter de se faire une fourguer une vieille base, à la signature parfaitement valide.
Exemple con:
- Debian annonce que OpenSSL est pete chez eux, mettez à jour
- je te mitma, et je prétend que la dernière version à jour est celle qui a été patchee a la truelle par Debian.
- tu fait ton apt-get update, le client est content, tu penses être a jour, mais tu continues à utiliser l'ancienne version, dont la signature est toujours parfaitement valide.
- tu régénérés tes clés
- je t'attaque sur la base que tes clés sont faibles, et paf le serveur
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par claudex . Évalué à 5.
Donc ton client va te sortir une erreur parce que la signature du dépôt security est trop vieille.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 2.
24 heures après qu'un paquet avec un correctif critique soit sortie, ta debian va magiquement deviner ca?
Ca marche comment ca au juste?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par claudex . Évalué à 2.
Comme indiqué dans un autre commentaire, ça lit le fichier Release qui contient l'attribut
Valid-Until:. C'est 10 jours la validité pour security. Si tu es à 10 jours près (et typiquement, les failles critiques genre le bug openssl Debian ou Heartbleed, ça fait le tour la presse informatique, tu ne passe pas vraiment à côté). Je te conseille d'utiliser autre chose qu'un apt-get update mais plutôt de suivre la mailing list de sécurité et/ou le site web avec la liste des annonces.Mais dans le cas HTTPS te sauverait de ça, c'est un attaquant qui peut faire du MitM entre toi et le dépôts (tout en ayant une fenêtre assez longue et une faille qui lui permette une exploitation) mais pas un MitM à plus grande échelle (qui lui permettrait d'avoir un certificat par une CA) et donc les clients qui peuvent être attaqués sont limités (mais on a quand même décidé de te cibler toi).
HTTPS offre la confidentialité (partielle) dans ce cas mais vraiment plus d'intégrité.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTP remplacent ?
Posté par barmic . Évalué à 6.
La question n'est pas de s'interdire d'utiliser du https, mais d'avoir fait suffisamment de sécurité au dessus du protocole pour ne pas être obligé de faire migrer tout le monde brutalement. Ça permet de fournir des paquets de manière indépendante du transport que ce soit http, https, ftp, bittorrent, tftp ou je ne sais quoi tu aura des garanties que le projet considère comme suffisant. L'inverse serait vraiment grave en se sentant protéger du simple fait d'utiliser https alors que ça ne suffit pas du tout à te garantir que tes paquets ne sont pas frauduleux (ça te garantie juste que tu les a pris là où tu pensais).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Et accessoirement, de déléguer le boulot.
Un FAI n’a pas besoin de contacter Debian pour faire un dépôt, et les utilisateurs de ce FAI peuvent utiliser ce dépôt sans contacter Debian.
Quand je monte des miroirs Debian dans les murs d’une entreprise parce qu’Internet est ravitaillé par les corbeaux, les Debian installées sont très contentes d’utiliser mes miroirs, sans que je n’ai rien à faire, ni côté distrib installée, ni côté fournisseur (Debian), et heureusement.
Si la sécurité reposait uniquement sur le lien https, il faudrait que le certificat https du miroir de ton FAI soit signé par Debian, qui ne serait pas seulement un dépôt de paquet mais aussi une autorité, et devoir monter des audits pour vérifier qu’aucun FAI fait de la merde et être prêt à en révoquer… Bref un merdier monstre ! Si le protocole de distribution ne fait pas confiance au transport, ça simplifie grave les choses.
Bien sûr, rien n’empêche d’utiliser https via tor pour cacher à Debian qui tu est et cacher au reste du monde que tu utilises Debian et quel paquet tu utilises précisément. Ce sont différents outils qui répondent à des besoins de sécurité différents. Vérifier que son interlocuteur est le bon quelque soit le transporteur n’est pas le même besoin que de vérifier que le transporteur est celui préféré, et n’est pas le même besoin que le besoin d’être anonyme.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 1.
???
Pourquoi est ce qu'un fai aurait besoin de contacter Debian pour servir son miroir en https?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Parce que le certificat https de ton fai prouve que c’est bien ton fai qui héberge le miroir, mais ne prouve pas que les paquets qu’il héberge sont des paquets Debian.
Pour que le certificat https de ton fai prouve que ce sont bien des paquets Debian qui sont hébergés, il faudrait que Debian signe le certificat de ton fai à condition que ton fai s’engage à n’héberger que des paquets Debian (ou autre contrat de ce style).
si https était utilisé pour assurer l’authenticité des paquets entre Debian et l’utilisateur, alors oui il faudrait que tout miroir se mette d’accord avec Debian pour garantir la chaîne de sécurité, ce qui serait d’une lourdeur administrative que personne ne veut.
C’est pourquoi https n’est pas du tout là pour garantir l’authenticité des paquets, si tu utilises https pour te connecter à un dépôt Debian, c’est uniquement pour t’assurer que tu parles bien à ton dépôt Debian préféré (et pas à un mitm qui tracerait tes usages), mais pas pour t’assurer que les paquets sont ceux que tu attends.
Bref, https c’est juste pour t’assurer que seul ton miroir sache que tu installes
hot-babe, pas pour t’assurer que ce sont bien des bellaminettes dedans.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: HTTP remplacent ?
Posté par groumly . Évalué à 2.
Ah bah, heureusement que j'ai explicitement dit plusieurs que c'était pas le sujet.
Sans deconner!
Bon, on va arrêter la, hein.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: HTTP remplacent ?
Posté par Ramón Perez (site web personnel) . Évalué à 0.
Le rebootent !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.