• # Faille ?

    Posté par  (site web personnel) . Évalué à 3.

    Doit-on en déduire qu’il n’y aurait pas encore de faille massivement exploitable dans ce protocole, plutôt que croire que le seul chiffrement des domaines accédés justifie ce blocage ? Après tout, la Chine n’autorise-t-elle pas des vpn à transiter au travers de son grand pare-feu ? Ce qui cache tout autant les destinations finales des paquets, non ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Faille ?

      Posté par  . Évalué à 1.

      Le VPN semble plus toléré dans certains cas, qu'autorisé.
      https://www.travelchinacheaper.com/is-it-legal-to-use-a-vpn-in-china

      • [^] # Re: Faille ?

        Posté par  . Évalué à 3. Dernière modification le 11 août 2020 à 09:25.

        mode_complot_on

        et si les VPN sont tolérés, peut-être que cela signifie que leurs failles sont déjà connues et exploitées par les agences gouvernementales (chinoises et autres) ?

        mode_complot_off

        Envoyé depuis mon Archlinux

        • [^] # Re: Faille ?

          Posté par  . Évalué à 2.

          Dans ce cas pourquoi avoir supprimé les applications VPN de l'Apple Store en Chine ?

          • [^] # Re: Faille ?

            Posté par  . Évalué à 4.

            mode_vendredi_on

            parce que les VPN certifiés par la pomme sont "espionables" uniquement par la NSA ?

            mode_vendredi_off

            Envoyé depuis mon Archlinux

        • [^] # Re: Faille ?

          Posté par  . Évalué à 3.

          Ce n'est pas du complot, c'est exactement ça: le filtrage est généralement moins strict sur les technos avec un faible niveau de sécurité (ex L2TP) que les autres (ex: OpenVPN, tunnel ssh). En pratique ça veut dire que ta connexion dure plus longtemps avant d'être interrompue par le filtrage automatique.
          En tout cas c'est l'expérience que j'ai eue quand j'y suis allé il y a quelques années.

          • [^] # Re: Faille ?

            Posté par  . Évalué à 1.

            OpenVPN

            Le ciphers par défaut d’OpenVPN sont très, très, permissifs.

            • [^] # Re: Faille ?

              Posté par  . Évalué à 4.

              C'est quoi un cipher "permissif" ?
              Pour moi un chiffrage est soit fort = pas encore craqué soit faible = craquable.

              • [^] # Re: Faille ?

                Posté par  . Évalué à 1.

                Je voulais dire que la « cipher suite » par défaut était très permissive. Dans la liste des algorithme par défaut tu as du SHA1, tu as du 3DES, tu as de l’AES CBC, bref certainement pas des choses que je veux voir dans un VPN moderne.

                • [^] # Re: Faille ?

                  Posté par  . Évalué à 3.

                  Et par défaut, c'était BF-CBC (sur 64bits) qui est choisi (maintenant si NCP et openvpn des deux côtés > 2.4, c'est de l'AES-256-GCM).

                  Perso, je trouve ça dommage pour openvpn. Autant, je comprends qu'on garde des vieux algo un certain temps pour de la retro-compatibilité, mais je trouve que ça devrait être désactivé par défaut dans les nouvelles version et seulement autorisé par une configuration explicite.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Faille ?

                  Posté par  . Évalué à 3. Dernière modification le 12 août 2020 à 17:48.

                  SHA1

                  C'est une fonction de hachage.

                   

                  3DES, tu as de l’AES CBC

                  Le chiffrement par défaut d'OpenVPN est depuis des années Blowfish en 64 bits, craqué en 2016 pour l'implémentation d'OpenVPN.
                  Fin 2016 OpenVPN est passé en version 2.4 qui est désormais par défaut en AES-256 réputé inviolable jusqu'à présent.

                  --> quel est le soucis avec OpenVPN ?

  • # Défaut de TLS?

    Posté par  (site web personnel) . Évalué à 3.

    Est-ce que ça ne montrerait pas un défaut de TLS (1.3 inclus), celui de pouvoir détecter le protocole même sans la clé privée?
    J'imagine que la prochaine étape est d'avoir un protocole qui n'est détectable que par celui qui a la clé privée (chiffrement dès le premier octet de la communication), dans le style de Truecrypt (qui ne permet pas de savoir que le disque est chiffré par lui sans avoir le mot de passe, ça reste que du "bruit" d'octets qui ne veulent rien dire).

    • [^] # Re: Défaut de TLS?

      Posté par  . Évalué à 7.

      Le truc c’est que pour TrueCrypt, le besoin c’est de pouvoir dire que ton disque est vide puisque les données qui sont dessus sont complètement aléatoire et qu’il n’y a pas de métadonnée prouvant qu’il y a chiffrement (déni plausible).

      Dans le cas d’un protocole réseau, tu pourras difficilement dire que tu ne sais rien, vu que tu génère du trafic (aléatoire car chiffré, par un protocole non identifiable, mais du trafic quand même).

      En plus de ça, on parle d’une dictature là, je pense pas que ça les dérangerait d’envoyer des gens en prison pour avoir envoyé « du bruit » sur 443/tcp.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.