VM: "Anonyme Festung" aufbauen - Sicher im Netz u. lokal

[mathmos]

Open Source ist business technisch gesehen komplett vor dem AUS. Niemand stellt sich mehr freiwillig irgendeine gefummelte Linux Schuessel in sein Netzwerk wenn er nicht unbedingt muss. Das hat zum einen was mit verschiedenen Rechtlichen vorgaben zu tun zum anderen will man sich nicht an linux nerds binden etc etc - kurz: open source ist bald weg vom fenster, zumindest business seitig.

Erzähl das mal Unternehmen wie Redhat (ca. 130 Millionen Euro Gewinn (netto) im letzten Geschäftsjahr).

 

[supreme]

In Unternehmen sind solche Setups durchaus üblich, im privaten Umfeld jedoch keineswegs (und dies ist das Szenario in diesem Thread).

Wenn man diese Denkweise an den Tag legt, kann man sich bestimmt einreden das eine laecherliche VPN verbindung irgendeinen sicherheitsbonus bringt.
willst du mir allen ernstes erzaehlen das du dir vollkommen im klaren bist welches zertifikat fuer welchen service mit welcher vererbung an wen ausgestellt wurde
und du kannst sicher validieren das keine der ketten unterbrochen wurde ???

Einfach und Plakativ - Wenn man sich das hier mal durchliest:

You do not have permission to view link please Anmelden or Registrieren

Willst Du jetzt ernsthaft mit sicherheit erklaeren das keines der Zertifikate die sich auf dem normalo Rechner tummeln, absichtlich frisiert wurden ?

on top, Wieviele solcher vorfaelle:

You do not have permission to view link please Anmelden or Registrieren

wirds wohl gegeben haben ueber die stillschweigen vereinbart wurde ?


Was das mit der Fragestellung zu tun hat, eine Menge:

Denn hier kommt ein User an und stellt eine valide frage und als antwort werden Vorgehensweisen gepostet die maximal die gefühlte sicherheit erhöhen,
aber doch in der realitaet keinerlei mehrwert bieten. das freut wahrscheinlich nur die Anbieter diverser vpn Services. ich denke das es gefährlich ist sowas zu publizieren...

 

[accC]

willst du mir allen ernstes erzaehlen das du dir vollkommen im klaren bist welches zertifikat fuer welchen service mit welcher vererbung an wen ausgestellt wurde
und du kannst sicher validieren das keine der ketten unterbrochen wurde ???

Ja, ich weiß, welche Zertifikate mein Server an welcher Stelle ausgibt und mein Server weiß auch ganz genau und eindeutig, welche Zertifikate ich ihm geben muss, um mich gegenüber ihm zu identifizieren. Bei verschlüsselten Chats und Emails sind die Fingerprints jedes Kontakts händisch von mir bzw. dem Kontakt abgeglichen worden. - Alles was ebenenmäßig darunter liegt, ist nicht vertrauenswürdig, aber das spielt auch keine Rolle, denn die Cryptosysteme sind so designed, dass sie auf einer unsicheren Leitung aufbauen können und trotzdem als sicher gelten. Um es noch mal zu sagen, das ist genau die Idee dahinter.

 

[Kugelfisch]

Wenn man diese Denkweise an den Tag legt, kann man sich bestimmt einreden das eine laecherliche VPN verbindung irgendeinen sicherheitsbonus bringt.
willst du mir allen ernstes erzaehlen das du dir vollkommen im klaren bist welches zertifikat fuer welchen service mit welcher vererbung an wen ausgestellt wurde
und du kannst sicher validieren das keine der ketten unterbrochen wurde ???

Ich will sicherlich nicht behaupten, dass die X.509-PKI, welche u.a. für SSL/TLS benutzt wird, absolut sicher ist. Ebenso wenig bestreite ich, dass es möglich ist, einen MitM-Angriff auf eine TLS-Verbindung durchzuführen, sofern die Anwendung ausschliesslich der X.509-PKI vertraut und ein Angreifer (was auch Gateways einschliesst, welche als MitM-Proxy fungieren) ein Zertifikat für den FQDN des Zielhosts erhalten kann. Eine unterbrochene Zertifikatskette stellt jedoch keine Gefahr dar, da sie automatisch validiert wird und die Verbindung abgelehnt wird, wenn die Zertifikatskette nicht über gültige Zertifikate bis zu einem gültigen, als vertrauenswürdig eingestuften Root-Zertifikat führt

Ausserdem lassen sich die Aussagen zu X.509 und TLS nicht auf alle VPN-Systeme anwenden. Im Falle von OpenVPN werden zwar in der Regel TLS-Verbindungen verwendet (die Alternative sind statische Schlüssel - vgl.

You do not have permission to view link please Anmelden or Registrieren

), allerdings wird das dazu nötige Root-Zertifikat einmalig mit der Konfigurationsdatei installiert (Option `--ca`, vgl.

You do not have permission to view link please Anmelden or Registrieren

). Anderen Root-Zertifikaten wird nicht vertraut. Daher lässt sich nur dann ein MitM-Angriff durchführen, wenn dem Angreifer der zu diesem spezifischen CA-Zertifikat zugehörige private Schlüssel bekannt ist. In aller Regel handelt es sich dabei um ein Root-Zertifikat einer eigenen CA des jeweiligen VPN-Anbieters, welche einzig und ausschliesslich dazu benutzt wird, VPN-Zertifikate auszustellen.
Es wäre natürlich denkbar, dass ein Angreifer bereits bei der erstmaligen Übertragung der Konfigurationsdateien zum Client einen MitM-Angriff durchführt und die Konfiguration inklusive Zertifikat austauscht. Allerdings wäre das sehr gefährlich, da dann sichergestellt werden müsste, dass jede zukünftige Verbindung ebenfalls über den MitM-Proxy des Angreifers umgeleitet wird, da andernfalls aufgrund des ausgetauschten Zertifikats keine Verbindung möglich ist. Daher wirst du kaum behaupten können, das würde in grossem Massstab getan. Viel einfacher wäre in solch einem Szenario, ein beliebiges heruntergeladenes Binary über einen MitM-Angriff gegen Malware auszutauschen und damit das Client-System komplett zu kompromittieren. Auch da wäre die Entdeckungsgefahr jedoch hoch, weshalb das maximal sehr gezielt geschieht.

Einfach und Plakativ - Wenn man sich das hier mal durchliest:

You do not have permission to view link please Anmelden or Registrieren

Wenn du auf eine derart umfangreiche Kollektion von Dokumenten verlinkst, wäre sehr sinnvoll, mit anzugeben, auf welche Dokumente du dich im Folgenden konkret beziehst.


Die vorherigen Beiträge zur Open-/Closed-Source-Diskussion habe ich in https://ngb.to/threads/9034-Meta-Diskussion-Streamseite-geht-auf-Linux-nicht verschoben.