Frage:
Kann ein Nameserver-Anbieter MX-Einträge entführen?
Ravexina
2020-05-12 13:09:49 UTC
view on stackexchange narkive permalink

Sagen wir:

  1. Wir kaufen eine Domain von http: //cheap-unsecure-domains.example.
  2. Dann in unserem Systemsteuerung unter cp.cheap-unsecure-domain.example konfigurieren wir es für die Verwendung des Cloudflare -Dienstes.
  3. Wir haben einen MX-Datensatz bei Cloudflare und eingestellt Zeigen Sie sie beispielsweise auf Google.
    4. ol>
  • Theoretisch sollte es billig-unsicheren Domains möglich sein, unsere zu entführen MX-Datensätze beantworten sie selbst, anstatt sich auf Cloudflare zu beziehen. Ist das richtig?
  • Wenn ja, gibt es irgendeine Art von Schutz gegen diese Art von Angriffen? Außer mit etwas wie GPG.

Ich denke über mögliche Angriffe auf der Empfangsseite nach.

Was Sie beschreiben, ist genau das, was Regierungen / Gerichte verwenden, um eine Domain-Abschaltung zu erzwingen - im Grunde genommen wird Ihre gesamte Domain legal entführt.Dies ist tatsächlich mehrmals bei Botnetzen, pädophilen Websites, Torrent-Websites usw. passiert. Der Hauptgrund, warum Dienste dies nicht ohne Gerichtsbeschluss tun, ist, dass dies sie schnell unbeliebt macht und sie ihr Geschäft verlieren oder selbst verklagt werden.Abgesehen davon gibt es im Grunde keinen anderen Schutz - alles basiert auf Vertrauen
@slebetman das ist ein ausgezeichneter Punkt.Aus diesem Grund verabscheuen autoritäre Regierungen dezentrale Netzwerke wie TOR (das Zwiebelnetzwerk), die Registrare, Zertifizierungsstellen und DNS überflüssig machen - indem sie Adressen verwenden, die von öffentlichen Schlüsseln abgeleitet sind.Der einzige Nachteil ist, dass die Adressen möglicherweise etwas benutzerunfreundlich sind (z. B. https://www.nytimes3xbfgragh.onion/).
"Billig-unsichere-Domains" stehen in Bezug auf die Domain-Verwaltung hierarchisch über Ihnen. Technisch gesehen müssen sie also nichts, was sie bereits kontrollieren, _hijack_.
Sie können Ihre Domain auf Cloudflare übertragen, damit Sie weniger Unternehmen haben, denen Sie vertrauen müssen. Dies ist wahrscheinlich auch billiger
@lights0123 - "weniger Unternehmen, denen Sie vertrauen müssen" **, die wiederholt werden müssen **.Wenn Sie eine ".us" -Domain von einem in Großbritannien ansässigen Registrar-Unternehmen kaufen und Ihre Web + E-Mail in Frankreich hosten, könnte zu diesem Zeitpunkt jede dieser drei Regierungen Ihre E-Mail entführen (mit der einzigen Einschränkung, dass die französische Regierung dies nicht könntedauerhaft / auf unbestimmte Zeit kommandieren).
@lights0123 CloudFlare ist derzeit weder in allen TLDs ein Registrar, noch weit davon entfernt, noch für Kunden außerhalb ihres Ökosystems offen.
@PatrickMevzek stimmt, aber der Fragesteller sagt, dass sie Cloudflare bereits verwenden, sodass sie bereits Teil ihres Ökosystems sind.
Ein Beispiel aus dem wirklichen Leben: Meine xyz-Domain ist anfällig für eine dauerhafte Beschlagnahme durch die britische Regierung, da diese TLD von [CentralNic] (http://archive.is/D2Itu) betrieben wird.Es ist ** auch ** anfällig für dauerhaftes Siezure durch die US-Regierung, da ich es lediglich von [Namecheap] (http://archive.is/epn38) registriert habe.Wenn ich tatsächlich etwas Bemerkenswertes tun würde / politischen Aktivismus / gegen soziale Normen verstoßen usw., würde ich es in einem neutralen Land wie "se" mit einem engagierteren Registrar (idealerweise einem im selben Land) hosten.
@JamesTheAwesomeDude Auch ohne die Abhängigkeit durch Namecheap wäre es weiterhin anfällig für US-Gesetze, da die Registrierung unter Vertrag mit ICANN steht, einer US-amerikanischen Einheit.Das macht alle gTLDs in gewisser Weise von US-Gesetzen abhängig.Für ccTLDs ist es weniger klar, aber beachten Sie die historische Klage für einige, ccTLDs als Teil der Vergeltung zurückzufordern: https://arstechnica.com/tech-policy/2014/11/judge-sides-with-icann-plaintiffs-cant-take-all-of-irans-Domain-Namen / Hinweis: Es ist eine Entscheidung eines US-Bundesrichters ...
Was Sie beschrieben haben, ist selbst für große Spieler bereits in großem Maßstab passiert, siehe: https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-eine beispiellose Skala / Sie sollten sich am Ende besonders die Liste der 7 möglichen Abschwächungen ansehen.DNSSEC ist einer von ihnen für einen Teil des Problems, aber nur einer von sieben und nur für einen Teil der Probleme.Sehen Sie auch, wie selbst Unternehmen, die tief im Feld sind und daher über Kenntnisse verfügen, drei Überwachungssysteme verwendeten und keines von ihnen half ...
Sechs antworten:
mti2935
2020-05-12 17:20:40 UTC
view on stackexchange narkive permalink

Ja, Ihr Registrar kann nicht nur Ihre MX -Datensätze, sondern Ihren gesamten DNS entführen.

Darüber hinaus können sie E-Mails abfangen, die an Ihre Domain gesendet wurden, ein gültiges, von der Zertifizierungsstelle signiertes SSL-Zertifikat für Ihre Domain erhalten und mithilfe des vertrauenswürdigen SSL-Zertifikats eine Site für Ihre Domain hosten. Und DNSSEC wird dies nicht verhindern.

Eine der Hauptfunktionen Ihres Registrars besteht darin, die Nameserver für Ihre Domain zu registrieren. Wenn Sie beispielsweise eine whois-Suche nach stackexchange.com durchführen, sehen Sie, dass der Registrar für stackexchange.com eNom, LLC. Ist und dass die Nameserver für stackexchange.com wird von Google Cloud und Amazon AWS gehostet. Das DNS für stackexchange.com wird also von Google Cloud und Amazon AWS verwaltet.

In dem Beispiel, das Sie in Ihrer Frage angegeben haben, ist billig-unsicher-Domains der Registrar für yourdomain.example . Bei billigen, unsicheren Domains haben Sie die Nameserver von Cloudflare als Nameserver für yourdomain.example angegeben. Daher wird DNS für yourdomain.example von den Nameservern von Cloudflare verwaltet. Anschließend richten Sie in der Systemsteuerung von Cloudflare Ihre DNS-Einträge für yourdomain.example ein, einschließlich Ihrer A -Datensätze, MX -Datensätze usw.

Wenn also billige, unsichere Domains Ihre E-Mails abfangen möchten, müssen sie sich nicht in Ihr Konto bei Cloudflare hacken, um Ihre DNS-Einträge zu ändern. Sie würden einfach die Nameserver für yourdomain.example in ihre eigenen ändern und dann MX-Einträge für yourdomain.example in ihren Nameservern erstellen, um auf ihre eigenen Mailserver zu verweisen. Dann würden sie E-Mails empfangen, die an Ihre Domain gesendet wurden.

Interessanterweise könnten sie mit SMTP STARTTLS sicher E-Mails für yourdomain.example empfangen, ohne auch nur ein SSL-Zertifikat für yourdomain.example zu erhalten. Sie könnten einfach ihr eigenes Zertifikat verwenden. Siehe https://blog.filippo.io/the-sad-state-of-smtp-encryption/.

Jetzt wird es heimtückischer. Sie können E-Mails für hostmaster@yourdomain.example (oder admin@yourdomain.example oder eine der anderen genehmigten E-Mail-Adressen erhalten, die für die SSL-Domain-Validierung verwendet werden). Anschließend können sie von einer vertrauenswürdigen Zertifizierungsstelle ein SSL-Zertifikat für yourdomain.example anfordern. Wenn die Zertifizierungsstelle den Bestätigungslink an hostmaster@yourdomain.example sendet, erhalten sie dieses es, und die CA wird das Zertifikat ausstellen. Jetzt können sie einen A -Datensatz für www.yourdomain.example einrichten und eine Site mit einem gültigen Zertifikat für www.yourdomain.example ausführen

An diesem Punkt wundern Sie sich vielleicht - kann diese Art von Angriff nicht mit DNSSEC verhindert werden? Die Antwort ist nein. DNSSEC-Einträge werden im DNS für die Domäne gespeichert. Wenn der Registrar die Nameserver für yourdomain.example in ihre eigenen ändert, werden die DNSSEC-Einträge, die Sie für yourdomain.example erstellt haben, sowie alle anderen DNS-Einträge gelöscht du hast geschaffen. Weitere Informationen finden Sie unter https://moxie.org/blog/ssl-and-the-future-of-authenticity/.

und es gibt nichts, was sie aufhalten könnte ... außer dass dies auffällt und sie den Ruf als Registrar für jede TLD verlieren, über die wir sprechen, und daher möglicherweise ihre Registrar-Berechtigungen vom TLD-Besitzer widerrufen werden - wenn sie sich die Mühe machen
@HagenvonEitzen fällt nur auf, wenn es maßstabsgetreu hergestellt wird oder wenn man Glück hat.
@fraxinus Oder einer ist ein kompetenter und möglicherweise leicht paranoider Administrator, der alles überwacht.Wenn dies einer meiner Domains passiert wäre, würde mein Telefon innerhalb von fünf Minuten explodieren.
Ja.Kompetent UND glücklich.Bei dieser Komplexität des möglichen Angriffs kostet es nichts, die richtigen DNS-Antworten für den Überwachungshost zu fälschen.
@fraxinus, solange sie wissen, was ein Überwachungshost sein könnte.Wenn die Überwachung auf einem Server ausgeführt wird, der einen Datensatz in der Domäne hat, wird dies getan.Aber es kann von einem unbenannten Knoten in einer zufälligen Cloud ausgeführt werden, und dann weiß der betrügerische Registrar nicht, ob er es fälschen soll oder nicht.Oder es kann tatsächlich eine rekursive Abfrage auf einem Caching-Nameserver anfordern, unabhängig davon, ob es sich um CFs (1.1.1.1), Googles (8.8.8.8) oder Internetanbieter handelt.Dann kennt der betrügerische Registrar nur die Region, aber nicht die spezifische Quelle der Abfrage.
Auf diese Weise verstößt der Registrar natürlich gegen den Vertrag und begeht schwere Straftaten.Und da es sich nicht um einen schwer zu verfolgenden Cracker handelt, sondern um ein identifiziertes Unternehmen, sollten Polizei und Gerichte in der Lage sein, ihn von dort aus zu übernehmen.Vermeiden Sie daher Registrare in Ländern, in denen Sie dem Justizsystem nicht vertrauen oder nicht sicher sind, ob Sie eine gute rechtliche Unterstützung erhalten könnten.
Als ehemaliger SRE für Stack Exchange bin ich besorgt über die NS-Datensätze, die Sie sehen ... Sie sollten Google Cloud und Route 53 als Nameserver sehen ...
@MarkHenderson Danke.Ich habe die Domain fett gefingert, als ich das Whois gemacht habe.Ich habe meine Antwort bearbeitet, um sie zu korrigieren.
Wäre es klarstellbar, dass ein ** Registrar eine Domain dauerhaft entführen kann **, ein `Name Server Provider` (wie in der Frage formuliert) ** nicht ** kann?Wenn ich beispielsweise meine Domain bei Gandi in Singapur registriere, aber meine NS-Einträge zur schnelleren Aktualisierung auf Afraid.orgs FreeDNS verweise, öffnet mich dies ** nicht ** für _permanent_ siezure von FreeDNS-and-or-USG_temporary_ Hijacking (vorausgesetzt, ich mache alles andere richtig.)
"DNSSEC-Einträge werden im DNS für die Domäne gespeichert."Nur teilweise wahr.DS-Datensätze befinden sich im übergeordneten Element und nicht im untergeordneten Element.Wenn Sie den Registrar kontrollieren, können Sie ihn natürlich dazu bringen, alle DS-Einträge an die Registrierung zu senden oder sie zu entfernen.
Es ist nicht erforderlich, E-Mails zu steuern, um Zertifikate auszustellen, wenn Sie das DNS bereits steuern: Für die Validierung von DV-Zertifikaten sind die Methoden http-01 oder dns-01 ausreichend und einfach, wenn Sie das DNS steuern
@JanHudec zumindest in der gTLD-Welt sind Registrare von ICANN akkreditiert.Wenn ICANN beteiligt wird, bedeutet dies wahrscheinlich, dass die Akkreditierungen schnell verloren gehen und Domain-Namen nicht mehr verwaltet werden können.Natürlich wäre der Schaden bereits angerichtet worden und dies würde nur weitere Schäden verhindern (aber dieselben Banditen könnten dann eine andere Einheit schaffen und das Gleiche erneut tun usw.).
"Wenn der Registrar die Nameserver für yourdomain.example in ihre eigenen ändert, sind die DNSSEC-Einträge, die Sie für yourdomain.example erstellt haben, nicht mehr vorhanden." Nicht genau richtig.Ein Registrar kann sowohl Nameserver als auch DS-Einträge in der Registrierung ändern.Dies können separate Vorgänge sein oder nur einer, der beides ausführt.Das Ändern der Nameserver ändert jedoch nicht automatisch die DS-Datensätze, sondern erfordert eine bestimmte Aktion des Registrars.Der verlinkte Artikel über "Trust Agility" ist ein Problem, das lange "gelöst" wurde (siehe PGP Web of Trust).Welches mit seinen eigenen Nachteilen / Grenzen kommt.
Pedro
2020-05-12 13:44:59 UTC
view on stackexchange narkive permalink

Theoretisch sollte es billigen, unsicheren Domains möglich sein, unsere MX-Datensätze zu entführen, indem sie sie selbst beantworten, anstatt sich auf Cloudflare zu beziehen. Ist das richtig?

Ja, es wäre ihnen möglich, dies zu tun. Obwohl sie nicht können, ohne dass Sie es merken. Sie können dies also überwachen.

Wenn ja, gibt es einen Schutz gegen diese Art von Angriffen? Außer so etwas wie GPG.

Verwenden Sie einen seriösen Domain-Registrar, nicht unbedingt einen billigen. Überwachen Sie Ihren DNS.

Es ist erwähnenswert, dass Registrare die Möglichkeit haben, eine auf IP-Regionen basierende DNS-Auflösung zu implementieren, damit sie Ihnen korrekt erscheinen und gleichzeitig E-Mails von Anbietern abfangen können, die in einem anderen Land ansässig sind.Jemand wird es beobachten können, ja, aber ein kluger Entführer könnte eine offensichtliche Überwachung durch die Person vermeiden, die die Domain gekauft hat.
Interessant.Und guter Anruf.
@daboross Wenn die NS-Einträge in der TLD für den Zonendelegierungspunkt zu Cloudflair der Registrar nicht mit ihren eigenen Anycast-Servern in Konflikt geraten kann, müssten sie diese Registrierung ändern, die von einer anderen Netzwerkkarte oder einem anderen Root-Nameserver gehostet wird, und können daher erkannt werden.
Oh, das ist wahr!Sie würden das tld nicht besitzen.
@eckes aber würden sie?Die tld NS-Datensätze (cheap-unsecure-domain.example) würden von Root-Nameservern gehalten und bereitgestellt, obwohl auf die genannte Subdomain von Nameservern verwiesen würde, die vom Domaininhaber kontrolliert werden, nicht von den Root-Nameservern.Ich bin sicher, dass ein paar überkomplizierte Dig-Befehle dies löschen könnten.
@ Pedro @daboross Sie scheinen beide zu vergessen, dass Registrar und DNS-Anbieter zwei verschiedene Jobs mit zwei verschiedenen Zwecken sind.Beide Funktionen können von derselben Entität ausgeführt werden. Die Tatsache, dass Sie eine Domain über Registrar X registrieren, bedeutet jedoch nicht unbedingt, dass X Ihr DNS-Anbieter ist.Der Registrar kann alle NS- und DS-Einträge im übergeordneten Element (Registrierung) technisch ändern.Der DNS-Anbieter kann jeden Eintrag in der gehosteten Zone technisch ändern.In beiden Fällen ist eine "stille" Änderung der wahren Werte möglich.
@Patrick Mevzek Ich denke, @ Pedro meinte, dass in diesem Fall (wo der DNS-Anbieter seriös ist, der Registrar jedoch nicht) NS-Änderungen in der TLD-Autorität vorgenommen werden müssen - und dass die TLD-Autorität jederzeit öffentlich beobachtbar ist und nichtgeografisch basiert.Sie können also immer feststellen, ob sich etwas geändert hat, indem Sie die Aufzeichnungen der TLD überprüfen.
"und diese TLD-Behörde ist jederzeit öffentlich beobachtbar und nicht geografisch begründet."Ich weiß nicht, was das heißt.ccTLD sind per Definition geografisch basiert.
Ich meine, wenn Sie eine Domain von einem TLD-Server anfordern, erhalten Sie denselben Datensatz, unabhängig davon, von wo auf der Welt Sie ihn anfordern.Einige Nameserver implementieren die Rückgabe unterschiedlicher lokaler IP-Adressen, je nachdem, wer die Daten anfordert.Meines Wissens tun dies keine TLD-Server, wenn sie NS-Datensätze zurückgeben.
mallocation
2020-05-12 13:38:17 UTC
view on stackexchange narkive permalink

"Theoretisch sollte es billig-unsicheren Domains möglich sein, unsere MX -Datensätze zu entführen. Ist das richtig?"

Dies ist richtig für ein Domain-Registrar-Unternehmen, das nicht seriös ist und dessen Sicherheit als mangelhaft angesehen werden kann! Gute Unternehmen bieten Sicherheitsdienste und -suiten für ihre Kunden an, dies ist jedoch häufig mit Kosten verbunden. Daher gibt es Benutzer, die häufig andere Alternativen wie diese billigen, unsicheren Domains Unternehmen verwenden '.

Die gängigsten Methoden, um solche Angriffe zu vereiteln (Entführung / Social Engineering / Identitätsdiebstahl), sind:

  • Die übliche gute alte Cyber-Hygiene (sichere Kennwörter, Zwei-Faktor-Authentifizierung (2FA) in Ihrem 'Domain Control Panel' und Ihrem E-Mail-Konto Ihres Domaininhabers)
  • Vermeiden Nicht seriöse Domain-Hosts-Anbieter (ein guter Prozentsatz der Entführung beruht auf der Ausnutzung einer Sicherheitsanfälligkeit im System des Domainnamen-Registrars)
  • Halten Sie Ihre Domain-Details und Kontaktinformationen auf dem neuesten Stand und Legen Sie Benachrichtigungen fest, wenn Änderungen vorgenommen werden (eher eine Wiederherstellungspraxis ).

Sie haben die Verwendung von Cloudflare als Kontrollfeld erwähnt. Sie bieten eine Reihe von Sicherheitsdiensten zu Ihrer Verfügung. Ihr DNSSEC ist möglicherweise für Sie geeignet.

Inwiefern helfen der erste und der dritte Punkt, einen solchen Angriff zu vereiteln?Denken Sie daran, dass es sich um einen Registrar handelt, der die Domain entführt, und nicht um einen Dritten.Mir scheint, dass hier nur der erste Punkt hilfreich ist.
(* zweiter Punkt ist hier hilfreich)
"Dies ist richtig für ein Domain-Registrar-Unternehmen, das nicht seriös ist und dessen Sicherheit als mangelhaft angesehen werden kann!"Absolut jeder kann scheitern, zum Social Engineering zu beten, kein Unternehmen ist davon abgeschirmt.In der Vergangenheit gab es zahlreiche Beispiele bei verschiedenen Registraren, bei denen jemand, der behauptete, Eigentümer der Domain zu sein, durch einen Anruf beim Kundendienst einige Änderungen vornehmen konnte, beginnend mit einer E-Mail-Änderung, die dann zum Zurücksetzen des Kennworts führteund dann die volle Kontrolle.Nur ein Registrar oder eine Registrierungssperre kann dies verhindern.
Martijn Heemels
2020-05-13 21:21:36 UTC
view on stackexchange narkive permalink

Sie müssten die Upstream-Nameserver für die Domain wieder auf ihre eigenen DNS-Server ändern, auf denen sie eine Kopie Ihrer DNS-Einträge hosten könnten, wobei nur der MX-Eintrag geändert wird. Solange die Upstream-NS-Einträge auf Cloudflare verweisen, können sie nicht nur den MX-Eintrag überschreiben.

Sie können also überwachen, ob die NS-Einträge Ihrer Domain in der Upstream-Registrierung weiterhin auf Cloudflare verweisen, und benachrichtigen, wenn Sie sind verändert.

Patrick Mevzek
2020-05-15 00:00:28 UTC
view on stackexchange narkive permalink

Es gibt eine Minderung dieses Problems: Registrierungssperre für Ihre Domains.

Wenn Sie diesen Dienst abonnieren, werden Änderungen, die vom Registrar an die Registrierung gesendet wurden, NICHT angewendet Bis die Registrierung separat überprüft, ob diese Änderungen tatsächlich erforderlich waren (durch Kontaktaufnahme mit relevanten Personen). Dies macht jede Änderung umständlich (und ist ein Problem für DNSSEC, wenn Sie Ihre Schlüssel beim übergeordneten Element über den DS drehen müssen Datensätze), schützt Sie jedoch vor einem böswilligen oder angegriffenen Registrar.

Nun einige Einschränkungen:

  • Der Name ist nicht einmal überall "Registrierungssperre"
  • existiert nicht bei allen Registern (TLDs)
  • ist völlig unüblich, daher bietet jede Registrierung einen etwas anderen Dienst. Sie müssen klar sehen, was geschützt (gesperrt) ist. Eine Änderung der Kontakte oder eine Änderung der Domäne der E-Mail-Adressen, die von Kontakten oder der zum Benennen des Nameservers verwendeten Domäne verwendet werden, kann sich auch auf Ihre Domäne auswirken.
  • kann kostspielig sein
  • Anfänglich in der Regel über Ihren aktuellen Registrar gekauft (möglicherweise erlauben einige Registries, es direkt bei ihnen zu bestellen, aber es ist wahrscheinlich weniger verbreitet), und wahrscheinlich bieten nicht viele von ihnen diesen Service an.

Einige Beispiele in einigen Registern:

Es ist nicht bekannt viel (aus verschiedenen Gründen), ist aber eindeutig Teil der Lösung für diese Probleme. Es ist unter den 7 Minderungspunkten unter https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-an-unprecedented-scale aufgeführt / Auf dieser Seite wird ein kürzlich aufgetretener Angriff angezeigt (der durch verschiedene Angriffe auf Registrar-, DNS- und E-Mail-Ebene auf nicht weniger als einen DNS-Anbieter von Root-Nameservern abzielt), der der von Ihnen beschriebenen Bedrohung sehr ähnlich ist.

Mit einer ordnungsgemäßen Registrierungssperre würde jede Änderung Ihrer Namensauflösung nach dem Festlegen Ihrer DS -Datensätze einen Fehler auslösen (und einen Angriff vereiteln) ... solange Benutzer die Validierung rekursiv verwenden Nameserver natürlich.

mkeith
2020-05-15 03:37:00 UTC
view on stackexchange narkive permalink

DNS kann geändert werden, aber höchstwahrscheinlich würden Sie feststellen, dass etwas nicht stimmt. Wenn zum Beispiel jemand veranlasst hat, dass mail.example.com in eine andere IP-Adresse aufgelöst wird, die nicht von mir kontrolliert wird, ohne jemals die ursprüngliche mail.example.com zu gefährden, werde ich aufgefordert, einen neuen Schlüssel zu akzeptieren, wenn ich mich über ssh authentifiziere. Es sei denn, sie haben den ursprünglichen Server vollständig kompromittiert und den privaten SSH-Schlüssel gestohlen. In diesem Fall müssen sie mein DNS jedoch nicht angreifen. Sie haben bereits Wurzel. Oder zumindest haben sie bereits meinen ssh-Benutzer, der sudo kann.

Wenn Sie sicherstellen möchten, dass Ihre E-Mail nicht gelesen wird, müssen Sie wahrscheinlich die Verschlüsselung mit öffentlichem Schlüssel (wie PGP und GPG) verwenden und Ihre erhalten Korrespondenten, um alle an Sie gesendeten E-Mails zu verschlüsseln. Selbst wenn "sie", wer auch immer sie sind, E-Mails erhalten, die für Sie bestimmt sind, können "sie" diese nicht lesen, es sei denn, sie haben auch Ihren privaten Schlüssel irgendwie gestohlen.

"Ich kann mich nicht mit der neuen mail.example.com authentifizieren." Warum?Der Server könnte antworten, dass ein Login + Passwort in Ordnung ist, und so Ihre Anmeldeinformationen abrufen.
Ich denke, das gilt für die Übermittlung von E-Mails.Ich müsste schon misstrauisch sein, aber dann testen Sie es, indem Sie absichtlich das falsche Passwort eingeben.Das passt nicht zum Szenario.Aber es würde ein Problem mit SSH geben.Sie hätten nicht den richtigen Schlüssel.Mein Kunde würde mich auffordern, einen neuen Schlüssel zu akzeptieren, und ich würde wissen, dass etwas nicht stimmt.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...