• chevron_right

      DNS Block: Canal+ Sues Cloudflare, Google & Cisco to Fight Piracy

      news.movim.eu / TorrentFreak · Saturday, 30 December - 15:54 · 3 minutes

    The music industry obtained a pioneering injunction to compel Danish ISPs to implement site-blocking measures back in 2006 .

    The goal was to limit access to unlicensed Russian music download platform AllofMP3, but the action also represented the thin end of a site-blocking wedge still being tapped in today.

    Broadcaster and site-blocking proponent Canal+ believes that when service providers implement technical measures to prevent access to pirate sites, that helps to reduce piracy rates. Unfortunately, online roadblocks reliant on technical tweaks always run up against other technical tweaks designed to circumvent them.

    Protecting Live Sports

    A report from the French news outlet l’Informé outlines a fairly typical framework adopted by rightsholders in Europe. To limit access to pirated live sports streams, this year Canal+ went to court in France arguing that local ISPs should prevent customers from accessing several pirate streaming sites.

    Through Footybite.co, Streamcheck.link, SportBay.sx, TVFutbol.info, and Catchystream.com, internet users were able to watch Premier League and Champions League football, plus matches from the Top 14 rugby union club competition, without paying Canal+, the local rightsholder.

    After the decisions went in favor of Canal+, ISPs including Orange, SFR, OutreMer Télécom, Free, and Bouygues Télécom, were required to implement blocking measures. This meant that when the ISPs’ customers attempted to visit any of the above domains, the ISPs’ respective DNS resolvers provided non-authentic responses, thereby denying customers access to the sites.

    Circumvention and New Legal Action

    The response to ISP blocking by increasingly savvy customers was to change their network settings to replace their ISPs’ DNS servers with those offered by unaffected third-party providers. By switching to DNS servers offered by Cloudflare , Google , and Cisco ( OpenDNS ), the domains functioned as expected. This entirely predictable response is now being countered by another.

    After tapping in the wedge just far enough to obtain the initial blocking orders, Canal+ has now returned to court hoping to resolve the blocking orders’ shortcomings. After failing to achieve voluntary cooperation, l’Informé reports ( paywall ) that Canal+ is now suing Cloudflare, Google, and Cisco at the Paris judicial court, to compel similar DNS blocking measures.

    Legal Basis: Article L333-10

    According to Article L333-10 of the French Sports Code (active Jan 2022), when there are “serious and repeated violations” by an “online public communication service” whose main objective is the unauthorized broadcasting of sporting competitions, rightsholders can go to court to demand “all proportionate measures likely to prevent or put an end to this infringement, against any person likely to contribute to remedying it.”

    Proportionate measures include blocking, deleting or deindexing communication services (in this case pirate streaming sites) when they meet the above criteria.

    The judicial court may order these measures to be implemented “for each of the days appearing in the official calendar of the competition or sporting event, within the limit of a period of twelve months.” In respect of the competitions Canal+ hopes to protect, that means until May 19, 2024, for the Premier League, until June 1, 2024, for the Champions League, and until June 29, 2024, for Top 14.

    How Serious is the Circumvention Situation?

    According to detailed reports published by telecoms regulator Arcom, ISP-only DNS blocking measures have enjoyed massive success in France.

    Published in May 2023, Arcom’s report for 2022 noted that the overall audience for illicit sports broadcasts decreased by 41% between 2021 and 2022, down from 2.8 million internet users on average to 1.6 million.

    On circumvention of blocking measures, in May 2023 Arcom reported that when confronted with a blocked site, almost half of all infringing Internet users (46%) completely abandoned the idea of watching the content.

    Of all infringing users, just 6% attempted to circumvent blocking measures using an alternative DNS, VPN or similar method.

    > france-dns-vpn-blocking

    While circumvention of blocking measures doesn’t seem to be an especially big problem in France right now, Arcom notes that it will remain vigilant moving forward.

    For the sake of curiosity, we searched for signs of blocking in France using data supplied by the Open Observatory of Network Interference ( OONI ). The system appears to detect pirate site blocking in France as an ‘anomaly’ (yellow) rather than confirmed, outright blocking (red).

    The green sections may indicate that a relatively small number of users are managing to access domains well-known for their links to piracy. Whether that volume warrants dragging third-party DNS providers to court is another matter.

    However, it can’t be ruled out that there’s also a strategic element to the Canal+ complaint; another tap of the wedge, more incremental progress, and then ever-expanding DNS blocking in preparation for whatever comes next.

    From: TF , for the latest news on copyright battles, piracy and more.

    • Sc chevron_right

      Cisco Can’t Stop Using Hard-Coded Passwords

      news.movim.eu / Schneier · Tuesday, 10 October - 20:09

    There’s a new Cisco vulnerability in its Emergency Responder product:

    This vulnerability is due to the presence of static user credentials for the root account that are typically reserved for use during development. An attacker could exploit this vulnerability by using the account to log in to an affected system. A successful exploit could allow the attacker to log in to the affected system and execute arbitrary commands as the root user.

    This is not the first time Cisco products have had hard-coded passwords made public. You’d think it would learn.

    • chevron_right

      Manchester City smart scarf wraps data-collecting sensors around fans’ necks

      news.movim.eu / ArsTechnica · Thursday, 28 July, 2022 - 16:17

    Manchester City smart scarf wraps data-collecting sensors around fans’ necks

    Enlarge (credit: Manchester City )

    England's Manchester City soccer club wants to know how its fans really feel, and it has gone so far as to pilot The Connected Scarf, a "smart scarf" stuffed with sensors that the organization says enables it to gauge fan emotions.

    According to Manchester City's page for the scarf , the club has been piloting the accessory with six fans thus far and has recorded "over 120 moments of interest across the 90 minutes of a match."

    "The scarf records a range of physiological measures, including heart rate, body temperature, and emotional arousal—giving us concrete information to analyze how fans are feeling at different moments in the match," the page says.

    Read 6 remaining paragraphs | Comments

    • At chevron_right

      Let's Encrypt

      motius · pubsub.gugod.fr / atomtest · Friday, 23 October, 2015 - 22:00 · 7 minutes

    Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

    Bonjour à tous !

    Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

    Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

    Chiffrement de bout en bout vs chiffrement point à point.

    C'est assez simple :

    • le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
    • le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
      • traverser un bout du réseau sans chiffrement ;
      • être lu par tous les pairs qui ont acheminé le message.
      • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

    Sur internet vous utilisez les deux :

    • le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
    • parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

    Comment fonctionne le HTTPS ?

    HTTP vs HTTPS, méthode de chiffement

    HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

    • quand on est le client :
      • donne moi la page à cette URL ;
    • quand on est le serveur :
      • la page que tu m'as demandé, je l'ai, la voici ;
      • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
      • la page que tu m'as demandé, bah elle existe pas (404) ;
      • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
      • j'ai pas compris ce que tu m'as demandé (400) ;
      • ce que tu fais-là, tu n'en as pas le droit (403) ;
      • le serveur est en panne (503)...

    Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

    • la requête (pas celles initiant le chiffrement) ;
    • les données échangées par la suite.

    Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

    Confiance de HTTPS

    Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

    • Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
    • B qui va indiquer qu'il sait parler HTTPS ;
    • A va interroger B ;
    • B va répondre, et s'il a la page, la transmettre.

    Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

    • A va obtenir via le réseau la clef publique de B.
    • Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
    • A va chiffrer ses messages pour B avec la clef publique de B.
    • B déchiffre ses messages avec sa clef privée.

    Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

    • comment le navigateur reconnait qu'un certificat est valide ;
    • la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

    On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

    Réseau de confiance de l'architecture X509

    Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

    On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

    Ainsi lorsqu'une clef publique arrive depuis internet :

    • si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
    • si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
    • le reste poubelle, la connexion est terminée.

    Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

    Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

    Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

    Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

    • c1 puisse signer des certificats ;
    • c1 puisse signer des AC ;

    On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

    • elles puissent signer des certificats ;
    • éventuellement elles puissent signer d'autres AC.

    Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

    Subtilité de X509, résilience

    Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

    Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

    Un problème se pose, et a pas mal de répercussions :

    Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

    • Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
    • Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

    Let's Encrypt

    Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

    • d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
    • ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

    Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

    C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

    Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

    Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

    Bon chiffrement à tous et bonne journée !

    Motius

    • Ha chevron_right

      Let's Encrypt

      motius · pubsub.gugod.fr / hashtagueule · Friday, 23 October, 2015 - 22:00 · 7 minutes

    Bonjour à tous ! Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt. Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement poi...

    Bonjour à tous !

    Savez-vous comment marche le mécanisme de la confiance dans une page web reçue avec HTTPS ? Petit tour rapide et présentation de Let's Encrypt.

    Si vous êtes un lecteur régulier du site, vous savez que le chiffrement de bout en bout est un dada chez moi, plutôt que le chiffrement point-à-point. On n'a pas encore fait de glossaire, donc je vais le réexpliquer à cette occasion, mais on finira par se référer à un petit manuel de bases. Donc si vous connaissez, vous pouvez zaper la partie 0 qui suit.

    Chiffrement de bout en bout vs chiffrement point à point.

    C'est assez simple :

    • le chiffrement de bout en bout signifie que votre ordinateur chiffre avec la clef de votre correspondant, et par conséquent sur le réseau, le message est toujours chiffré ;
    • le chiffrement point à point est appliqué entre vous et votre pair direct, puis (éventuellement) votre pair chiffre avec son pair, etc. jusqu'à destination, le message peut donc :
      • traverser un bout du réseau sans chiffrement ;
      • être lu par tous les pairs qui ont acheminé le message.
      • En comparaison, c'est comme si une lettre à La Poste était lu par tous ceux qui l'ont en main, et que de temps en temps le service de poste était négligent, et laissait à tous la possibilité de lire la lettre.

    Sur internet vous utilisez les deux :

    • le mail utilise le chiffrment point à point (sur lequel vous pouvez rajouter du chiffrement de bout en bout avec GPG/PGP) ;
    • parler HTTPS avec un serveur permet de récupérer une page qui sera chiffrée entre vous et le serveur, donc d'un bout du réseau à l'autre.

    Comment fonctionne le HTTPS ?

    HTTP vs HTTPS, méthode de chiffement

    HTTP est un protocole qui permet de récupérer des pages web. Exemples de ce qu'on peut "dire en HTTP" :

    • quand on est le client :
      • donne moi la page à cette URL ;
    • quand on est le serveur :
      • la page que tu m'as demandé, je l'ai, la voici ;
      • la page que tu m'as demandé, je l'ai, mais attends un peu, je suis surbooké, là (schématiquement) ;
      • la page que tu m'as demandé, bah elle existe pas (404) ;
      • ce que tu demandes n'est pas ici, va voir ailleurs (301) ;
      • j'ai pas compris ce que tu m'as demandé (400) ;
      • ce que tu fais-là, tu n'en as pas le droit (403) ;
      • le serveur est en panne (503)...

    Et beaucoup d'autres. HTTPS n'est que l'utilisation d'une couche de chiffrement (SSL/TLS) pour chiffrer les données :

    • la requête (pas celles initiant le chiffrement) ;
    • les données échangées par la suite.

    Pour visualiser la couche de chiffrement, on peut se représenter un tunnel entre le client et le serveur dans lequel la donnée passe. Personne ne peut accéder à l'intérieur du tunnel parce qu'il est solide, et le tunnel a une entrée (le client) et une sortie (le serveur).

    Confiance de HTTPS

    Lorsqu'Alice va demander la page web de Bob en HTTPS, que va-t-il se passer ?

    • Le client A (son navigateur web Firefox) va faire une requête vers un serveur B
    • B qui va indiquer qu'il sait parler HTTPS ;
    • A va interroger B ;
    • B va répondre, et s'il a la page, la transmettre.

    Tout ça s'est fait automatiquement. Voyons un peu l'architecture de chiffrement mise en place ici. Il s'agit d'une infrastructure clef publique/clef privée + autorité de confiance :

    • A va obtenir via le réseau la clef publique de B.
    • Le navigateur web de A va vérifier que la clef est valide, c'est à dire qu'il s'agit bien de la bonne clef (et pas celle d'un attaquant) et qu'elle est toujours valide (par mesure de sécurité, les clefs ont une durée de validité, d'un an en général).
    • A va chiffrer ses messages pour B avec la clef publique de B.
    • B déchiffre ses messages avec sa clef privée.

    Ainsi, la confiance que l'on a dans HTTPS dépend de deux facteurs :

    • comment le navigateur reconnait qu'un certificat est valide ;
    • la qualité du chiffrement, ie les algorithmes utilisés (RC4 : mauvais, AES-256 très bon, à ce jour).

    On ne parlera pas plus des algorithmes ici, à la place on se concentrera sur comment le navigateur a décidé de reconnaître un certificat, ou de l'invalider.

    Réseau de confiance de l'architecture X509

    Le problème de fond, c'est de reconnaître la validité d'une clef de chiffrement (publique) pouvant changer fréquemment obtenue via internet.

    On utilise ce qu'on appelle un pair de confiance. Si un certificat est signé par un pair de confiance, alors le certificat est considéré comme valide. Le pair de confiance dans l'architecture X509 s'appelle une autorité de certification (AC, parce que j'ai pas envie de le réécrire ;) ). Par défaut Firefox fait donc confiance à un certaint nombre d'AC.

    Ainsi lorsqu'une clef publique arrive depuis internet :

    • si le certificat est signé par une AC, il est valide (sauf cas exceptionnel où l'utilisateur a interdit le certificat) ;
    • si le certificat n'est pas signé par une AC, mais est accepté par l'utilisateur, il est valide ;
    • le reste poubelle, la connexion est terminée.

    Dans les AC vous en connaissez peut-être quelques unes dont Thawte, VeriSign, GoDaddy, CA-Cert, Gandi, Google (eh oui, il font ça aussi), et depuis peu Let's Encrypt.

    Mais la chaîne de confiance n'est pas complète. Comment savoir quelles sont les entités reconnues, comment en rajouter sans mettre à jour tous les navigateurs ?

    Eh bien à la base de la création de X509, on a généré une clef c0, et une clef c1, on a signé la clef c1 avec la clef c0 et découpé c0 en plusieurs (4 ?) parties qu'on a dispachées dans des coffres-forts. On fait donc en sorte que la clef 0 soit reconnue, et on signe les AC avec la clef c1. Les entités créent leur clef c_entite (plusieurs en fait), qui est valide, puisque signée par c1, elle-même valide puisque signée par c0.

    Récapitulons. On fait confiance à c0. c0 signe c1, de telle sorte que :

    • c1 puisse signer des certificats ;
    • c1 puisse signer des AC ;

    On signe les AC, qui créent leur clefs, qui sont signées par c1 de telle sorte que :

    • elles puissent signer des certificats ;
    • éventuellement elles puissent signer d'autres AC.

    Ainsi, la chaîne de confiance est une hiérarchie. Faire confiance à c0 permet/implique a priori de faire confiance à beaucoup de gens (on peut cependant demander à Firefox de ne pas accepter un certificat valide).

    Subtilité de X509, résilience

    Vous avez peut-être remarqué que c0 ne sert qu'à signer c1, puis on demande au navigateur de reconnaître c0, puis on signe avec c1.

    Vous vous demandez peut être pourquoi... Imaginons que c0 = c1 = c$latex \alpha $, c'est à dire qu'au début de la chaîne de confiance il y ait non pas deux mais une seule clef c$latex \alpha $.

    Un problème se pose, et a pas mal de répercussions :

    Si la clef $latex \alpha $ est perdue alors toute la sécurité de l'architecture X509 s'effondre.

    • Dans le cas où on n'a qu'une clef c$latex \alpha $, on ne peut rien faire.
    • Dans le cas ou on a c0 et c1, et c1 est perdue (on suppose que c0 n'est pas perdue, elle sous clef, éparpillée sur le globe), on révoque c1 à l'aide de c0, et on regénère une clef c1'. Ça permet notamment de pouvoir rapidement recréer un environnement de confiance, et de ne pas avoir besoin de rediffuser la clef à toutes les machines.

    Let's Encrypt

    Alors pourquoi est-ce que je vous rabats les oreilles avec tout ça ? Eh bien pour deux raisons :

    • d'abord pour que vous sachiez quelle confiance accorder dans des connexions HTTPS ;
    • ensuite pour vous parler spécialement d'une AC : Let's Encrypt.

    Vous l'avez compris, il y a beaucoup d'enjeux concernant une AC. La confiance qu'on a, la qualité de son travail, de la façon dont elle sécurise ses données pour ne pas perdre sa clef et servir de vecteur d'attaque, etc. Il y a d'autres enjeux dont la possibilité pour tous de chiffrer facilement, en effet les certificats ne sont pas gratuits, sauf certains de CA-Cert, et de Gandi.

    C'est pourquoi Mozilla Cisco l'EFF et d'autres se sont unis pour créer une AC dont le but serit de permettre à tous de pratiquer le chiffrement à tour de bras. Et voilà qui est fait.

    Depuis le 19 octobre 2015 les certificats de Let's Encrypt sont de confiance par défaut dans les versions récentes de Firefox (probablement Chrome/Chromium, Microsoft Edge, et Safari).

    Let's Encrypt va donc pouvoir se mettre à un rythme de croisière de signatures de certificats d'ici très peu de temps.

    Bon chiffrement à tous et bonne journée !

    Motius