Journal tcpcrypt

Posté par  (site web personnel) .
Étiquettes : aucune
9
8
nov.
2010
Je viens de tomber sur http://tcpcrypt.org mais rassurez-vous je ne me suis pas fait mal. Voici ce que dit le site:

Tcpcrypt is a protocol that attempts to encrypt (almost) all of your network traffic. Unlike other security mechanisms, Tcpcrypt works out of the box: it requires no configuration, no changes to applications, and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you'll feel no difference in your every day user experience, but yet your traffic will be more secure and you'll have made life much harder for hackers.

Qu'en pensez vous ?

  • # Intéressant

    Posté par  . Évalué à 6.

    L'équipe semble largement compétente, après une lecture du draft et de l'implémentation sous Linux, pour le coup je ne serais pas un early adopter, je vais être mauvais joueur et attendre que ça se répande un peu.

    La couche cryptographique a l'air performante mais représente tout de même un certain surcoût... Surtout que netfilter jongle avec un processus userspace, bonjour les changements de contexte.

    Le risque de déni de service me semble grandement augmenté, et à moins de passer longtemps à examiner les possibilités pour le réduire correctement et suffisamment, j'aurais peur pour mes systèmes.

    Pour finir, j'aimerais des benchmarks sur l'impact en débit et latence sur divers types de connexions et flux. Et non, je n'en ai pas assez envie pour les faire moi-même.

    • [^] # Re: Intéressant

      Posté par  . Évalué à 3.

      les slides de USENIX 2010 sont intéressants et l'équipe a l'air compétente (au niveau code et sécu).
      Les perfs par rapport a ssl ont l'air pas mal.

      Maintenant reste a voir comment ca va évolué.

  • # your network connections will continue to work even if the remote end d

    Posté par  . Évalué à 8.

    Le problème c'est que

    By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

    donc ça ne sert pas à grand chose en l'état :(

    • [^] # Re: your network connections will continue to work even if the remote en

      Posté par  . Évalué à 10.

      C'est pas parce qu'il y a des vulnérabilités connues, fussent-elles grave, qu'un truc ne sert pas à grand chose. C'est comme le TLS tel qu'implémenté par à peu près tout le monde ; susceptible de se prendre du man in the middle (avec un vrai faux certificat), mais c'est pas pour autant qu'il est _totalement_ inutile.

    • [^] # Re: your network connections will continue to work even if the remote en

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

      Bah ça permet de se protéger des attaques passives.

      De toutes manières, avec un MITM (principe de base de l'attaque active), je ne vois pas trop comment tu peux t'en tirer, à moins d'avoir une autorité de confiance (ou un réseau de confiance) pour certifier l'identité de la personne en face. Et comme tcpcrypt tourne de manière transparente pour l'utilisateur, pas moyen de lui dire : « hep, y'a un problème avec ce certificat, je fais quoi ? » comme c'est le cas avec SSL.

    • [^] # Re: your network connections will continue to work even if the remote en

      Posté par  . Évalué à 5.

      Oui, c'est typiquement un traitement de la sécurité du type "poudre magique": on installe le logiciel qui fait de la sécurité, on touche plus à rien, et voilà.
      C'est trouable de partout, ça ne garantit absolument rien. C'est vulnérable au MITM, ça augmente les risques d'attaques DOS, c'est vulnérable aux attaques par déni comme tu le décris.

      Par contre, il peut quand même y avoir un intérêt, je pense: faire ch*** les gens qui veulent faire du DPI. Pour une consommation somme toute raisonnable de CPU côté client, et côté serveur, on peut faire exploser le coût des routeurs qui cherchent à savoir ce qu'on fait du réseau alors que ce n'est définitivement pas leur rôle.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: your network connections will continue to work even if the remote en

      Posté par  . Évalué à 3.

      Euh, je ne suis pas expert sur la question, mais là je ne vois pas où est le problème.

      Si je comprends bien, si tcpcrypt n'est pas dispo sur une machine, alors on ne l'utilise pas et à la place, on utilise... le même TCP qu'on a déjà?
      En quoi est-ce moins sécurisé que ce qu'on fait tous les jours?
      Et au passage, qu'est-ce qui empêche de signaler à l'appli (ou autre, là je ne sais pas à qui s'adresser) "Attention, là on bascule tout en clair au niveau TCP, donc c'est une bonne idée de repasser à https, ftps et co!"

      Le seul "problème" que je vois, c'est que le côté "c'est bon je suis sécurisé" de l'utilisateur parce qu'il a installé un truc qu'il ne comprend pas va lui donner une confiance injustifiée dans le réseau. Mais si ce même utilisateur pense qu'il a trouvé une solution miracle, j'aurais de gros doutes quant à la sécurité qu'il a en place aujourd'hui...

      En gros, en quoi est-ce différent de "Ah non, moi le https, je prends pas! Envoie ton mot de passe sur http en clair stp!" ?

      • [^] # Re: your network connections will continue to work even if the remote en

        Posté par  . Évalué à 2.

        Rien n'empêche, effectivement, l'application cliente d'afficher l'info comme ce que nous connaissons aujourd'hui avec l'affichage d'un cadenas dans la barre des tâches, une couleur dans la barre d'adresse du navigateur web, etc. En allant sur leur site web, on voit en bas de page "You're not using tcpcrypt =(" ce qui veut dire que le mode utilisé peut être détecté et affiché d'un façon ou d'une autre (le contraire aurait été étonnant).
        Mais cela va demander un développement spécifique dans l'appli cliente pour prendre en compte cette info et l'afficher. Viendront ensuite les options, comme pour TLS, "utilise tcpcrypt si disponible", "ne jamais utiliser tcpcrypt", "toujours utiliser tcpcrypt". Biensûr, quand on passera d'un mode à l'autre, il faudra un popup que l'utilisateur validera, etc. Bref, s'ils veulent faire qqch qui informe l'utilisateur de son niveau de sécurité (ce qui est le minimum !), alors on est loin d'une solution plug and play. Leur principal argument qui est que ça sécurise la connexion de manière transparente, tombe à l'eau. Comparé à TLS, il ne reste plus grand chose d'innovant.

        Le fait de passer en TCP non chiffré de manière automatique me paraît une bonne chose pour assurer la compatibilité avec l'existant et donc son déploiement progressif. Mais ça en reste là.

  • # sécurité

    Posté par  (Mastodon) . Évalué à 5.

    if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you'll feel no difference in your every day user experience,

    Oui en gros tu ne sais jamais si ce qui transite est chiffré ou pas. Ne pas savoir si ce qui est envoyé est chiffré ou pas, c'est carrément problématique d'un point de vue sécurité.

Suivre le flux des commentaires

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