Résolution de l'année: arrêter d'utiliser netstat!

'ss' appartient au paquet iproute2 dont voici une grosse doc: https://jeekajoo.eu/links/?g3Er4g

iproute2 remplace net-tools (ifconfig, route, netstat, arp...) qui est déprécié depuis 2009: https://lists.debian.org/debian-devel/2009/03/msg00780.html

Article intéressant sur les limitations TCP sur du IaaS AWS, avec du c3.large
"""
Our case didn’t finish at this point though. After another few days one of Amazon technicians spotted another interesting thing – if we set the security group to allow all TCP traffic the issue also doesn’t occur.
"""
ಠ_ಠ

Un article intéressant qui rappele qu'il faut dissocier

• timeout client (entre les clients et l'ELB): réglages au niveau du client + ELB (60 sec par défaut)
• timeout backend (entre les backends (nginx) et l'ELB): réglages au niveau de nginx + ELB (60 sec par défaut)

Il n'y a pas non plus de rapport 1 pour 1 entre les connexions tcp de part et d'autre de l'ELB. On a des choses différentes pour:

• nombre de connexions client: réglage au niveau du client
• nombre de connexions backend: pas de réglage

"""
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.
"""
Au niveau client, il suffit d'installer le tcpcryptd. Pas besoin de générer des clés ni rien.. Pareil au niveau serveur.
Tcpcrypt fait du chiffrement de manière opportuniste. Si le serveur et le client savent parler tcpcrypt, ça chiffre ; sinon ça fallback en TCP classique. C'est une force (facilité) mais c'est aussi une faiblesse face aux attaques MITM où un attaquant peut modifier la réponse du serveur et dire qu'il ne supporte pas tcpcrypt (alors qu'en fait si) pour que toutes les communications restent en TCP classique.

C'est complémentaire avec un chiffrement SSL/TLS fait en couche 5 (session, http://security.stackexchange.com/questions/19681/where-does-ssl-encryption-take-place)

Un papier qui va dans le détail: http://tcpcrypt.org/tcpcrypt.pdf
Code: https://github.com/scslab/tcpcrypt