Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › HTTPS: Private Schlüssel auf dem…

Doch was, wenn der Schlüssel auf dem Webserver landet ...

  1. Thema

Neues Thema Ansicht wechseln


  1. Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Anonymer Nutzer 12.07.17 - 16:46

    ...- und dann nicht mehr privat ist?

    Was wenn der Webserver den privaten Schlüssel nicht kennt, wie verschlüsselter dieser dann?

  2. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Subsystemzero 12.07.17 - 16:54

    Das ist ja eigentlich das nächste, das unklar ist.

    Der private Schlüssel dient ja letztlich nur dazu Https serverseitig zu realisieren. Wie kann man damit denn neue valide CSR gegen eine namhafte CA stellen? Benötigt man da nicht zusätzlich ein Benutzerkonto?

    Sorry, für die Frage, aber mit der Theorie ists schon etwas her..

    Edit: alles klar, geht "nur" um Man-in-the-middle



    1 mal bearbeitet, zuletzt am 12.07.17 16:59 durch Subsystemzero.

  3. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: c3rl 12.07.17 - 17:27

    MysticaX schrieb:
    --------------------------------------------------------------------------------
    > ...- und dann nicht mehr privat ist?
    >
    > Was wenn der Webserver den privaten Schlüssel nicht kennt, wie
    > verschlüsselter dieser dann?

    Dem Webserver muss der Schlüssel natürlich zur Verfügung stehen, aber der Artikel beschreibt eben den Fall, dass dieser im öffentlichen Webroot lag, was ein absolut katastrophaler Fehler ist, von dem ich mir nicht erklären kann, wie das passiert.

    Keys sollten in einem Verzeichnis liegen, welches dem super user gehört und umask 0077 erfüllt. Beispiel Debian: `/etc/ssl/mycompany/foobar.crt` für das das Zertifikat, `/etc/ssl/mycompany/private/foobar.key` für den Schlüssel.

    OpenSSH kreidet es z.B. an und bricht dann ab, wenn Schlüssel zu offen herumliegen. Wäre wohl mal eine gute Idee, so einen Check auch in Apache und NGINX einzubauen.



    1 mal bearbeitet, zuletzt am 12.07.17 17:28 durch c3rl.

  4. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Itchy 12.07.17 - 17:29

    c3rl schrieb:
    --------------------------------------------------------------------------------

    > OpenSSH kreidet es z.B. an und bricht dann ab, wenn Schlüssel zu offen
    > herumliegen. Wäre wohl mal eine gute Idee, so einen Check auch in Apache
    > und NGINX einzubauen.

    +1

  5. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Anonymer Nutzer 12.07.17 - 19:06

    c3rl schrieb:
    --------------------------------------------------------------------------------

    > Dem Webserver muss der Schlüssel natürlich zur Verfügung stehen, aber der
    > Artikel beschreibt eben den Fall, dass dieser im öffentlichen Webroot lag,
    > was ein absolut katastrophaler Fehler ist, von dem ich mir nicht erklären
    > kann, wie das passiert.

    Meine Fragestellung war übrigens mehr eine Anspielung auf dem besagten Ausschnitt, weil ich mich mit der Materie auskenne.

    Der Titel und der von mir kopierte Anreissertext suggerieren das der private Schlüssel nichts auf einem Webserver zu suchen haben.

    Im Artikel der Satz:
    "Dieser Vorfall zeigt einmal mehr, dass Daten auf Webservern ein bislang unterschätztes Sicherheitsrisiko darstellen."
    Suggeriert dann das man am besten gar keine Dateien auf einen Webserver packt.

    Interessanterweise ist der letzte Satz im Anreissertext dann richtig
    "Webseiten, die ihren privaten Schlüssel zum Herunterladen anbieten"

    Ist ein riesengrosser Unterschied ob eine Datei auf dem Webserver liegt oder in einem öffentlich zugänglichen Verzeichniss liegt, das man treffender weise als Webseite bezeichnen kann.

    Dann noch mal zurück zu dem Sicherheitsrisiko, in beidem Fällen das hier und auch das mit dem Datenbank dumps, ist pure Schlampigkeit, sehe da nun nicht den Bezug des Sicherheitsrisikos, wenn der Webserver gehackt wurde und Zugriff genommen wurden auf Dateien die nicht im Webroot liegen, dann kann man das gerne Sicherheitsrisiko nennen.


    > Keys sollten in einem Verzeichnis liegen, welches dem super user gehört und
    > umask 0077 erfüllt. Beispiel Debian: `/etc/ssl/mycompany/foobar.crt` für
    > das das Zertifikat, `/etc/ssl/mycompany/private/foobar.key` für den
    > Schlüssel.
    >
    > OpenSSH kreidet es z.B. an und bricht dann ab, wenn Schlüssel zu offen
    > herumliegen. Wäre wohl mal eine gute Idee, so einen Check auch in Apache
    > und NGINX einzubauen.

  6. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: ibsi 12.07.17 - 19:55

    Danke, ich war schon kurz am überlegen was ich denn nun falsch gemacht habe :D Der *Key MUSS doch auf dem Server liegen ... wie soll das denn sonst gehen* dachte ich mir.

    Aber Private Schlüssel sollten doch Grundsätzlich NICHT zum Download bereit stehen, ob das nun SSH, SSL, oder sonst was ist. Deshalb sind sie ja PRIVAT.

  7. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: rugel 12.07.17 - 20:18

    c3rl schrieb:
    --------------------------------------------------------------------------------

    > OpenSSH kreidet es z.B. an und bricht dann ab, wenn Schlüssel zu offen
    > herumliegen. Wäre wohl mal eine gute Idee, so einen Check auch in Apache
    > und NGINX einzubauen.

    Wozu ? Es gibt noch genügend andere Möglichkeiten Mumpitz zu konfigurieren und wo fängt man an und wo hört man dann auf.

  8. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: amagol 12.07.17 - 21:20

    ibsi schrieb:
    --------------------------------------------------------------------------------
    > Danke, ich war schon kurz am überlegen was ich denn nun falsch gemacht habe
    > :D Der *Key MUSS doch auf dem Server liegen ... wie soll das denn sonst
    > gehen* dachte ich mir.

    Der Key MUSS dort liegen wo die SSL-Verbindung terminiert wird. Das muss nicht zwangslaeufig der Webserver sein (das koennen auch einige Loadbalancer).

  9. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Anonymer Nutzer 12.07.17 - 21:57

    amagol schrieb:
    --------------------------------------------------------------------------------
    > Der Key MUSS dort liegen wo die SSL-Verbindung terminiert wird. Das muss
    > nicht zwangslaeufig der Webserver sein (das koennen auch einige
    > Loadbalancer).

    Solange der aber nicht direkt an mit den anderen Server verbunden ist oder man ein eigenes Rechenzentrum hat,sollte man auch intern verschlüsseln.
    Das wäre dann noch mal ein ganz anderes Level.

    Mir ging es lediglich darum, das die Nachricht, die Dinge nicht klar darstellt, was generell ein Problem mit Nachrichten ist, das Niveau geht stetig bergab :-(

  10. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Anonymer Nutzer 12.07.17 - 22:10

    schau dir mal keyless von cloudflare an.

  11. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: 486dx4-160 13.07.17 - 00:12

    Ein ziemlich einleuchtender Ansatz zur Lösung von Versicherungsproblemen.
    In der Praxis dürfte das die Probleme nur vergrößern. Wer's nicht schafft seinen privaten Schlüssel außerhalb von htdocs zu speichern wird's 2x nicht schaffen den "keyless ssl server" korrekt, sicher und stabil zu betreiben. Der Spaß vervielfacht die Komplexität.

  12. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: nicoledos 13.07.17 - 14:38

    Ähnlich wie bei den Datenbankdumps sehe ich das Problem wohl darin. Bei Webservern gibt es oft kein separates home-verzeichnis. Im Webroot ist gleich das home des users.

    Alles was man da im vermeintlichen 'home' per ssh, ftp und was auch immer anstellt stellt der Webserver gleichzeitig der Welt zur Verfügung. Nur wenigen ist dieses Problem wirklich bewusst.

  13. Re: Doch was, wenn der Schlüssel auf dem Webserver landet ...

    Autor: Anonymer Nutzer 13.07.17 - 22:51

    nicoledos schrieb:
    --------------------------------------------------------------------------------
    > Alles was man da im vermeintlichen 'home' per ssh, ftp und was auch immer
    > anstellt stellt der Webserver gleichzeitig der Welt zur Verfügung. Nur
    > wenigen ist dieses Problem wirklich bewusst.

    Ich gehe mal von aus du meinst die Situation bei Webhostern?
    Da habe ich schon lange keinen mehr gesehen wo das der Fall ist, bei dem meisten kann man sogar für jede Domain einen webroot selbst eingeben.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Lösch und Partner GmbH, München
  2. Hays AG, Rhein-Main-Gebiet
  3. Universität Passau, Passau
  4. Bosch Gruppe, Abstatt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. 4 Blu-rays für 20€, 2 TV-Serien für 20€)
  2. Jetzt für 150 EUR kaufen und 75 EUR sparen


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gigabit: 5G-Planungen gehen völlig an den Nutzern vorbei
Gigabit
5G-Planungen gehen völlig an den Nutzern vorbei

Fast täglich hören wir Erklärungen aus der Telekommunikationsbranche, was 5G erfüllen müsse und warum sonst das Ende der Welt drohe. Wir haben die Konzerngruppen nach Interessenlage kartografiert.
Ein IMHO von Achim Sawall

  1. Bundesnetzagentur Regierung will gemeinsames 5G-Netz auf dem Land durchsetzen
  2. Mobilfunk Telekom will 5G-Infrastruktur mit anderen gemeinsam nutzen
  3. Fixed Wireless Access Nokia bringt mehrere 100 MBit/s mit LTE ins Festnetz

Künstliche Intelligenz: Wie Computer lernen
Künstliche Intelligenz
Wie Computer lernen

Künstliche Intelligenz, Machine Learning und neuronale Netze zählen zu den wichtigen Buzzwords dieses Jahres. Oft wird der Eindruck vermittelt, dass Computer bald wie Menschen denken können. Allerdings wird bei dem Thema viel durcheinandergeworfen. Wir sortieren.
Von Miroslav Stimac

  1. Innotrans KI-System identifiziert Schwarzfahrer
  2. USA Pentagon fordert KI-Strategie fürs Militär
  3. KI Deepmind-System diagnostiziert Augenkrankheiten

Shine 3: Neuer Tolino-Reader bringt mehr Lesekomfort
Shine 3
Neuer Tolino-Reader bringt mehr Lesekomfort

Die Tolino-Allianz bringt das Nachfolgemodell des Shine 2 HD auf den Markt. Das Shine 3 erhält mehr Ausstattungsdetails aus der E-Book-Reader-Oberklasse. Vor allem beim Lesen macht sich das positiv bemerkbar.
Ein Hands on von Ingo Pakalski

  1. E-Book-Reader Update macht Tolino-Geräte unbrauchbar

  1. Windows 10: Retpoline-Patch gegen Spectre verbessert CPU-Leistung
    Windows 10
    Retpoline-Patch gegen Spectre verbessert CPU-Leistung

    In der kommenden Version von Windows 10 will Microsoft Retpoline gegen Spectre einführen. Das verlangsame das System nicht mehr so stark und bringe gerade auf älteren PCs eine spürbare Verbesserung. Allerdings dauert die Einführung noch ein wenig.

  2. Richard Stallman: GNU-Projekt bekommt Richtlinien für gute Kommunikation
    Richard Stallman
    GNU-Projekt bekommt Richtlinien für gute Kommunikation

    Ausgelöst durch die Diskussionen um den Code-of-Conduct in Linux und anderen Projekten erhält nun auch das GNU-Projekt Richtlinien zur Kommunikation. Strikte Vorschriften sollen aber explizit nicht gemacht werden, entschied Projektgründer Richard Stallman.

  3. Fertigungsprozess: Intel soll 10-nm-Node eingestampft haben
    Fertigungsprozess
    Intel soll 10-nm-Node eingestampft haben

    Abseits eines einzelnen Prozessors aus der Cannon-Lake-Serie hat Intel bisher keine 10-nm-Chips vorzuweisen. Das soll auch so bleiben: Angeblich hat der Hersteller die erfolglose Fertigung komplett eingestellt und wechselt direkt auf 7 nm samt extrem-ultravioletter Strahlung.


  1. 17:58

  2. 17:50

  3. 17:42

  4. 17:14

  5. 16:47

  6. 16:33

  7. 13:53

  8. 13:33