Sécurité tcp additionnel (tcpcrypt) et iptables

j'avais déjà pris lecture du man et en avais retenue que le suivi de connexion n'était nécessaire que pour un nat avec le FORWARD d'activer. Il ma parût logique étant donné que le suivis de connection doit ce faire sur un autre protocole que lo, donc il faut que le suivis des paquets de la machine a vers internet soit bien crypté et renvoyé par un second protocole de cryptage a la machine émanente de la requête (la machine derrière le nat). #je précise que je n'utilise pas encore le nat avec tcpcryptd, pas pour le moment.

Sinon j'ai abandonné, tcpcryptd est mal porté sur linux et je ne pense pas qu'il soit a la base porté sur debian, c'est le même bug que sur celui de github, un protocole nouveau émanent d'une application utilisant des variables noyau (module*, je sais j'ai mon language à moi même et je pense qu'il est très comprehensible) mal implémenté sur le kernel lui même, il faudra donc vérifier l'implémentation et la bonne coordination entre netfilter et l'application, sans compté entre deux le noyau.
Il y a le problème du mkdir -p /var/run/tcpcryptd à faire sinon il ne ce lance pas, un problème de chmod applicatif relatif avec ces droits, je pense.

Donc la question est est-ce parcequ'il résulte d'un manquement à la "sécurité local debian" que tcpcryptd est si délaissé (je ne site pas le problème de dépendance vitale non installé alors qu'elle ce trouve dans les dépots et qui font que sans elles, impossible de faire fonctionner l'application à sa principale et seul fonction ....
Ou bien est-ce parceque debian considère que la vie privé qui est aussi contraignante et non indispensable ne vaut pas mieux en faite que de la simple conduite protectrice et ce peu importe le produit utilisé, comparable à un triple brossage de dent journallier pour les fervants des non sos dentiste ?

Sécurité tcp additionnel (tcpcrypt) et iptables

Sécurité tcp additionnel (tcpcrypt) et iptables

Bonsoir,

Après avoir installé tcpcryptd et avoir ajouté dans mon fichier iptables :

iptables -filter -A OUTPUT -p tcp --dport 80 -j NFQUEUE --queue-num 666
iptables -filter -A INPUT -p tcp --sport 80 -j NFQUEUE --queue-num 666
 

J'obtiens après le lancement de tcpcryptd :

Initializing...
Reading random seed from /dev/urandom
Running
Testing network via 171.66.3.195
No timestamp provided in packet - expect low performance due to calls to gettimeofday
Test result: port 80 crypt 0 req 0 state 2 err 666 flags 0
Test result: port 80 crypt 0 req 1 state 2 err 666 flags 0
Test result: port 80 crypt 1 req 2 state 1 err 666 flags 0
Test result: port 7777 crypt 0 req 0 state 2 err 666 flags 0
Test result: port 7777 crypt 0 req 1 state 2 err 666 flags 0
Test result: port 7777 crypt 1 req 2 state 2 err 666 flags 0
Tests done! 1 2 3 4 5 6 failed [6/6]!
 

Après deux vérification il semble que iptables ne filtre pas correctement les paquets tcp passant par le port 80 nécessitant l'utilisation de tcpcrypt.

Si quelqu'un a une idée,

Sécurité tcp additionnel (tcpcrypt) et iptables