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 ?
Posté par pralines .
É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) ?
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.
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.
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
Posté par Kerro .
É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.
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).
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.
# Faille ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (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 gorbal . É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 pralines . É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 gorbal . Évalué à 2.
Dans ce cas pourquoi avoir supprimé les applications VPN de l'Apple Store en Chine ?
[^] # Re: Faille ?
Posté par pralines . É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 nlgranger . É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 Anonyme . Évalué à 1.
Le ciphers par défaut d’OpenVPN sont très, très, permissifs.
[^] # Re: Faille ?
Posté par steph1978 . É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 Anonyme . É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 claudex . É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 Kerro . Évalué à 3. Dernière modification le 12 août 2020 à 17:48.
C'est une fonction de hachage.
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 Zenitram (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 Anonyme . É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.