Bonjour,
Je ne trouve pas de réponse à mes problèmes en cherchant sur le net,
donc j'aimerais savoir que faire dans le cas suivant.
Chaque fois que j'éteins ou que je remémarre mon Mac, iCloud me demande
mon mot de passe Apple et celui de mon Mac, je m'exécute et il
recommence à me demaqnder mes mots de passe. J'ai essayé de fermer la
cession d'iCloud, de la réouvrir et j'ai, dans la foulée, redémarré mon
Mac. Et toujours cette demande de mot de passe.
Si je ne m'exécute pas, le Trousseau n'est pas coché.
Deux solutions, soit je fais avec, soit j'abandonne iCloud.
--
René
Lascia la spina cogli la rosa
chambara1@free.fr
Puisqu'on en est là on va mettre de l'encryptage des données dès le départ (https, ftps...), mais, même si on n'a pas le contenu, on sait qui discute avec qui. C'est la course entre ceux qui veulent protéger les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA accepte la sécurisation des transmissions via TLS. Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA ne veulent pas chiffrer les transmissions pour différentes raisons (veilles versions de smtpd, fainéantise/incompétences des postmasters, voir dans le pire des cas les deux), donc nous utilisons ce que nous appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui permettent de proposer lors de l'émission ou la réception le chiffrement de la transmission. Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour des tiers reconnus acceptant le chiffrement et pour ceux inconnus, proposons le chiffrement.
On est d'accord, l'email n'offre en soi aucune garantie de confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des mortels. -- <oliveDKS> ...et en Word, tu excelle? * bashfr.org
On jeu. 12 mars 2020 (15:59),
pehache <pehache.7@gmail.com> wrote:
Puisqu'on en est là on va mettre de l'encryptage des données dès le
départ (https, ftps...), mais, même si on n'a pas le contenu, on sait
qui discute avec qui. C'est la course entre ceux qui veulent protéger
les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la
session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA
accepte la sécurisation des transmissions via TLS.
Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA
ne veulent pas chiffrer les transmissions pour différentes raisons
(veilles versions de smtpd, fainéantise/incompétences des postmasters,
voir dans le pire des cas les deux), donc nous utilisons ce que nous
appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui
permettent de proposer lors de l'émission ou la réception le chiffrement
de la transmission.
Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour
des tiers reconnus acceptant le chiffrement et pour ceux inconnus,
proposons le chiffrement.
On est d'accord, l'email n'offre en soi aucune garantie de
confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des
mortels.
--
<oliveDKS> ...et en Word, tu excelle?
* bashfr.org
Puisqu'on en est là on va mettre de l'encryptage des données dès le départ (https, ftps...), mais, même si on n'a pas le contenu, on sait qui discute avec qui. C'est la course entre ceux qui veulent protéger les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA accepte la sécurisation des transmissions via TLS. Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA ne veulent pas chiffrer les transmissions pour différentes raisons (veilles versions de smtpd, fainéantise/incompétences des postmasters, voir dans le pire des cas les deux), donc nous utilisons ce que nous appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui permettent de proposer lors de l'émission ou la réception le chiffrement de la transmission. Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour des tiers reconnus acceptant le chiffrement et pour ceux inconnus, proposons le chiffrement.
On est d'accord, l'email n'offre en soi aucune garantie de confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des mortels. -- <oliveDKS> ...et en Word, tu excelle? * bashfr.org
benoit
Matt wrote:
On jeu. 12 mars 2020 (15:59), pehache wrote:
Puisqu'on en est là on va mettre de l'encryptage des données dès le départ (https, ftps...), mais, même si on n'a pas le contenu, on sait qui discute avec qui. C'est la course entre ceux qui veulent protéger les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA accepte la sécurisation des transmissions via TLS. Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA ne veulent pas chiffrer les transmissions pour différentes raisons (veilles versions de smtpd, fainéantise/incompétences des postmasters, voir dans le pire des cas les deux), donc nous utilisons ce que nous appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui permettent de proposer lors de l'émission ou la réception le chiffrement de la transmission. Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour des tiers reconnus acceptant le chiffrement et pour ceux inconnus, proposons le chiffrement.
On est d'accord, l'email n'offre en soi aucune garantie de confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des mortels.
Ok pour le contenu, mais pas pour la ou les adresses. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoît chez leraillez.com
Matt <matt@lv426.eu.invalid> wrote:
On jeu. 12 mars 2020 (15:59),
pehache <pehache.7@gmail.com> wrote:
>> Puisqu'on en est là on va mettre de l'encryptage des données dès le
>> départ (https, ftps...), mais, même si on n'a pas le contenu, on sait
>> qui discute avec qui. C'est la course entre ceux qui veulent protéger
>> les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la
session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA
accepte la sécurisation des transmissions via TLS.
Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA
ne veulent pas chiffrer les transmissions pour différentes raisons
(veilles versions de smtpd, fainéantise/incompétences des postmasters,
voir dans le pire des cas les deux), donc nous utilisons ce que nous
appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui
permettent de proposer lors de l'émission ou la réception le chiffrement
de la transmission.
Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour
des tiers reconnus acceptant le chiffrement et pour ceux inconnus,
proposons le chiffrement.
> On est d'accord, l'email n'offre en soi aucune garantie de
> confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des
mortels.
Ok pour le contenu, mais pas pour la ou les adresses.
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoît chez leraillez.com
Puisqu'on en est là on va mettre de l'encryptage des données dès le départ (https, ftps...), mais, même si on n'a pas le contenu, on sait qui discute avec qui. C'est la course entre ceux qui veulent protéger les communications et ceux qui veulent les écouter :)
Sauf dans le cas de SMTP où l'on peut exiger le chiffrement de toute la session. Bien sûr cela peut se faire si l'on est sûr que l'autre MTA accepte la sécurisation des transmissions via TLS. Actuellement ce n'est malheureusement pas généralisable; beaucoup de MTA ne veulent pas chiffrer les transmissions pour différentes raisons (veilles versions de smtpd, fainéantise/incompétences des postmasters, voir dans le pire des cas les deux), donc nous utilisons ce que nous appelons dans le jargon SMTP, les /transmissions TLS opportunistes/, qui permettent de proposer lors de l'émission ou la réception le chiffrement de la transmission. Concrètement, pour les postmasters, nous forçons l'utilisons de TLS pour des tiers reconnus acceptant le chiffrement et pour ceux inconnus, proposons le chiffrement.
On est d'accord, l'email n'offre en soi aucune garantie de confidentialité.
Seul le chiffrement S/MIME ou GPG/PGP le garantisse pour le commun des mortels.
Ok pour le contenu, mais pas pour la ou les adresses. -- Vie : n.f. maladie mortelle sexuellement transmissible Benoît chez leraillez.com
Matt
On jeu. 12 mars 2020 (19:32), Benoît wrote:
[...] mais pas pour la ou les adresses.
Bien sûr que non... Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non), toute la session est chiffrée avant toute commande SMTP (cf. la RFC3207). -- <DerrOuT> NOM D'UN BLOWJOB * bashfr.org
On jeu. 12 mars 2020 (19:32),
Benoît <benoit@com.invalid> wrote:
[...] mais pas pour la ou les adresses.
Bien sûr que non...
Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non),
toute la session est chiffrée avant toute commande SMTP (cf. la
RFC3207).
Bien sûr que non... Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non), toute la session est chiffrée avant toute commande SMTP (cf. la RFC3207). -- <DerrOuT> NOM D'UN BLOWJOB * bashfr.org
benoit
Matt wrote:
On jeu. 12 mars 2020 (19:32), Benoît wrote:
[...] mais pas pour la ou les adresses.
Bien sûr que non... Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non), toute la session est chiffrée avant toute commande SMTP (cf. la RFC3207).
Oui : « si ». D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob, pourquoi je ne peux pas décoder ? -- Vie : n.f. maladie mortelle sexuellement transmissible Benoît chez leraillez.com
Matt <matt@lv426.eu.invalid> wrote:
On jeu. 12 mars 2020 (19:32),
Benoît <benoit@com.invalid> wrote:
> [...] mais pas pour la ou les adresses.
Bien sûr que non...
Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non),
toute la session est chiffrée avant toute commande SMTP (cf. la
RFC3207).
Oui : « si ».
D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob,
pourquoi je ne peux pas décoder ?
--
Vie : n.f. maladie mortelle sexuellement transmissible
Benoît chez leraillez.com
Bien sûr que non... Si les deux MTA s'accordent pour le chiffrement (via STARTTLS ou non), toute la session est chiffrée avant toute commande SMTP (cf. la RFC3207).
Oui : « si ». D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob, pourquoi je ne peux pas décoder ? -- Vie : n.f. maladie mortelle sexuellement transmissible Benoît chez leraillez.com
Matt
On ven. 13 mars 2020 (17:40), Benoît wrote:
Oui : « si ».
Si les conditions sont réunies (accord de chiffrer la transmission entre les MTAs) alors il est faux de dire que la communication entre courriels, n'est pas sécurisée.
D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob, pourquoi je ne peux pas décoder ?
Tu parles de S/MIME et/ou GPG/PGP ? Si c'est le cas, alors les certificats (pour S/MIME) / clefs publiques (pour GPG/PGP) sont probablement échus ou révoqué(e)s par Alice et Bob. Cela m'est arrivé et demander aux intéressés de vérifier si leurs certificats/clefs sont toujours valides. Il n'y a rien que tu ne puisses faire de ton côté malheureusement. Parlant de ça, dans mon secteur d'activité, il y eut une usurpation d'identité en 2017 d'un de nos correspondants et depuis ce jour à chaque fois que je le vois il me remercie encore de lui avoir conseiller d'utiliser GPG, qui si on a la clef publique de l'utilisateur, l'assurance qu'on parle à la bonne personne :) -- Aurélien : Que serait-on sans hypocrisie... Noni : honnêtes ? Aurélien : Ah ouais. * bashfr.org
On ven. 13 mars 2020 (17:40),
Benoît <benoit@com.invalid> wrote:
Oui : « si ».
Si les conditions sont réunies (accord de chiffrer la transmission entre
les MTAs) alors il est faux de dire que la communication entre
courriels, n'est pas sécurisée.
D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob,
pourquoi je ne peux pas décoder ?
Tu parles de S/MIME et/ou GPG/PGP ?
Si c'est le cas, alors les certificats (pour S/MIME) / clefs publiques
(pour GPG/PGP) sont probablement échus ou révoqué(e)s par Alice et Bob.
Cela m'est arrivé et demander aux intéressés de vérifier si leurs
certificats/clefs sont toujours valides. Il n'y a rien que tu ne puisses
faire de ton côté malheureusement.
Parlant de ça, dans mon secteur d'activité, il y eut une usurpation
d'identité en 2017 d'un de nos correspondants et depuis ce jour à chaque
fois que je le vois il me remercie encore de lui avoir conseiller
d'utiliser GPG, qui si on a la clef publique de l'utilisateur,
l'assurance qu'on parle à la bonne personne :)
--
Aurélien : Que serait-on sans hypocrisie...
Noni : honnêtes ?
Aurélien : Ah ouais.
* bashfr.org
Si les conditions sont réunies (accord de chiffrer la transmission entre les MTAs) alors il est faux de dire que la communication entre courriels, n'est pas sécurisée.
D'ailleurs une question : si j'ai les clefs publiques d'Alice et Bob, pourquoi je ne peux pas décoder ?
Tu parles de S/MIME et/ou GPG/PGP ? Si c'est le cas, alors les certificats (pour S/MIME) / clefs publiques (pour GPG/PGP) sont probablement échus ou révoqué(e)s par Alice et Bob. Cela m'est arrivé et demander aux intéressés de vérifier si leurs certificats/clefs sont toujours valides. Il n'y a rien que tu ne puisses faire de ton côté malheureusement. Parlant de ça, dans mon secteur d'activité, il y eut une usurpation d'identité en 2017 d'un de nos correspondants et depuis ce jour à chaque fois que je le vois il me remercie encore de lui avoir conseiller d'utiliser GPG, qui si on a la clef publique de l'utilisateur, l'assurance qu'on parle à la bonne personne :) -- Aurélien : Que serait-on sans hypocrisie... Noni : honnêtes ? Aurélien : Ah ouais. * bashfr.org
