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: bjs 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. Randstad Deutschland GmbH & Co. KG, Berlin
  2. Hochschule für angewandte Wissenschaften Augsburg, Augsburg
  3. über duerenhoff GmbH, Raum Lübeck
  4. CSL Behring GmbH, Marburg, Bern (Schweiz)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 59,90€
  2. bei Alternate kaufen


Haben wir etwas übersehen?

E-Mail an news@golem.de


PC Building Simulator im Test: Wenn's doch nur in der Realität so einfach wäre
PC Building Simulator im Test
Wenn's doch nur in der Realität so einfach wäre
  1. Halbleiter China pumpt 47 Milliarden US-Dollar in eigene Chip-Industrie
  2. Dell Neue Optiplex-Systeme in drei Größen und mit Dual-GPUs
  3. Patterson und Hennessy ACM zeichnet RISC-Entwickler aus

Hyundai Ioniq im Test: Mit Hartmut in der Sauna
Hyundai Ioniq im Test
Mit Hartmut in der Sauna
  1. Elektroautos BMW-Betriebsrat fürchtet Akkus aus China
  2. Uniti One Günstiges Elektroauto aus Schweden ist fertig
  3. Axialflusselektromotor Leichte Elektroantriebe mit hoher Leistung entwickelt

P20 Pro im Hands on: Huawei erhöht die Anzahl der Kameras - und den Preis
P20 Pro im Hands on
Huawei erhöht die Anzahl der Kameras - und den Preis
  1. Critical Communications World Huawei will langsames Tetra mit eLTE MCCS retten
  2. Smartphones Huawei soll eigene Android-Alternative haben
  3. Porsche Design Mate RS Huaweis neues Porsche-Smartphone kommt in den Handel

  1. Zuckerberg-Anhörung: Nicht mehr reden, sondern regulieren
    Zuckerberg-Anhörung
    Nicht mehr reden, sondern regulieren

    Viele kritische Fragen, nur ausweichende Antworten: Facebook-Chef Mark Zuckerberg ist in der Anhörung vor dem EU-Parlament noch besser davongekommen als vor dem US-Kongress. Doch nun drohen Abgeordnete mit Bußgeldern und Regulierung.

  2. Funklöcher: Brandenburg errichtet neue Mobilfunkmasten
    Funklöcher
    Brandenburg errichtet neue Mobilfunkmasten

    Mit 32 neuen Mobilfunkmasten will ein Bundesland die Mobilfunkversorgung verbessern. Doch es gibt über 23.000 Funklöcher in Brandenburg.

  3. IT-Studium: Informatikstudiengänge haben zu wenig Professoren
    IT-Studium
    Informatikstudiengänge haben zu wenig Professoren

    Trotz wachsendem Interesse an der Informatik werden kaum mehr Professoren und Lehrkräfte eingestellt. Die Hochschulen müssten selbst mehr tun, um wissenschaftlichen Nachwuchs zu halten.


  1. 23:05

  2. 18:56

  3. 18:14

  4. 16:59

  5. 16:47

  6. 16:33

  7. 16:19

  8. 15:56