Das längste Thema

  • Es könnte natürlich sein, dass ich da etwas verwechsel und das doch mit einem aktuellen OpenSSL neu gelinkt gehört. :/


    Ich nehme an, OpenSSL 1.1.1 hast Du aus diesem Repo? Und Nginx, woher ist der?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich habe nochmals in den Logs nachgesehen: OpenSSL 1.1.1~~pre8-1 habe ich am 23.07.2018 testweise unter Buster aus Experimental installiert. Nach den ersten erfolgreichen Tests, nachzulesen hier, habe ich das am Ende des Tages wieder downgegraded. Zu diesem Zeitpunkt war Nginx 1.13.12-1 drauf, der laut Buildlogs mit OpenSSL 1.1.0h-2 gebaut/gelinkt wurde.

    Code
    Install: […] openssl:amd64 (1.1.0h-4, automatic) […]
    Install: […] nginx-full:amd64 (1.13.12-1) […]
    
    Upgrade: openssl:amd64 (1.1.0h-4, 1.1.1~~pre8-1), libssl1.1:amd64 (1.1.0h-4, 1.1.1~~pre8-1)

    Meinem Verständnis nach müsste es somit egal sein. Es kann aber auch sein, dass die Pakete aus den externen Repositories anders erstellt werden. Das weiß ich nicht.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Nginx hab ich aus

    deb http://nginx.org/packages/mainline/debian/ stretch nginx

    Das ist das Problem, die Version aus dem Repo von nginx.org wurde mit noch mit dem Paket openssl 1.1.0f kompiliert, daher keine TLS1.3 Unterstützung.

    Wenn du aber nginx mit TLS1.3 Unterstützung brauchst, dann nimm das Paket von deb.sury.org/nginx-mainline/. Diese Version wurde mit openssl 1.1.1 kompiliert.


    nginx Version aus dem nginx.org Repo:

    Code
    nginx version: nginx/1.15.7
    built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 
    built with OpenSSL 1.1.0f  25 May 2017 (running with OpenSSL 1.1.1  11 Sep 2018)

    nginx Version aus dem deb.sury.org/nginx-mainline/ :

    Code
    nginx version: nginx/1.15.6
    built with OpenSSL 1.1.1  11 Sep 2018 (running with OpenSSL 1.1.1a  20 Nov 2018)
  • joas: Das klingt absolut logisch, aber warum hat es dann im Juli bei mir mit einem Paket funktioniert, das auch "nur" mit OpenSSL 1.1.0h kompiliert wurde?


    Ich würde wirklich gerne verstehen, wo der Unterschied liegt… ?(

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Mit nginx aus dem stretch-backports Repo funktioniert TLS 1.3 auch.

    Tatsächlich funktioniert TLS 1.3 auch bei der Version aus dem stretch-backports, auch mit openssl 1.1.0f kompiliert.

    Das hat alles echt keinen Sinn, denn in der Dokumentation von nginx.org steht folgendes:

    Code
    Syntax:    ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];
    Default:   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    Context:   http, server
    Enables the specified protocols.
    
    The TLSv1.1 and TLSv1.2 parameters (1.1.13, 1.0.12) work only when OpenSSL 1.0.1 or higher is used.
    The TLSv1.3 parameter (1.13.0) works only when OpenSSL 1.1.1 built with TLSv1.3 support is used.
  • Ich als Privatanwender stecke einen Switch oder Router in die Steck- und LAN-Dose und das Teil "funktioniert einfach". Bei netcup gab es jetzt schon mehrere Störungen innerhalb der letzten Monate (27.11. / 15.09. / 05.09.). Auch bei Het***er gab es in den letzten Monaten mehrfach Berichte über größere Netzwerkprobleme. Die Frage (aus reiner Neugierde, ich möchte hier nicht meckern) ist: Bemerke ich diese Probleme im Privatgebrauch einfach nicht, oder gibt es im professionellen Umfeld mehr Sonderfälle, die auftreten können?


    BTW: Das Handling dieses Vorfalls seitens netcup finde ich bis jetzt echt gut, zeitnahe Updates die auch noch Informationen enthalten! :)

    Das mit den Sonderfällen ist zutreffend. Einerseits können wir glücklich sein, wenn unser Privatkundenswitch in seiner Lebensdauer wenigstens ein Softwareupdate erhält. Bei hochverfügbaren Switches, die in aller Regel einen Wartungsvertrag dabei haben werden, werden Fehler auch irgendwann beseitigt (wobei wir das kennen, ein behobener Fehler im hochkomplexen System ergibt irgendwo ein nicht nachvollziehbares Verhalten an anderer Stelle). Auch ist es nicht immer so, dass eine Implementierung ab Werk einen RFC voll erfüllt. Auch können sich RFCs teilweise widersprechen oder werden durch neuere RFC angepasst. Wenn wir jetzt an Core-Router und Switches denken, gibt es viel, was schief gehen kann. DDoS-Abwehr, eventuell auch da Speicherlecks in speziellen Situationen, ...

    Privatkundenprodukte werden mit einer Software ausgeliefert und den Stand behalten sie bei. Die Anzahl der Zugriffe, die sie verarbeiten müssen ist wesentlich geringer. Teilweise liefern Hersteller Privatkundengeräte oder SOHO-Geräte auch mit anderer Erwartungshaltung aus. Da hab ich kürzlich einen Switch gehabt, der vollmundig Spanning Tree Protocol in der Spec stehen hatte, aber eine fix eingestellte Bridge Priority hatte, damit man ihn ja nur nicht anders als als Desktop-Switch einsetzen kann... steht nirgendwo drinnen, macht aber irgendwann Probleme, wenn man im Abstellkammerl Provider spielen möchte ;)

  • Du wirst Störungen in Zukunft auch im privaten Bereich unmittelbarer bemerken als jetzt, wenn der komplette Telefontraffic auf IP umgestellt ist... ich sehe schon kommen, dass ich zuhause einen pfsense-cluster hinstelle mit DSL, Telefkom-LTE und Gigacube von Vodafone, damit ich jederzeit arbeiten kann. Ich bin an drei Telefonanlagen per voip angebunden plus mein privater Anschluß (der zum Glück noch über ISDN läuft).

    Also ich kann mit dem DSL Anschluss der Telekom berichten, dass dieser in zwei Jahren nur einen Ausfall hatte, der sich zum Glück in den frühen Morgenstunden befand. Achja, dieser Anschluss basiert bereits komplett auf IP.

  • der_webcode : Sind das gefühlte Ausfälle oder laut Monitoring?


    Ich höre immer wieder nur: Seit wir das Monitoring haben, haben wir dauernd Ausfälle und Störungen. Früher hat sich der Kunde nur tagsüber beschwert.... :D

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