NodeJS Applikation erhält keinen Zugriff auf Port 443 (SSL)

    Hallo Leute,

    Ich sitze gerade daran, eine NodeJS Applikation auf meiner Domain zum laufen zu bekommen und stoße nun auf folgendes Problem:

    Mein Applikation gibt folgenden Fehler zurück:

    Code
    Error: listen EACCES: permission denied 0.0.0.0:443

    Das bedeutet, dass mein Programm keinen Zugriff auf den SSL-Port hat, was aber zwingend notwendig ist, weil ich über meine Applikation auch Login-Daten austausche, welche nach der DSGVO ja über SSL gesichert sein müssen.


    Hab ich da vielleicht bei mir was übersehen?

    (Ich weiß nicht was für Infos ihr braucht, um mir zu helfen, bitte einfach mit schreiben wenn ich noch was sagen muss)


    Vielen Dank schonmal


    Lukas

    Bist du im Webhosting? die Anfragen kommen über eine nginx Proxy rein, der TLS terminiert.


    Bist du auf einem eigenen Server? Die App muss mit root Rechten gestartet werden, oder davor ein Proxy laufen, der ebenfalls TLS terminiert.

    Danke für die Hilfe, ich habs inzwischen selber rausgefunden:

    Man darf sich nur mit Port 80 verbinden, die SSL verschlüsselung macht ngingx? selber irgendwo zwischen Anfrage und NodeJS.

    Das heißt, dass alle Anfragen unverschlüsselt bei der Applikation ankommen, aber nach außen hin verschlüsselt sind.

    Das ist, wie ich finde, ein SSL Supergau, weil man halt dann allem zwischen NodeJS und dem Anfang der SSL Verschlüsselung vertrauen MUSS, aber immerhin funktioniert es jetzt.


    Jetzt kann ich mich nur nicht mit den Datenbanken verbinden -.- - Kann es sein dass die Datenbank-Server gerade down sind?
    Und LetsEncrypt war bis gerade auch down... Heute ist nicht mein Tag


    Und noch ein Tipp für alle die das selbe Problem haben und nicht weiter kommen, weil da ein 403 Apache Serverfehler kommt:

    In den Einstellungen der Subdomain (Einstellungen für Apache und Nginx) muss der Haken bei Proxymodus entfernt sein:
    pasted-from-clipboard.png

    Quote from astrogd

    Das ist, wie ich finde, ein SSL Supergau, weil man halt dann allem zwischen NodeJS und dem Anfang der SSL Verschlüsselung vertrauen MUSS, aber immerhin funktioniert es jetzt.

    Wieso ist das ein Supergau? Es ist üblich, dass nginx hier die TLS Verbindung terminiert.

    Und was hat das mit Vertrauen zu tun? TLS ist dafür da, dass der Client ein Vertrauen zum Server aufbauen kann. Loopback Traffic sollte davon unberührt sein.

    Du kannst trotzdem über die URL feststellen, ob gerade eine verschlüsselte oder unverschlüsselte Verbindung hast.


    Unverschlüsselte Verbindungen kannst du über nginx umleiten, oder über deine Applikation.


    Quote from astrogd

    Jetzt kann ich mich nur nicht mit den Datenbanken verbinden

    Das heißt genau? Hat es denn vorher funktioniert?

    Welche Fehlermeldung kommt und welche Daten hast du in der Connect Funktion eingegeben?

    Quote from H6G

    Wieso ist das ein Supergau? Es ist üblich, dass nginx hier die TLS Verbindung terminiert.

    Und was hat das mit Vertrauen zu tun? TLS ist dafür da, dass der Client ein Vertrauen zum Server aufbauen kann. Loopback Traffic sollte davon unberührt sein.

    Du kannst trotzdem über die URL feststellen, ob gerade eine verschlüsselte oder unverschlüsselte Verbindung hast.


    Unverschlüsselte Verbindungen kannst du über nginx umleiten, oder über deine Applikation.

    Naja ich kann nicht gewährleisten dass zwischen Client und meiner Applikation die Daten verschlüsselt sind, weil sie unverschlüsselt bei mir ankommen (und auch unverschlüsselt losgesendet werden müssen)

    Quote from astrogd

    Naja ich kann nicht gewährleisten dass zwischen Client und meiner Applikation die Daten verschlüsselt sind

    Doch, das kannst du über die URL prüfen. Das Protokoll wird zwischen nginx und deiner App ausgetauscht.


    Quote from astrogd

    weil sie unverschlüsselt bei mir ankommen (und auch unverschlüsselt losgesendet werden müssen)

    Die Daten liegen früher oder später unverschlüsselt im RAM, da wirst du auf keinem System und keiner Architektur 'drum herum kommen.

    Verkehr auf dem Loopback Device wird eigentlich nicht gesendet. Es handelt sich hierbei um Shared Memory, der vom Kernel verwaltet wird, auf ein und der selben Maschine. Irgendwann muss ein Datum unverschlüsselt im RAM liegen, um verarbeitet zu werden. Ob das nun in der Applikation selbst ist, oder im Shared Memory Space durch das Loopback Interface spielt hierbei keine Rolle. Du hast durch eine Kryptierung von Datenverkehr über ein Loopback Device keine Vorteile.


    Du holst dir eher noch den Supergau rein. Um nämlich verschlüsseln zu können, muss deine Applikation Zugriff auf einen privaten Schlüssel haben, der auch irgendwo im Dateisystem liegt. Lässt du aber nginx verschlüsseln, so muss die gesamte Maschine übernommen werden, um an den privaten Schlüssel zu kommen.


    Als Nutzer im Webhosting kannst du nämlich keinen Privilege Drop machen.

    Ich hoffe du erkennst, dass du hier Unfug erzählst.


    Solltest du dir aber wirklich so große Sorgen um Sicherheit machen, ist ein shared Webhosting allerdings nicht das Richtige für dich. Hier solltest du dich nach richtigen Servern umsehen.

    Quote from H6G

    Doch, das kannst du über die URL prüfen. Das Protokoll wird zwischen nginx und deiner App ausgetauscht.

    Ich hatte in meiner Applikation Abfragen drinnen, die getestet haben, ob die Verbindung sicher sind und ansonsten den Austausch von (gehashten)Passwörtern ablehnen. Ich musste diese Abfragen entfernen, da die Verbindung nicht sicher war. Oder verstehe ich das gerade falsch mit dem prüfen?

    Quote from H6G

    Guck einfach in die HTTP Header. Alles andere ist für Shared Webhosting Paranoia.

    Aus Interesse: wie hast du denn eine sichere Verbindung getestet?

    Hmm ich glaub da liegt mein Fehler: Ich habs über das Protokoll getestet und das ist ja jetzt logischerweise HTTP, da die Verbindung von Nginx zu mir ja nicht mehr verschlüsselt wird.

    Quote from astrogd

    Naja ich kann nicht gewährleisten dass zwischen Client und meiner Applikation die Daten verschlüsselt sind, weil sie unverschlüsselt bei mir ankommen (und auch unverschlüsselt losgesendet werden müssen)

    Das wird immer so sein, wenn du nicht selbst die SSL-Verbindung terminierst. Damit fängst du dir aber ganz viele andere Nachteile ein.


    Und es ist so üblich, dass SSL auf der Empfänger-Seite teilweise mehrfach ent- und verschlüsselt wird. Je nach dem welches Konstrukt man in größeren Umgebungen mit Loadbalancern, etc fährt.


    Quote from astrogd

    Hmm ich glaub da liegt mein Fehler: Ich habs über das Protokoll getestet und das ist ja jetzt logischerweise HTTP, da die Verbindung von Nginx zu mir ja nicht mehr verschlüsselt wird.


    Dann wende dich via Ticket an netcup. Die X-Header sind offenbar nicht richtig gesetzt.

    "Security is like an onion - the more you dig in the more you want to cry"