internet & fixe mon mail Orange Voir tous les sujets internet & fixe

[#1]

C'est de la auvaise foi de ta part. Tu n'as absolument pas besoin de mes DNS puisque je t'a irépondu que ça concerne TOUS les accès Internet que j'ai essayés (fixe ou mobiles).

Tu me demandes une copie des certificats, mais justement en cas d'erreur SSL 48, je n'ai QUE le statu et aucun système ne me présdente une copie du certificat refusé.

Tou ce que je peux dire c'est que même un accès par le navigateur web à https://pop.orange.fr:995/ ne parvient pas non plus à établior une connexion SSL et affiche "port unsafe", et le détail donne aussi une erreur SSL 48 (la néco SSL a lieu et est interrompu avant de commencer la session HTTP (le première commande "GET / HTTP/1.1" n'est même pas envoyé, pas plus que la commande Hello pour POP ni aucun autre attribut).

Les IP de pop.orange.fr sont correctes d'après tous les DNS testés.

------------
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 10, authority records = 2, additional = 4

QUESTIONS:
pop.orange.fr, type = A, class = IN
ANSWERS:
-> pop.orange.fr
internet address = 80.12.24.17
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.15
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.206
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.207
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.16
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.208
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.205
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.14
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.209
ttl = 323 (5 mins 23 secs)
-> pop.orange.fr
internet address = 80.12.24.13
ttl = 323 (5 mins 23 secs)
AUTHORITY RECORDS:
-> orange.fr
nameserver = ns1.orange.fr
ttl = 146373 (1 day 16 hours 39 mins 33 secs)
-> orange.fr
nameserver = ns2.orange.fr
ttl = 146373 (1 day 16 hours 39 mins 33 secs)
ADDITIONAL RECORDS:
-> ns1.orange.fr
internet address = 80.10.201.224
ttl = 95111 (1 day 2 hours 25 mins 11 secs)
-> ns2.orange.fr
internet address = 80.10.202.224
ttl = 88396 (1 day 33 mins 16 secs)
-> ns1.orange.fr
AAAA IPv6 address = 2a01:cb04:2040:2::1
ttl = 89174 (1 day 46 mins 14 secs)
-> ns2.orange.fr
AAAA IPv6 address = 2a01:cb14:2040::1
ttl = 106670 (1 day 5 hours 37 mins 50 secs)

------------
Réponse ne faisant pas autorité :
------------
Got answer:
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
pop.orange.fr, type = AAAA, class = IN
AUTHORITY RECORDS:
-> orange.fr
ttl = 335 (5 mins 35 secs)
primary name server = ns1.orange.fr
responsible mail addr = postmaster.orange.fr
serial = 2018051702
refresh = 21600 (6 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 300 (5 mins)

------------
Nom : pop.orange.fr
Addresses: 80.12.24.17
80.12.24.15
80.12.24.206
80.12.24.207
80.12.24.16
80.12.24.208
80.12.24.205
80.12.24.14
80.12.24.209
80.12.24.13

------------

Je ne vois pas de différence de résultat si je fais un nslookup avec les serveurs DNS publics de Google (8.8.8.8 et 8.8.4.4) ou ceux d'OpenDNS (208.67.222.222 et 208.67.220.220), hormi l'ordre aléatoire des réponses pour les adresses possibles:

> pop.orange.fr
Serveur : google-public-dns-a.google.com
Address: 8.8.8.8

Réponse ne faisant pas autorité :
Nom : pop.orange.fr
Addresses: 80.12.24.205
80.12.24.15
80.12.24.13
80.12.24.14
80.12.24.16
80.12.24.209
80.12.24.206
80.12.24.17
80.12.24.207
80.12.24.208

> server 8.8.4.4
Serveur par défaut : google-public-dns-b.google.com
Address: 8.8.4.4

> pop.orange.fr
Serveur : google-public-dns-b.google.com
Address: 8.8.4.4

Réponse ne faisant pas autorité :
Nom : pop.orange.fr
Addresses: 80.12.24.209
80.12.24.16
80.12.24.14
80.12.24.206
80.12.24.207
80.12.24.205
80.12.24.13
80.12.24.208
80.12.24.15
80.12.24.17

> pop.orange.fr
Serveur : resolver1.opendns.com
Address: 208.67.222.222

Réponse ne faisant pas autorité :
Nom : pop.orange.fr
Addresses: 80.12.24.16
80.12.24.206
80.12.24.14
80.12.24.13
80.12.24.207
80.12.24.208
80.12.24.15
80.12.24.209
80.12.24.205
80.12.24.17

> pop.orange.fr
Serveur : resolver2.opendns.com
Address: 208.67.220.220

Réponse ne faisant pas autorité :
Nom : pop.orange.fr
Addresses: 80.12.24.205
80.12.24.17
80.12.24.16
80.12.24.206
80.12.24.14
80.12.24.13
80.12.24.207
80.12.24.208
80.12.24.15
80.12.24.209

Le "traceroute" semble aller effectivement vers Orange:

-----

Détermination de l’itinéraire vers pop.orange.fr [80.12.24.17] avec un maximum de 30 sauts :

1 <1 ms <1 ms <1 ms [192.168.1.254]
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
4 32 ms 33 ms 42 ms 193.253.13.69
5 23 ms 23 ms 23 ms ae50-0.nridf302.Paris13eArrondissement.francetelecom.net [193.252.99.105]
6 24 ms 25 ms 24 ms ae40-0.ncidf304.Neuilly-sur-marne.francetelecom.net [81.253.180.29]
7 24 ms 24 ms 24 ms lag-1.npidf302.Neuilly-sur-marne.francetelecom.net [193.252.159.138]
8 24 ms 24 ms 24 ms 193.252.164.102
9 * * * Délai d’attente de la demande dépassé.
10 24 ms 24 ms 24 ms pop.orange.fr [80.12.24.17]

----

Selon le fournisseur d'accès, la seule chose qui varie ci-dessus ce sont les premières lignes (avec les astérisques) mais les dernières sont toujours là (celles en 193.252.*.* et la dernière 80.12.24.*). ce sont là des temps mesurés depuis un accès fibre 1Gigabit/s (avant le 1er mai les temps de latence étaient voisins de 9-12ms contre 24ms aujourd'hui). La première ligne est celle de mon routeur Internet local.

Mais l'adresse IP finale (qui répond bien au ping) n'a pas les bon certificats. Je ne sais pas quel hôte est à la ligne 9 de la traceroute ci-dessus entre 193.252.164.102 et 80.12.24.17, il n'est pas identifié.

Ce qui m'intrigue c'est la ligne 4 (193.253.13.69) dont le temps de ping est plus long et pas identifiée, et je soupçonne un spoofing à ce niveau (les autres adresses plus bas seraient alors simulées).

[#2]

Et si je fais un whois sur 193.253.13.69, selon RIPE cette adresse IP n'est PAS attribuée, donc elle est piratée.

Je la vois partout sur toutes les traceroutes depuis tous les accès internet que je teste.

Y compris en testant depuis d'autres sites comme ici un site de test depuis l'Australie:

https://dig.whois.com.au/trace/80.12.24.16

qui mentionne 193.252.159.134 mais ce cerveur ne parvien pas à trouver une route vers 80.12.24.16, le pop d'Orange inaccessible depuis ce serveur Australien.

Et pas plus avec https://www.ultratools.com/tools qui ne trouve pas de route vers 193.253.13.69, ni même par d'autres chemins vers  80.12.24.16; le chemin testé s'arrête à :

8 Connected to: hundredgige1-2-0-3.auvtr4.aubervilliers.opentransit.net (193.251.128.81 ) Roundtrip times: 95,862 ms

et n'aboutit nulle part.

Une bonne partie des routes internes chez Orange ne marche pas du tout. Le routage est bogué.

Si TU fais les tests depuis ton accès Orange actuel ce n'est PAS significatif du tout.

Recommence en faisant les tests à partir de serveurs externes à Orange, peu importe lesquels, ça ne marche jamais nulle part.

[#3]

Donc arrête les accusations de "pananoïa", ce sont des faits réels et tous les outils d'analyse externes à Orange mentionnent des anomalies graves chez Orange.

Orange ne communique pas (ou ne veut pas communiquer, pas plus que les autres opérateurs qui doivent avoir mis en place quelques liens VPN par des peering **privés** pour véhiculer une partie du trafic, avec au point de connexion du VPN avec les autres réseau un parefeu très agressif qui bloque plein de traffic).

Le réseau interne chez Orange est bel et bien compromis et ça explique les pannes sérieuse qu'ont eu tous les réseaux mobiles en France (dont c'est Orange qui faisait l'acheminement via son infrastructure) jusqu'à ce que ces opérateurs négocient secrètement avec Orange des VPN privés pour sécuriser leurs échanges avec certains services ou pour délivrer des contenus aux abonnés Orange (Orange a du mettre en place des serveurs proxy ou NAT relais). Le HTTP ou HTTPS semble fonctionner, mais pas tous les protocoles (ICMP ne fonctionne pas correctement, pas plus que le PMUTD pour IPv6 qui pendant 8 jours souffrait de défauts à cause de la fragmentation des trames non supportées en IPv6 avec IPSEC ou DNSSEC). Le DNSSEC chez Orange est lui aussi non fonctionnel sur tous ses domaines.

[#4]

Bonjour à tous,

J'ai exactement le même problème en IMAP et en POP: les serveurs refusent mon authentification.

Mon adresse email a récemment été créée (nouveau client Sosh depuis février) et l'authentification échoue systématiquement sur imap.orange.fr:993 et pop.orange.fr:995. La raison est "identifiant ou mot de passe incorrect ou l'accès POP3/IMAP n'est pas activé sur votre compte..."

Vous vous imaginez bien que je connais parfaitement mon mot de passe et que mes doigts ne sont pas si gros...

Le plus étonnant dans tout ça, c'est que l'authentification fonctionne très bien sur une seconde boîte mail orange créée pour l'occasion.

Pour moi, je penche sur un problème d'association du compte d'administration du contrat Orange (le compte de gestion de l'abonnement) et du compte de messagerie! Oui ce sont les mêmes !

Autre élément perturbant, le compte de gestion accepte les mots de passe avec un underscore (_) (lors de la souscription de mon contrat Sosh) alors qu'il n'est pas possible d'en mettre un dans le mot de passe de l'adresse email !!??

Ca coince quelque part par là à mon avis.

Je vais essayer en elevant tout caractère spécial dans le mot de passe pour voir...

Dans tous les cas, la recommandation suivante "mon mot de passe doit comporter entre 8 et 16 caractères en combinant lettres et chiffres, sans accent ni tiret ni espace" n'est pas adaptée à la sécurisation d'un mot de passe...

[#5]

Apparemment c'est le certificat racide Thawte (initialement détenu par Symantec) qui a été révoqué par DigiCert (qui a acquis Symantec il y a 3 ans) :

https://creditcall.zendesk.com/hc/en-gb/articles/360000200291-Important-Announcement-Retiring-Thawte...

Et le test de "pop.orange.fr" sur le siute de test de DigiCert le confirme.

Ce certificat aurait du être remplacé depuis 3 ans par "DigiCert Global Root G2" bien avant la révocation qui a eu lieu en fin avril (donc avant la date limtie de validité du certificat initial).

De plus, toutes les versions de SSL sont maintenant désapprouvées et remplacées par TLS. En juin prochain les versions TLS 1.0 et 1.1 seront aussi désapprouvées TLS 1.2 sera obligatoire.

Plusieurs algos cyrptographiques seront requis et d'autres supprimés. Les longueurs de clés sont également supérieures. Le certificat ci-dessus était basé sur des clés déjà trop courtes, mais surtout Symantec a voulu maintenir ce certificat uniquement pour ses opérations internes.

Google, puis les autres fournisseurs de logiciels (les OS ou navigateurs, ou applications) ont déjà intégré les nouveaux certificats et maintenant commence à retirer l'approbation des anciens certificats qui ont été retirés des magasins de certificats racine.

Cela donne donc bien l'erreur 48 (unknown CA) tel que défini dans la RFC du protocole TLS: une chaine de certificats a bien été reçu, mais le certificat présenté par le serveur pop.wanadoo.fr ou pop.orange.fr ne peut plus être vérifié car il est signé par une CA inconnue ou non approuvée ou retirée de la liste des Root CA de confiance.

Ceux qui ne sont pas affectés utilisent d'anciennes versions de logiciels ayant leur propre magasin de certificats pas à jour, où l'ancien certificat est encore présent donc accepté. Et où leur logiciel est réglé également (de façon très fortement déconseillée) pour ne pas utiliser les listes de révocation de certificats (fichiers .crl ou protocole OCSP) émis par les émetteurs de certificats.

Tout acquéreur de certificat est normalement abonné à une lsite de diffusion ou un bulletin qui l'informe de la possibilité que les signatures de leurs certificats pourraient être révoquées: le fournisseur de PKI leur émettra un nouveau certificat à ajouter sur leur serveur (les deux cohabitent sur le serveur tant que l'ancien n'est pas encore désapprouvé, un client peut se connecter au serveur en utilisant soit l'un soit l'autre dans cette période de transition, mais le client reçoit aussi une notification lui indiquant qu'un autre certificat est recommandé, et un client bien fichu va le charger pour l'utiliser de préférence à l'ancien; finalement quand la période de transition se termine, elle dure au moins 3 mois et jusqu'à 2 ou 3 ans, l'ancien certificat est révoqué).

Pour les navigateurs web, les listes de certificats racine sont celles du magasin de certificats de l'OS sous-jascent... sauf Mozilla Firefox qui dispose de son propre magasin, mais même la version actuelle de Firefox contient les nouvelles listes de certificats dans son magasin par défaut. La plupart des utilisateurs n'a pas à s'occuper de cette mise à jour qui est faite en même temps que leur OS ou leur navigateur. Si vous utilisez encore une vieille version de Windows ou ne mettez pas à jour votre Linux, vous n'avez que l'ancien certificat en magasin, et si vous ne voulez pas faire la mise à jour de l'OS ou l'application, il vous faut installer manuellement le nouveau certificat racine. Si vous ne désinstallez pas l'ancien certificat racine il marche encore pour vous connecter aux serveurs qui l'utilisent comme signataires des certificats serveurs, même s'il est déjà désapprouvé/révoqué, et cela marche seulement si vous avez désactivé les listes de révocation ou le protocol OCSP dans votre logiciel.

Pour les clients de messagerie web, le magasin est géré par le fourniseur de messagerie: Google est à jour et a honoré la désapprobation demandée par Digicert sur le vieux certificat Thawte, puisque l'immense majorité des navigateurs webs sont déjà à jour. Il n'accepte plusl'ancien certificat.

Orange n'a pas mis à jour ses serveurs depuis des années, il aurait pu le faire depuis déjà 3 ans.

Son certificat de serveur n'est plus conforme. De plus ils sont des problèmes de connectivité (difficile à joindre aux adresses IP indiquées, et le routage a été facilement détourné (spoofé) depuis cette révocation.

Les parefeus entre réseaux analysent les connexion SSL pour vérifier l'intégrité des certificats et si un certificat présenté par un serveur est rejeté, ils peuvent interrompre une session et ne même pas présenter au client demandeur le certificat proposé, à la place ils envoient uniquement une alerte SSL avec l'erreur 48 (unknown CA) et interrompent immédiatement la connexion. Aucun réseau tiers ne va accepter d'honorer des sessions SSL utilisant des certificats invérifiables et s'ils le font, ils aident à propager un certificat que les utilsiateurs ne devraient PAS installer dans le magasin local (puisqu'en plus le certificat racine est officiellement révoqué par son détenteur).

De nombreuses révocations de certificats ont lieu depuis le début de l'année (pas seulement des certificats racines, dont la révocation est plus rare, mais des tas de certificats des autorités intermédiaires qui sont eux-mêmes signés par une autorité racine: et depuis janvier des tas d'autorité intermédiaires ont publié de nouveaux certificats pour remplacer les certificats racine auparavant émis par Symantec et ses filiales, toutes passées chez Digicert, et notamment les certificats "Thawte"). DigiCert a informé tous ses clients depuis des années, y compris Orange qui n'en a pas tenu compte....

[#6]

@verdy_p

Tu parles de ce défaut d'autorité de certification ?:

openssl s_client -showcerts -connect imap.orange.fr:993
CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=FR/ST=Paris/L=Paris/O=Orange/OU=Orange France/CN=imap.orange.fr
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4

[#7]

non c'est encore autre chose. Un "self signed certificate" c'est normal, ce n'est pas une erreur si c'est un certificat racine (il n'est pas contresigné par une autre autorité.

D'ailleurs l'erreur SSL/TLS est 19 (on la trouve sur TOUS les certificats racine) et non 48 (qui n'existe que pour les certificats non-racines signés par une autorité racine ou intermédiaire qui n'est pas reconnue).

L'erreur 19 n'est pas fatale, contrairement à l'erreur 48 qui l'est **oligatoirement** selon les RFC) mais peut l'être pour un logiciel si elle est trouvé dans un magasin de certificats intermédiaires ou de serveurs/d'applications.

Le certificat "VeriSign Class 3 Public Primary Certification Authority - G5" est parfaitement valide et fait partie des nouveaux certificats qui ont remplacé d'autres certiticats racines plus anciens de VeriSign.

 Ensuite ce certificat est utilisé pour approuver le certificat d'Orange affiché en dessous.

Là je parle d'un vieux certificat Thawte (regarde un peu sur Internet et cherche "root ca certificate revoked" et tu trouveras plein d'annonces chez les fournisseurs de certificats intermédiaires, demandant depuis fin 2017 à leur clients de se mettre à jour de façon urgente (délai court: moins de 3 mois, les dates butoir étaient en général en fin mars 2018 avant leur révocation peu après).

Et puis tu testes "imap.orange.fr:993" et non "pop.orange.fr:995" ! Tu te trompes de serveur !

[#8]

C'est complètement dingue et grave comme histoire mais je pense que tu as raison.

Ma femme me confirme avoir configuré sa nouvelle boîte mail Orange sur son Android il ya une semaine/10 jours.

Ce qui voudrait dire qu'elle n'a pas le bon certificat d'après toi ?

Et moi j'essaie désespérement de configurer la mienne depuis hier soir mais ni Android ni Outlook 2016 n'accepte le certificat...

[#9]

open_ssl sous Linux affiche ce statut final pour pop.orange.fr:995

Verify code: 21 (unable to verify the first certificate)

La cause: 

La renégociation échoue à trouver la méthode de chiffrage appropriée pour l'échange de clés en TLS 1.2

Le chiffrage sélectionné est trop faible pour ce type de certificat: ECDHE-RSA-AES128-SHA

Ce devrait être EDCHE-RSA-AES128-GCM-SHA256

car le certificat de signature de DigiCert n'a pas d'empreinte numérique faible en SHA1, seulement en SHA256 (et cela depuis fin avril), et Orange n'a pas utilisé le bon algo pour nenouveler son certificat.

Digicert maintenant ne diffuse plus sa propre signature en SHA1 et les clés de cryptage fournies par Digicert ne permettent plus de déchiffer et certifier sa signature du certificat Orange. Le certificat Orange n'est donc pas utilisable et ne peut donc être stocké en cache dans le magasin de certificats "serveurs" local du client puisqu'il n'est pas approuvé par l'autorité racine.

Chez toi ça marche parce que tu as déjà installé l'ancien certificat serveur d'Orange et qu'il est encore dans ton cache local et pas désapprouvé non plus par Orange.

[#10]

bonsoir ! (ça marche aussi ? ^^)

j'ai un souci un peu similiaire mais quelque peu étrange.

Ce matin (vers 8h), j'ai été victime d'une tentative de phishing.

Je m'en suis aperçu immédiatement après avoir tenté de m'identifier sur ma boite répondeur.

Dans les 10 mn qui ont suivi j'ai changé mon mot de passe...

j'ai continué à recevoir mes mails normalement sur outlook jusqu'à environ 11h.

Puis plus rien... outlook ne se connectait plus ni au pop, ni au smtp.

Appel au SAV... pendant 2 heures tentatives de paramétrage sur Outlook et sur Mail (je suis sous OS 10.10).

Echec... rendez-vous est pris mardi prochain.

MAIS...

tout à l'heure ultime tentative, je remets l'ancien mot de passe dans outlook et... il relève les mails scotchés dans webmail...

Donc j'ai un mot de passe pour m'identifier au webmail, espace client etc.

ET, un mot de passe pour relever mes mails ???

Comment est-ce possible ?

Problème de serveur Orange, piratage ?

quelqu'un aurait-il idée ?

{edit : j'ai essayé de lire tout ce qui précède, mais j'avoue que je n'ai pas tout compris au jargon technique...}