Recherchez dans la Communauté

Vous avez une question ?

Interrogez la communauté

internet & fixe mon mail Orange

L'identification sur le serveur pop.orange.fr a échoué.

papou22
#TopMembre
#TopMembre
2 828  

Re: L'identification sur le serveur pop.orange.fr a échoué.

@verdy_p,

 

Et alors ?!

 

Tu crois vraiment que c'est en postant des posts imbitable de 10 Km de long en étalant ta science sur ce forum d'entraide entre clients d'Orange que tu vas régler le problème ?

 

Un problème bien décrit est déjà à moitié résolu

Chris972
contributeur
2 779  

Re: L'identification sur le serveur pop.orange.fr a échoué.

Et bien @verdy_p moi je dis CHAPEAU BAS pour tes analyses (dans ce fil et un autre).

 

Tes posts sont argumentés, et tes propos sont démontrés.

 

Je me suis retrouvé ici car sous Linux, mon fetchmail n'est plus capable de discuter avec les serveurs pop.orange.fr, et tes explications, vérifiés, pleines de bon sens, m'ont permis de comprendre.

 

A ceux qui trouvent tes posts trop longs ou trop compliqués, je ne pourrai que dire : ne les lisez donc pas si ça vous dépasse. Y en a assez du nivellement par le bas. Que les cancres parlent aux cancres ?

Il n'empêche que depuis le début tu mets en cause orange, et tu avais parfaitement raison.

Si certains préfèrent fermer les yeux, c'est leur problème, mais de nos jours, de telles ERREURS sont inadmissibles, et il faut les dénoncer haut et fort.

 

EDIT : Et donc encore un MERCI à @verdy_p grâce à qui j'ai donc résolu mon problème avec :

# grep orange /etc/local.d/nullroute.start
/bin/ip route add blackhole 80.12.24.209 # ne fourni pas le bon certificat pop.orange.fr
/bin/ip route add blackhole 80.12.24.17 # ne fourni pas le bon certificat pop.orange.fr
verdy_p
contributeur confirmé
contributeur confirmé
2 757  

Re: L'identification sur le serveur pop.orange.fr a échoué.

Ce n'est pour tant pas compliqué à voir; ces certificats invalides ne sont pas signés.

La seule signature présente n'est pas le certificat mais une signature très faible (SHA1) uniquement de leur "timestamp" indiquant juste qu'Orange a utilisé un serveur de temps de Digicert pour dater sa demande du 9 avril.

 

On y trouve donc que:

 

     X509v3 Basic Constraints: 
                CA:FALSE
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : A4:(..snip..):0A:
                                3C:(..snip..):10
                    Timestamp : Apr  9 14:28:59.450 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256

et rien d'autre. Et surtout rien pour prouver que cela émane réellement d'Orange et pas assez pour certifier même que le timestamp vient des serveurs d'horloge authentiques de Digicert et donc dater précisément cette demande et sécuriser la séquence des demandes-réponses entre Orange et Digicert contre le détournement d'identité (ces échanges se font probablement par mail ici, alors qu'on n'a pas besoin de "précertificats" comme ici si il avait été utilisé l'interface web de Digicert destinée à ses clients comme Orange). Si ça s'est fait par mail c'est que ce n'est pas Orange qui a formulé les demandes mais un de ses prestataires externes qui n'ont pas accès directement à l'interface web du compte client Orange chez Digicert.

 

Au vu de la date du 9 avril (non sécurisée) indiquée, logiquement cette demande de certificat a du être rejetée par Digicert qui exige depuis fin mars que ces demandes soient horiodatées avec une signature en SHA2 (SHA1 n'est plus autorisé). Cette demande de certifiocat a du revenir par mail en copie à Orange qui a confondu ce cerficait retourné comme le véritable certificat accepté et enregistré par Digicert. D'ailleurs on le voit sur les 8 autres serveurs: c'est une date ulrérieure, et les horodatages sont signés avec une empreinte SHA2 et non SHA1 comme ici. donc soit Orange s'est bien planté et a confondu les mails de réponse de Digicert, ou bien ce sont des faux certificats montés sur des serveurs qui ne sont en faiut pas chez Orange (et alors n'ont rien à faire dans les DNS d'Orange) ! Ce certificat de demande de signature est donc très probablement un faux, cette demande n'a pas pu être acceptée avec ce "précertificat".

 

Ces deux serveurs sont en plus à des adresses IP étranges, comme s'ils avaient été ajoutés aux DNS avant d'avoir été installés. Rien ne garantit qu'au bout cela arrive réellement sur un serveur Orange, ça peut être chez un tiers qui aurait trouvé le moyen de rerouter ces adresses 17 et 209 en installant un routeru parasite et en réduisant le bloc IPv4 à un /31 (le .16 peut rester chez Orange, le .17 tombe sur un routeur aconnecté chez Orange via un VPN parasite, qui redirige secrètement le trafic ailleurs; même chose pour le .209).

Je m'interroge sur les annonces de routage IP, d'autant plus qu'Orange n'utilise pas du tout DNSSEC pour ses domaines mais un protocole plus basique (qui n'est pas protégé en cas d'acheminement de clients IPv6 via des tunnels IPv6 vers IPv4). DNSSEC éviterait cela totalement.

 

verdy_p
contributeur confirmé
contributeur confirmé
2 756  

Re: L'identification sur le serveur pop.orange.fr a échoué.

Et il serait temps qu'Orange mette ses serveurs POP3 accessibles nativement en IPv6 (d'autant plus pour les abonnés Orange sur réseaux mobiles). Et là DNSSEC ne sera plus une option, ce sera obligatoire, de même que le routage ICMPv6 pour PMTUD car DNSSEC ne peut pas supporter la fragementation en IPv6. Quitte à installer DNSSEC, autant le mettre aussi sur les interfaces IPv4.

A mon avis Orange n'a même pas 10 serveurs POP3 comme indiqué par un "nslookup pop.orange.fr", mais seulement 8 (les 4 premiers de chacune des deux plages IPv4 mentionnées), les deux autres ajoutés à la fin de chaque plage ne devraient pas être là dans les DNS "d'autorité" du domaine orange.fr, ou ne devraient être que des adresses de routeurs (sans aucune port POP3 ou autre à l'écoute sur le port 995). Ou bien ils n'ont été créés que temporairement pour créer des serveurs de test/débogage, afin de seulement tester les routages IP et depuis sont restés de façon parasite et ne sont pas administrés du tout (Orange aurait du alors les inscrire dans un sous-domaine spécifique tel que "test.pop.orange.fr" mais pas dans "pop.orange.fr" avec un enregistrement de type "A").

Même chose pour les enregistrements DNS inverses (d'une IP vers un nom de domaine "canonique" qui eux aussi devraient aussi être protégés par DNSSEC, donc pas seulement des enregistrements "A" ou "AAAA", mais aussi "RRRR"; la protection utilisée est un vieux système utilisant des enregistrements "TXT" avec un protocole peu fiable et très verbeux, qui ne seont même pas lisibles par requête DNS par UDP sans fragmentation de trames IP, donc incompatible avec IPv6; sachant aussi que la plupart des clients n'utilisent que l'UDP pour interroger les DNS, très rarement TCP sauf pour les requêtes de transfert dont l'usage est très limité en volume, et pose de sérieux problèmes de connectivité du fait de la rareté des ports TCP et du temps très long pour les éteindre: le DNS en TCP est sensible aux attaques DDOS, alors que le DNS en UDP est très résistant à condition d'utiliser des requêtes très limitées, jamais plus de 500 octets en IPv4 et jamais plus de 1500 octets en IPv6).

Je note que les DNS d'ORange fournissent des réponses dépassant les 800 octets, ils sont déjà sensibles et craquables en UDP, notamment en utilisant la fragmentation IPv4 et l'insertion de trames fragmentées par un hôte malveillant utilisant des techniques de "spoofing" par "flood de réponses". DNSSEC bloque cette attaque avec des requêtes courtes compatibles en taille avec UDP (aussi bien en IPv4 qu'IPv6), mais la sécurisation "pseudo-renforcée" avec le protocole "TXT" trop verbeux utilisé sur les enregistrements DNS d'Orange est illusoire, on la casse facilement en empêchant un client DNS d'avoir accès aux infos des services web de vérification (en plus ce protocole de vérification est particulièrement lent car pour l'utiliser il faut établir des sessions TCP, c'est tellement lent que ces enregistrements ne sont pas vérifiés et même ignorés et jamais demandés par les clients).

Pour plein d'agents de messagerie POP3, les domaines d'Orange ne sont pas sécurisés même s'ils utilisent SSL, et au final même SSL echoue puisque'il ne parvient pas non plus à charger des certificats signés par une CA connue et facilement vérifiable sans avoir à réaliser de façon des requêtes répétées sur les réseaux, ce qui pour Orange se traduirait de la même façon que des attaques DDOS contre ses serveurs avec un flux de connexions TCP venant toute les 5 minutes de millions de clients: avec seulement 8 ou même 10 adresses IP, impossible de tenir la charge à cause de la saturation des ports disponibles sur le serveur pour y répondre en TCP).

Un calcul simple: un serveur n'attribera au mieux de 32000 sessions TCP à la fois sur un listener IP. Et la session dure au minimum 1 seconde, et le port TCP n'est libéré au mieux que 30 secondes aprsè la fin de session, et cela donne une capacité maximale de 64000 client par minute; avec 10 adresses IP cela monte au maximum à 640 000 clients distinct servis par minute, mais Orange a des millions de clients et doit pouvoir répondre toutes les 5 minutes à 10% d'entre eux et tenir pour chacune une sessions moyenne durant au plus 5 secondes. Il lui faudrait donc une centaine d'adresses IPv4 pour y répondre, à condition qu'un équilibreur de charge (au niveau 2) soit inséré à l'entrée de son réseau/parefeu pour garantir qu'ils soient tous servis équitablement, ce qui n'est pas le cas apparement (il n'y a visiblement aucun proxy frontal).

- Si Orange avait ses serveurs POP3 accessibles en IPv6, il pourrait les router vai un large bloc /48 sans jamais saturer ses ports disponibles, et un équilibrage de charge serait plus simple, les délais de réponse allongés (et pas réduits à quelques secondes), il pourrait permettre des sessions TCP très longues, et utiliser une sécurisation renforcée (y compris avec chiffrement en ligne) pour servir tous les millions de clients, même connectés presque en permanence. Orange pourrait à loisir ajouter autant de serveurs qu'il veut sur le bloc IPv6 /48 (où il y a des milliards d'adresses IP, bien plus que l'ensemble des clients Orange sur l'ensemble de leurs équipements et terminaux d'accès). Et le tout en annonçais route IPv6 unique sur un bloc non fragmenté.Le bloc IPv6 serait inclus en entier dans un enregistrement DNSSSEC unique.

- Le trafic s'établierait par défaut avec une MTU d'au moins 1500 octets (en IPv6 elle peut augmenter à 1472 octets sans fragmentation, contre 1500 en IPv4 mais au prix d'une fragmentation à éviter totalement pour la sécurité) et non 500 octets pour les premières trames (démarrage lent) si on veut éviter la fragmentation et l'usage obligatoire de PMTUD pour monter la MTU de façon sécurisée, et avoir une bien meilleure performance et mieux resister aux attaques DDOS).

- Orange dispose déjà de milliers de tunnels IPv6 vers IPv4 pour ses réseaux mobiles, il peut aussi faire l'inverse et router nativement en IPv6 ses millions de clients mobiles et utiliser des milliers de tunnels IPv4 sur IPv6 (sans aucune contrainte sur les ports) pour ses vieux clients (de moins en moins nombreux) qui n'utilisent que l'IPv4 (et bientôt n'auront plus le choix! IPv6 sera obligatoire car il n'y aura pas une adresse IPv4 pour tout le monde, Orange va devoir céder des adresses pour les réserver aux serveurs, pas aux abonnés qui devront se les partager en NAT avec des tranches de ports plus petites, comme chez Free qui n'a plus que 16384 ports et non 65536 sur l'adresse IPv4 fournie partagée par 4 clients qui peuvent être n'importe où en France ce qui impose de centraliser le trafic sur un seul noeud parisien et donne des routages très peu efficaces et un goulot d'étranglement sur les réseaux de collecte).

----

Noter qu'il faut le dire tout de suite: Ipv4 est condamné à mourir pour les clients: sur Internet il ne servira qu'à interconencter les structures, et à terme il ne devrait plus servir que sur des réseaux privés. Il est temps qu'Orange se mette à IPv6 et pas que pour les mobiles (les APN mobiles fournissent seulement une adresse IPv4 privée par NAT comme si on était sur une box à domicile, errière cela c'est soit du routage IPv6 natif, soit la transition par des serveurs web proxy surchargés et limités sur les protocoles pris en charge et aussi fortement limités en débit avec un temps de réponse allongé de +20 milliseconde, pour la 5G il n'y aura pas le choix que d'offrir la connexion IPv6 native, mais alors Orange devra aussi fournir ses services de messagerrie en IPv6 natif, comme le font déjà Google ou Free depuis longtemps, car aucun proxy web ne peut tenir la charge de millions de clients, déjà la vidéo ou la TV sur mobiles ne se diffuse plus qu'en IPv6 chez Youtube, DailyMotion, Facebook, Twitter...) Et la vidéo sur Internet représente maintenant 80% du trafic mondial et les accès internet mobiles sont maintenant majoritaires.

L'investissement d'Orange pour upgrader ses serveurs de messagerie en IPv6 sera ridiculement faible en comparaison du cout de maintenance de milliers de serveurs de tunnels et de leur extrême lenteur (inadaptée à la fibre ou la 5G), car la messagerie représente un trafic de volume ridiculement faible en comparaison de la vidéo et même la téléphonie.

Avec IPv6, le seule chose qu'il anque à Orange c'est un unique certificat pour DNSSEC et une mise à jour unique (au passage il pourra économiser sur la maintenance de son plan de routage IPv4 de plus en plus complexe car très fragmenté).

Ceux qui critiquent IPv6 en disant que c'est lent, c'était vrai au début mais ce n'est plus le cas: IPv6 est maitnenant un peu plus rapide et plus résistant à plein d'attaques (y compris DDOS) en évitant la fragmentation (qui ne résiste pas aux attaques d'obfuscation par "flooding" des clients, très peu couteux à mettre en oeuvre car cela ne demande pas plus de quelques mégabit/s de flood pendant quelques secondes pour une attaque "man-in-the-middle").

Google pour résister aux attaques (DDOS contre ses serveurs et flood contre ses clients) est obligé d'avoir des dizaines de milliers d'addreses IPv4 et des proxies partout dans le monde via un CDN très couteux. En Ipv6 il n'a besoin d'annoncer qu'une seule route IPv6 sur un unique bloc IPv6 /48 par service (exemple POP3) qui est extrêmement difficile de compromettre et il peut l'tuliser pour mettre en face des milliers ou même des millions de serveurs dans quelques très gros datacenters très centralisés et de cout d'exploitation très réduit et une grande facilité de maintenance et beaucoup de redondance possible contre les pannes. On comprend pourquoi Google milite maintenant tous les ans pour une adoption mondiale d'IPv6. En France et même en Europe Free a été longtemps pionnier en donnant la connexion IPv6 native chez tous ses abonnés. Orange commence à peine les travaux quand il n'y a plus d'adresses IPv4 disponibles et qu'il est contraint de céder des adresses aux fournisseurs de service (d'autant plus que les couts par adresse IPv4 détenue explosent et dépassent les 11 dollars par an, plus une vingtaine de dollars par an pour maintenir les plans de routage entre opérateurs de réseaux)

Rien que l'argument du cout croissant du cout d'IPv4 sur l'Internet public devrait convaincre que ce protocole n'est plus du tout pour l'Internet, juste pour les réseaux privés.

black-ice
#TopMembre
#TopMembre
2 649  

Re: L'identification sur le serveur pop.orange.fr a échoué.


@KaLisBlack@  a écrit :

Il est temps qu'Orange fasse quelque chose sérieusement... Comment expliquer que je n'arrive qu'à paramétrer correctement en POP ou en IMAP un seul compte de messagerie sur 2 ?

 

J'ai peur pour la confidentialité de mes mails :-(


bonjour @KaLisBlack @verdy_p @papou22

  @PhilDur

des erreurs de certificatsdes problèmes de configuration et je vois

Révélation

Comment expliquer que je n'arrive qu'à paramétrer correctement en POP ou en IMAP un seul compte de messagerie sur 2 ?

 

je pense que ca doit etre l'usage du webmail

@pourma part j'ai plusiieurs boites mail configuré en @orange.fr et je ne rencontre aucun problème tant en emission qu'en reception,

changez vos habitudes oubliez le webmail et passez par un client mail de type thunderbird ou autre vous aurez moins de problèmes voire pas du tout

keep calm and stay connected


melet39
#TopMembre
#TopMembre
1 181  

Re: Re : L'identification sur le serveur pop.orange.fr a échoué.

@Piclote 

 

explique ton problème,ce fil a 2 ans

"L'obstination est le chemin de la réussite." Charlie Chaplin
Helllo
helper
156  

Re: Re : L'identification sur le serveur pop.orange.fr a échoué.

Bon, il paraît qu'il y a une réponse de @PhilDur en réponse à mon message que je ne vois plus, mais je ne sais pas où elle est.

Vous avez une question ?

Interrogez la communauté

Déjà 712972 membres inscrits 🧡

1994 personnes actuellement en ligne

Tous les membres en ligne