Thunderbird Zertifikate-Überprüfung komplett deaktivieren

[Hot Dog]

Gibt es eine Möglichkeit die Zertifikat-Funktion in Thunderbird komplett zu deaktivieren?
Also so, dass Thunderbird alles was mit Zertifikaten zu tun hat komplett ignoriert? Gerne auch in den erweiterten 'Experten-Einstellungen'. Das gilt auch für Firefox, bei dem halten meine manuellen Ausnahmen allerdings zum Glück etwas länger.

Hintergrund:
Ich nutze Thunderbird ausschließlich für interne Verbindungen zum eigenen Server und dem vertraue ich. Alles danach (also die Auflösung sowie Weiterleitung) regelt dann das DNS.
Trotz dauerhafter Ausnahme beschwert sich Thunderbird beinahe jeden Tag über unsichere Zertifikate.
Ich muss also fast jedes Mal beim Senden einer Mail auf 'Ausnahme bestätigen' und dann erneut auf Senden klicken, damit eine Mail raus geht und das nervt etwas.

Außerdem vermute ich, dass auch das Empfangen von Mails dadurch behindert oder zumindest verzögert wird. Eine Verbindung von Thunderbird (IMAP) zum Mail-Server wird nach dem Start des PCs erst so nach 5-15 Minuten hergestellt. Bis dahin lässt sich der IMAP-Server noch nicht einmal anpingen (obwohl er nachweislich läuft). Aber keine Ahnung ob das tatsächlich am Zertifikat liegt oder etwas anderem (nur eine Vermutung, aber darum geht es mir hier nicht wirklich).

Falls das mit dem Ausschalten der Zertifikate-Überprüfung nicht möglich ist, kann mir jemand einen besseren Mail-Client empfehlen, bei dem sowas möglich ist?

Danke!

Proof:

 

[CoMo]

Setz doch deine eigene CA auf und stelle damit Zertifikate für deine internen Domains aus. Dafür gibt es fertige Lösungen.

https://lab-ca.net/
https://smallstep.com/docs/step-ca/

 

[IchbinbeiCB]

Hallo auch also wenn nicht willst das TB auf Zertifikate prüft warum nimmst dann nicht Einstellungen wo keine Prüfung vornehmen wenn das intern ist wie du sagst. Nutze doch auch beim smtp den unverschlüsselten Port 25 (465 und 587 sind halt die Ports um Verschlüsselung zu nutzen).

Bei imap nutzt doch den unverschlüsselten Port 143 warum also nicht auch beim smtp ?

Ansonsten falls am Server eigene Zertifikate nutzt, zieh die im Zweifel dann halt in den Zertifikatsspeicher vom TB rein.

Gruß
Sascha

 

[Hot Dog]

Setz doch deine eigene CA auf und stelle damit Zertifikate für deine internen Domains aus. Dafür gibt es fertige Lösungen.

Ist zwar möglich aber wozu?
Das muss ich am Ende nur selber managen, warten und erneuern usw. und wozu das Ganze? Damit hab ich keinerlei Vorteile. Komplett deaktivieren wäre da bedeutend einfacher und nutzerfreundlicher, wenn nicht mal die Ausnahme-Regelung greift.

Nutze doch auch beim smtp den unverschlüsselten Port 25 (465 und 587 sind halt die Ports um Verschlüsselung zu nutzen).

Die Ports hat er automatisch ausgewählt, nachdem ich STARTTLS eingestellt habe. Und STARTTLS ist das einzig funktionierende Protokoll für den Mail-Server.
Port 587 ist heutzutage eben der Standard bei SMTP, alles andere is veraltet (Port 25). Also warum nicht nutzen?
Ist zwar äußerst unwahrscheinlich, dass jemand in mein Netz kommt aber falls doch, ist zumindest der Mail-Verkehr verschlüsselt.

Aber abseits davon sollte das doch keinen Unterschied machen. Ob eine Verbindung verschlüsselt ist oder nicht hat doch nichts mit den Zertifikaten zu tun oder etwa doch?

Bei imap nutzt doch den unverschlüsselten Port 143 warum also nicht auch beim smtp ?

Wie gesagt, sind die default-Ports nachdem man STARTTLS einstellt. Sehe keinen Grund davon abzuweichen.

Ansonsten falls am Server eigene Zertifikate nutzt, zieh die im Zweifel dann halt in den Zertifikatsspeicher vom TB rein.

Geht leider auch nicht. Der Server stellt selbst keine Zertifikate aus und eine CA möchte ich da jetzt nicht wirklich einrichten müssen, nur um eine solche bescheuerte Fehlermeldung wegzubekommen.
Und da es sich ja um eine interne, nicht offizielle (.home)-Domain handelt, bekomme ich die auch nicht von einem offiziellen CA verifiziert. Sollte aber auch gar nicht nötig sein, wie gesagt, nur für interne Verwendung gedacht.

 

[IchbinbeiCB]

Ob eine Verbindung verschlüsselt ist oder nicht hat doch nichts mit den Zertifikaten zu tun oder etwa doch?

Zertifikate sind bestandteil von ner verschlüsselten Verbindung. Da du ja hier auf CB unterwegs bist, kannst dir des ja anschauen. Beim Schlossymbol was kurz vorm Anfang der Adressleiste findest, wenn darauf gehst findest die infos von wem des Verifiziert ist und unter weitere Infos kommst zu den Infos über die beteiligten Zertifikate und welches Verschlüssellungsprotokoll etc. genutzt wird und in welcher Stärke.

Das mit der eigenen CA wäre wie man so schön sagt der Königsweg bzgl. eigener Zertifikate.
Geht aber auch ohne:
Jeder kann seine eigenen Zertifikate ohne Hilfe einer CA machen. Der einzige Untersschied ist, dass von Ihnen selbst erstellte Zertifikate von niemanden vertraut werden. Für lokale Entwicklungsumgebungen ist das fein. Sie können Ihren lokalen Webserver mit localhost.

https://letsencrypt.org/de/docs/certificates-for-localhost/

Gruß
Sascha

 

[JumpingCat]

Port 587 ist heutzutage eben der Standard bei SMTP, alles andere is veraltet (Port 25).

Kannst du das konkretisieren? SMTP auf Port 25 ist halt unverschlüsselt und nur aus dem Grund nicht empfehlenswert.

Ob eine Verbindung verschlüsselt ist oder nicht hat doch nichts mit den Zertifikaten zu tun oder etwa doch?

Die Verschlüsselung läuft doch über die Zertifikate. Oder was sonst?

Ist zwar möglich aber wozu?
Das muss ich am Ende nur selber managen, warten und erneuern usw. und wozu das Ganze?

Du kannst die CA und Zertifikate gerne auch 99 Jahre oder länger austellen.

Einfacher wäre es aber einfach entweder Port 25 und 143 zu nutzen oder einfach die Zertifikate dauerhaft in den Client importieren.

Eine Verbindung von Thunderbird (IMAP) zum Mail-Server wird nach dem Start des PCs erst so nach 5-15 Minuten hergestellt

Das klingt so als würde da ein IP-Block wegen fehlerhafter Logins greifen. Sprich mal deinen Admin von dem Synology an, der kann in die Log-Files gucken. Du hast sicherlich für irgendwas veraltete Passwörter gespeichert was sich versucht automatisch anzumelden. Mich wundert es das dem Admin von dem Synology so was nicht auffällt

Thunderbird

Du kannst gerne auf https://www.betterbird.eu/ wechseln, der macht einiges besser als Thunderbird.

 

[Hot Dog]

Zertifikate sind bestandteil von ner verschlüsselten Verbindung.

Verstehe. Das heißt verschlüsselte Verbindungen sind ohne Zertifikat nicht möglich? Finde das zwar etwas merkwürdig aber ok.

Das mit der eigenen CA wäre wie man so schön sagt der Königsweg bzgl. eigener Zertifikate.

Ja schon, aber das bietet sich nur dann an, wenn man tatsächlich mehr mit seiner Domain macht als nur Mail-Verkehr. Also wenn man mehere Clients oder Anwendungen hat, die darauf zugreifen würden, könnte man sich das ja noch überlegen. Aber als single Nutzer für lediglich 1 Anwendung? Halte ich für übertrieben und obsolet.

Jeder kann seine eigenen Zertifikate ohne Hilfe einer CA machen. Der einzige Untersschied ist, dass von Ihnen selbst erstellte Zertifikate von niemanden vertraut werden.

Aber das entspricht doch dann in den Grundzügen einer Ausnahme-Regelung in Thunderbird.
Also wenn Thunderbird schon meinen Ausnahmen nicht traut, warum sollte er dann einem Zertifikat trauen, welches ich selbst signiert habe?
Ich kann mir irgendwie nicht vorstellen, dass es damit dann klappen würde.

Ergänzung (30. Oktober 2024)

Kannst du das konkretisieren? SMTP auf Port 25 ist halt unverschlüsselt und nur aus dem Grund nicht empfehlenswert.

Wer nutzt denn heutzutage noch unverschlüsselte Verbindungen? HTTP wird ja schließlich auch nicht mehr verwendet, selbst intern i.d.R. nicht mehr.
Versteh mich nicht falsch, wenn es mit Port 25 am Ende klappt, soll mir recht sein. Aber finde ich keine besonders schöne Lösung, nur weil Thunderbird das mit den Zertifikaten nicht gebacken bekommt. Werde mir das aber mal überlegen ob ich nicht einfach doch auf komplett unverschlüsselt umsteige, bis TB das irgendwann zuverlässig hinbekommt.

Du kannst die CA und Zertifikate gerne auch 99 Jahre oder länger austellen.

Ja schon. Aber dennoch muss ich die dann nach jedem OS-Wechsel wieder händisch einpflegen und im Falle einer Namensänderung der Domain komplett erneuern. Alles nicht schön und lediglich Zusatzaufwand für keinerlei Mehrwert.

Einfacher wäre es aber einfach entweder Port 25 und 143 zu nutzen oder einfach die Zertifikate dauerhaft in den Client importieren.

Ok, dann werde ich das wohl so machen müssen. Ist zwar doof aber seis drum.

Das klingt so als würde da ein IP-Block wegen fehlerhafter Logins greifen. Sprich mal deinen Admin von dem Synology an, der kann in die Log-Files gucken.

In den Logfiles gibt es 2 Meldungen aber die ergeben irgendwie keinen Sinn:

-> Im DNS ist kein einziger AAAA-Eintrag hinterlegt.

-> Auch hierzu gibt es keinen AAAA-Eintrag. Nutze IPv4 und nicht v6 hier, keine Ahnung wie er zu dieser Meldung kommt.

Du kannst gerne auf https://www.betterbird.eu/ wechseln, der macht einiges besser als Thunderbird.

Bin vor ein paar Tagen auf Betterbrid umgestiegen, weil der mir empfohlen wurde. Aber bisher sehe ich keinerlei Besserung in irgendwas. Im Gegenteil, manche Dinge laufen jetzt sogar schlechter als vorher mit TB.

 

[cumulonimbus8]

Das heißt verschlüsselte Verbindungen sind ohne Zertifikat nicht möglich? Finde das zwar etwas merkwürdig

Da massiv Schindluder damit getrieben wurde hat man sich auf diese Maßnahme geeinigt, über verscheiden grenzen hinweg. Ist halt so, alte und überholte Protokolle mussten ersetzt werden.

Aber das entspricht doch dann in den Grundzügen einer Ausnahme-Regelung in Thunderbird.

Nein, tut es nicht… …wirklich.
Es ist eben keine Ausnahme seitens TB - du gaukelst ihm nur Blauen Dunst vor (wie auch bei den anderen analogen Vorschlägen) aber er verhält sich weiterhin wie er soll, auf dem hohen Sicherheitsniveau. Grund siehe oben.

Warum du aber demnach rein intern beim Mailserver eine Sicherheit aufbaust die dann aber gar nicht gewollt ist und TB solls richten ist schon komisch. Der Bauerntrick mit 25 und 143 wäre doch gnauso gangbar?!

CN8

 

[Hot Dog]

Da massiv Schindluder damit getrieben wurde hat man sich auf diese Maßnahme geeinigt.

Interessant, gut zu wissen.

Warum du aber demnach rein intern beim Mailserver eine Sicherheit aufbaust die dann aber gar nicht gewollt ist und TB solls richten ist schon komisch. Der Bauerntrick mit 25 und 143 wäre doch gnauso gangbar?!

Fair enough. Im Grunde ja vollkommen richtig. Verstehe dennoch nicht, warum er das mit der Ausnahme nicht einfach hinnimmt. Kann doch nicht so schwer sein oder etwa doch? Es liegt doch alles vor was er braucht, warum also jedes mal neu nachfragen. Ist einfach mega unintuitiv.

Im Grunde waren die Einstellungen so gedacht, dass ich sie eines Tages auch für externe Verwendung nutzen kann, ohne groß was an den Einstellungen vornehmen zu müssen.
Aber stimmt schon, vorerst kann ich defintiv über Port 25 kommunizieren.

 

[cumulonimbus8]

Ich stoße mich an der «Ausnahme».
Zertifikate füge ich, wie schon erklärt wurde, TB hinzu; und nichts Anderes tue ich, keine Ausnahmeliste pflegen usw.
Ich lüge dich also jetzt an, dass es diese (Art) Ausnahmeliste nicht gibt und auch nicht geben soll.

CN8

 

[Hot Dog]

Ich stoße mich an der «Ausnahme».

Wie gesagt, ich kann das aus Sicherheitsgründen ja total nachvollziehen. Dennoch sollten Ausnahmen greifen, wenn diese EXPLIZIT sowie BEWUSST vom Nutzer selbst getätigt werden. Ich brauch keinen CA-Abgleich von mir zum NAS, das ist einfach nur überflüssig.
Das gilt natürlich nicht für Unternehmen oder andere Fälle, wo das durchaus sinnvoll und sogar ratsam ist.

 

[IchbinbeiCB]

Aber das entspricht doch dann in den Grundzügen einer Ausnahme-Regelung in Thunderbird.

Diese Ausnahme-Regelung sagt erstmal nur, du vertraust der Verbindung (weil Sie eben nicht von ner CA Verifiziert worden ist) Bei ner öffentlichen CA würden die Zertifikate in der Zertifikatsverwaltung unter Zertifizierungsstellen zu finden sein, um das wiederum zu bestätigen. Dies wird durch die Seite von Thunderbird durch Updates Aktuell gehalten oder man fügt da selbst was hinzu.

Weil wenn du diese Ausnahme (unter Server in der Zerrtverwaltung) nicht hinzugefügt hättest, würde er die Verbindung abbrechen. Doch so versucht er weiter zu machen und scheitert eben am fehlenden Zertifikat.

warum sollte er dann einem Zertifikat trauen, welches ich selbst signiert habe?

Weil das eben auf dem Prinzip beruht Server - Client. Sprich du hast nen Zertifikat am Server hinterlegt und nen Gegenstück dazu am Client (deshalb meinte ich vorhins wenn eigene Zertifikate nutzt, zieh die in den Zertspeicher vom TB rein). Wenn TB jetzt ne Anfrage in Richtung Server macht, wird da eben (wie aktuell durch die Einstellung mit Port 587 auch schon) auf nen vorhandenes Zert geprüft und wenn das Valide (weil der Serverpart hier sagt, jupp hab hier des Gegenstück) ist, ist alles gut.

Das mit dem ändern von irgendwelchen Namen, liegt ja am Ende bei dir wie oft du da denn Anpassungen an den Zertifikaten vornehmen müsstest.

Und bzgl. Verschlüsselung und Zertifikate, das diese einander bedingen hat was mit deiner Person und deinem Perso ne Ähnlichkeit. Du kannst zwar auch ohne, irgendwem erzählen wer du bist aber ohne etwas wo des bezeugt, ist dieser Punkt eben nichtssagend. Ähnlich ist das eben beim Thema Verschlüsselung und Zertifikate.

Gruß
Sascha

 

[Hot Dog]

...

Danke für die ausführliche Erklärung, wieder was gelernt.

Und bzgl. Verschlüsselung und Zertifikate, das diese einander bedingen hat was mit deiner Person und deinem Perso ne Ähnlichkeit. Du kannst zwar auch ohne, irgendwem erzählen wer du bist aber ohne etwas wo des bezeugt, ist dieser Punkt eben nichtssagend. Ähnlich ist das eben beim Thema Verschlüsselung und Zertifikate.

Das ergibt zwar durchaus Sinn aber entsprechen selbst signierte Zertifikate dann nicht eher einem selbst gefälschten Perso? 😅
Klar, wenn der beim Kauf von Alkohol zugelassen wird, soll mir recht sein aber ist ja eigentlich nicht Sinn der Sache.
Aber habs jetzt schon einigermaßen verstanden.

Ich denke um eine eigene CA werde ich wohl auf lange Sicht nicht herum kommen, ganz egal wie wenig Anwendungen bzw. Clients ich eigentlich damit ausstatten möchte.
Und wer weiß, vielleicht lernt man dabei ja noch das ein oder andere. Ich seh mich aber schon wieder neue Threads hier im Forum bezüglich eigene CA eröffnen 😂

 

[JumpingCat]

Ich denke um eine eigene CA werde ich wohl auf lange Sicht nicht herum kommen, ganz egal wie wenig Anwendungen bzw. Clients ich eigentlich damit ausstatten möchte.

Du kannst auch Zertifikate von Lets Encrypt verwerden. Ein Wildcard ist auch möglich.

 

[Hot Dog]

@JumpingCat Schon versucht, leider nein.
Synology ist was das angeht äußerst restriktiv. Let's Encrypt Wildcard is lediglich für eine Synology-Domain zulässig (z.B. Synology.me ist der Klassiker). <- Ich schätze das ist Monopol-bedingt Eigenwerbung bei denen.
Für eigene Domains gibt es da leider kein Wildcard von Let's Encrypt.
-> Mit der Ausnahme, diese Einschränkung mittels ACME.sh zu umgehen (siehe: Github ACME.sh)
Aber das war mir dann doch viel zu viel Aufwand mit SSH rooten und Konsole usw. und das alles dann auch noch alle 3 Monate wiederholen zu müssen.

Ich verwende daher unter Synology für meine externen und damit von außerhalb nutzbaren Angelegenheiten 1 Let's Encrypt Zertifikat pro Subdomain (z.B. Cloud), ist zwar etwas umständlicher aber hab ja nur 2-3 Subdomains von daher halb so wild.

Das Problem ist eher:
Da meine interne Domain (.home) nicht von außen erreichbar sein soll, kommt eine Verifizierung von außen so oder so nicht wirklich in Frage. Ich möchte ja schließlich nicht, dass jemand auf mein NAS kommt (bzw. auch nur die Chance dazu bekommt).
Wenn ich also meine externe/offizielle Domain (.de) für meine internen Zugriffe verwenden wollen würde, müsste ich diese nach außen hin exposen und das möchte ich eigentlich nicht.
Und zudem möchte ich auch nicht auf das Internet zugreifen müssen, nur um über diesen langen Umweg dann auf mein NAS zu kommen, welches lediglich 10 Meter von mir entfernt steht 😅.
Von den Sicherheitsbedenken erst gar nicht zu sprechen.

 

[JumpingCat]

@JumpingCat Schon versucht, leider nein.
Synology ist was das angeht äußerst restriktiv. Let's Encrypt Wildcard is lediglich für eine Synology-Domain zulässig

Nein. Ich habe auf meiner Synology ein Wildcard Zertifikat drauf. Das klappt problemlos für Mailing, Weboberfläche, etc.

Den Teil mit SSH rooten verstehe ich nicht. Der ganze Part läuft zu 100% über die Weboberfläche.

Ich stimme dir aber zu, wenn man das komplett automatisieren möchte, dann landet man entweder bei der API oder irgendwas mit ssh.

Da meine interne Domain (.home) nicht von außen erreichbar sein soll, kommt eine Verifizierung von außen so oder so nicht wirklich in Frage. Ich möchte ja schließlich nicht, dass jemand auf mein NAS kommt (bzw. auch nur die Chance dazu bekommt).

Das verstehe ich wieder nicht. Ich hole mir ein Wildcard per DNS Challenge. Da ist nichts von aussen erreichbar.

 

[Hot Dog]

Nein. Ich habe auf meiner Synology ein Wildcard Zertifikat drauf. Das klappt problemlos für Mailing, Weboberfläche, etc.

Häh?
Siehe Punkt Nr. 2 (DDNS):

Den Teil mit SSH rooten verstehe ich nicht. Der ganze Part läuft zu 100% über die Weboberfläche.

Das mit dem SSH rooten usw. wird nur gemacht, um genau die Limitierung von oben aus Punkt Nr. 2 zu umgehen. Mit dem verlinkten Skript kommt man auch mit einer eigenen Domain trotz Synology an ein Let's Encrypt Wildcard-Zertifikat ran.
-> Ich beziehe mich auf folgende Anleitung: how-to-create-a-lets-encrypt-wildcard-certificate-on-a-synology-nas und in der heißt es: "This does work, however only on Synology domains. If you are running a custom domain, you still need to go the [manual] route as described below."

Ich stimme dir aber zu, wenn man das komplett automatisieren möchte, dann landet man entweder bei der API oder irgendwas mit ssh.

Es ging mir nicht um Automatisierung.
Nur ist das Beantragen des Zertifikats über das Synology-Interface wesentlich leichter und schneller erledigt, als diesen Prozess jedes Mal händisch in der Konsole (hier: Powershell per SSH) durchgehen zu müssen.
Und da man das ja alle 3 Monate machen muss, kommt da schnell einiges zusammen (4x pro Jahr). Natürlich könnte man es auch größtenteils automatisieren, aber davon verstehe ich zu wenig.

Das verstehe ich wieder nicht. Ich hole mir ein Wildcard per DNS Challenge. Da ist nichts von aussen erreichbar.

Welche DSM bzw. Version nutzt du? Sehen deine Möglichkeit dort anders aus?
Ich beziehe mich auf den Screenshot oben und behaupte, für eine eigene Domain kommst du über das Synology-Interface für Let's Encrypt an kein Wildcard-Zertifikat ran.
Falls das doch irgendwie möglich sein sollte, bitte ich um Erklärung.

Und um an ein gültiges Zertifikat zu kommen, muss die Adresse doch von außen aufgelöst werden können, ansonsten könnte der CA diese ja nicht überprüfen (Ich meine versuch mal ein Zertifikat für eine .home-Domain bei Let's Encrypt zu bekommen, viel Glück ^^).
Und von außen aufgelöst werden zu können bedeutet doch nichts anderes als von jederman von extern aufrufbar zu sein. Oder verstehe ich hier etwas komplett falsch?
-> Wenn ich also für z.B. [home.DOMAIN.de] (Subdomain) ein Zertifikat beantrage, dann muss [home.DOMAIN.de] doch auch von außen erreichbar sein und zu irgendwas weiterleiten oder nicht? Wie sonst sollte der CA das sonst verifizieren können.

 

[Nixdorf]

Das heißt verschlüsselte Verbindungen sind ohne Zertifikat nicht möglich? Finde das zwar etwas merkwürdig aber ok.

Was soll daran merkwürdig sein, dass man den etablierten Standard nutzt? Verschlüsselte Verbindungen im Internet setzen meist auf TLS auf, und das nutzt X.509 für die Public-Key-Infrastruktur. Alles seit Jahrzehnten bewährt. Und vor allem wird die Sicherheit von unzähligen Stellen ständig überprüft.

Es werden Zertifikate statt nur Schlüssel genutzt, weil man nicht nur verschlüsseln, sondern auch authentifizieren und beglaubigen will. Man will nicht nur mit irgendwem verschlüsselt kommunizieren, sondern mit der richtigen Gegenstelle. Das kann in einigen Anwendungen egal sein, in vielen ist es das aber nicht. Und warum dann separate Standards verwenden, wenn einer für alles reicht?

 

[Hot Dog]

Und warum dann separate Standards verwenden, wenn einer für alles reicht?

Weil genau dieser Standard voraussetzt, dass man von Extern (CA) verifziert wird, obwohl man sich zu 100% sicher sein kann, dass die Gegenstelle (internes NAS) bereits sicher ist, auch ganz ohne Zertifikat. Das ist alles.
Wäre einfach nutzerfreundlicher gewesen, da noch eine Abstufung einzubauen, die einem die Implementierung im internen Netz erleichtert.
So muss ich jetzt entweder selbst Zertifikate ausstellen (also selbst CA spielen) oder aber ich verzichte auf Verschlüsselung (und riskiere bei einer MITM-Attacke, dass alles mitgelesen wird). Sind doch beides keine nutzerfreundlichen Wege.

 

[Nixdorf]

von Extern (CA)

Der Standard schreibt "Extern" nicht vor. Eine CA kann man auch selbst betreiben, wie es hier bereits erwähnt wurde.

obwohl man sich zu 100% sicher sein kann

und riskiere bei einer MITM-Attacke

Was soll es sein? Hundertprozentig sicher oder es besteht die Gefahr einer MITM-Attacke? Letztendlich gibt es keine hundertprozentige Sicherheit. Das interne Netz ist solange sicher, bis jemand es infiltriert, zum Beispiel durch eine WLAN-Schwachstelle. Und wenn jemand erstmal im Netz ist, besteht die Gefahr, dass man nicht mehr mit dem NAS redet, sondern mit dem Angreifer. Ohne Zertifikatsprüfung kann man dann die Verschlüsselung auch gleich sein lassen, denn ungeprüft redet auch jeder Angreifer gerne verschlüsselt.