La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: vivien le 17 décembre 2016 à 21:27:17
-
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://lafibre.info/testdebit/ubuntu/201612_mirror_ubuntu.png)
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 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=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.
-
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.
-
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.
-
"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...
-
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.
-
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 :)
-
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 DNS CAA ou qq chose de ce type interdit cette autorité de certification.
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.
-
Merci beaucoup ! Je vais tester ça de ce pas :)
-
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 (https://launchpad.net/ubuntu/+source/apt-transport-tor)
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
-
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.
-
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.
-
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 (https://fr.wikipedia.org/wiki/Enregistrement_de_service)
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
-
Il faut faire comme ceci:
18% [jack:~]dig -t SRV _http._tcp.deb.debian.org +short
10 1 80 prod.debian.map.fastly.net.
10 1 80 dpvctowv9b08b.cloudfront.net.
-
...Il est possible de faire de la réparation de charge entre plusieurs acteurs qui ont des miroirs autour du monde...
...Ne voulais-tu pas dire répartition ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
Mail que je viens d'envoyer :
(en Anglais)
Hello,
Ubuntu mirrors are currently available with two protocols: http and ftp (+ rsync for synchronization)
Would it be possible to remove ftp, which is an obsolete protocol, and to add the possibility to the mirrors that wish to propose https in addition to http?
Note that Debian will no longer offer FTP from 1 November 2017: https://www.debian.org/News/2017/20170425.en.html the FTP protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons.
I see 3 advantages to using https:
- https obscures the packages you download: it is more complicated for someone listening to your internet connection to know your version of Ubuntu and can not know which packages you download.
- https allows to bypass the limitations on port 80: proxies block content, when some keyword appears in the URL.
- https can finally complicate an attack, if a vulnerability makes it possible to bypass the end-to-end signature with GPG like this bug 1647467: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
I maintain a mirror available in https: https://bouyguestelecom.ubuntu.lafibre.info/
I do not have the possibility today to reference the fact that my mirror proposes https.
Regards,
Vivien GUEANT
La version française :
Bonjour,
Les miroirs Ubuntu sont actuellement disponibles avec deux protocoles : http et ftp (+rsync pour la synchronisation)
Serait-il possible de supprimer ftp, qui est un protocole obsolète, et de rajouter la possibilité aux miroirs qui le souhaitent de proposer https en plus de http ?
A noter que Debian ne va plus proposer de FTP à partir du 1er novembre 2017 : https://www.debian.org/News/2017/20170425.fr.html le protocole FTP est peu efficace et demande l'ajout de bidouillages compliqués pour les pare-feu et les démons de répartition de charge.
Je vois 3 avantages à utiliser https :
- https obscurcit les paquets que vous téléchargez : il est plus compliqué pour une personne écoutant votre connexion internet de connaître votre version d'Ubuntu et impossible de savoir quels paquets vous téléchargez.
- https permet de contourner les limitations sur le port 80: des proxy bloquent du contenus, quand certains mot-clé apparaissent dans l’URL.
- https permet enfin de compliquer une attaque, si une vulnérabilité fait qu'il est possible de contourner la signature de bout en bout avec GPG comme ce bug 1647467 : https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
Je maintien un miroir disponible en https: https://bouyguestelecom.ubuntu.lafibre.info/
Je n'ai pas aujourd'hui la possibilité de référencer le fait que mon miroir propose du https.
Cordialement,
Vivien GUEANT
-
Vive le FTP, https ok mais pas en supprimant le FTP >:(
C'est un protocole simple et très fonctionnel.
-
Pour information, mon mail n'a pas eu de réponse.
Si Ubuntu permet de référencer un miroir en FTP sur https://launchpad.net/ubuntu/+archivemirrors , il ne permet plus aux clients de l'utiliser sans modifier a la main /etc/apt/sources.list
C'est un protocole très complexe pour les NAT et qui ne passe pas sur certains réseaux : En effet, il faut modifier l'IP privée en IP publique dans les paquets de commande FTP.
Dans les arguments de Debian pour arrêter le FTP, il y a la sécurité : le FTP propose de nombreux angles d'attaque. Par exemple, dans la configuration d'un serveur, il ne faut pas oublier de mettre "AllowForeignAddress off" pour interdir au client d'indiquer des IP qui ne sont pas les siennes (et oui FTP permet ce type de truc tordu)
Bref, je suis preneur d'un cas où le FTP est plus pertinent que le http pour la mise à jour d'Ubuntu.
-
Vive le FTP, https ok mais pas en supprimant le FTP >:(
C'est un protocole simple et très fonctionnel.
Pour avoir maintenu une implèmentation d'un serveur FTP, non, FTP n'est ni "simple", ni "fonctionnel", dans le sens où il y a à peu près autant d'implèmentations différentes que de serveurs et de clients...
HTTP n'est certes pas la panacée, mais FTP pose beaucoup de problèmes en pratique.
-
+1, j'éradique FTP où je peux.
-
Pour avoir maintenu une implèmentation d'un serveur FTP
Laquelle par curiosité ?
J'utilisais ProFTPD dans le passé. Il est toujours activement maintenu : La dernière version majeure est sortie en avril 2017.
-
Pour information, mon mail n'a pas eu de réponse.
Normal, HTTPS a plus d'inconvénient que d'avantages. Regarde ton premier message :
- Tu avances l'argument de la vie privée : on parle de mise à jour d'un OS là. Donc faire un lien entre une "vie" et une mise à jour... wouah. En quoi ça intéresse les Nestlé, les Unilever, les Kraft Foods, les Lactalis, etc de savoir que tu passes de kernel 36 à 37 ?
- Tu parles d'un proxy que les gens ne contrôlent pas. Au contraire, c'est clairement un avantage pour HTTP, un proxy ça défonce sa maman quand tu mets à jour tout ton LAN avec du cache en interne. C'est super efficace sur une longue liste de petits paquets où 1 requête = 1 paquet.
- Tu dis qu'HTTP a eu une faille, mais qu'elle est corrigée. Baaah si elle est corrigée, c'est tant mieux pour HTTP.
Dans les arguments de Debian pour arrêter le FTP, il y a la sécurité : le FTP propose de nombreux angles d'attaque. Par exemple, dans la configuration d'un serveur, il ne faut pas oublier de mettre "AllowForeignAddress off" pour interdir au client d'indiquer des IP qui ne sont pas les siennes (et oui FTP permet ce type de truc tordu)
Ca n'a rien d'un truc tordu. On appelle ça du FXP. C'est très utilisé pour faire des migrations de serveur à serveur... tout en restant sur son client dans un contexte où les gens étaient en ADSL, voire moins et qu'il était impensable d'utiliser sa propre connexion. Genre bouger l'hébergement d'un site d'un shared à un autre, et certains fichiers lourds. Ca évite de downloader et de réuploader comme un con. Là, pouf, tu fous direct de l'ancien serveur vers le nouveau avec un drag'n'drop. Ca m'a aidé de nombreuses fois. ;)
Bref, je suis preneur d'un cas où le FTP est plus pertinent que le http pour la mise à jour d'Ubuntu.
Grosso-modo, c'est utile pour les grosses mises à jour avec de petites connexions. Le FTP garde une session active tout le long (avec HTTP non, sauf KeepAlive, mais avec des petites connexions tu oublies, ça timeout), le FTP a très peu d'overhead dans chaque requête (avec HTTP on s'en fout de connaitre ton navigateur, le contenu accepté ou le serveur utilisé), et FTP transfère en binaire de base (même poids de fichier = poids de téléchargement, là où HTTP te fait des surprises en transférant en base64 qui rajoute 1/3 du poids lol, ou du chunked qui rajoute de l'hexa durant le transfert).
Perso j'utilise HTTP, notamment pour pouvoir mettre en cache les fichiers téléchargés via un proxy. Une fois que tu as gouté à ça, chaque MàJ devient un plaisir :)
-
Laquelle par curiosité ?
En fait, c'était une implèmentation propriétaire. On avait implèmenté un serveur FTP/FTPS qui était mappé directement sur du Azure Storage (sans utiliser de système de fichiers local). Bref, c'était un travail d'équilibriste entre coller aux RFC et supporter les implèmentations merdiques de clients FTP qui peuvent exister dans des systèmes d'entreprise un peu legacy...
Sans compter la gestion des ports en FTP qui complexifie les déploiements dès qu'on essaie de faire du load-balancing :)
-
Je ne demande pas d'imposer https par défaut : je demande de le proposer en plus de http.
- Tu avances l'argument de la vie privée : on parle de mise à jour d'un OS là. Donc faire un lien entre une "vie" et une mise à jour... wouah. En quoi ça intéresse les Nestlé, les Unilever, les Kraft Foods, les Lactalis, etc de savoir que tu passes de kernel 36 à 37 ?
Si ton lien est sur écoute, cela permet de savoir quels logiciels tu possèdes avec quelles faille de sécurité, vu qu'il connaît avec exactitude le fichier téléchargé ou qui n'a pas été téléchargé au vu de ton historique.
- Tu parles d'un proxy que les gens ne contrôlent pas.
Je parle de proxy qui vont bloquer ta mise à jour au cause de la présence d'une chaîne de caractère interdite.
J'ai déjà été empêché d'accéder à un phpmyadmin en http depuis une grande entreprise pour ces raisons. Passer le phpmyadmin en https et le proxy ne peut plus te bloquer.
- Tu dis qu'HTTP a eu une faille, mais qu'elle est corrigée. Baaah si elle est corrigée, c'est tant mieux pour HTTP.
Si il y a déjà eu une faille, cela pourrait se reproduire. Bref en sécurité on préfère empiler les sécurités, comme ça en cas de défaillance d'une sécurité, cela limite ce qu'il est possible de faire. Les hackers sont obligés d'utilisés plusieurs failles pour réussir.
-
Question posée à Canonical en marge d'un échange sur push mirroring : Is-it possible to reference on https://launchpad.net/ubuntu/+mirror/bouygues-telecom hosting Ubuntu mirror in http secure (https in addition of http and rsync)
Would it be possible to remove ftp, which is an obsolete protocol, and to add the possibility to the mirrors that wish to propose https in addition to http?
Note that Debian will no longer offer FTP from 1 November 2017: https://www.debian.org/News/2017/20170425.en.html the FTP protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons.
La réponse : So, short answer, there's no reason you can't drop FTP, as far as I know it's not a requirement for even a country mirror. In terms of adding HTTPS, there's quite a bit of complexity there and it's something we've been discussing but haven't reach a point where there's a good path going forward. We'd have to manage the SSL certificate for you, for example, if you wanted to support HTTPS on the fr.archive.ubuntu.com virtual host, among other things. It is something we're actively working on supporting and have a strong interest in doing, though I can't give you a timeline for it.
Traduction rapide de la réponse : Donc, pour répondre rapidement, il n'y a aucune raison pour laquelle vous ne pouvez pas abandonner le FTP, pour autant que je sache que ce n'est même pas une obligation pour un miroir de pays. Pour ce qui est de l'ajout du protocole HTTPS, cela entraîne beaucoup de complexité et c'est quelque chose dont nous avons discuté, mais qui n'est pas prêt. Nous devrons gérer le certificat SSL pour vous, par exemple, si vous souhaitez prendre en charge HTTPS sur l'hôte virtuel fr.archive.ubuntu.com, entre autres choses. C'est quelque chose que nous travaillons activement à soutenir et qui nous intéresse vivement, même si je ne peux pas vous donner un échéancier.
Il me semble plus simple de continuer sur le bug https://bugs.launchpad.net/ubuntu/+bug/1464064 ( Ubuntu apt repos are not available via HTTPS )
-
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 DNS CAA ou qq chose de ce type interdit cette autorité de certification.
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.
J'ai refais une tentative : plus de problème. https://ubuntu.lafibre.info/ a maintenant un certificat TLS.
Pour ceux qui utilisent l'autre nom de domaine, https://bouyguestelecom.ubuntu.lafibre.info/ est toujours utilisable avec un certificat (le même certificat qui certifie fr.archive.ubuntu.com)
(https://lafibre.info/images/ssl/201811_ssl_labs_fr.archive.ubuntu.com.png)
D'ailleurs, fr.archive.ubuntu.com a juste un CNAME (lien) vers bouyguestelecom.ubuntu.lafibre.info
$ dig AAAA fr.archive.ubuntu.com
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> AAAA fr.archive.ubuntu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39121
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;fr.archive.ubuntu.com. IN AAAA
;; ANSWER SECTION:
fr.archive.ubuntu.com. 335 IN CNAME bouyguestelecom.ubuntu.lafibre.info.
bouyguestelecom.ubuntu.lafibre.info. 338 IN AAAA 2001:860:f70a::2
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: dim. nov. 25 17:06:45 CET 2018
;; MSG SIZE rcvd: 127