On 26/06/2023 22:18, Laurent Barme wrote:
Le 26/06/2023 à 21:23, Léo El Amri via frnog a écrit :
Je ne comprend pas très bien comment c'est possible. Est-ce qu'on
parle d'un serveur HTTP ? Si oui, est-ce que "le serveur non contacté"
est derrière un reverse-proxy ?
Il s'agit bien sûr d'un serveur HTTP (…non de domaine…). Il n'y avait
pas de "reverse-proxy" (et je vois pas trop ce que cela vient faire ici).
Alors du coup je n'ai rien compris à l'architecture. Il n'y a pas de
concept d'erreur TLS dans un navigateur si le serveur ne répond pas.
Si non comment est-ce que le client peut avoir une erreur TLS si le
serveur n'est jamais atteint ?
Le serveur n'est jamais atteint car il n'écoutait pas sur une IPv6.
L'erreur de certificat est manifestement un bug (et une fausse piste qui
m'a fait perdre du temps). Voici mon hypothèse : l'OS résout le nom de
domaine en IPv6, le navigateur ne parvient pas à obtenir le certificat
SSL pour cette IPv6 (pas de réponse du serveur) affiche une erreur TLS
au lieu d'essayer de passer par l'IPv4 à moins que l'OS refuse de
fournir une IPv4 puisqu'il a trouvé une IPv6 pour le nom de domaine.
Je ne connais aucun navigateur avec ce comportement, mais soit.
Déjà, l'OS résout le nom de domaine pour les familles d'adresse
demandées par l'application. Si cette dernière ne supporte pas happy
eyeballs, il y a de fortes chances qu'elle tente la première réponse
qu'elle a obtenu. Admettons que ce soit une adresse IPv6. Si le
navigateur essaye de se connecter en TLS sur l'adresse IP retournée par
l'OS, mais que personne ne répond en face, l'application n'a même pas
l'occasion de négocier du TLS, donc il ne devrait même pas y avoir
d'erreur de certificat TLS. Enfin, l'OS n'a pas la responsabilité de se
connecter sous une autre adresse IP, c'est l'application qui décide ça,
et si elle est naïve, il y a de fortes chances qu'elle ne retente rien,
et qu'elle affiche que le site est indisponible.
Si l'application montre un autre comportement que celui-ci, c'est
qu'elle est sérieusement cassée.
(Par OS je sous-entend iOS ou Android)
depuis un mobile via la 4G (quelque soit le navigateur utilisé) alors
qu'il fonctionne bien par ailleurs ! Depuis le même mobile, toujours
en 4G, un autre site sur le même serveur fonctionne pourtant sans
souci. Le blocage se produit sur le réseau Orange et Bouygues mais
pas sur Free ni en WiFi (via une ADSL).
La cause était une IPv6 aussi définie pour le nom de domaine alors
que le serveur n’était pas configuré pour accepter les connexions
IPv6. Comme Orange et Bouygues privilégient manifestement l'IPv6
quand il y en a une déclarée… évidemment ça coince.
Pour moi c'est un problème logiciel : Le happy eyeballs n'a pas été
utilisé.
Ok le "happy eyeballs" n'a manifestement pas été utilisé mais il est
impossible d'intervenir au niveau du logiciel/OS des visiteurs d'un site.
Je rappelle que ce sous-fil de discussion (désolé Louis pour la
digression) part de mon témoignage à propos d'une intervention à faire
impérativement sur le logiciel d'après une réponse de Bertrand.
Je suis d'avis de ne pas supporter les logiciels cassés dans une
certaine mesure. Là on est dans cette "certaine mesure". Les standards
existaient avant les implémentations dans la nature (un bon contre
exemple est IRC). Essayer de supporter ces logiciels défectueux ce
serait comme lorsqu'on essayait de continuer de supporter IE5 en 2010.
On voit l'impact que ça a eu sur le "web". Sauf que là on a même pas
l'excuse de "c'est l'application la plus utilisée du monde".
La solution aura été de simplement supprimer l'entrée AAAA de la zone
DNS pour le nom de domaine. Configurer le serveur web pour de l'IPv6
aurait considérablement agrandi la surface d'attaques possibles.
Et un problème humain ! Si le serveur n'accepte pas l'IPv6,
l'administrateur n'aurait jamais du renseigner de AAAA dans la zone !
Tout à fait ; c'est toujours un problème humain si on remonte
suffisamment la pile. D'ailleurs si l'humain n'avait pas inventé l'IPv6…
:-))
C'est vrai, mais il ne faut pas abuser. Et là on parle de LA personne
qui est sensée être le plus au courant de l'environnement qu'elle
configure. En plus si le serveur est déjà utilisé pour d'autres sites et
que les zones DNS de ces autres sites n'ont pas d'IPv6, ça met la puce à
l'oreille.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
