Bonjour J'utilise captivity pour télécharger des émissions de TV depuis plusieurs années et évidemment ça m'a toujours télécharger un seul les fichiers comprenant le son et la vidéo mais maintenant ça me télécharge 2 fichiers un pour le son et un pour la vidéo est-ce que vous avez le même souci?
Cyril

Tu parles de France Télévisions ? Dernièrement, ils ont changé de procédé et généralisé celui qui avait déjà cours pour les émissions de France Ô et les jeux de Nagui : flux audio et vidéos sont désormais séparés, et il faut les réunir (mais attention : selon comment on s’y prend, j’ai remarqué que ça ne téléchargeait que les 10 premières secondes du flux audio, pas le reste).
 
Honnêtement, je te conseillerais de lâcher Captvty et de passer par l’outil qui est au cœur du fonctionnement de ce dernier : youtube-dl (secondé par ffmpeg ; les deux disposent d’une version pour Windows). Oui, c’est de la ligne de commandes, mais je t’assure qu’une fois que tu auras mémorisé les bons patterns (personnellement, je me suis fait une liste de commandes-types à adapter/compléter dans un fichier texte, et j’ai plus qu’à copier-coller ensuite dans une Invite de commandes), tu ne regretteras pas d’avoir abandonné Captvty !

Supprime ton message en trop (icône , et « Effacer le message »).

Ils ont dû mettre à jour le logiciel en conséquence, alors. Parce qu’ils ont modifié leur système (passage de playlists de fichiers *.ts en M3U8 vers le système de « dash » via un fichier manifest.mpd), en même temps qu’ils ont abandonné la définition 576p pour la remplacer par du 720p.

C'est normal, que le site de téléchargement contenant les exécutables et l'empreinte SHA-1 soit en HTTP et non HTTPS ?

pourquoi ? ca changerait quoi qu'il soit en SSL ?

a part je veux dire bien sur la joie de uper un topic pour ..., pourquoi déjà ?

S'il ne l'est pas, le fichier téléchargé peut ne pas être celui qui se trouve sur le site, ce qui est dangereux dans le cas d'un exécutable (qui peut contenir un malware). Voir https://security.googleblog.com/202 [...] ure_6.html par exemple.

D'autres gens qui ont soudainement des problèmes pour Scorpion sur W9 ? (ça marchait avant sans problème, et ça marche toujours pour certaines émissions de W9 mais pas pour d'autres: « indisponible » sans autre précision, est-ce dû à la demande de login quand on veut regarder l'émission sur le site de W9 ?)

C'est une conclusion très approximative car ça n'a pas de rapport direct.
Le SSL/TLS sert à chiffrer les échanges entre le client (le navigateur) et le serveur.
Le protocole ouvre un canal chiffré entre toi et le serveur, mais c'est à toi de t'assurer que le serveur en face est bien celui auquel tu t'attends.
Le navigateur ne fera pas de miracles.

Si le certificat SSL est valide et suffisamment trusté, tu peux faire passer n'importe quoi (c'est très facile avec Let's Encrypt par exemple).
C'est aussi comme ça que fonctionne les CDN et autres systèmes de Man In The Middle légitimes qui font du SSL Offload pour lire le contenu des requêtes et les rediriger où il faut.
Et c'est sans compter les problèmes d'autorités de certification obsolètes, ou corrompues (comme le certificat racine de Symantec en 2014 par exemple).

Rien à voir avec le fait que le site soit chiffré ou non : le site de Linux Mint était chiffré, et ça n’a pas empêché des pirates de mettre des ISO vérolées sur leurs serveurs en 2018 (voire avant, puisque la détection a eu lieu en février 2018, mais on ignore depuis quand ces fichiers étaient là ; le tout avec les hash qui allaient bien, histoire de rendre encore plus compliquée la détection de ces ISO trafiquées).

Je ne parlais pas de garantir l'intégrité des fichiers présents sur le serveur, mais de garantir que les fichiers consultés proviennent bien de ce serveur. Ce sont deux problèmes différents.

Justement ce n'est pas possible avec le protocole SSL/TLS seulement.

Une grande majorité des sites sont "servis" aux utilisateurs via un CDN (Cloudflare, Cloudfront, Akamai, ...) qui font office de cache mais aussi de reverse proxy à leur manière.
Et pour fonctionner en HTTPS, ils sont obligés de faire du Man in the Middle et de decoder le trafic pour savoir comment servir au mieux les requêtes (SSL offload). Le certificat qui est présenté à ton navigateur étant celui du CDN et non celui du serveur auquel tu souhaites accéder.
Sauf que dans ce fonctionnement, ce n'est pas toi qui décide où part ta requête (vers le site officiel ou non, etc...) mais le CDN.
Donc en cas de mauvaise configuration, de corruption ou d'attaque, rien ne te garantie ce que tu consultes/télécharges alors que pourtant, en tant qu'utilisateur, tu as l'impression que le site est "légitime".

Et ça c'est le fonctionnement normal sur internet pour tout site voulant être accessible partout autour du globe et rapidement.
Je ne parle donc pas des attaques du type Man in the Middle (non légitimes celles-là) : proxy transparent sur hotspot wifi, dns spoofing, etc ...

En conclusion, NON le SSL/TLS n'a que peu de rapport avec le schmillblick.
Ce n'est que du chiffrement des échanges avec un serveur auquel tu as confiance en te basant sur sa chaine de certification (et donc sur le principe du tiers de confiance : l'autorité de certification), avec les réserves/contraintes que j'ai cité.
Ce n'est pas suffisant pour garantir que tu la réponse vient du "bon" serveur.
Encore une fois je vais ressortir mon exemple d'un des certificats de l'autorité de certification Symantec qui s'est fait "troué" en 2014, et qui permettait donc à n'importe qui l'ayant récupéré de générer des certificats valides et reconnus pour n'importe quoi et donc se faire passer pour n'importe qui.

que ce soit HTTPS ou pas, si tu veux remplacer le fichier ca sera facile, tu met en place le fichier sur un serveur avec Let's Encrypt et tout browser va accepter le fichier comme papa dans maman.

mans dans les deux cas, tu va devoir hacker un DNS ....

jusqu'a il y a peut (c'est peut être encore le cas j 'ai pas regardé), tout les hardwares Apple prenaient leur mise a jours sur du simple HTTP .