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. über duerenhoff GmbH, Erkrath
  2. Deutsche Post DHL Group, Bonn
  3. Hexagon Metrology GmbH, Wetzlar
  4. über duerenhoff GmbH, Wasserburg am Inn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. und Assassins Creed Odyssey, Strange Brigade und Star Control Origins kostenlos dazu erhalten


Haben wir etwas übersehen?

E-Mail an news@golem.de


Always Connected PCs im Test: Das kann Windows 10 on Snapdragon
Always Connected PCs im Test
Das kann Windows 10 on Snapdragon

Noch keine Konkurrenz für x86-Notebooks: Die Convertibles mit Snapdragon-Chip und Windows 10 on ARM sind flott, haben LTE integriert und eine extrem lange Akkulaufzeit. Der App- und der Treiber-Support ist im Alltag teils ein Manko, aber nur eins der bisherigen Geräte überzeugt uns.
Ein Test von Marc Sauter und Oliver Nickel

  1. Qualcomm "Wir entwickeln dediziertes Silizium für Laptops"
  2. Windows 10 on ARM Microsoft plant 64-Bit-Support ab Mai 2018
  3. Always Connected PCs Vielversprechender Windows-RT-Nachfolger mit Fragezeichen

Battlefield 5 Closed Alpha angespielt: Schneller sterben, länger tot
Battlefield 5 Closed Alpha angespielt
Schneller sterben, länger tot

Das neue Battlefield bekommt ein bisschen was von Fortnite und wird allgemein realistischer und dynamischer. Wir konnten in der Closed Alpha Eindrücke sammeln und erklären die Änderungen.
Von Michael Wieczorek

  1. Battlefield 5 Mehr Reaktionsmöglichkeiten statt schwächerer Munition
  2. Battlefield 5 Closed Alpha startet mit neuen Systemanforderungen
  3. Battlefield 5 Schatzkisten und Systemanforderungen

Indiegames-Rundschau: Schiffbruch, Anime und viel Brummbrumm
Indiegames-Rundschau
Schiffbruch, Anime und viel Brummbrumm

Gas geben, den weißen Hai besiegen und endlich die eine verlorene Socke wiederfinden: Die sommerlichen Indiegames bieten für jeden etwas - besonders fürs Spielen zu zweit.
Von Rainer Sigl

  1. Indiegames-Rundschau Spezial Unabhängige Riesen und Ritter für Nintendo Switch
  2. Indiegames-Rundschau Schwerelose Action statt höllischer Qualen
  3. Indiegames-Rundschau Kampfkrieger und Abenteuer in 1001 Nacht

  1. Mobilfunkzentrum: Bayern schließt seine Funklöcher
    Mobilfunkzentrum
    Bayern schließt seine Funklöcher

    Wo staatliches Geld fließt, schließen sich die Mobilfunk-Löcher erheblich schneller. Wie in Bayern, dessen Landesregierung nun ein Mobilfunkzentrum gründet.

  2. Joint Venture: United Internet will mit Telekom FTTH für Millionen ausbauen
    Joint Venture
    United Internet will mit Telekom FTTH für Millionen ausbauen

    United Internet kann das Angebot nicht ausschlagen, mit der Telekom einige Milliarden Euro für Glasfaserausbau auszugeben. Doch ein 50:50-Joint-Venture traut sich Ralph Dommermuth denn doch nicht zu.

  3. IMP: Neues Fach für Digitalisierung an deutschen Oberschulen
    IMP
    Neues Fach für Digitalisierung an deutschen Oberschulen

    In Deutschland sollen Schüler besser auf die Digitalisierung der Gesellschaft vorbereitet werden. Dazu wird es ab dem kommenden Schuljahr ein neues Fach an Gymnasien geben: IMP steht für Informatik, Mathematik und Physik.


  1. 18:09

  2. 16:50

  3. 16:36

  4. 16:14

  5. 15:53

  6. 15:35

  7. 14:45

  8. 14:35