Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.
QUIC peut déjà être utilisé comme amplification d'attaque DoS. L'entête de première réponse du serveur contient le certificat du serveur pour ouvrir la session TLS au plus tôt. L'effet est limité en demandant au client d'envoyer un gros premier paquet d'ouverture de session.
Le port QUIC peut-être simplement flooder aussi comme le ferai une attaque de type TCP-SYNFLOOD. Je suppose que les serveurs auront un moyen de se protéger (limitation par ip, SNI ou autre) mais il va être difficile de faire grands chose au niveau d'un firewall avant un serveur. Avec TCP, on peut faire un proxy tcp-syn avec iptables par exemple qui vérifie la véracité d'une connexion TCP avant de la donner au serveur. Avec QUIC, je ne sais pas si cela est possible sans avoir recours à un vrai proxy logiciel qui devra avoir au moins les certificats pour chaques SNI. Les premiers paquets des sessions QUIC devant être plus gros pour limiter l'amplification en cas d'attaque par rebond, une attaque DoS de type TCP-SYNFLOOD utilisant QUIC pourra viser la saturation du serveur et la saturation des liens réseaux.
Je ne doute pas que les gros vont avoir des solutions pour cela. Mais en tant que petit, quel seront les solutions pour se protéger de ces attaques ?
[^] # Re: Inconvénients ?
Posté par KiKouN . En réponse à la dépêche Le protocole QUIC désormais normalisé. Évalué à 9.
Utilisant UDP, il en reprends aussi les défauts. Je pense surtout au problème pour les attaques DoS.
QUIC peut déjà être utilisé comme amplification d'attaque DoS. L'entête de première réponse du serveur contient le certificat du serveur pour ouvrir la session TLS au plus tôt. L'effet est limité en demandant au client d'envoyer un gros premier paquet d'ouverture de session.
Le port QUIC peut-être simplement flooder aussi comme le ferai une attaque de type TCP-SYNFLOOD. Je suppose que les serveurs auront un moyen de se protéger (limitation par ip, SNI ou autre) mais il va être difficile de faire grands chose au niveau d'un firewall avant un serveur. Avec TCP, on peut faire un proxy tcp-syn avec iptables par exemple qui vérifie la véracité d'une connexion TCP avant de la donner au serveur. Avec QUIC, je ne sais pas si cela est possible sans avoir recours à un vrai proxy logiciel qui devra avoir au moins les certificats pour chaques SNI. Les premiers paquets des sessions QUIC devant être plus gros pour limiter l'amplification en cas d'attaque par rebond, une attaque DoS de type TCP-SYNFLOOD utilisant QUIC pourra viser la saturation du serveur et la saturation des liens réseaux.
Je ne doute pas que les gros vont avoir des solutions pour cela. Mais en tant que petit, quel seront les solutions pour se protéger de ces attaques ?