Auteur Sujet: Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?  (Lu 2648 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?

Aujourd'hui sur Ubuntu apt-transport-https est installé par défaut sur tous les Ubuntu (serveurs, PC avec interface graphique,...)

Il permet de faire des mises à jour en utilisant https, à la place de http / ftp traditionnellement utilisé.

Problème : Canonical n'enregistre que du http ou du ftp pour les serveurs miroirs.

Formulaire pour l'enregistrement d'un serveur miroir d'Ubuntu :


https n'est pas indispensable pour la sécurité, car les paquets Ubuntu .DEB sont signés de bout en bout avec GPG. En cas d'attaque man-in-the-middle attack (MITM) ou de serveur miroir avec des paquets corrompus, la corruption sera détectée parce que les signatures GPG ne seront pas valides.


Je vois 3 avantages à utiliser https :

- https fournit un léger avantage de la vie privée en ce qu'elle obscurcit les paquets que vous téléchargez : il est plus compliqué de connaître votre version d'Ubuntu et impossible de savoir quels paquets vous téléchargez.

- https permet proposer un autre protocole, pour ceux qui ont des limitations sur le port 80, à cause d'un proxy qu'ils ne contrôlent pas.

- https enfin surtout de compliquer une attaque si une vulnérabilité fait qu'il est possible de contourner la signature de bout en bout avec GPG. Je fantasme ? Voici un bug remonté le 5 décembre 2016 qui a été rapidement corrigé : https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

Nous venons été mis au courant d'un problème de sécurité en amont qui affecte la validation des signatures sur le fichier InRelease. Ce bug est de suivre les progrès pour elle.

Il permet d'attaquer un dépôt via des attaques MITM, contournant la signature du fichier InRelease.

Il fonctionne en faisant un appel à getline () échouent avec ENOMEM, qui est pas documenté comme une erreur pour cela, mais découle du fait que getline () peut allouer de la mémoire. Dans un tel cas, apt traiterait la première partie du fichier en tant que fichier de sortie valide.

[...]

Comme vous pouvez le voir, si l'attaquant a de la chance avec le randomisation ASLR, il n'y a pas d' avertissements de sécurité et "apt-get upgrade" installe simplement le malveillant version du package.


=> CVE-2016-1252


Pourquoi https n'a pas proposé ? Je vois deux points bloquants qui sont aujourd'hui levés.

- Difficulté de gestion d'un certificat pour des serveurs miroirs : Aujourd'hui Let’s Encrypt semble répondre à la problématique

- Charge supplèmentaire liée au chiffrement sur les serveurs : Aujourd'hui, le jeu d'instruction AES / AES-NI (Advanced Encryption Standard New Instructions) est présent sur tous les serveurs. Je pense qu'il n'y a plus de serveur miroir Ubuntu qui gère plus de 1 Gb/s de trafic qui n'a pas ces instructions.



Trouvez-vous pertinent que je demande à Canonical de rajouter les connexions à un miroir en https et de supprimer FTP ? (il me semble vraiment inutile en 2016 de proposer le protocole FTP)

Les téléchargements resteraient par défaut en http, mais ceux qui le souhaitent pourraient chiffrer le trafic.
Peut-être que dans quelques années une seconde étape pourraient être franchi en mettant https par défaut. Il me semble inutile de parler de cette seconde étape tant que la première n'est pas réalisée.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 327
  • Malissard (26)
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #1 le: 18 décembre 2016 à 10:54:30 »
FTP peut éventuellement être plus avantageux sur des connexions à forte latence. Le supprimer pourquoi pas mais bon...

Par contre, ajouter https me parait clairement avantageux.

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #2 le: 19 décembre 2016 à 08:43:55 »
Pourquoi le FTP, qui utilise TCP, tout comme http, serait plus intéressant sur des lignes à forte latence ?

Il me semble qu'il y a plus d'échanges avant de commencer le transfert, en FTP que en http.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 327
  • Malissard (26)
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #3 le: 20 décembre 2016 à 21:20:23 »
"Plus d'échange" ouais enfin c'est quand même limité.

Le gros avantage de TCP c'est son flux data séparé et que le protocole est plus basique à gérer niveau CPU. Bon aujourd'hui vu nos CPU, la différence ne doit plus être trop flagrante...


kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 410
  • FTTH 1Gb/s sur Paris (75)
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #4 le: 20 décembre 2016 à 22:20:06 »
S'ils ne sont pas passé a HTTPS c'est principalement pour les gains de cache des proxy que permet HTTP: ceux qui gere des mirroirs ou des flottes de machines sous ubuntu apprécient le gain de volume.

Apres rien n’empêche d'utiliser HTTPS pour soi-meme. il suffit de trouver un mirroir qui supporte HTTPS.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 465
  • Paris (15ème)
    • MilkyWan
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #5 le: 20 décembre 2016 à 22:28:10 »
Vivien : Tu peux passer bouyguestelecom.ubuntu.lafibre.info en HTTPS ? J'utilise ce nom de domaine là perso, vu que tu gère le domaine, c'est plus simple de mettre le certificat :)

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #6 le: 09 janvier 2017 à 21:49:32 »
C'est fait !

https://bouyguestelecom.ubuntu.lafibre.info/

Pour passer du serveur par défaut pour la France en http à https :
sudo sed -i -e "s/http:\/\/fr.archive.ubuntu.com/https:\/\/bouyguestelecom.ubuntu.lafibre.info/g" /etc/apt/sources.list
sudo sed -i -e "s/http:\/\/security.ubuntu.com/https:\/\/bouyguestelecom.ubuntu.lafibre.info/g" /etc/apt/sources.list


Spécialement pour toi, si il y a déja bouyguestelecom.ubuntu.lafibre.info, pour mettre le https :
sudo sed -i -e "s/http:\/\/bouyguestelecom.ubuntu.lafibre.info/https:\/\/bouyguestelecom.ubuntu.lafibre.info/g" /etc/apt/sources.list

J'ai souhaité mettre aussi http://fr.archive.ubuntu.com en https, mais Let's Encrypt refuse. J'imagine que c'est par ce que le domaine principal à un certificat "Extended Validation Package" avec la couleur verte.

Voici l'erreur que j'obtiens pour fr.archive.ubuntu.com :
An unexpected error occurred:
Policy forbids issuing for name
Please see the logfiles in /var/log/letsencrypt for more details.


https est donc disponible mais pas avec le bon certificat.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 465
  • Paris (15ème)
    • MilkyWan
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #7 le: 09 janvier 2017 à 22:20:27 »
Merci beaucoup ! Je vais tester ça de ce pas :)

kcdtv

  • Client FAI autre
  • *
  • Messages: 100
  • Internacionalunya 00
    • wifi-libre
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #8 le: 27 mars 2017 à 07:52:36 »
  Bonne idée.
On est en 2017:  Let's encrypt and https everywhere! Nom d'une pipe.  :D
Une alternative intéressante: apt-transport-tor package
On aura du chiffrement de bout en bout en passant par le réseau TOR plus de l'"anonymat IP" grâce au réseau
Ça rend la tàche très très difficile pour celui qui chercherait à exploiter les données qui transitent en clair par apt...
Bonne chance à lui, il en aura besoin.  :D

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #9 le: 27 mars 2017 à 08:34:58 »
Justement Let's Encrypt refuse pour les noms de domaines en ubuntu.com :
J'ai souhaité mettre aussi http://fr.archive.ubuntu.com en https, mais Let's Encrypt refuse. J'imagine que c'est par ce que le domaine principal à un certificat "Extended Validation Package" avec la couleur verte.

Voici l'erreur que j'obtiens pour fr.archive.ubuntu.com :
An unexpected error occurred:
Policy forbids issuing for name
Please see the logfiles in /var/log/letsencrypt for more details.


https est donc disponible mais pas avec le bon certificat.

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #10 le: 06 mai 2017 à 16:03:09 »
FTP peut éventuellement être plus avantageux sur des connexions à forte latence. Le supprimer pourquoi pas mais bon...

Par contre, ajouter https me parait clairement avantageux.

Debian va supprimer le FTP pour les mises à jour : https://www.debian.org/News/2017/20170425.fr.html
Les mises à jour ne pourront plus se faire que en http. (Debian support https pour les mises à jour, mais http://ftp.debian.org n'est pas encore disponible en https)
Le FTP est un protocole qui date d'avril 1971 (RFC 1142) tandis que HTTP  date de mai 1996 (RFC 1945).

Debian : Fermeture des services FTP publics

25 avril 2017

Après de nombreuses années au service des besoins des utilisateurs et une utilisation encore plus décroissante en faveur de meilleures options, tous les services FTP debian.org destinés au public seront fermés le 1er novembre 2017. Il s'agit de :
- ftp://ftp.debian.org
- ftp://security.debian.org

Cette décision est motivée par les considérations suivantes :
- 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.

Informations pour les utilisateurs

Les noms de DNS ftp.debian.org et ftp.<CC>.debian.org resteront inchangés. Mais les miroirs seront seulement accessibles par HTTP :
- http://ftp.debian.org
- http://security.debian.org

Informations pour les développeurs

Les services des développeurs Debian ne seront pas affectés. Il s'agit des files d'attente d'envoi pour à la fois l'archive principale « main » et l'archive de sécurité :
- ftp://ftp.upload.debian.org
- ftp://security-master.debian.org

À propos de Debian

Le projet Debian est une association de développeurs de logiciels libres qui offrent volontairement leur temps et leurs efforts pour produire le système d'exploitation complètement libre Debian.


Dommage de ne pas en profiter pour mettre du https.

A noter que le FTP pour fr.archive.ubuntu.com n'existe plus depuis que j'ai repris le service, il y a un peu plus d'un an. Cela fait un moment que Ubuntu ne propose plus ce protocole, donc je ne pense pas que cela ai eu un impact. Le FTP pour ftp://archive.ubuntu.com/ (géré directement par Canonical) est lui toujours disponible.

vivien

  • Administrateur
  • *
  • Messages: 29 564
    • Twitter LaFibre.info
Demander à Canonical de rajouter https pour les mises à jour d'Ubuntu ?
« Réponse #11 le: 06 mai 2017 à 20:36:54 »
Debian est peut-être en train de changer la façon de gérer les miroirs.

En plus des miroirs gérés de façon traditionnelle (liste disponible sur https://www.debian.org/mirror/list.fr.html ) avec pour la France http://ftp.fr.debian.org/ qui est géré par Free (pas de https proposé), il y a un second type de miroir cloud qui est disponible en https : https://deb.debian.org/

Il est possible de faire de la répartition de charge entre plusieurs acteurs qui ont des miroirs autour du monde.
Aujourd'hui le service est proposé par les CDN Amazon CloudFront et Fastly’s edge cloud platform.

Le principe est de passer par les enregistrements "SRV" proposés par le DNS.

Cela permet de gérer la priorité et la répartition de charge finement :

Le champ priorité est similaire au champ de même nom des enregistrements MX. Les clients commencent par utiliser l'enregistrement SRV de plus basse priorité, et se rabattent sur les autres enregistrements uniquement en cas d'échec de la connexion. Ainsi, un service peut avoir un serveur désigné comme serveur de secours, qui sera seulement utilisé en cas de panne du serveur primaire: il suffit pour cela d'insérer un enregistrement SRV avec une priorité plus élevée que pour le serveur primaire.

Lorsqu'un service possède plusieurs enregistrements SRV de même priorité, les clients utilisent alors le champ poids pour décider quel serveur utiliser. Le poids ne prend son sens que lorsqu'il est mis en relation avec le poids des autres enregistrements de même priorité (toujours pour un service donné).

Dans l'exemple ci-dessous, on utilise à la fois les champs priorité et poids, afin de fournir simultanèment une répartition de charge et un service de secours.
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 gros-serveur.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 20 5060 petit-serveur2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 100 5060 serveur-de-secours.example.com.


Les trois premiers enregistrements ont tous une priorité de 10. Les clients vont donc devoir utiliser le champ poids afin de déterminer quel serveur contacter. Pour ce champ, la somme des trois valeurs est 100, donc gros-serveur.example.com sera utilisé 60 % du temps, et chacun des deux autres (petit-serveur1 et petit-serveur2) sera utilisé 20 % du temps. Si, d'aventure, gros-serveur devenait indisponible, les deux "petits serveurs", seuls en piste, se partageraient alors la charge, ayant un poids identique.

Par ailleurs, si ces serveurs de priorité 10 deviennent tous trois indisponibles, l'enregistrement de priorité immédiatement supérieure sera choisi, en l'occurrence serveur-de-secours.example.com. Il peut s'agir d'une machine géographiquement éloignée des trois autres, donc a priori non touchée par la cause de l'indisponibilité de celles-ci.

La répartition de charge fournie par les enregistrements SRV est forcèment limitée, étant donné que l'information est essentiellement statique. La charge réelle des serveurs n'est pas prise en compte.

Source : Wikipedia

Par contre, je ne récupère pas les enregistrements SRV avec un dig, vous comprenez pourquoi ?

$ dig -t SRV deb.debian.org +short
static.debian.org.
$ dig -t SRV static.debian.org +short

$ dig -t A deb.debian.org +short
static.debian.org.
128.31.0.62
130.89.148.14
5.153.231.4
149.20.4.15
140.211.166.202
$ dig -t A static.debian.org +short
130.89.148.14
5.153.231.4
149.20.4.15
140.211.166.202
128.31.0.62

$ dig -t AAAA deb.debian.org +short
static.debian.org.
2605:bc80:3010:b00:0:deb:166:202
2001:4f8:1:c::15
2001:610:1908:b000::148:14
2001:41c8:1000:21::21:4
$ dig -t AAAA static.debian.org +short
2001:4f8:1:c::15
2001:610:1908:b000::148:14
2001:41c8:1000:21::21:4
2605:bc80:3010:b00:0:deb:166:202

 

Mobile View