1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Verschlüsselung: Was noch…

Zertifizierungsstellen, Master-Keys / HTTPS

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: elcorazon 10.09.13 - 11:02

    Die ganze mathematische Sicherheit nützt überhaupt nichts, wenn eine Behörde einfach den Zertifizierungsstellen ein paar Millionen in die Hand drückt und dafür sämtliche ausgestellten Zertifikate und Keys erhält. Das ist doch eigentlich das derzeitige Hauptproblem, oder habe ich da etwas falsch verstanden?

    Was in dem Artikel nicht beschrieben wurde ist wie Zertifizierungsstellen arbeiten und was mit den private-keys dort passiert. Kann jemand erklären wie beispielsweise eine HTTPS-Verbindung funktioniert und was passiert, wenn ein Man-in-the-middle über den serverseitigen private-key verfügt?

  2. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: BLi8819 10.09.13 - 18:51

    Wie genau es bei HTTPS umgesetzt ist weiß ich nicht. Aber es baut doch auf asymmetrische Verschlüsslung auf.
    Und wenn ein Angreifer den privaten Schlüssel des Servers hat, kann er alle ankommenden Pakete mitlesen. Um die ausgehenden Pakete zu lesen brächte der Angreifer noch den privaten Schlüssel des Clients. Oder er fängt die Pakete ab, bevor sie verschlüsselt wurden. Also auf dem Server.

  3. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: Nixion 11.09.13 - 11:42

    Auch wenn die Behörden im Besitz aller durch die CAs ausgestellten Zertifikate sein sollten oder gar Zugriff auf die Root-CAs haben sollten, ist es ihnen nicht ohne weiteres möglich, bereits erfolgte Kommunikation zu entschlüsseln.
    Das liegt daran, dass die Zertifizierungsstellen im Regelfall überhaupt nicht im Besitz des zu den einzelnen Zertifikaten zugehörigen Private Keys sind. Wenn ich ein Zertifikat erwerbe, generiere ich im Vorfeld ein Schlüsselpaar. Den Public Key füge ich zusammen mit anderen relevanten Daten, welche meine Organisation bzw. mein System beschreiben (z. B. Common Name -> IP-Adresse oder FQDN) zu einem Zertifikat zusammen.
    Dieses Zertifikat wird dann von einer Stammzertifizierungsstelle mit ihrem Private Key signiert, welche somit für die hinterlegten Daten mit ihrem guten Namen "bürgt". Der Browser kann durch den im Zertifikatsspeicher hinterlegten Public Key der Stammzertifizierungsstelle diese Signatur überprüfen und das Zertifikat als gültig erachten.

    Ich hoffe, das ist so einigermaßen nachvollziehbar. Worauf ich eigentlich hinaus will: Der Private Key sollte IMMER vom Serverinhaber generiert werden und nicht aus der Hand gegeben werden. Er muss nur auf dem Server hinterlegt werden, für den das Zertifikat bestimmt ist.

    Natürlich wäre es den Behörden möglich, durch Zugriff auf das Root-Zertifikat einer Stammzertifizierungsstelle beliebige Zertifikate auszustellen und somit künftige Kommunikation durch MitM-Angriffe abzuhören, aber das ist eine andere Geschichte.

    Kleine Info am Rande: mit dem Private und Public Key wird übrigens in aller Regel nur die initiale Kommunikation verschlüsselt. Über diesen gesicherten Kanal wird ein gemeinsamer Schlüssel übertragen, mit dem dann aus Performance-Gründen eine symmetrische Verschlüsselung für die eigentliche Kommunikation genutzt wird.

  4. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: elcorazon 11.09.13 - 12:01

    Richtig, danke für die gut zusammengefasste Auffrischung!

    Hört sich ja so an als sei HTTPS doch noch sicher, vorausgesetzt der Client und Server sind nicht kompromittiert und der Schlüssel ist groß genug.

    Nixion schrieb:
    --------------------------------------------------------------------------------
    > Kleine Info am Rande: mit dem Private und Public Key wird übrigens in aller
    > Regel nur die initiale Kommunikation verschlüsselt. Über diesen gesicherten
    > Kanal wird ein gemeinsamer Schlüssel übertragen, mit dem dann aus
    > Performance-Gründen eine symmetrische Verschlüsselung für die eigentliche
    > Kommunikation genutzt wird.
    Könnte das der Angriffspunkt sein? Das würde ja bedeuten, es muss zunächst "nur" die initiale Kommunikation entschlüsselt werden - was ggf. mit ausreichend Rechenleistung möglich wäre (?) und anschließend kann die weitere Kommunikation mitgelesen werden. Oder ist die Entschlüsselung der initialen Kommunikation gleichbedeutend mit dem Knacken des z.B. 2.048 Bit langen RSA Schlüssels und damit laut Artikel kaum möglich?

  5. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: hw75 11.09.13 - 12:38

    Wurde doch alles schon zigmal durchgekaut.

    Sicher ist nur eine End-to-End Verschlüsselung. HTTPS verschlüsselt nur den Weg zum Webserver, dort wird sowieso wieder entschlüsselt. Also vollkommen sinnlos, das schützt nur wenn jemand im gleichen LAN per Sniffer den Netzwerktraffic abfangen würde. Ist aber unnötig geworden, seitdem beliebige Regierungen mit Weltherrschaftsgedanken die Daten einfach einkaufen können. Bisschen Geld nachgedruckt, dann ist das auch quasi umsonst.

    Das Hauptproblem zur Zeit sind die zig Backdoors die extra überall eingebaut werden. In Betriebssystemen, Apps, Routern und wer weiß wo noch überall. Und ich glaube nicht, dass diese Hintertüren 100% von allen anderen Angreifern sicher sind. Ist nur eine Frage der Zeit, ich hoffe dass demnächst mal einige Backdoors bekannt werden in irgendwelchen Hackergruppen und dann ordentlich mal alles kaputtgehackt wird. Am besten mit einer Nachricht noch dabei "NSA was here".

  6. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: elcorazon 11.09.13 - 18:05

    hw75 schrieb:
    --------------------------------------------------------------------------------
    > Sicher ist nur eine End-to-End Verschlüsselung. HTTPS verschlüsselt nur den
    > Weg zum Webserver, dort wird sowieso wieder entschlüsselt. [...]
    > Das Hauptproblem zur Zeit sind die zig Backdoors die extra überall
    > eingebaut werden. In Betriebssystemen, Apps, Routern und wer weiß wo noch
    > überall.
    Was wäre denn dann eine End-to-End Verschlüsselung für Webseiten? Wie gesagt, wenn Client und Server nicht kompromittiert sind, sollte das ja in Ordnung sein. Es geht ja um Zugriff auf Online-Banking oder ähnliches - natürlich kann der Betreiber des Webservers meine Daten immer noch verkaufen. Die Backdoors in Geräten auf dem Weg zwischen Client und Server spielen auch keine Rolle, wenn die Verschlüsselung ok ist. Die Backdoors in Betriebssystemen (auf Client und Server) sind eine andere Sache. Darauf habe ich zumindest ein kleines Stück weit noch selbst Einfluss.

  7. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: Nixion 11.09.13 - 23:03

    hw75 schrieb:
    --------------------------------------------------------------------------------
    > Wurde doch alles schon zigmal durchgekaut.
    >
    > Sicher ist nur eine End-to-End Verschlüsselung. HTTPS verschlüsselt nur den
    > Weg zum Webserver, dort wird sowieso wieder entschlüsselt. Also vollkommen
    > sinnlos, das schützt nur wenn jemand im gleichen LAN per Sniffer den
    > Netzwerktraffic abfangen würde. Ist aber unnötig geworden, seitdem
    > beliebige Regierungen mit Weltherrschaftsgedanken die Daten einfach
    > einkaufen können. Bisschen Geld nachgedruckt, dann ist das auch quasi
    > umsonst.

    HTTPS ist eine Ende-zu-Ende-Verschlüsselung (von Proxy-Konstruktionen mal abgesehen). Und natürlich muss der Webserver den Stream entschlüsseln, er muss ja wissen, was er mit den Daten überhaupt anfangen soll.

    Der Kanal kann aus heutiger Sicht als sicher erachtet werden, wenn das Zertifikat gültig (von Trusted Root CA signiert), der Private Key nicht entwendet wurde (schwer bis unmöglich zu überprüfen), die Key-Länge des asymmetrischen Schlüsselpaars ausreichend Reserven bietet (2048+ Bits) und das symmetrische Verschlüsselungsverfahren zeitgemäß ist. Schwache Verschlüsselungsverfahren sollten deaktiviert werden, da es in älteren TLS/SSL-Versionen (vor TLS 1.1) möglich ist, als MitM ein Downgrade auf eine ältere Version zu forcieren und bei SSLv2 sogar die Wahl des symmetrischen Verschlüsselungsverfahren zu bestimmen!

  8. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: BLi8819 11.09.13 - 23:24

    > Sicher ist nur eine End-to-End Verschlüsselung. HTTPS verschlüsselt nur den Weg zum Webserver, dort wird sowieso wieder entschlüsselt.

    HTTPS ist ja auch genau dafür da. Um den Datenverkehr zwischen Client und Webserver zu verschlüsseln...
    Was soll der Server mit Daten, die er nicht entschlüsseln kann?

  9. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: Julius Csar 14.09.13 - 14:04

    Siehe AESload.de

    Daten kommen verschlüsselt beim Server an, ohne dass der Server das Passwort kennt -> verschlüsselte Daten werden dort für einige Tage aufbewahrt -> Clients können verschlüsselte Daten abrufen (selbst die verschlüsselten Daten werden nur freigegeben, wenn zuvor die richtigen Prüfsumme an den Server gesendet wurde) -> Clients können nur mit dem richtigen Passwort die Daten entschlüsseln



    1 mal bearbeitet, zuletzt am 14.09.13 14:07 durch Julius Csar.

  10. Re: Zertifizierungsstellen, Master-Keys / HTTPS

    Autor: hjp 14.09.13 - 15:20

    Nixion schrieb:
    > HTTPS ist eine Ende-zu-Ende-Verschlüsselung (von Proxy-Konstruktionen mal
    > abgesehen). Und natürlich muss der Webserver den Stream entschlüsseln, er
    > muss ja wissen, was er mit den Daten überhaupt anfangen soll.
    >
    > Der Kanal kann aus heutiger Sicht als sicher erachtet werden, wenn das
    > Zertifikat gültig (von Trusted Root CA signiert),

    ... und die CA das Zertifikat tatsächlich für den rechtmäßigen
    Eigentümer des CN ausgestellt hat. Per default vetrauen Browser allen
    installierten Root CAs absolut. Ein Angreifer muss nur eine beliebige
    dieser CAs kompromittieren (z.B. durch Vorlegen eines NSL), um ein
    gültiges Zertifikat zu erhalten.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Referent Digitale Produkte & Services (m/w/d)
    Brückner Servtec GmbH, Siegsdorf
  2. Senior Softwareingenieur - Test für Hubschraubersysteme (gn)
    ESG Elektroniksystem- und Logistik-GmbH, Donauwörth
  3. IT-Systemadministrator (m/w/d)
    BruderhausDiakonie Stiftung Gustav Werner und Haus am Berg, Reutlingen
  4. Full Stack Developer (m/w/d)
    Allianz Technology SE, Stuttgart

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 499,99€
  3. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de