Où est le problème ?
Ça tournait depuis 2 ans et soudainement les gens de tails décident de prendre en considération les exigences de microsoft, je n’y suis pour rien.
Le navigateur ne pose pas de problème dans mon cas de figure, c’est la ligne de commande et gnome-firmware (je n’ai essayé que ces solutions) qui sont bloqués.
Enquiquiné avec quoi ?
Quelle config initiale ?
Non, ça n’est pas Microsoft, c’est le système de secure boot (largement initié par Microsoft il est vrai). Tous les OS installés ont un système de mise à jour du bios EFI et des bases de données des certificats.
Le fil va dérapé mais Apple OS est à Windows ce que Windows est à linux. Là je me bas pour qu’une personne puisse exécuter un qemu avec accélération sur un Mac M1 aarch64. Pourquoi? Pour faire tourner une version arm64 de la clef APESAM. Impossible de démarrer un mac M1 sur un périphérique extérieur sans modifier la machine. La seule solution que j’ai trouvé est de lancer un qemu qui utilise le périphérique extérieur comme disque, le tout avec l’accélération HVF. Oui, mais pour utiliser cette accélération, il faut avoir la certification d’Apple (une après midi et je n’ai pas fini). Cette certification est payante sauf si on est une gentielle association qui sème la paix et le bonheur dans le monde (c’est notre cas 
).
Donc en clair tu as une machine et tu ne peux PAS l’utiliser comme tu veux. Entre autres, l’installation de linux sur les mac ARM64 est quasi impossible à ce jour.
Les PCs standards ARM64 et les Raspberries boutent ss pbm (à vérifier, je n’ai pas bcp de recul)
PS: peut être à mettre ds pause café ça non?
Tu veux dire qu’il n’y a pas d’échappatoire à cette histoire de certificats ?
Je suis obligé d’y passer ?
Au final, existe t-il une solution pour libérer temporairement le port 443 ?
Merci.
sudo iptables -F INPUT
sudo iptables -F OUTPUT
sudo iptables -F FORWARD
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F PREROUTING
sudo iptables -F POSTROUTINGSi iptables n’existe pas, essaye xptables
C’est surtout les routing et output qui comptent
Je vous suggère la lecture de cette explication complète de Zargos
Fonctionnement de secure boot Debian
En résumé, la chaine de boot sécurisée est
UEFI → Shim → Grub → kernel
Par défaut, seules les clés Microsoft sont présentes dans le bios/EFI . Celles ci expirent ( cf votre premier message). La première étape est de voir si le fabricant de votre carte mère fourni un bios/efi mise à jour avec ces clés ( pour un CM de plus de 5-6 ans, c’est pas évident).
Si ce n’est pas le cas, vous pouvez soit désactiver secureboot ou vous pouvez intégrer votre propre clé et signer kernel et module avec celle ci ( loin d’etre simple, et à faire à chaque maj).
Mise à joru du BIOS précisément.
Microsoft et fournisseur de la carte mère.
Pour M$ c’est normal, c’est eux qui sont à l’origine de la techno.
Ou bien directement nftables? Car si Tail est issu de Debian, c’est nftables au cœur du pare-feu.
Quand au port 443, il n’y a aucune corrélation en le Secure Boot et le protocole HTTPS. Je ne vois pas le rapport ici.
Bonjour,
j’ai déjà tenté de désactiver le secure boot, sans succès.
Bonjour,
merci pour ta réponse.
Cette suite de commandes me permettraient de pouvoir éliminer temporairement cette problématique de port 443 ?
Voilà la réponse que j’obtient de la part de la base de données :
**sudo fwupdmgr refresh**
**[sudo] Mot de passe de amnesia :**
**Mise à jour lvfs**
**Téléchargement… [ - ]**
**Failed to download metadata for lvfs: failed to download file: Failed to connect to cdn.fwupd.org port 443 after 790 ms: Could not connect to server**
Idem avec gnome-firmware :
Concernant iptables, voilà ce que j’ai pu trouver :
**sudo iptables -L --line-numbers**
**[sudo] Mot de passe de amnesia : **
**Chain INPUT (policy DROP)**
**num target prot opt source destination **
**1 ACCEPT all -- anywhere anywhere state ESTABLISHED**
**2 ACCEPT all -- anywhere anywhere **
**3 ACCEPT tcp -- 10.200.1.2 10.200.1.1 multiport dports 9050,951**
**4 ACCEPT tcp -- 10.200.1.6 10.200.1.5 multiport dports 951**
**5 ACCEPT tcp -- 10.200.1.10 10.200.1.9 multiport dports 951**
**6 ACCEPT tcp -- 10.200.1.14 10.200.1.13 multiport dports 9050,951**
**7 REJECT all -- anywhere 10.200.1.0/24 reject-with icmp-port-unreachable**
**Chain FORWARD (policy DROP)**
**num target prot opt source destination **
**1 ACCEPT all -- anywhere anywhere **
**2 ACCEPT all -- anywhere anywhere **
**Chain OUTPUT (policy DROP)**
**num target prot opt source destination **
**1 ACCEPT all -- anywhere anywhere state ESTABLISHED**
**2 ACCEPT icmp -- anywhere anywhere state RELATED**
**3 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match _apt**
**4 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match proxy**
**5 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match nobody**
**6 ACCEPT tcp -- anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend**
**7 ACCEPT tcp -- anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match htp**
**8 ACCEPT tcp -- anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend**
**9 ACCEPT tcp -- anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-iuk-get-target-file**
**10 log_reject tcp -- anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia**
**11 log_reject tcp -- anywhere localhost tcp dpt:9052 owner UID match amnesia**
**12 ACCEPT tcp -- anywhere localhost tcp dpt:9052 owner UID match root**
**13 ACCEPT tcp -- anywhere localhost tcp dpt:951 owner UID match root**
**14 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match amnesia**
**15 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match amnesia**
**16 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match htp**
**17 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match htp**
**18 log_reject udp -- anywhere localhost udp dpt:domain owner UID match _apt**
**19 log_reject udp -- anywhere localhost udp dpt:mdns owner UID match _apt**
**20 ACCEPT udp -- anywhere localhost udp dpt:domain owner UID match root**
**21 ACCEPT udp -- anywhere localhost udp dpt:mdns owner UID match root**
**22 ACCEPT tcp -- anywhere localhost tcp dpt:4101 flags:FIN,SYN,RST,ACK/SYN owner UID match Debian-gdm**
**23 ACCEPT tcp -- anywhere localhost tcp flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia**
**24 ACCEPT tcp -- anywhere anywhere owner UID match clearnet**
**25 ACCEPT udp -- anywhere anywhere owner UID match clearnet udp dpt:domain**
**26 ACCEPT tcp -- anywhere anywhere owner UID match debian-tor tcp flags:FIN,SYN,RST,ACK/SYN state NEW**
**27 ACCEPT udp -- anywhere anywhere owner UID match debian-tor udp dpt:domain**
**28 lan all -- anywhere 10.0.0.0/8 **
**29 lan all -- anywhere 172.16.0.0/12 **
**30 lan all -- anywhere 192.168.0.0/16 **
**31 log_reject all -- anywhere anywhere **
**Chain lan (3 references)**
**num target prot opt source destination **
**1 log_reject tcp -- anywhere anywhere tcp dpt:domain**
**2 log_reject udp -- anywhere anywhere udp dpt:domain**
**3 log_reject udp -- anywhere anywhere udp dpt:netbios-ns**
**4 ACCEPT all -- anywhere anywhere **
**Chain log_reject (8 references)**
**num target prot opt source destination **
**1 LOG all -- anywhere anywhere LOG level debug uid prefix "Dropped outbound packet: "**
**2 REJECT all -- anywhere anywhere reject-with icmp-port-unreachable**
Merci.
Bonjour,
je ne sais pas si c’est le cas mais le système me renvoie systématiquement la même erreur concernant le port 443 (cf. ma réponse précédente).
Merci.
C’est un défaut de la configuration de ton système.
Visiblement les commandes sudo n’ont pas efface tes règles iptables existantes
Bon fais un
Sudo iptables -I OUTPUT --dport 443 -j ACCEPT (Syntaxe à vérifier) Mais c’est curieux, les -F auraient dû tout effacer
Vous êtes sur qu’il n’y a pas un UFW ou autre d’utilisé? car pour une distro de ce type, je doute que la ligne de commande soit la seule configuration possible.
Le parefeu est par des règles nftables gérées par iptables, nftables ou xptables, il s’agit juste de faire une mise à jour ponctuelle. Donc ici les iptables -F suppriment toutes règles, les iptables -P mettent les politiques par défaut à ACCEPT et les iptables -F *ROUTING suppriment toutes les redirections possibles. L’étonnant est qu’il y ait encore des règles iptables.
Démolir une configuration pour un seul accès occasionnel, c’est quand même excessif, donc oui la ligne de commande me parait idéale
Peut être, je ne peux pas te le confirmer.
Ce que je peux te confirmer c’est que je n’ai rien modifié, la distrib est entièrement d’origine.
Mais finalement ça ne m’étonne pas tant que ça, quand j’installe falkon ou chromium, impossible de surfer, toutes les requêtes sont refusées, ça ressemble beaucoup à mon problème de mise à jour.
Pour ma part, je n’ai touché à rien.
sudo iptables -I OUTPUT --dport 443 -j ACCEPT
[sudo] Mot de passe de amnesia :
iptables v1.8.11 (legacy): unknown option "--dport"
Try `iptables -h' or 'iptables --help' for more information.
Apparement, ça continu à coincer.
Si je comprends bien, tu me propose de « démolir » toute la config du pare-feu pour voir si la maj peut fonctionner ?
C’est temporaire, d’accord, mais est-ce bien prudent, même pour quelques minutes ?
Je t’avoue que ça me fout un peu les jetons de faire ça.
J’ai oublier le -p tcp:
sudo iptables -I OUTPUT -p tcp --dport 443 -j ACCEPT mais c’est curieux que les preières commandes n’aient rien fait. Tu as la sortie lors des commandes
sudo iptables -F INPUT
sudo iptables -F OUTPUT
sudo iptables -F FORWARD
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F PREROUTING
sudo iptables -F POSTROUTINGSinon, ce que tu peux faire si tu as la trouille:
Avant:
sudo iptables-save > regles_de_la_mort_qui_tuepuis les manips diverses (tu en profites pour nous donner le fichier obtenu, ça precisera la config de Tails
et lorsque tu as fini
iptables-restore < regles_de_la_mort_qui_tueÇa remet tout en place, mais n’exagerons rien, je doute que ta machine héberge un serveur ouvert sur l’exterieur. Je pense que les règles sont faites pour rendre la machine non visible sur le réseau (non réponse aux pings via -j DROP par exemple) et doit redirigé les requetes pour l’extérieur vers Tor ou autre. Je me demande ce qu’elle fait pour le DNS?
La même, ce genre d’outils est réellement pas fait pour être modifier mais utiliser tel quel … je dit pas que ça ne conviens pas pour consulter un forum, juste que prendre le temps de préparer une clé usb avec Debian live et une persistance ce serait exactement pareil à l’utilisation mais nettement plus simple à la maintenance 
Mais pourquoi ne pas faire la mise à jour du bios et des firmwares depuis un live Ubuntu ou Debian ?
Et pourquoi ne pas faire une image du disque d’installation du PC pour conserver une copie du Windows que t’as payé mais que tu ne veux sans doute pas utiliser sur un disque USB, ça te permettrai de pouvoir installer ce que tu veux et utiliser sans prise de tête ton PC
Et en finalité pourquoi ne pas utiliser selon ton matériel un utilitaire directement embarqué sur clé usb pour mettre à jour ?