Meine Experimente mit TLS 1.3

    • Offizieller Beitrag

    Hallo,

    1. Es wurde gesagt, es wäre nicht angeraten OpenSSL 1.1.1 zu nutzen. Als Mitleser würde ich nun unsicher sein, daher die Frage an dich, du hast keine Bedenken, würdest dazu raten bzw. wie siehst du das?

    Ich kann nur jedem davon abraten: OpenSSL 1.1.1 ist nicht offiziell veröffentlicht, damit auch noch nicht in den Distributionen. Das bedeutet, dass es keine Sicherheitsunterstützung in der sonst üblichen Form erfährt, man sich selbst um etwaige Aktualisierungen kümmern muss und potentiell andere Dinge dabei kaputt gehen (je nachdem wie genau libssl 1.1.1 jetzt genau installiert wird).

    2. Ich bin leider fachlich nicht so fit wie du dann wohl, sieh es mir bitte nach. Frage vom Laien: Die Verschlüsselung selber, die würdest du per se jedem Betreiber empfehlen, nur spezifischen Projekten oder...?

    Klares ja für Verschlüsselung. Auch für TLS 1.3 – das ist aber noch nicht fertig und dementsprechend ist ein Einsatz zum aktuellen Zeitpunkt verfrüht. Zumindest wenn man kein Unternehmen mit einem Team ist, was gegebenenfalls selbst Korrekturen vornehmen kann und sich 24 Stunden am Tag um Probleme kümmert (u.A. Google, CloudFlare).

    3. Es tut mir Leid, aber ich bin nicht in der Lage anhand der Screenshots etwaige Innovationen abzulesen. Könntest du bei Gelegenheit netterweise etwas einfacher und verkürzt festhalten, was genau du meinst, warum es innovativ ist und man es daher auf dem Bildschirm haben sollte?

    Ich könnte das ganze erklären, lasse das aber mal bewusst offen – vielleicht möchte Dukemaster seine Sicht erklären :)

  • Tim Düsterhus : Tim, ein Dankeschön dir wieder für die hilfreichen Hinweise, das schätzen sicher auch andere Mitleser. :thumbup:Ich möchte dich nicht ausnutzen und von etwas Wichtigem abhalten, aber würde das Angebot betreff weiterer Erklärungen/Diskussion auch ungern verfallen lassen. Machen wir es also so, wie du vorschlugst: Dukemaster kann sich äußern und man arbeitet sich dann am Thema weiter voran, später könntest du bei Gelegenheit noch ein paar Sätze verlieren?

    Ich rede jetzt nicht um den heißen Brei herum, sondern sage es direkt. Das Thema Sicherheit, Authentifizierung, Verschlüsselung usw. ist wichtig, aber vermutlich wird unser Otto Normalbetreiber nicht alles wissen, richtig einschätzen und umsetzen können. Ich gehe da auch von mir aus und denke, wir sind hier im Forum an der richtigen "Quelle", es gibt eben dann auch Leute wie dich, die sich mit dem Thema beschäftigt haben und klipp und klar sagen können, was "state of the art", was wichtig ist und ob es Empfehlungen gibt oder wir eben, wie Dukemaster erwähnte, damit leben müssen, dass 100% Sicherheit nur eine Phrase, eine schöne Idee ist.

    Von daher, wenn es dann zeitlich bei dir passt, schaust du hier wieder rein und dann könnte man das Thema noch etwas weiterspinnen? Falls möglich, hilfreiche Links, Nachschlagetipps usw. sind sowieso willkommen, dann könnten sich Interessierte einlesen, explizite Fragen formulieren und da hier ja doch Fachkundige im Thread sind, ist die Chance hoch, viel zu lernen und besser einzuschätzen. Heißt also: Ja, dein Input ist willkommen und wird definitiv nicht vergessen. :)


    ..........

    Und um noch was zum Thema zu sagen, ich empfehle nicht, den Tipp bezüglich der Aktivierung von TLS 1.3 in Firefox durchzuführen. Es hat Gründe, wieso die standardmäßige Aktivierung nun schon seit mehreren Versionen verschoben wird.


    Huhu und du als Mozilla-"Versteher" ;), kannst du diesen Punkt bei Gelegenheit bitte etwas näher beschreiben? Du rätst ab, verstanden, das hat aber welche Gründe, aus Interesse gefragt? Angenommen ich hätte deine Einschätzung nun aber nicht gehört, hätte es gemacht oder habe das vor, kann dann ein "worst case"-Szenario einsetzen, kann es üble Folgen haben oder in welcher Dimension sind wir?


    Wenn die Frage nicht zu persönlich ist, nutzt du als Fachler eigentlich sozusagen das normale Maß an Sicherheitsoptionen, noch etwas anderes, gar mehr und würdest auch explizit zu bestimmten Dingen raten? Du hast ja einige Projekte plus Kundenaufträge, das wird einen Unterschied machen, richtig oder falsch vermutet?

  • Zitat

    @Gabbid

    dass 100% Sicherheit nur eine Phrase, eine schöne Idee ist.

    Also das kann man schön reden wie man will aber es ist so schützen kann man sich nur in einem Gewissen Rahmen aber mehr auch nicht aber immerhin kann man sich damit dir Script Kiddies fernhalten.

    Es ist auch so das es immer hinter Türen gibt, die Entwickler des jeweiligen CMS kennen diese auch. So war es auch als ich damals bei einem CMS mit gewirkt habe.Ich kannte da meine Kniffe an jeweilige Daten ran zu kommen im Falle von Support ohne zig mal nach Sachen fragen zu müssen.

    Wer rein will kommt rein und wenn's eben mit dem Hammer ist sprichwörtlich gesprochen.

  • Huhu und du als Mozilla-"Versteher" ;) , kannst du diesen Punkt bei Gelegenheit bitte etwas näher beschreiben? Du rätst ab, verstanden, das hat aber welche Gründe, aus Interesse gefragt? Angenommen ich hätte deine Einschätzung nun aber nicht gehört, hätte es gemacht oder habe das vor, kann dann ein "worst case"-Szenario einsetzen, kann es üble Folgen haben oder in welcher Dimension sind wir?

    Firefox bietet zahlreiche Optionen an und über about:config vermutlich mehr als alle anderen Browser. Was nicht jeder versteht: diese Einstellungen sind nicht alle gleichwertig. Es gibt Einstellungen, die sind wirklich dafür da, dass der Nutzer Dinge nach seinem Geschmack konfigurieren kann. Es gibt aber auch Einstellungen, die existieren, damit die Entwickler von Firefox sowie die Tester-Community Dinge testen können, ohne Firefox dafür selbst kompilieren zu müssen, was sehr lange dauert und einiges an vorheriger Einrichtung benötigt. Dinge, die einfach noch nicht reif für den Produktivbetrieb sind und daher standardmäßig nicht aktiviert sind. Darum bin ich auch kein Freund davon, about:config in den Raum zu rufen, ohne ausdrücklichen Hinweis darauf, dass da nur spielen soll, wer ganz genau weiß, was er oder sie tut.

    Was konkret TLS 1.3 betrifft, ist in Firefox noch Draft 18 implementiert, während es schon Draft 20 gibt, Webseiten sprechen außerdem teilweise Draft 18 und teilweise Draft 20. Und Mozilla wartet mit der Implementierung von Draft 20 noch, bis große Seiten wie Facebook oder Cloudflare auf Draft 20 umgestellt haben.

    Das Problem, wenn Server- und Browserkonfiguration nicht zusammenpassen, ist, dass Webseiten unter Umständen gar nicht mehr laden. Gerade bei solchen Geschichten sollte man den Standard-Einstellungen des Browsers vertrauen.

    Wenn die Frage nicht zu persönlich ist, nutzt du als Fachler eigentlich sozusagen das normale Maß an Sicherheitsoptionen, noch etwas anderes, gar mehr und würdest auch explizit zu bestimmten Dingen raten? Du hast ja einige Projekte plus Kundenaufträge, das wird einen Unterschied machen, richtig oder falsch vermutet?

    Ich verwende meine Browser mit Standard-Einstellungen, weil Standard-Einstellungen deswegen Standard sind, weil sie für die ganz große Masse das beste sind. Um die serverseitige Konfiguration von Projekten, sowohl private als auch berufliche Projekte, kümmern sich andere, da mische ich mich gar nicht ein. Ich lege wert auf Aufgabenteilung, jeder sollte in seinem Kernkompetenzgebiet volle Leistung bringen statt alles ein bisschen zu machen. In meiner Arbeit ist es darum auch so, dass ich nur Programmierung mache, andere nur Design, wieder andere schreiben Texte, wieder andere machen Bilder und Videos, wieder andere machen Übersetzungen, wieder andere machen Social Media- und AdWords-Kampagnen, wieder andere machen Print-Sachen. Jeder ist ein Spezialist auf seinem Gebiet (wir sind eine Full-Service-Agency, wir machen alles). Nur Hosting ist ausgelagert. ;)

    5 Mal editiert, zuletzt von Cadeyrn (6. Oktober 2017 um 13:40)

  • Danke an alle interessierten Mitleser, Tim Düsterhus

    Ja, Tim, muss Dich leider enttäuschen, die OpenSSL geniest höchste Reputation und wird sehr wohl als sicher gewertet und von tausenden kompetenter Serveradministratoren genutzt. Testphase ist schon vorbei, das wissen die meisten leider nicht, weil sie nur negative Kritiken lesen.

    Das folgende ist nicht auf Dich bezogen, Tim.

    Zu jedem x-beliebigen Thema und nahezu jeder Installation gibt es zufriedene Nutzer und Kritiker. Jeder Serveradministrator und jeder Webapplikationsnutzer (Stichwort Woltlab) benutzt seiner ganz individuelle, einzigartige Konfiguration. Was sich bei dem/der einen durch Performance in Lichtgeschwindigkeit äußert, zerschlägt bei seinem Tischnachbarn die ganze vhost- oder Webseiten-Konfiguration.

    Man muss sich gut, nein sehr gut informieren. Ich für mein Teil tue es. Allein zu meiner DNS Konfiguration habe ich über 2 Monate jeden Tag Stunden recherchiert in mind. 5 Sprachen bevor ich überhaupt den ersten Test auf meinem Server vollzog.

    Dennoch kann jeder liebend gerne seine ganz individuelle persönliche Meinung zu allem haben.

    jedoch, wenn ich mir nur ansehe, lese was teilweise hier von einigen Plugin-Anbietern zum Besten gegeben wird, das ist bei weitem tatsächlich aufs Höchste sicherheitsbedenklich.

    Ihr wolltet nähere Informationen zur Installation und Sicherheit. Damit verweise ich auf den netten und kompetenten Serveradministrator Uwe *** DANKE *** dessen Anleitung ich genaustens befolgte, dessen Erfahrung ich genauso vertraue wie der des Woltlab Teams, auch Dir, lieber Tim.

    Eigentlicher Kern deiner Frage Tim Düsterhus - Es ist OpenSSL pur

    Part 5 aus der Haupt-Anleitung

    An alle Leser: Die folgenden Auszüge meiner Installation sind unique.

    Bitte nicht aufs Gratewohl ausführen, da z.B. der folgende Part, auch die anderen ohne die komplette Nginx-Kompilation absolut nutzlos sind. !!!

    Code
    cd /usr/share
    git clone https://github.com/openssl/openssl.git
    cd openssl
    git checkout tls1.3-draft-18
    
    ./config shared enable-tls1_3 --prefix=/usr/share/openssl --openssldir=/usr/share/openssl -Wl,-rpath,'$(LIBRPATH)'

    Der folgende Teil X war eigentlich unwichtig, denn zuerst wollte ich mit dieser OpenSSL-Version 1.1.0f nginx 1.13.5 kompilieren.

    So installierte ich eine neuere OpenSSL 1.1.0f als zuvor 1.0.2l

    Den folgenden Download explizit für mein Betriebssystems gewählt - Quelle/Ersteller ist hervorragend.

    https://launchpad.net/~ondrej/+archi…+build/12858809

    Code
    dpkg -l openssl
    Desired=Unknown/Install/Remove/Purge/Hold
    | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
    |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
    ||/ Name           Version      Architecture Description
    +++-==============-============-============-=================================
    ii  openssl        1.1.0f-2~ubu amd64        Secure Sockets Layer toolkit - cr
    root@server:~#


    Teil 2

    Installation und Kompilieren von NGINX 1.13.5 gegen OpenSSL 1.1.1-dev mit den folgenden für mich wichtigen Komponenten (brotli Kompression und Pagespeed), die in der letzten Box am Ende gesetzt wurden. Warum das alles: Weil das Modul Pagespeed auf Version 1.12.34.3-stable upgedatet wurde.

    Code
    --with-openssl-opt=enable-tls1_3 
    --add-module=/usr/share/nginx/modules/ngx_brotli 
    --add-module=/usr/share/nginx/modules/ngx_pagespeed-1.12.34.3-stable 
    --add-module=/usr/share/passenger/ngx_http_passenger_module 
    --add-module=/usr/share/nginx/modules/ngx_cache_purge-2.3 
    --add-module=/usr/share/nginx/modules/ngx_coolkit-0.2 
    --add-module=/usr/share/nginx/modules/ngx_slowfs_cache-1.10 
    --add-module=/usr/share/nginx/modules/ngx_headers-more-0.32

    Details:

    Code
     root@server:~# nginx -V
    nginx version: nginx/1.13.5
    built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
    built with OpenSSL 1.1.1-dev  xx XXX xxxx
    TLS SNI support enabled
    configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-debug --with-file-aio --with-google_perftools_module --with-mail --with-mail_ssl_module --with-threads --with-select_module --with-stream --with-stream_ssl_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module --with-http_ssl_module --with-http_v2_module --with-http_xslt_module --with-poll_module --with-openssl=/usr/share/openssl --with-openssl-opt=enable-tls1_3 --add-module=/usr/share/nginx/modules/ngx_brotli --add-module=/usr/share/nginx/modules/ngx_pagespeed-1.12.34.3-stable --add-module=/usr/share/passenger/ngx_http_passenger_module --add-module=/usr/share/nginx/modules/ngx_cache_purge-2.3 --add-module=/usr/share/nginx/modules/ngx_coolkit-0.2 --add-module=/usr/share/nginx/modules/ngx_slowfs_cache-1.10 --add-module=/usr/share/nginx/modules/ngx_headers-more-0.32

    Viele Grüße

  • Ja, Tim, muss Dich leider enttäuschen, die OpenSSL geniest höchste Reputation und wird sehr wohl als sicher gewertet und von tausenden kompetenter Serveradministratoren genutzt. Testphase ist schon vorbei, das wissen die meisten leider nicht, weil sie nur negative Kritiken lesen.

    Dir ist aber schon klar, dass es nicht um OpenSSL im allgemeinen geht sondern um die TLS 1.3 branches im speziellen ?

    Wenn du also sagst dass letzteres aus der Testphase raus wäre hätte ich gerne eine offizielle Quelle.

    Denn der von dir installierte Draft-18 ist zwar kompatibel mit FF und Co, jedoch keines wegs die aktuelle entwicklungsversion von OpenSSL, ist ja nicht mal kompatibel mit dem aktuellen Draft-20 (was sowohl tim, als auch Cadeyrn versuchten dir zu erklären).

    Im schlimmsten Fall hast du also, wenn FF und co auf einen höheren Draft geupdatet werden das Problem, dass einzelne Browser deine Seite nicht mehr aufrufen können.

  • Ja, weiss ich, Morik, gebe Dir absolut recht. Natürlich auch Tim und allen, die sagen man soll und muss vorsichtig sein. Aber es ist durch. Real sind die Entwickler schon bei der nächsten oder übernächsten Version. OpenSSL ist besonders anfällig und problematisch (backfalls).

    Habe dazu auch viel gelesen. Klar hab ich Bedenken und Zweifel wie jeder, doch irgendwann ist die Zeit reif was neues zu probieren.

  • Ist das hier jetzt eine Variation von "Theo gegen den Rest der Welt" oder eine moderne Variante von "Don QuiJote"?

    Seit fast einem Jahr frage ich mich bei gewissen Themen immer wieder, was nun eigentlich die Botschaft dahinter sein soll und kann nicht anders, als innerlich die Augen zu verdrehen.


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

  • Sorry, ich habe nach meinem vorletzten Beitrag gar nichts mehr gelesen und wollte es auch nicht.

    Die Wucht der Sinnlosigkeit und dem Bestreben alles Schlechtzureden begegne ich durch schlichte Ignoranz. Gebe zumindest in solchen Threads eine Inspiration, aber Zerreden das könne andere. Erst mit Tim und seiner Frage nach dem technischen Hintergrund, und auch Morik, dem will ich mich nicht entziehen.

    Denke ich habe es gestern und leider in der letzten Zeit 1001 mal erklärt, was auch jeder klar denkende Mensch weiss, hier mischt sich Spaß am Diskutieren mit Spaß am Kritisieren, und all dem Schmoder, der es gar nicht wert ist hier darzulegen. :/

    Gruß - Jetzt reichts auch für mich - Links zum Weiterinformieren sind ja da.

  • Die Wucht der Sinnlosigkeit und dem Bestreben alles Schlechtzureden begegne ich durch schlichte Ignoranz.

    Sorry, aber liest du eigentlich den Stuss, den du da von dir gibst?

    Hier antworten dir Mitglieder, die technisches Fachwissen haben und warnen(!) dich eindringlich davor, unstable Zeugs zu nutzen, welches du aus Jux und Dollerei mal eben, basierend auf einem Tutorial, zusammenkompiliert hast.

    Anschließend preist du das ganze hoch an, und sagst "Neuheit, Neuheit, muss man nutzen!", ohne dir auch nur einmal kurz Gedanken zu machen, was du da eigentlich kompiliert hast und produktiv(!) einsetzt.

    • Offizieller Beitrag

    Hallo,

    Ich möchte dich nicht ausnutzen und von etwas Wichtigem abhalten, aber würde das Angebot betreff weiterer Erklärungen/Diskussion auch ungern verfallen lassen.

    grundsätzlich erfolgt das ganze nicht komplett uneigennützig: Alle Probleme und Missverständnisse die man präventiv verhindern kann sorgen langfristig für weniger Stress bei mir. Ein Beispiel, welches nicht direkt mit diesem Thema zu tun hat: Ein gehackter Server verursacht mir insofern potentiell Ärger, als, dass der Spam bei mir ankommt. Genauso helfe ich, abseits von „WoltLab“, gerne bei der Einrichtung und Auswahl des neuen Computers: Wenn der Rechner direkt auf Basis meiner Hinweise eingerichtet wird, dann sorgt das langfristig für weniger Arbeit bei mir.

    Ja, Tim, muss Dich leider enttäuschen, die OpenSSL geniest höchste Reputation und wird sehr wohl als sicher gewertet und von tausenden kompetenter Serveradministratoren genutzt.

    Nach dem Heartbleed-Debakel würde ich nicht behaupten, dass OpenSSL „höchste Reputation“ genießt. OpenSSL war lange Zeit extrem „underfunded“, ist eine historisch gewachsene Codebasis, die viel zu viele Features enthält, die keiner verwendet und ist nicht der Standard, weil es besonders gut ist, sondern schlicht weil praktisch alle Programme aus historischen Gründen gegen libssl linken. Nicht ohne Grund gibt es den LibreSSL-Fork.

    lese was teilweise hier von einigen Plugin-Anbietern zum Besten gegeben wird, das ist bei weitem tatsächlich aufs Höchste sicherheitsbedenklich.

    Wenn dir Sicherheitslücken in einem Plugin bekannt sind, dann freue ich mich über eine Konversation mit Details, damit ich die Pluginentwickler darüber informieren kann.

    git checkout tls1.3-draft-18

    Dieser branch ist über 1000 Commits hinter dem master. Da fehlen potentiell sicherheitsrelevante Bugfixes: Wie ich sagte, die Dev-Versionen erhalten keine reguläre Sicherheitsunterstützung.

  • Andrea Berg 7. Oktober 2017 um 11:58

    Hat den Titel des Themas von „Woltlab Suite 3 mit TLS 1.3“ zu „Meine Experimente mit TLS 1.3“ geändert.
  • Uff, viel Input und ich mache gerade doch drei Kreuze, dass nicht ich administrieren muss, sondern das "Bodenpersonal" bin. :whistling:^^

    Ich versuche jetzt gar nicht chronologisch vorzugehen, seht es mir alle bitte nach, sondern ich muss erst einiges nachschlagen, mir Sachen erklären lassen und daher komme ich einfach im Laufe der Unterhaltung auf Punkte zurück. Aber, ich bleibe am Ball, bin motiviert und ihr wiederum lauft mal nicht ganz so schnell wieder weg, bleibt in der Nähe. ;)

    Dukemaster: Du bleibst doch auch, also bitte, alles ist gut, keiner will dir an den Kragen, dich in eine Ecke drängen oder andeuten, du wärst nicht kompetent. Falsch, du musst bleiben und ja, es ist mitunter hart, wenn man denkt, man argumentiere, es kommen aber Gegenargumente und keiner sekundiert sozusagen.

    Wenn wir einmal Zeit haben, kann ich dir aber im Gegenzug auch eine nette Geschichte erzählen und wie ich gegen eine halbe Community bzw. bestimmte Administratoren die Stellung gehalten habe. Verkürzt gesagt, ein Vorschlag von mir wurde bewusst missinterpretiert, persönlicher Ärger suchte ein Ventil und da ich keiner Diskussion aus dem Weg gehe, stand ich da eben. Ich hätte es mir einfach machen und sagen können, ich wäre Moderatorin, also Schluss, Thema schließen und sollen es die Administratoren "richten". Das wäre aber armselig und würden nur eins zeigen, ich bin moderativ nicht fähig, mache es falsch und drohe rein über den Rang. Also, nein, da musste ich also durch und es waren haarige Wochen, kann ich dir so sagen. Das Ende des Liedes war, dass man - natürlich - wieder Verstand einziehen lassen kann, Leute nicht per se bashen, weniger intelligent sind oder mich persönlich attackieren möchten. Die Diskussion wurde weiter hitzig geführt, aber mit Argumenten, also denke ich heute, das war es wert.

    Keiner zwingt dir etwas auf, keiner streitet ab, dass du abschätzen kannst, was du tust oder nicht, aber bitte, nimm es nicht persönlich, sondern bleib hier, schau dir die Argumente an und könntest du sie dann versuchen aus deiner Sicht zu entkräften, deine Erfahrungen einfließen zu lassen bzw. dieser oft zitierte Uwe von der Plesk-Seite, er ist auch in Sachen WBB/Suite versiert und überprüft alles im Kontext von eben dieser Community Software oder...?

    Also, wir gehen uns jetzt nicht wie die Kesselflicker an, gehen hier nicht mit einem hohen Blutdruck raus, sondern selbstverständlich äußerst du stets deine Gedanken, Neuerungsvorschläge, Input und selbst wenn 1001 Gegenargumente kommen, du wankst nun nicht, wirst nicht wütend oder hasst uns, sondern wir müssen hier vernünftig alle Seiten ausloten. Die Mitleser, Interessierten und gerade die Neulinge brauchen solche fachlichen Diskurse, um nicht ggf. Fehler zu machen, falsche Entscheidungen zu treffen oder mit einem Fragezeichen im Gesicht von dannen zu ziehen. Ohne Diskussion können wir das Community Forum gleich schließen, wozu haben wir es dann, warum sind wir hier? Richtig, es lebt doch per se von Interaktion und somit auch deinem Beitrag. :):thumbup:


    Also das kann man schön reden wie man will aber es ist so schützen kann man sich nur in einem Gewissen Rahmen aber mehr auch nicht aber immerhin kann man sich damit dir Script Kiddies fernhalten.


    Es ist auch so das es immer hinter Türen gibt, die Entwickler des jeweiligen CMS kennen diese auch. So war es auch als ich damals bei einem CMS mit gewirkt habe.Ich kannte da meine Kniffe an jeweilige Daten ran zu kommen im Falle von Support ohne zig mal nach Sachen fragen zu müssen.

    Wer rein will kommt rein und wenn's eben mit dem Hammer ist sprichwörtlich gesprochen.

    Da du das erlebt hast, nutze ich es direkt aus und kann ich dich dazu ein wenig befragen? :) Folgendes frage ich mich:

    1. Wenn ich es richtig in Erinnerung habe (?), war "Heartbleed" in der Ausgangssituation einem Programmierfehler geschuldet, richtig? Vereinfacht gesagt: Programmierer programmiert, hat irgendwo einen Fehler, etwas nicht bedacht, aus Versehen gelöscht oder x und das wird dann von z.B. einem Hacker ausgenutzt. Als Laie denke ich, der Programmierer hat es nicht absichtlich gemacht, es war menschliches Versagen und ja, hatte gravierende Folgen, nur zugleich hat dann eben jemand gezielt gesucht, es ausgenutzt.

    Frage: Es ist fachlich dann trotzdem so, der Programmierer ist schuld, er hat eine Lücke nicht entdeckt, muss es aber - egal wie unmöglich es in der Praxis auch ist (?) - bedenken können? Das ist doch utopisch, also auch wenn ich, sagen wir, 50 Programmierer an dann eben das CMS - dein Beispiel - lasse, wer sagt mir, sie können je alle möglichen Schwachstellen auftun und sie schließen - vorab?


    2. Bleiben wir bei deinem Beispiel. Wenn du weißt, es gibt "Hintertürchen", egal wie komplex, klein oder groß, realistisch oder unrealistisch sie in der Ausnutzung sind, musst du das trotzdem fixen, es den Anwendern sagen und Sicherheitsmaßnahmen implementieren oder nicht, erst , so hart es klingt, wenn etwas passiert, sich jemand meldet...? Ich weiß nicht, also wo genau (?) verläuft die Linie zwischen optional, fahrlässig und grob fahrlässig, woher weißt du als Entwickler, wann du ggf. wirklich grob fahrlässig handeln würdest, wir haben keinen juristischen, technischen Leitfaden, oder?


    3. Gib mir bitte keine zu dramatischen Beispiele, sonst laufe ich hier demnächst semi-paranoid herum ;), aber allgemein gefragt, wenn z.B. du mein Projekt angreifen/kompromittieren wolltest (ich besitze keines, also fiktives Beispiel), was könntest du bei "worst case"-Szenerien tun? Das und noch mehr?

    - Forum zerhacken/löschen u.ä.

    - Nutzerdaten herauslesen/löschen u.ä.

    - Schadcode einbinden und ich merke das ggf. als Betreiber nicht/zu spät

    - Kannst du theoretisch die ganze Seite übernehmen und ich könnte nichts mehr tun/sichern?


    4. Du sagst, 100%iger Schutz ist Wunschdenken, wir können uns also nur in einem "gewissen Rahmen" schützen. Deiner Erfahrung nach, nehmen Probleme, Attacken usw. auf Foren/Projekte zu, weniger und kannst du grob sagen, ob Administratoren zumindest das tun, was nötig ist, oder sind sie tendenziell nachlässig/er? Ich lese schon ab und an von Angriffen, Bots usw., aber ich habe kein Gefühl dafür, wie gering/massiv das ist und ob die Mehrheit der Betreiber gut geschützt sind oder nicht. :/


    Tim Düsterhus : Du hast die Anfälligkeit bzw. Problematik von OpenSSL angesprochen, hast du dich in dem Zusammenhang zufällig auch mit anderen Angeboten befasst bzw. du kannst fachlich abschätzen, was gut, weniger gut bis riskant wäre? Ok, das ist eigentlich fast schon eine rhetorische Frage ;), du konntest bislang immer alles beantworten, also wage ich jetzt einmal die These, du hast (d)eine Haltung hierzu? Wenn ja, hast du Zeit und Lust etwas zu den nun folgenden Angeboten zu sagen (gut, problematisch, Hände weg...)?

    https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS

    https://www.insidesecure.com/Products/Data-…ts/GUARD-TLS-TK

    https://boringssl.googlesource.com/boringssl/


    Weil du ja nicht nur entwickelst, sondern auch administrierst und vermutlich mehr als einmal von einem unsicheren Neuling dazu befragst wurdest, könntest du spontan sagen, ob es "die" typischen Sicherheitsfehler gibt, die vielleicht eben besagte WBB/Suite-Neulinge machen, was sie gerne vergessen, falsch einschätzen und was schieflaufen kann? Datensicherung/Backups sind eine Sache, was geht sonst schief, wird unterschätzt bzw. wo hapert es aus deiner Sicht oft?

    Wenn du laut denken solltest, was meinst du, wird die zukünftige Authentifizierung (2-Wege-Authentifizierung) in der gegenwärtigen Form ausreichen oder was ist der nächste Schritt, wenn wir im Bereich Plattform, Online-Shop usw. bleiben?


    jedoch, wenn ich mir nur ansehe, lese was teilweise hier von einigen Plugin-Anbietern zum Besten gegeben wird, das ist bei weitem tatsächlich aufs Höchste sicherheitsbedenklich.

    Oha, das klingt nicht gut, du sprichst von realen Fehlern in Sachen Sicherheit bei konkreten Produkten und/oder dass einzelne Entwickler eine zu lockere Haltung zu dem Thema haben, aus deiner Sicht? So oder so, das wäre natürlich fatal bzw. die Frage ist, ob die entsprechenden Entwickler das wissen, du hast mit ihnen gesprochen, sie wissen von deinen Einschätzungen?

    Wir betreiben keine "Kollegenschelte" bzw. keiner wird angeprangert, aber kannst du bei Gelegenheit notieren, was für bedenkliche Dinge du bemerkst hast, also hast du etwas im Code gefunden, bei der realen Umsetzung oder...? Ich frage, weil ich so etwas nicht entdecken würde, aber man auch als Anwender wissen sollte (?), worauf man achten kann, wenn sich die Möglichkeit bietet.


    Dann noch ein Schwenk zu einer anderen Sache. Chris, also der Entwickler der WSC-App, hatte doch sein WSC-Connect vorgestellt, ihr erinnert euch sicher? Er war so freundlich und sagte, ich dürfe ruhig auch einen Blick riskieren, kommentieren und das tun, was ich sonst tue, also kritteln, am Text mäkeln usw. ;) Fachlich ist klar, er weiß was er tut und wird alles bedacht haben, ich will also weder etwas Gegenteiliges andeuten, noch bin ich in der Lage es entwicklungstechnisch genau abzuklopfen, aber ihr alle vermutlich schon, nicht wahr?

    In den FAQ steht ja, was gespeichert wird, was nicht, aber wegen unserer Diskussion hier frage ich mich nun, wie steht es um SSL bzw. muss man das als Punkt nicht explizit erwähnen, gar overt sichtbar machen (Stichwort Cookie-Hinweis und Datenschutzerklärung...) oder denke ich jetzt falsch? Um ehrlich zu sein, ich habe vorher nicht darüber nachgedacht und weiß nun nicht, ob ich ihn hätte darauf ansprechen sollen bzw. ob man das als Punkt im Kontext mit der App diskutieren muss...:/ (In dem Fall kann man es ihm noch sagen oder ihn sogar in die Runde einladen).

    Die gemachten Angaben usw. laufen dann über den WSC-App-Server, ja oder nein? Ich denke Ja, wenn das nicht falsch ist, kann der Server dann auch alle zukünftigen App-Ergänzungen von mir "einsehen", also Konversationsansicht u.ä. Das wäre in meinem Fall kein Drama, aber es geht nicht um mich als Einzelperson, sondern abstrakter darum, was der Server dann sehen/abgreifen könnte und was nicht, grob so richtig formuliert? Falls auch noch richtig gedacht/formuliert, könnte das ein Problem sein, man müsste das beschränken, darf es gar nicht oder muss ich die Nutzer vorab darüber in Kenntnis setzen, was genau der Server "tut" und ob sie das möchten bzw. nicht?

    Sorry, das klingt für eure Ohren sicher schlimm formuliert, aber besser geht es gerade nicht, ich bin einfach kein "Server"-Versteher. X/


    Andrea Berg : Huhu du und Dankeschön für das Verschieben des Threads! :) Das hätte uns selber einfallen können/müssen, aber du hast es sicher gesehen, wir waren gefühlt im Diskussionsrausch und da achtet man nicht mehr darauf, wo man antwortet, man will nur antworten. ^^ Für den Fall, dass das wieder passiert, sage ich lieber gleich einmal, drücke dann netterweise beide Augen zu, verschiebe, seufze nur innerlich und denke dir "Ach, die Kleinen...". ;)^^

    • Offizieller Beitrag

    Hallo,

    1. Wenn ich es richtig in Erinnerung habe (?), war "Heartbleed" in der Ausgangssituation einem Programmierfehler geschuldet, richtig? Vereinfacht gesagt: Programmierer programmiert, hat irgendwo einen Fehler, etwas nicht bedacht, aus Versehen gelöscht oder x und das wird dann von z.B. einem Hacker ausgenutzt

    Korrekt. Der xkcd zum Thema erklärt es meiner Ansicht nach sehr gut für Laien:

    https://xkcd.com/1354/

    Als Laie denke ich, der Programmierer hat es nicht absichtlich gemacht, es war menschliches Versagen und ja, hatte gravierende Folgen, nur zugleich hat dann eben jemand gezielt gesucht, es ausgenutzt.

    Direkt nach dem Debakel war der Aluhut einiger Menschen am glühen, da die Person, die den Programmierfehler gemacht hat bei T-Systems angestellt war und das ganze als Unternehmen mit staatlichem Einfluss ein Interesse an der Sicherheitslücke gehabt haben könnte.

    Vergleiche dieser Artikel:

    http://www.smh.com.au/it-pro/securit…0410-zqta1.html

    Frage: Es ist fachlich dann trotzdem so, der Programmierer ist schuld, er hat eine Lücke nicht entdeckt, muss es aber - egal wie unmöglich es in der Praxis auch ist (?) - bedenken können? Das ist doch utopisch, also auch wenn ich, sagen wir, 50 Programmierer an dann eben das CMS - dein Beispiel - lasse, wer sagt mir, sie können je alle möglichen Schwachstellen auftun und sie schließen - vorab?

    Die Sicherheitslücke war ein typischer Memory-Safety-Fehler in der Programmiersprache C (Buffer Overrun). Das ist der typische Programmierfehler, wenn man C verwendet. Die Konsequenzen davon betreffen die komplette Bandbreite an Schlimmheit: Nichts passiert bis Remote Code Execution. Das ist beispielsweise auch der Grund, warum Mozilla die Programmiersprache Rust für den Einsatz im Firefox entwickelt.

    Wenn du weißt, es gibt "Hintertürchen", egal wie komplex, klein oder groß, realistisch oder unrealistisch sie in der Ausnutzung sind, musst du das trotzdem fixen, es den Anwendern sagen und Sicherheitsmaßnahmen implementieren oder nicht, erst , so hart es klingt, wenn etwas passiert, sich jemand meldet...?

    Jegliche Art von Sicherheitslücken gehört sofort korrigiert. Wenn du den Fehler findest, dann kannst du dir sicher sein, dass jemand anders ihn ebenfalls schon gefunden hat. Spätestens, sobald die Korrektur zur Verfügung steht ist der Fehler den „bösen Jungs“ bekannt. Ein Beispiel aus der letzten Zeit ist Shellshock, es hat keine 12 Stunden nach Veröffentlichung der Korrekturen gedauert, bis die Lücke vollautomatisiert ausgenutzt wurde. Mein Server war durch die Konfiguration ohnehin nicht von der Lücke betroffen – ich hatte die Updates aber bereits 30 Minuten nach Veröffentlichung eingespielt. Ich kann nur empfehlen die Debian Security Announces bzw. Ubuntu Security Notices zu abonnieren.

    Nicht umsonst habe ich hier schon mehrfach erwähnt, dass Pluginentwickler eine vorgezogene Prüfung bekommen, wenn sie schwerwiegende Probleme in einem Update korrigiert haben.

    3. Gib mir bitte keine zu dramatischen Beispiele, sonst laufe ich hier demnächst semi-paranoid herum ;) , aber allgemein gefragt, wenn z.B. du mein Projekt angreifen/kompromittieren wolltest (ich besitze keines, also fiktives Beispiel), was könntest du bei "worst case"-Szenerien tun? Das und noch mehr?

    Die Königsklasse der Sicherheitslücken ist die Remote Code Execution (ggf. combiniert mit einer Privilege Escalation-Lücke im Kernel): Ausführung von beliebigen Programmcode. Sobald du beliebigen Code ausführen kannst, kannst du alles machen.

    Wenn ja, hast du Zeit und Lust etwas zu den nun folgenden Angeboten zu sagen (gut, problematisch, Hände weg...)?

    NSS ist für den Einsatzzweck in Serversoftware regelmäßig unbrauchbar, weil die Software nicht gegen NSS gelinkt werden kann. Das zweite kenne ich nicht. Google rät explizit davon ab BoringSSL einzusetzen, wenn man nicht Google ist.

    Neben OpenSSL ist GnuTLS meines Wissens noch relativ verbreitet. Und dann halt der LibreSSL-Fork von OpenBSD.

    Weil du ja nicht nur entwickelst, sondern auch administrierst und vermutlich mehr als einmal von einem unsicheren Neuling dazu befragst wurdest, könntest du spontan sagen, ob es "die" typischen Sicherheitsfehler gibt, die vielleicht eben besagte WBB/Suite-Neulinge machen, was sie gerne vergessen, falsch einschätzen und was schieflaufen kann? Datensicherung/Backups sind eine Sache, was geht sonst schief, wird unterschätzt bzw. wo hapert es aus deiner Sicht oft?

    Viel schlimmer sind schlechte Passwörter. Fehlende Backups sorgen für Tränen beim Betreiber, schlechte Passwörter sorgen für Tränen beim Betreiber und Tränen bei jedem anderen.

    Wenn du laut denken solltest, was meinst du, wird die zukünftige Authentifizierung (2-Wege-Authentifizierung) in der gegenwärtigen Form ausreichen oder was ist der nächste Schritt, wenn wir im Bereich Plattform, Online-Shop usw. bleiben?

    Wir sind ja noch nicht einmal an dem Punkt, dass 2-Faktor-Authentifizierung (ja, mein Plugin ist schlecht benannt …) flächendeckend eingesetzt wird.

    Fachlich ist klar, er weiß was er tut und wird alles bedacht haben, ich will also weder etwas Gegenteiliges andeuten, noch bin ich in der Lage es entwicklungstechnisch genau abzuklopfen, aber ihr alle vermutlich schon, nicht wahr?

    Das Plugin enthielt bereits Sicherheitslücken (

    https://github.com/ChristopherWal…df1c58b63715464), die nach Anmerkung durch den Prüfer allerdings zeitnah korrigiert wurden.

    Die gemachten Angaben usw. laufen dann über den WSC-App-Server, ja oder nein?

    Aus technischen Gründen müssen mindestens die Benachrichtigungen an den Server von Christopher Walz gesendet werden, da nur dieser die API-Keys für den Google-Pushdienst besitzt.

  • Tim Düsterhus Danke fürs beantworten meiner Fragen besser hätte ich es nicht machen können:):D

    Nur zu Punkt 4 würde ich noch was Hinzufügen wollen.

    Nicht die Angriffe und Sicherheits Lücken nehmen zu sondern eher krass ausgedrückt die Dummen User bzw möchte gern Administratoren die mit ihren Server Quasie zum Tag der offenen Tür einladen. Dadurch gibt es dann natürlich im Umkehrschluss mehr Botnetze,Spam Server uvm. Und diese Leute sind meines Erachtens das größte Sicherheitsrisiko den durch ihrer Unwissenheit und ignoranten Verhalten gefährden sie nicht nur sich sondern auch andere unschuldige User.

  • Oh, ein Comic! :love: Ähem ja, da kommt das "Spielkind" durch und es betrifft nicht alle Bereiche, aber ich finde Grafiken, Comics usw. im Kontext von IT super, da freut man sich als Newbie und findet es nicht mehr soooo kompliziert. :whistling:^^

    Off-Topic: Nett ist auch, der Autor hat eine literarische Anspielung eingebaut, also die Anfrage von Meg ist doch eine Allusion an den Roman von Judy Blume? Im Roman stellt Margaret die bekannte, repetitive Frage "Bist du da, Gott?", im Comic ist es der vermeintlich allwissende "Gott" Server, der dann aber die Anfrage mit der Zahlenmenge nicht in Einklang bringen kann.

    Im Comic "antwortet" der Server stets mit "User Meg", das dürfte dann nicht willkürlich sein, sondern das eben jeder Nutzer die Lücke ausnutzen könnte?


    Mir fehlt kriminelle Energie bzw. ich besitze kein Naturell, dass ich Leuten schaden, etwas ausnutzen oder sozusagen "einfach so" zerstören möchte. Aus dem Grund kann ich bei Diskussionen rund um Hacker, Cracker und wie sie da alle heißen nur bedingt "nachvollziehen", was die Leute antreibt. Daher muss ich jetzt tatsächlich eine triviale Fragen stellen, hierzu:

    Wenn du den Fehler findest, dann kannst du dir sicher sein, dass jemand anders ihn ebenfalls schon gefunden hat. Spätestens, sobald die Korrektur zur Verfügung steht ist der Fehler den „bösen Jungs“ bekannt.

    Es ist davon auszugehen, dass Leute theoretisch (und praktisch) ihre Zeit damit verbringen gezielt nur etwaige Sicherheitslücken zu finden, sie suchen auch Fehlermeldungen ab, würden bei Github&Co. mitlesen, um daraus Schadenspotenzial abzuleiten und vorzunehmen, tatsächlich so? :huh:

    Schon die Vorstellung ist verstörend, aber wenn es so ist und wir bei den "normalen" WBB-Projekten bleiben, dann würde ein Hacker/Cracker tendenziell was wollen, an Daten herankommen, die Seite lahmlegen oder...? Mir fehlt die Fantasie so ein Szenario durchzuspielen, also ok, ich könnte dann Daten haben/entwenden und wenn ich versiert bin, könnte ich mit den Daten Schindluder betreiben, aber wenn ich eine Plattform crashe, sonst etwas damit tue, wo genau liegt da die "Befriedigung", also was bringt es, ist das nur ein "Weil ich es kann", kindliche Zerstörwut oder...?


    Tim, nur so weit du es sagen kannst/darfst, aber grundsätzlich, das Vier-Augen-Prinzip bzw. Mehr-Augen-Prinzip, das gilt auch bei dir auf der Seite und wenn man Marcel und Alexander hier fragen, sie zumindest nicken würden, dann auch eben bei WoltLab? Soll heißen, egal was ihr hier tut, das kontrollieren stets mehrere Leute, es gibt eine Art festen Ablauf und weil ihr die Programmiersprachen kennt, daher auch Fehler in diesen, könnt ihr vorab diese Fehlerquellen ausmerzen, ihr könnt auch hypothetische Probleme simulieren und daher direkt die Hintertüren schließen - selbst wenn noch keiner an solche Hintertüren dachte?


    Ich will wirklich nicht paranoid klingen, aber wenn wir sagen, das jeweilige Projekt ist gesichert, die Software ist auf dem aktuellen Stand, ich sichere regelmäßig usw., reicht das wirklich? Anders gefragt, ist es (un-)realistisch und (un-)nötig, dass ich als Betreiber selber testen sollte, ob und welche Schwachstellen meine Plattform hat, sollte ich so weit gehen und dann wirklich testen, ob meine Seite gegen bestimmte Angriffe gesichert ist oder nicht? Die Frage erscheint sicher merkwürdig, aber nachdem ich jetzt auch Fightcrashers Antwort gelesen habe, frage ich doch.


    Nach dem Lesen deiner Antwort habe ich mir Details angesehen (Heise) und ich wusste noch, dass Teralios die "Codebibel" verfasst hat und MysteryCode erklärt Begrifflichkeiten, Updateserver-Verfahren usw. Nun kommt aber meine Frage: Wie genau wird ein kritischer Fehler definiert und warum wird das als Parameter nicht mehr mit WSC ausgelesen? Ich frage, weil ersteres nicht mehr von Teralios beschrieben wurde, letzteres habe ich bei MysteryCode im Tutorial gelesen, ich zitiere ihn kurz wörtlich bzw. den Absatz:

    critical

    Dieses Attribut legt fest, ob diese Version kritische Fehler behebt und wird in der Regel bei Patchlevel-Updates verwendet.


    Mögliche Werte: 0 (falsch), 1 (wahr)


    Dieses Attribut ist nur für WCF 1.1 und kleiner relevant, es wird seit Version 2.0 nicht mehr ausgewertet.


    Wir sind ja noch nicht einmal an dem Punkt, dass 2-Faktor-Authentifizierung (ja, mein Plugin ist schlecht benannt …) flächendeckend eingesetzt wird.

    Das liegt noch an den Betreibern selber bzw. müssen wir da an die Suite dran, also von der Reihenfolge her müssen wir zuerst die Endanwendung/en selber standardmäßig so bestücken oder geht es nicht, noch nicht bzw. egal was wir anbieten, wir können trotzdem nicht 100%ig sicherstellen, dass z.B. nicht zwei Personen einen Account nutzen und daher "großzügiger" mit den Daten sind?


    Aus technischen Gründen müssen mindestens die Benachrichtigungen an den Server von Christopher Walz gesendet werden, da nur dieser die API-Keys für den Google-Pushdienst besitzt.


    Verstanden, Tim, aber nun muss ich wegen deinem einschränkenden "mindestens" nachfragen. Es ist wichtig, also wenn es eventuell ein Problem gäbe, etwas nicht überdacht wurde, muss man es Chris sagen, daher frage ich einfach nur um sicherzugehen.

    Du hast die dir App angesehen, sie getestet und kannst du aufgrund dessen "herauslesen", was ggf. noch über den Server geht, also laienhaft gefragt, wie würde ich das ohne entsprechenden Vorabhinweis seitens des Entwicklers herausfinden/herauslesen?

    Hoffentlich bin ich durch den "Heise"-Artikel nicht schon durcheinander, aber eine hypothetische Frage: Angenommen ich käme in den Besitz von UserIDs und dann hätte ich die API der App, dann könnte das ein böses Erwachen geben? Ich sehe bei GitHub also den Aufbau und wir gehen davon aus, dass dann bei UserID die meine stünde, ich alles korrekt nutze. Nun, warum auch immer, hätte ich deine UserID, Tim, dann noch die von Fightcrasher und wenn ich diese eingebe, würde ich dann nicht eigentlich sehen können, welche Konversationen ihr erhalten habt, welche Benachrichtigungen usw.? :/

    Natürlich muss da das allgemeine, universelle UserID-Feld sein, aber eben weil es allgemein gehalten ist, kann es ausgenutzt werden...? Ich bin jetzt etwas verwirrt, also stoppe ich, sonst kommt eine ganz krude gedankliche Herleitung und du bekommst Schnappatmung. ^^*

    * Nachtrag:

    Diesen Abschnitt ignorieren, Chris war/ist da und hat es korrigiert! Also, alles gut, kein mögliches Problem :thumbup:und Chris, wenn du das liest, ich hatte mir die Seite zwecks der Konversationszeile aufgehoben (Z.156). Dass man es als Anwender wird zur Verfügung haben, es kommen wird. Gut, dass du aber selber hier bist und es präzierst hast, dann weiß jeder Bescheid :) und ich sollte nicht zu viel bei "Heise" lesen, sonst komme ich immer auf seltsame Gedanken. :rolleyes:


    Nicht die Angriffe und Sicherheits Lücken nehmen zu sondern eher krass ausgedrückt die Dummen User bzw möchte gern Administratoren die mit ihren Server Quasie zum Tag der offenen Tür einladen. Dadurch gibt es dann natürlich im Umkehrschluss mehr Botnetze,Spam Server uvm. Und diese Leute sind meines Erachtens das größte Sicherheitsrisiko den durch ihrer Unwissenheit und ignoranten Verhalten gefährden sie nicht nur sich sondern auch andere unschuldige User

    Oh oh, das klingt gar nicht gut, harte Worte, aber ich möchte das nicht so stehenlassen. Die Serverprobleme, fehlerhaften Einstellungen usw., kannst du mir das vielleicht kurz beschreiben, was läuft z.B. schief?

    Ich lese oft mit, wenn Administratoren nachfragen, ob sie zu einem Webhoster gehen oder sich einen eigenen Server zulegen sollten. Je nach Angebot heißt das bei Leuten, sie versuchen sich selber an Server-Management. Es steht außer Frage, dass ich das wagen würde, aber so unter uns hier, ab welchem Niveau sollte man sich an einen eigenen Server heranwagen, was sollte man an Wissen, Erfahrung und auch Lernwillen mitbringen, hast du dazu eine Meinung und Erfahrung/en?


    Schreit und knufft mich, wenn ihr eine Pause braucht, ich euch ein Ohr abkaue bzw. ihr schon unterzuckert vor dem Rechner sitzt, ok? Dann drossle ich zumindest die Fragen- und Themensalve, ich verspreche es. ^^

    Einmal editiert, zuletzt von Gabbid (9. Oktober 2017 um 14:37)

  • Ich sehe bei GitHub also den Aufbau und wir gehen davon aus, dass dann bei UserID die meine stünde, ich alles korrekt nutze. Nun, warum auch immer, hätte ich deine UserID, Tim, dann noch die von Fightcrasher und wenn ich diese eingebe, würde ich dann nicht eigentlich sehen können, welche Konversationen ihr erhalten habt, welche Benachrichtigungen usw.? :/

    Du hast, wieso auch immer, einen veralteten Code verlinkt. Den neuen findest du hier: https://github.com/ChristopherWal….class.php#L303

    Anmerkung: Es war und wird natürlich nie möglich sein (weder mit dem von dir oder von mir verlinkten Code) Benachrichtigungen oder Konversationen von anderen Nutzern abzufragen.

    • Offizieller Beitrag

    Hallo,

    Off-Topic: Nett ist auch, der Autor hat eine literarische Anspielung eingebaut, also die Anfrage von Meg ist doch eine Allusion an den Roman von Judy Blume?

    das kann ich dir nicht sagen. Was ich dir sagen kann, dass das Feature, welches diese Sicherheitslücke hatte tatsächlich für ein „Bist du da“ zuständig war. Konkret war das die Heartbeat-Extension für TLS (daher auch der Name Heartbleed). Dort konnte ein Client eine Anfrage an den Server stellen, die aus drei Teilen besteht:

    • Die Art der Anfrage („Bist du noch da“)?
    • Ein beliebiger Text, den der Server zurück senden muss
    • Die Länge dieses Textes, damit der Server weiß wann die Daten vollständig angekommen sind.

    Die Problematik war nun, dass der Server die Länge nicht auf Plausibilität überprüft hat.

    Im Comic "antwortet" der Server stets mit "User Meg", das dürfte dann nicht willkürlich sein, sondern das eben jeder Nutzer die Lücke ausnutzen könnte?

    Die Lücke kann von jedem der zum Server verbinden kann, ohne Authentifizierung ausgenutzt werden.

    Es ist davon auszugehen, dass Leute theoretisch (und praktisch) ihre Zeit damit verbringen gezielt nur etwaige Sicherheitslücken zu finden, sie suchen auch Fehlermeldungen ab, würden bei Github&Co. mitlesen, um daraus Schadenspotenzial abzuleiten und vorzunehmen, tatsächlich so? :huh:

    Ja.

    Schon die Vorstellung ist verstörend, aber wenn es so ist und wir bei den "normalen" WBB-Projekten bleiben, dann würde ein Hacker/Cracker tendenziell was wollen, an Daten herankommen, die Seite lahmlegen oder...?

    Geld verdienen. Das kann geschehen, indem über die Seite weitere Schadsoftware verteilt wird oder aber Spam verschickt wird.

    aber wenn ich eine Plattform crashe, sonst etwas damit tue, wo genau liegt da die "Befriedigung", also was bringt es, ist das nur ein "Weil ich es kann", kindliche Zerstörwut oder...?

    Kindliche Zerstörwut. Die Leute die die Seiten „zerstören“ werden daher auch als Scriptkiddies bezeichnet, sie erbringen selbst keine kognitive Leistung, sondern nehmen sich vorgefertigte Tools aus dem Internet und ziehen Energie aus der Schadenfreude.

    Tim, nur so weit du es sagen kannst/darfst, aber grundsätzlich, das Vier-Augen-Prinzip bzw. Mehr-Augen-Prinzip, das gilt auch bei dir auf der Seite und wenn man Marcel und Alexander hier fragen, sie zumindest nicken würden, dann auch eben bei WoltLab? Soll heißen, egal was ihr hier tut, das kontrollieren stets mehrere Leute, es gibt eine Art festen Ablauf und weil ihr die Programmiersprachen kennt, daher auch Fehler in diesen, könnt ihr vorab diese Fehlerquellen ausmerzen, ihr könnt auch hypothetische Probleme simulieren und daher direkt die Hintertüren schließen - selbst wenn noch keiner an solche Hintertüren dachte?

    Ich halte Code-Review für sehr wichtig. Mein Ziel ist es jede Änderung der anderen zumindest zu Überfliegen und bei möglichen Problemen (ganz gleich welcher Art) einen Kommentar zu hinterlassen. Das kann ein simpler Tippfehler in einer Sprachvariable sein, das kann aber auch eine potentielle Sicherheitslücke sein.

    Erfahrung hilft bei der Vermeidung von Bugs (Sicherheitslücken sind nur eine Teilmenge von Bugs generell) definitiv weiter. Das merke ich oftmals bei der Pluginprüfung. PHP enthält viele unintuitive Gotchas, die Leuten, die nicht professionell Programmieren oftmals nicht bekannt sind. Ich kann auf derartige Probleme hinweisen.

    Ein Beispiel für die von dir genannten hypothetischen Probleme ist der Image-Proxy in WSC 3. Sieh dir folgende Änderung an:

    https://github.com/WoltLab/WCF/co…4ef1cd7489a8b32

    Diese Änderung sorgt dafür, dass eine potentielle „Denial of Service“-Sicherheitslücke geschlossen wurde. Der Image-Proxy lädt jetzt Bilder mit maximal 10 Megabyte Größe herunter. Vorher war es möglich dem Image-Proxy Daten mit mehreren Gigabyte Größe zu schicken und dadurch beispielsweise die Festplatte des Servers zu füllen. Nach der Änderung wird die Verbindung nach dem Herunterladen von 10 Megabyte automatisch getrennt.

    Ich will wirklich nicht paranoid klingen, aber wenn wir sagen, das jeweilige Projekt ist gesichert, die Software ist auf dem aktuellen Stand, ich sichere regelmäßig usw., reicht das wirklich?

    Jein. Wie du schon sagtest: Perfekten Schutz wirst du niemals erreichen. Stichwort „0-Day-Sicherheitslücken“. Aber mit sicheren Passwörtern und zeitnahen (nicht regelmäßigen! Regelmäßig kann alle 2 Jahre sein) Updates ist man schon besser dabei als der Durchschnitt. Ein Schritt mehr wäre noch die Abschottung jedes Dienstes in eine eigene virtuelle Maschine, um präventiv vor Sicherheitslücken zu schützen. Wenn du darüber hinaus noch Googlen möchtest: SELinux oder AppArmor.

    Anders gefragt, ist es (un-)realistisch und (un-)nötig, dass ich als Betreiber selber testen sollte, ob und welche Schwachstellen meine Plattform hat, sollte ich so weit gehen und dann wirklich testen, ob meine Seite gegen bestimmte Angriffe gesichert ist oder nicht? Die Frage erscheint sicher merkwürdig, aber nachdem ich jetzt auch Fightcrashers Antwort gelesen habe, frage ich doch.

    Es ist sicherlich zu viel verlangt, jegliche eingesetzte Software selbst zu überprüfen. Das verschlingt viel zu viel Zeit und garantiert nicht, dass du Probleme findest. Es sollte aber sichergestellt werden, dass nach der Einrichtung ein paar Sanity-Checks durchgeführt werden. Ein Beispiel dafür ist die Authentifizierung über SSH-Keys. Das erste was ich bei meinen Servern mache (literally: Erste) ist das Root-Passwort zu ändern und anschließend die Authentifizierung über Passwörter abzuschalten. Nach der Abschaltung überprüfe ich auch tatsächlich, dass die Abschaltung erfolgreich war (ich also selbst mit korrektem Passwort nicht herein komme).

    Nun kommt aber meine Frage: Wie genau wird ein kritischer Fehler definiert und warum wird das als Parameter nicht mehr mit WSC ausgelesen?

    Alle Updates sollten installiert werden.

    Das liegt noch an den Betreibern selber bzw. müssen wir da an die Suite dran, also von der Reihenfolge her müssen wir zuerst die Endanwendung/en selber standardmäßig so bestücken oder geht es nicht, noch nicht bzw. egal was wir anbieten, wir können trotzdem nicht 100%ig sicherstellen, dass z.B. nicht zwei Personen einen Account nutzen und daher "großzügiger" mit den Daten sind?

    Meine Antwort war im größeren Kontext zu verstehen. Selbst bei Diensten wie Online-Shops oder E-Mails nutzt nur ein Bruchteil der Menschen eine Zweifaktor-Authentifizierung, es ist einfach ein Mehraufwand, bei dem viele den Nutzen nicht erkennen. Ich wäre ja schon glücklich, wenn „alle“ Leute einen Passwort-Manager nutzen würden.

    Du hast die dir App angesehen, sie getestet und kannst du aufgrund dessen "herauslesen", was ggf. noch über den Server geht, also laienhaft gefragt, wie würde ich das ohne entsprechenden Vorabhinweis seitens des Entwicklers herausfinden/herauslesen?

    Ich habe mir die App nicht im Detail angesehen und sie auch nicht getestet. Das mindestens steht da, weil ich nicht mit Sicherheit beurteilen kann, was alles an den Server von Christopher gesendet wird.

    Oh oh, das klingt gar nicht gut, harte Worte, aber ich möchte das nicht so stehenlassen. Die Serverprobleme, fehlerhaften Einstellungen usw., kannst du mir das vielleicht kurz beschreiben, was läuft z.B. schief?

    Faulheit: Fehlende Updates, schlechte Passwörter.

    Ich lese oft mit, wenn Administratoren nachfragen, ob sie zu einem Webhoster gehen oder sich einen eigenen Server zulegen sollten. Je nach Angebot heißt das bei Leuten, sie versuchen sich selber an Server-Management. Es steht außer Frage, dass ich das wagen würde, aber so unter uns hier, ab welchem Niveau sollte man sich an einen eigenen Server heranwagen, was sollte man an Wissen, Erfahrung und auch Lernwillen mitbringen, hast du dazu eine Meinung und Erfahrung/en?

    Man sollte fortgeschrittene Linux-Kenntnisse besitzen (d.h. wissen wie man mit einem Terminal effizient umgeht) und in der Lage sein zu lesen und zu verstehen. Das ganze ist sicherlich nicht zu schwierig wie ich und andere gerne behaupten, man merkt aber an der Art der Fragestellung schnell wer geeignet ist und wer nicht. Ein „nein, tu es nicht“ ist für die Leute aber besser zu verstehen als ein „ja, aber nur wenn du XYZ“.

    Du hast, wieso auch immer, einen veralteten Code verlinkt.

    Ich nehme an, dass sie von dem von mir verlinkten Commit auf die Datei gekommen ist.

  • Ach ja..

    Alle Security-Experten sind sich einig, dass der Standard TLS 1.3 ein deutlicher Schritt zu mehr Sicherheit im Internet wäre. Doch ausgerechnet Security-Devices, die Verschlüsselung aufbrechen, verhindern die Einführung auf nicht absehbare Zeit.

    Die Zukunft des neuen Standards für Verschlüsselung im Web ist wieder völlig offen. Eigentlich stand die kommende Version TLS 1.3 bereits im Sommer zur Verabschiedung an. Doch wegen einer recht hohen Fehlerquote in Feldtests wurde sie damals zugunsten weiterer Tests nochmals verschoben. Diese Tests zeigen nun eine definitiv nicht akzeptable Anzahl von Verbindungsfehlern – verursacht durch "Middleboxes", die Ende-zu-Ende-Verschlüsselung aufbrechen, um den übertragenen Inhalt zu inspizieren.

    TLS 1.3 super empfehlenswert. Zukunft völlig offen. Besser nicht produktiv einsetzen.. :D

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!