votre avatar Abonné

bzero

est avec nous depuis le 2 mai 2024 ❤️

Bio

Oups.
On dirait que quelqu'un ici aime garder ses petits secrets, comme si de par hasard il y avait quelque chose à cacher...
Désolé, ô lectrice de passage, cher lecteur égaré, pas de révélation sensationnelle pour le moment sur ce profil.
Repassez plus tard ?

2 commentaires

Microsoft retire une mise à jour faisant redémarrer en boucle Windows 11

Le 28/06/2024

Le 30/06/2024 à 11h 17

évidemment que j'utilise TLS et au minimum 1.2

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).

[1]: https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.txt

Le 30/06/2024 à 09h 40

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.