Le chiffrement actuel ne représente rien; quand tu fais de l'échange de clés (KEX) avec X25519 (trèa répandu), c'est 32 bytes échangés par chacune des parties. Autant te dire que ce n'est rien et que ça tient dans un packet TCP! Niveau puissance de calcul, on peut considérer que X25519 est "gratuit" tellement c'est rapide. Il en va de même pour EcDSA. En revanche, les algorithmes PQ pour du KEX sont plus coûteux mais pas plus gros. ML-KEM 768 c'est 1184 bytes échangés pour la clé publique, ce qui reste peu (et encore une fois ça rentre dans un seul paquet TCP sans fragmentation).
Donc l'hybride n'est pas vraiment le problème ici!
Globalement, le message que j'essaye de faire passer est pour ceux qui n'ont pas ton degré de compétences. Je reformule donc:
Avec les modules de type flux de nginx, il est possible de router automatiquement les connexions https vers la bonne destination et le protocole proxy sans sacrifier la confidentialité des échanges.
Le mandataire inverse est capable de déterminer cela à partir du tout premier paquet envoyé par le client https car ce paquet est en clair.
Le protocole proxy permet de transmettre au serveur destinataire l'adresse ip du client et d'autres informations.
Du coup, les flux https IPv4 arrivent au mandataire qui les renvoie en IPv6 au serveurs IPv6 only par protocole proxy sur des adresses ULA. Les flux IPv6 arrivent directement aux serveurs.
Bref, il est possible et même très simple d'arrêter de faire du NAT44 comme des idiots pour des serveurs en conteneurs ou en machines virtuelles en migrants sur IPv6
Merci pour ces détails! :)
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire. J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
EDIT: t'as une RFC[1] pour des ClientHello chiffrés en TLS 1.3, c'est cool, et ta confidentialité s'en retrouve encore plus grandie. D'un point de vue on-path attack, il n'y aurait plus que le routing qui pourrait leaker des informations. Manque plus que OpenSSL le supporte pour l'avoir de-facto dans nginx (BoringSSL le supporte déjà, Envoy utilise BoringSSL).
Je suis déjà en full IPv6: sur mes VLAN, l'IPv4 est coupé et j'utilise des préfixes ULA donc je n'ai pas de problème de fuite vers l'extérieur.
le SMB sur IPv6 fonctionne très bien et permet de couper définitivement l’infâme service de nom netbios qui est mécaniquement incompatible IPv6.
Côté serveur, mes machines virtuelles sont quasiment à 100% en IPv6: c'est un mandataire inversé nginx qui reçois les connexions en IPv4 et les retransmet par détection de flux au bon serveur en IPv6 avec le protocole proxy.
Le traffic reste chiffré jusqu'au serveurs finaux car l'aiguillage se fait sur le flux lors de la phase de connexion SSL avec le paquet HELO. Pas besoin de gérer les certificats sur l’hôte.
Il me reste encore une dernière chose à faire pour bouter l'IPv4 de ces machines: mettre en place un NAT64 et un DNS64. Mais tayga est chiant à configurer donc je n'ai pas encore résussi.
SSL, paquet HELO, what? De quel paquet parles-tu ici? Tu confonds avec SMTP. Et j'espère que tu n'utilises plus SSL!
J'imagine que tu parlais de SNI dans le ClientHello de TLS.
3 commentaires
10 ans de peur autour du « post-quantique » : derrière les annonces, quelle réalité ?
02/10/2024
Le 02/10/2024 à 23h 19
Le chiffrement actuel ne représente rien; quand tu fais de l'échange de clés (KEX) avec X25519 (trèa répandu), c'est 32 bytes échangés par chacune des parties. Autant te dire que ce n'est rien et que ça tient dans un packet TCP!Niveau puissance de calcul, on peut considérer que X25519 est "gratuit" tellement c'est rapide. Il en va de même pour EcDSA.
En revanche, les algorithmes PQ pour du KEX sont plus coûteux mais pas plus gros. ML-KEM 768 c'est 1184 bytes échangés pour la clé publique, ce qui reste peu (et encore une fois ça rentre dans un seul paquet TCP sans fragmentation).
Donc l'hybride n'est pas vraiment le problème ici!
Microsoft retire une mise à jour faisant redémarrer en boucle Windows 11
28/06/2024
Le 30/06/2024 à 11h 17
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire.
J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
EDIT: t'as une RFC[1] pour des ClientHello chiffrés en TLS 1.3, c'est cool, et ta confidentialité s'en retrouve encore plus grandie. D'un point de vue on-path attack, il n'y aurait plus que le routing qui pourrait leaker des informations.
Manque plus que OpenSSL le supporte pour l'avoir de-facto dans nginx (BoringSSL le supporte déjà, Envoy utilise BoringSSL).
[1]: https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.txt
Le 30/06/2024 à 09h 40
J'imagine que tu parlais de SNI dans le ClientHello de TLS.