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

[#1]

Le certificat donne effectivement des noms de domaines et pas des IP, mais la négociation SSL se fait toujours en se connectant avec des IP.

Tu ne sembles pas comprendre:

Le client fait dans l'ordre:

- une résolution du Nom DNS en adresses IP (l'équivalent du nslookup pop.orange.fr qui retourne 10 ici 10 adresses dans un ordre aléatoire, il en choisit une, lke plus ouvent juste la première présentée, et il la garde dans un cache DNS local, il peut également garder les autres en cache si une connexion avec la première adresse échoue et que le client refera une autre requête de connexion)

- dans le cas présent il parvient à établir une connexion TCP sur le port SSL indiqué 995 quelque soit l'adresse IP utilisée, il n'a donc pas besoin d'aller chercher les autres, la première lui suffit même si la session SSL ensuite produit une erreur

- il engage l'échange des clés pour SSL avec les certificats: le serveur lui donne un certificat, il ne sait pas si le client a accédé par une nom de domaine ou pas (ce n'est pas transmis sur la session TCP par le client), ce sera donc le même certificat quel que soit le nom domaine utilisé et résolu par le client ou l'adresse IP utilisée pour se connecter.

- le client commence par vérifier l'authenticité du certificat. S'il n'est pas un certificat racine, le client va rechercher le certificat de la racine signataire: c'est là qu'à lieu l'erreur openssl 20 ou 21 (erreur 48 unknown_ca dans le protocole SSL)

- c'est seulement a près avoir validé l'authenticité de la signature du certificat que le client va ensuite en vérifier le contenu: là il va voir que le certificat est bien conçu pour authentifier un nom de domaine: si le client vouait effectivement se connecter à ce nom de domaine, il va continuer sinon c'est le client qui va décider soit de refuser ce certificat et fermer la session, soit présenter le certificat à l'utilisateur pour lui demander si le client accepte la connexion avec un certificat ne correpondant pas au domaine demandé (et comme dans ce cas le client a demandé une adresse IP et non un nom de domaine, cela ne correspond pas au départ mais le client pourrait regarder si l'adresse IP qu'il a utilisé correspond à un des domaines exposés par le certificat, mais cette méthode n'est pas aisée car un certificat peut exposer des domaines "wildcard" ne correspondant à aucune IP précise, et le DNS n'est pas obligé non plus de retourner toutes les adresses IP correspondant à un nom de domaine demandé, il peut n'en fournir qu'une partie et c'est aussi le cas ici, puisque les 10 adresses IP publiques que tu vois lors d'une connexion par Internet public ne sont pas les seules que le serveur peut servir, et en l'occurence les serveurs POP3 ont aussi des interfaces d'accès par d'autres adresses IP internes ou même éventuellement en IPv6 alors que le client a pu ne demander que les adresses IPv4).

- si le client accepte ce certificat, il va utiliser les clés de chiffrement négociées (entre le certificat du client et celui du serveur et les échanges de clés qui suivent, elles mêmes signées par une clé de hachage forte sur le bloc comprenant les clés publiques échangées et un bloc de données aléatoire unique pour la session SSL). Avec cette session est également fournie une "session key" unique (voir-ci dessous)

- le client peut utiliser cette session SSL pour échanger et chiffrer les login/mot de passe, puis entrer dans le protocole POP3 voulu et se déconnecter

- le client et le serveur peuvent conserver la "session key" en cache pour le réutiliser les fois suivantes (dans un délai imparti pouvant être long, et contenant aussi un numéro de séquence): pas besoin d'échanger les certificats SSL ni les clés de chiffrement, le client fournit sa session key et le numéro de séquence et si le serveur l'accepte encore et le numéro de séquence est correct, le client n'aura pas à faire l'échange de certificats et de clés à nouveau, il poursuit directement avec la session POP3 normale (mais sur le canal chiffré) donc en fournissant login et mot de passe au serveur POP3: Cela économise plusieurs pings-pongs pour la connexion SSL.

Dans ton cas, le fait de changer l'IP dans un fichier hosts n'a pas d'effet sur ton Thunderbird: d'une part il a déjà l'adresse IP du nom de domaine déjà utilisé avc succès, d'autre part il a une "session key" également en cache associé au certificat du serveur qu'il a déjà utilisé (et également encore en cache).

Si tu ne fermes pas complètement Thunderbird, ces caches internes (caches DNS, caches de certificat des serveurs déjà configurés, et cache des "session key") sont encore là. Tu peux toujours changer l'adresse IP de connexion mais ton Thunderbord a toujours le cache du certificat et sa session key et peut immédiatement tenter dès la connexion l'envoi d'une ouverture de session SSL (avec la MTU demandée pour TCP dans la trame SYN), que le serveur peut acquiter en même temps que la connexion TCP (trame ACK avec ma MTU adaptée par le serveur). Et sans attendre plus le client peut ensuite envoyer aussitôt (avec le chiffrement déjà en place poru la session en cache) les données chiffrées d'ouverture de session POP3 (login/mot de passe). La seule chose que vérifie le client c'est que l'empreinte numérique (SHA256 normalement) de sa demande de connexion, chiffrée par la clé privée du client et la clé publique du serveur est bien déchiffrée par le serveur qui connait la clé publique du client et la clé privée du serveur, sinon le serveur n'acquitte pas aussitôt la session SSL mais demande au client à renégocier les échanges de certificats d'identité et de clés...

Si tu fais tes tests en gardant Thunderbord ouvert avec une config qui marchait, mais que tu te contentes juste de changer le nom de domaine en adresse IP, ici cela va marcher car les deux certificats (celui invérifiable car non signé par Digicert, et celui complet et signé sur les autres serveurs) utilisent la même clé privée attendue. C'est le certificat qui est erroné, pas les clés: dans les deux cas (les deux certificats) les clés publiques exposées par le serveur sont les mêmes. Mais rien ne prouve que ce soit un serveur authentique (à mon avis c'est un bogue de Thunderbird, il devrait se rendre compte que bien que les clés soient identiques les certificats exposés sont différents: ce serveur pourrait être un faux faisant une attaque de type "man-in-the-middle", par détournement d'adresse IP). Ce n'est pas une anomalie de SSL. Le but de SSL ici est justement de pouvoir vérifier que c'est un serveur authentique.

Il faut aussi d'autres certificats pour certifier que les adresses IP obtenues par DNS pour un nom de domaine sont authentiques: cela nécessite DNSSEC sinon le client est exposé par une attaque de type "flood" pendant qu'il effectue sa requête DNS si un autre serveur malveillant fournit une réponse avant le serveur DNS véritable (quand on voit qu'il faut facilement 20 à 30ms pour résoudre une requête d'adresse IP à partir d'un nom de domaine, un système malveillant pourrait avoir une réponse toute prête pour diriger le client vers une autre adresse IP avant même que le client reçoive une réponse du serveur DNS qu'il a interrogé. C'est la raison pour laquelle les clients limitent fortement ce risque en utilisant un cache DNS: pour ne pas avoir à faire trop souvent les mêmes requêtes prévisibles de résolution du même nom de domaine, car on pourrait flooder ces réponses facilement (la protection des réponses DNS en UDP est relativement faible: l'attaquant doit juste deviner un numéro de séquence 16 bits et le port UDP auquel le client attend sa réponse, ce qui dans bien des cas est souvent le port 53, le même que le serveur, et sinon cela ne fait que 64K requêtes et un attaquant "floodeur" peut facilement envoyer plusieurs centaines voire milliers de réponses UDP contenant l'adresse IP qu'il veut, à un client dont il sait qu'il va faire des requêtes répétées du même nom de domaine).

Seul DNSSEC permet d'assurer que les réponses de résolution DNS sont authentiques et proviennent bien du serveur DNS interrogé et non pas d'un tiers qui peut savoir facilement, quand un client fait une requête poru un nom de domaine donné.

Là encore les noms de domaines des POP Orange ne sont toujorus pas protégés par DNSSEC (les enregistrements DNS de ces domaines n'ont pas les certificats nécessaires). Il est donc possible que le client se connecte en fait à une IP qui n'est pas celle d'un serveur POP d'Orange, et c'est au serveur de se présenter alors (une fois connecté à lui) avec un certificat valide et vérifiable (ce qui n'est pas le cas puisqu'oin ne voit que les certificats non signés qu'un attaquant peut reproduire à l'identique en prétendant être Orange, et en échangeant alors avec le client des clés de chiffrement qui en fait ne serviront pas à grand chose pour éviter la divulgation des login/mot de passe du client, comme si c'était en clair).

D'autres certificats existent enfin pour protéger les routes IP mais là ça se passe entre les routeurs du backbone internet et cela ne joue pas sur le protocole d'échange qui ne se fait que de bout en bout entre le client et un serveur qui accepte sa connexion.

Donc dans l'état actuel, avec les serveurs POP3 d'Orange non correctement certifiés, il est possible à des attaquants de capter les connexion des clients qui vont consulter leurs mail de façon répétitive: l'attaque est possible contre des clients dont les attaquants connaissent l'adresse IP: ils n'ont qu'à "flooder" ce client avec des réponses de résolution DNS fausses pour les diriger vers des serveurs malveillants. Il y a une parade à ça: que le client fasse ses requêtes DNS uniquement en TCP avec des sessions sécurisées elles aussi avec SSL/TLS mais c'est couteux et lent et peu de serveurs DNS le supportent pour des questions de charge: une session SSL à un serveur DNS peut cependant être maintenue active pendant assez longtemps pour éviter une attaque man-in-the-middle par flood vers le client, d'autant plus que la session SSL vers le serveur DNS est sécurisée contre les insertions de trames par les tiers et pas son chiffrement ou la signature par ajout d'une empreinte chiffrée et l'insertion de padding à contenu aléatoire dans les données dont on calcule l'empreinte chiffrée et la signature de cette empreinte.

SSL/TLS a toute une série de modèles d'algo de chiffrements, de signature, de clés, de padding, des options de vérification du temps. Utilisé avec DNSSEC, il est très solide, mais sans DNSSEC l'attaque est bien plus facile et encore plus si le service DNS est utilisé en UDP.

Un client POP3 en SSL demande normalement des certificats signés, il devrait refuser les certificats invalides. Il devrait aussi détecter l'IP spoofing, et le client DNS devrait aussi détecter les attaques MITM par flooding de réponses, et s'il en détecte devrait changer de port source et ne pas utiliser le port 53 par défaut, ou utiliser une session TCP par SSL à un serveur DNS sécurisé, lequel va également vérifier les entregistrements DNS "d'autorité" avec les données DNSSEC ajoutées aux domaines comme ceux d'Orange (qui malheureusement ne le sont toujours pas)

Les serveurs POP3 sont donc facilement attaquables. Et pour peu qu'ils aient servi à échanger des clés privées nécessaires pour l'obtention de certificats sans que ça passe par des serveurs de mail sécurisés eux aussi en SSL/TLS, le vol de clé privé est possible (normalement une clé priové de serveur ne devrait jamais être envoyée à distance par un réseau, mais des adminsitrateurs imprudents peuvent se connecter à un serveur où elles sont stockées ou fabriquées en utilsiant une session TELNET non chiffrée au lieu d'une session SSH sécurisée elle aussi par SSL/TLS... Partout sur Internet les certificats signés sont nécessaires, sauf pour les certificats racines dont l'authenticité peut être garantie en transitant par des réseaux sécurisés par des certificats émis par d'autres racines. Plus communément les listes de serveurs racine sont mises à jour par les OS ou par les installations de navigateurs et une premire liste de certificats racine figure dans le fichier ISO ou le DVD d'installation de l'OS ou directement dans le BIOS des ordinateurs ou le firmware des mobiles.

[#2]

@KaLisBlack,

Oh tu peux faire "Mouais..." ! Ce cas est du vécu et si tu ne veux pas de solution, surtout ne viens pas en demander !

[#3]

j'ai plutôt la preuve que ton Thunderbird (chez toi) ne t'affiche pas le vrai certificat associé au serveur situé derrière l'adresse IP mais continue de t'afficher le certificat obtenu aurpès d'une autre adresse située dans le domaine prétendu.

soit tu est loin d'être à jour sur ce logiciel, soit c'est ton OS, soit tu as accepté ce certificat invalide

Et tu n'as même pas regardé l'onglet "détail" pour voir s'il y a avait le certificat signé de Digicert dans la chaine parente ! S'il n'y est pas, ce certitificat que tu vois est uniquement "auto-signé", donc pas vérifiable, tu l'as accepté alors même que ton Thunderbord t'affiche un gros point d'exclamation jaune indiquant que tu as passé outre l'avertissement donné maintenant: "vous êtes en train de passer outre la façon dont Thunderbird identifie ce site". Tu as été averti et tu as choisi de passer outre.

Que Thunderbird accepte de faire ça est un gros bug de Thunderbird, cela n'aurait pas du être traité comme un avertissement mais comme une erreur fatale (lis bien les RFC) car ce n'est accepté QUE pour les certificats racine (certificats identifiant une entité, et qui doit être signé par elle-même et pas comme ici "émis par Digicert" alors que ce n'est même pas vérifible et ton thunderbird t'affiche un second message "OU: ne fait pas partie du certificat pour t'avertir encore que ce n'est pas un certificat racine)

Ce que tu affiches est clairement un faux certificat (ou un certificat incomplet NON approuvé par Digicert même s'il semble affirme qu'il a été émis par Digicert) que tu as installé volontairement sur ta machine en passant outre un avertissement.

Tous les logiciels de messagerie normaux ne te laissent pas installer un tel certificat, ils rejettent la connexion.

Je vois bien ce certificat que tu affiches ici (j'ai le même numéro de série: "03:fd:4a:...") mais si on le décode en clair (avec "openssl x509 -text") tu verras que c'est juste un "précertificat" correspondant à une demande à effectuer par Orange à Digicert de produire un certificat signé. On voit juste Digicert comme *destinataire* de ce certificat mais pas du tout comme "émetteur" ni signataire.

C'est toi qui a un problème de sécurité sur ta machine !

[#4]

Bonjour @verdy_p

***********

A quoi ça servirait que dans chaque machine la résolution de nom soit régie par des règles simples si chaque application gérait sa propre résolution de nom.

Celle de la machine passe en premier, c'est elle qui décide si on utilise le fichier host ou une requête DNS.

J'ai vérifié, non, Thunderbird ne refait pas de résolution de nom.

J'ai forcé pop.orange.fr à 127.0.0.1 dans le fichier host de la machine, Thunderbird a immédiatement perdu sa connectivité avec le serveur POP d'Orange.

Pour ce qui est du contrôle du certificat : c'est l'application qui regarde l'URL à la quelle elle cherche à se connecter et la compare  (une comparaison texte sans aucune interprétation) à ce que contient le certificat.

"80.X.y.z" ne sera jamais égal à "pop.orange.fr". C'est la seule manière de vérifier si le site est une usurpation du site pour lequel le c ertificat a été produit. 

C'est ce qui permet à une entreprise de déplacer son site quand elle veut, notament de démarrer un site de secours en cas de sinistre grave.

Non je n'ai pas installé ce certificat comme une exception.

Non il n'y a pas de négociation SSL tant que mon navigateur ou mon courrielleur ne fait pas confiance au certificat. Mon courrielleur a cherché à se connecté à une adresse 80. ... et elle ne figure pas dans le Certificat.

Donc le site n'étant pas le titulaire du certificat, mon courrielleur me présente une erreur.

Non seulement tu n'as jamais répondu à une seule des questions posées, tu n'as pas apporté le moindre  début de commencement de référence ou de preuve dans tes discours fleuve, mais encore tu les appuies sur des assertions fausses.

***************

********

PhilDur

[Edit : Merci de rester courtois. Equipe modération]

[#5]

@PhilDur  c'est toi qui ne regardes pas ce certificat.

Utilise linux et openssl sur ce certificat affiché, il manque celui de Digicert. Et c'est clair car ce n'est pas du tout un certificat pour serveur c'est une demande de certificat (un "précertificat")

Bref TU ne veux pas l'admettre mais c'est bien toi qui a un problème de sécurité (en plus de celui d'Orange) sur ton installation.

Personne (aucun outil) n'accepte ce certificat pour s'authentifier en SSL... sauf toi sur ta machine.

Je te suggère d'installer un linux propre dans une VM ou booter sur une ISO et essayer de te connecter et vérifier avec openssl. Ou de booter sur un DVD Windows (pas besoin de l'installer complètement) ou d'essayer un client de messagerie POP3 standard sur ton smartphone et tu verras que la connexion est refusée. Si tu as un accès à un shell Linux sur ton smartphone, tu peux aussi lancer la commande openssl qui t'affichera les certificats x509 et les décodera quand il sont en format binaire (DER) ou hexadécimal (PEM) et tu verras par toi-même. Ce certificat n'a jamais été signé et approuvé par Digicert.

Bref Google a raison de rejeter la connexion pour la consultation des mails Orange par Gmail), de même que le client Windows 10 Mail, ou mon installation propre (pas comme la tienne) de Thunderbird, de même que mon smartphone avec Android Mail intégré, de même que Office Outlook 2010 ou 2013 ou Office Live, de même que tous les autres fournisseurs de webmails que j'ai pu tester. Absolument tous rapportent l'erreur SSL standard 48 (unknown CA) à cause de ce certificat incorrect.

Tu ne comprend pas ce qui se passe et tu l'as même admis. Je ne suis pas chevalier blanc mais lào tu veux agir en redressseur de tord alors que tu ne comprends rien.

D'ailleurs demande toi pourquoi le certificat présenté sur ton Thunderbord à l'adresse .17 ou .209 n'est PAS le même que celui aux autres adresses (les numéros de série sont différents déjà, et leur contenu est très différent, les 8 autres IP ont un certificat correct réellement émis, approuvé et signé par Digicert, il y a une chaine de 3 approbations: Orange, une approbation par le CA intermédiaire de Digicert, qui lui-même mentionne le Root CA de Digicert et qui est le seul à n'avoir pas besoin de certificat supplémentaire puique ce Root CA est installé avec un certificat racine dans le magasin des OS; sur les seruveurs .8 et .9 il n'y a aucune chaine, seul Orange semble être indiqué comme créateur, il suggère que cela vient de Digicert mais ce n'est pas vérifiable car il manque cette deuxième signature qui réellement authentifierait Orange).

[#6]

tu dis "J'ai forcé pop.orange.fr à 127.0.0.1 dans le fichier host de la machine, Thunderbird a immédiatement perdu sa connectivité avec le serveur POP d'Orange."

c'est normal et je n'ai pas affirmé le contraire.

Et si tu remets l'adresse IP 80.12.24.17 ça marche à nouveau simplement parce que ce serveur te présente à nouveau le même certificat invalide que tu as ajouté avec une exception dans ton magasin local pour qu'il soit accepté par Thunderbird: cette exception n'est PAS supprimée elle est toujours là, stockée dans TON magasin local de certificats où TU l'as volontairement installée (ce qu'il ne faut absolument JAMAIS faire si tu n'es pas toi-même le créateur de ce certificat, destiné à un site ou un service web dont TU es propriétaire et tu assumes tous les risques, ou sur lequel tu es habilité à le faire avec un mandat du propriétaire qui peut te demander des comptes même si tu te trompes).

Un certificat c'est l'équivalent d'une pièce d'identité pour un individu et en France cela a maintenant la même force légale. Passer outre ou faire usage d'une pièce d'identité falsifiée ou l'usiliser comme si c'était une pièce d'identité officielle c'est pénalement (et lourdement) répréhensible. Et en pratique la quasi totalité des gens ne touche jamais à ce paramétrage, de peur de se tromper, car c'est effectivement assez compliqué à vérifier et très technique.

Ce que tu as fait c'est exactement comme si: quelqu'un s'est présenté chez toi se prétendant être un agent de police pour entrer, il te montre sa pièce d'identité avec son nom et sa photo, mais il n'y a pas le logo ou le cachet "république française" dessus. Qu'importe, tu crées une exception et tu ajoute manuellement le logo manquant. Et tu le laisse entrer librement chez toi avec sa pièce d'identité fausse et tu lui fais totalement confiance et de façon permanente (tu lui as même installé une porte d'accès en mettant une serrure sur une porte qui fonctionne avec sa clé pour qu'il puisse entrer chez toi quand il veut)...

Je ne suis pas Orange, tu n'es pas Orange, ni moi ni toi ne devons utiliser cette exception que tu as ajoutée avec ton Thunderbird malgré les avertissements affichés !

[#7]

---

@verdy_p a écrit :

tu dis "J'ai forcé pop.orange.fr à 127.0.0.1 dans le fichier host de la machine, Thunderbird a immédiatement perdu sa connectivité avec le serveur POP d'Orange."

c'est normal et je n'ai pas affirmé le contraire.

---

Si ! tu as dit que TB avait son propre DNS. TB aurait du utiliser son DNS et se connecter quand même.

Mais t as déj oublié l'avoir dit.

---

Et si tu remets l'adresse IP 80.12.24.17 ça marche à nouveau simplement parce que ce serveur te présente à nouveau le même certificat invalide que tu as ajouté avec une exception dans ton magasin local pour qu'il soit accepté par Thunderbird:

---

J'avais supprimé l'exception !

Tu racontes n'importes quoi !

PhilDur

[#8]

@PhilDur

Non je n'ai absolument pas dit ça !

J'ai dit que TB avait son propre **cache** DNS interne comme aussi les navigateurs web qui ne font pas des requêtes DNS sans arrêt au serveur DNS qui y a été paramétré).

Tu inventes ou tu lis ce qui t'arrange en sautant volontairemetn des mots.

J'ai dis aussi que pour éviter ça (purger ce cache) il fallait nécessairement fermer totalement l'application et la relancer (certaines applis ont leur cache résident et ça ne suffit pas, il faut utiliser une commande de purge, et notamment nombre de navigateurs web dans les paramètres de "confidentialité", là où on peut aussi effacer les cookies et autres données résidentes ou le cache des pages web, et dans ce cas tu n'es pas obligé de quitter l'application, l'action de purge est instantanée dans le navigateur... sauf le cache des sessions HTTP temporaires en cours qui lui est purgé seulement quand tu fermes un onglet ou quand tu forces un rafraichissement complet de page, lequel peut cependant réutiliser les sessions résidentes et cookies à moins qu'ils aient été purgés comme précédemment). Tu ne lis même pas les avertissements pourtant clairs donnés par ta machine.

**TU** racontes n'importe quoi. Et tu as démontré que même tu mentais: tu n'as certainement jamais travaillé sur la PKI d'une banque, et même avoué que tu ne comprenais pas vraiment comment ça marche. Tu n'as jamais lu la moindre RFC tu restes cantonné à ce qui marhe chez toi et sur ton bidouillage local sur TA machine (avec la preuve en image que tu as postée ici!).

Tu as montré que tu n'avais aucune idée de ce qu'était le CERT (pourtant c'est une obligation professionelle pour travailler dans une banque sur sa PKI: des preuves de formation sont exigées et il y a même un test obligatoire de connaissance à passer chez ton employeur ou même chez son client la banque avant qu'elle t'habilite, et même une banque avant ça va organiser une session de formation ou de rappel des procédures, et ce devrait être le cas aussi chez Orange, avec des formations régulières obligatoires, car les règles évoluent et doivent prendre en compte de nouveaux risques qui se multiplient, et se former à de nouveaux outils, y compris des outils "maison" imposés pour faire un suivi de qualité avant, pendant et même après les déploiements; toutes les habilitations de personnels sont temporaires, jamais plus de 3 ans, et doivent être renouvellés dans un calendrier strict bien défini et normalement pas question d'y dériger : la date passée tu dois passer les nouvelles formations exigées, et passer les tests de certification à nouveau et ton badge d'accès pour entrer travailler dans la partie sensible des systèmes n'est plus valable; idem si tu changes d'employeur, l'habilitation chez l'ancien employeur n'est plus valable et c'est au nouvel employeur de te faire passer la formation et l'examen habilitation à ses frais).

Je pense même qu'Orange et toute banque sérieuse exige encore en plus l'habilitation défense (payée par ton employeur, cela inclut une enquête judiciaire l'accès par une autorité publique à ton casier judiciaire qui va donner son agrément ou pas) qui elle aussi n'est pas valable si tu changes d'employeur (l'entreprise elle-même doit d'abord passer sa propre habilitation et faire certifier ses méthodes, ses plans de formation et ça coûte cher, avant même de pouvoir proposer à ses clients ses employés qu'elle a préparés !) et avant de t'envoyer en mission tu signes un contrat supplémentaire entre toi, ton employeur et son client, un contrat qui peut être dénoncé à tout moment par une des trois parties (sans avoir à le justifier, cela ne rompt pas ton contrat de travail avec l'entreprise), mais sans supprimer les obligations de secret (ce contrat est très fort et t'engage judiciairement, ce n'est pas n'importe quoi et si tu violes les termes que tu as signé les sanctions peuvent être très lourdes, en plus du fait que tu risque fort la rupture de ton contrat de travail pour faute lourde ou une mise à pied, là tu pourras toujours te plaindre aux prud'hommes mais ils donneront raison à l'employeur s'il y a eu une sanction pénale qui a couté cher à l'entreprise qui peut en retour t'attaquer au civil en te demandant des réparations sous forme de dommages financiers).

[#9]

@verdy_p,

Les attaques personnelles n'étant pas autorisées et totalement contraires aux règles d'usage de ce forum d'entraide, j'ai signalé tes derniers posts à rallonge à la modération. Merci de bien vouloir cesser immédiatement de polluer avec des posts au kilomètre auxquels personne ne comprend rien ce fil de discussion qui n'est pas le tien.

Si tu veux faire changer Orange, ce n'est pas ici qu'il faut le faire en insultant des usagers, mais en déposant une réclamation à Orange.

[#10]

@papou22 en l'occurance ce n'est pas moi mais bien celui à qui je répondais qui a été modéré pour ses insultes.

Ses mensonges sont prouvés, il nie même les images qu'il a lui-même postées, ses contradictions il cherche à les éviter et insiste pour dire que je n'ai pas répondu du tout à ses questions (alors non je lui ait montré et à chaque fois il a changé d'argument en ajoutant une contradiction, ou en tronquant volontairement ce que j'ai dit)

Les réclamations à Orange je les ai faites. Mais Orange n'a rien fait remonter.

Maintenant la réclamation est au CERT (partie française officielle du gouvernement d'une organisation mondaile de la sécurité), elle est suivie aussi par OVH, Free, Bouygues Telecom.

Le CERT m'a même dit merci. Il y a bien un problème de sécurité chez Orange, et qu'Orange veut cacher. Mais les problèmes d'accès à la messagerie sont démontrés.

Maintenant si tu crois que le CERT n'est fait que d'ignorants, alors que c'est leur rôle de gérer ça de façon independante.