Das längste Thema

  • vmk was war bei TLS1.2 anders? daß man ohne die Verbindung aufzubrechen den entschlüsselten Inhalt ohne gröberen Aufwand bekommt?



    Korrekt, man konnte ohne eine man-in-middle-attack / proxy / dpi bestimmte Teile im Klartext rauslesen. Das ist jetzt bei TLS1.3 anders. Unter anderem stören sich die Anbieter von dem ganzen Middleware-Zeugs an diesem Punkt.

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

  • julian-w

    das Certificate Pinning hat ja mit TLS auch nichts zu tun, das kannst ja auch mit SSL3 haben;

    es sagt ja auch DNSSEC/TLSA nichts darüber aus aus,

    welche TLS version und welche Ciphersuite sich Dein Client mit dem Server aushandeln;


    es sind beides Mechanismen, soferne sie im Client implementiert sind - zweiteres ist es nicht -

    welche Dir eine zusätzliche Mglkt. geben zu validieren, ob das vom Server gelieferte Zertifikat

    auch das richtige ist;


    es bedarf gar keiner Manipulation des Clients, Google selbst sagt ja, daß sie gewisse Prüfungen bei Verbindungen

    zu RFC1918 Adressen bzw. IPv6 des selben Prefixes nicht machen, auch andere Browser handhaben es analog;


    ... nicht möglich ist TLSv1.3 zu "100%" auszurollen, weil schlichtweg ein Großteil des Verbindungsaufbaus an solchen Security Boxen gescheitert ist.

    kann es sein, daß hier einfach vorweggenommen wird, daß TLSv1.3 dann das einzige Verfahren ist, aber diese Boxen einfach dies (noch) nicht implementiert haben?

    natürlich scheitert der Verbindungsaufbau, wenn die Boxen keine Ahnung von TLSv1.3 haben, der Server aber TLSv1.3 verlangt;


    ich hab meine Zeifel - eben wegen der verschiedensten kontroversen Diskussionen - ob TLSv1.3 tatsächlich das bringt was manche

    evtl. nur hineininterpretieren;

    es muss sich ja jetzt schon jemand gut überlegen, TLSv1.2 als einziges TLS am Server zuzulassen; ähnliches gilt bei der Wahl der zugelassenen Ciphersuiten;

    bei mir zu Hause hat es schon x mal "gekracht", weil der doofe Server¹ keine meiner zugelassenen Ciphersuites angeboten hat;


    ¹ http://www.iana.net nur als Beispiel zu nennen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Hay,


    TLS 1.2/TLS 1.3 - gegen festgelegte persönliche Meinung ist schwer zu diskutieren, deswegen könnte das Ewigkeiten so weiter gehen. Wenn ja, verlegt das auf nach 20 Uhr, dann mache ich mir noch ein Portion Popcorn. Muss es aber nicht, wenn man einfach nur die Meinung anderer ohne einen weiteren Widerspruch toleriert (man muss sie ja nicht akzeptieren) und damit die Diskussion noch halbwegs positiv abschließt.


    Für jede Meinung lassen sich unendlich viele Links im Netz finden genauso dafür, ob die Erde flach ist oder eine Kugel. 8)


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • das Certificate Pinning hat ja mit TLS auch nichts zu tun, das kannst ja auch mit SSL3 haben;

    Hab ich auch nie behauptet. Es ging ja auch um Security Boxen die wegen TLSv1.3 Probleme bekommen (und weswegen du TLSv1.3 an den Pranger stellst, warum auch immer). Wenn du dein eigenes root-CA auslieferst, passt das nicht mehr zusammen ;) Wenn ich z.B. per Certificate Pinning das Zertifikat A verlange, du aber die Verbindung aufbrichst und mit Zertifikat B neu verschlüsselt, wird die Verbindung abgelehnt. Andere Beispiele sind Anwendungen, die ein root-CA fest einprogrammiert haben. Solche fällen müssen die Security Boxen umschiffen. Zu Zeiten von TLSv1.2 konnten die Security Boxen die Verbindung inspizieren ohne neu zu verschlüsseln, da gab es gewisse Möglichkeiten, lies dir einfach den verlinkten Artikel von der IETF durch...


    Das Thema ist eben sehr komplex, in der Uni sind Crypto und Security ein paar harte aber auch sehr interessante Vorlesungen...

    es bedarf gar keiner Manipulation des Clients

    Dann erklär mir wie dein System (Zitat von dir: "die Verbindung kannst ja ohnehin nur in der Art aufbrechen, indem Du sie bei Dir terminierst und wieder verschlüsselst") standardkonform funktionieren soll, wenn das Zertifikat vorher festgelegt ist (durch Certificate Pinning, fest vorgegeben oder was auch immer, die Welt besteht auch nicht nur aus Google Chrome). Eben gar nicht, daher brauchst du entweder manipulierte Clients oder entschlüsselt ohne neu zu verschlüsseln.

    kann es sein, daß hier einfach vorweggenommen wird, daß TLSv1.3 dann das einzige Verfahren ist, aber diese Boxen einfach dies (noch) nicht implementiert haben?

    natürlich scheitert der Verbindungsaufbau, wenn die Boxen keine Ahnung von TLSv1.3 haben, der Server aber TLSv1.3 verlangt;

    Der Punkt ist die Boxen können TLSv1.3 nicht, und das ist eben keine Schwäche im TLSv1.3 Protokoll, sondern eine stärke, weil abhören/MITM-Attacken etc. schlichtweg schwerer bis (quasi) unmöglich sind. Auch einige Downgrade-Attacken werden bei TLSv1.3 verhindert. Bei TLSv1.2 war es durch Attacken möglich (ist noch möglich) die Verbindung auf bis zu SSL 3 herunterzustufen (wenn es der Server anbietet), wodurch alle Schutzmechanismen die in TLSv1.2 implementiert sind hinfällig waren. Daher müssen Downgrades auf jeden Fall verhindert werden. Und langfristig ist natürlich das Zeil TLSv1.3 alleine anzubieten, heute käme ja auch keiner mehr auf die Idee SSLv2/3 anzubieten. Daher wird es noch eine lange Zeit TLSv1.3 und TLSv1.2 parallel geben.


    Aber ich die Entscheidung gut, nämlich in Richtung mehr Sicherheit anstatt "kompatibel" mit irgendwelchen ominösen Security Boxen zu sein.

    ich hab meine Zeifel - eben wegen der verschiedensten kontroversen Diskussionen - ob TLSv1.3 tatsächlich das bringt was manche

    evtl. nur hineininterpretieren;

    Der Standard ist doch quasi da, was bezweifelst du konkret daran? Und das er mehr Sicherheit bringt ist eindeutig, schau dir doch das Dokument der IETF an, du willst doch auch immer das mein deine Links liest und schickt sie zwei mal ;)Da sind etliche Verbesserungen genannt in Sachen abhören/MITM, oben hab ich dir extra eine Stelle zitiert, das ist ein Beispiel für ein mehr an Sicherheit. Es gibt noch mehr Beispiele, ich wüsste nicht ein Punkt der gegen TLSv1.3 spricht, außer die Akzeptanz (bei den Browsern wird es immer mehr und eine Implementierung ist problemlos möglich, nur diese "Security Boxen" machen Probleme), was aber bei jeder neuen Technologie etwas dauert bis sie aus den Startlöchern kommt 8)

  • Dann erklär mir wie dein System ....

    ganz einfach man unterdrückt z.B. auch gewisse Header des HTTP-Replies; und das Certificate Pinning ist bis auf ganz wenige Ausnahmen (googe.com im Chrome) nur dynamisch; sprich man verläßt sich auf HPKP, und genau das würgst auf der Box ebenfalls ab; und vereinzelte Ausnahmen kannst ja auch definieren;

    habe ich z.B. auch gemacht; und das CAA im DNS juckt keinen Browser oder sonst welchen Client, sondern einzig der CA bei der Ausstellung des Zertifikates - wäre ein weiteres Instrument, wenn denn mal DNSSEC sich verbreiten würde ...

    Der Standard ist doch quasi da, was bezweifelst du konkret daran?

    ich antworte das mal mit einer allgemeinen Gegenfrage:

    macht es Sinn einen neuen Standard zu haben, bei der Implementierung von vorne zu beginnen, und bis man am Status von halbwegs fehlerfrei ist, Jahre verstreichen zu lassen, an Stelle die etwaigen noch vorhandenen Fehler aktueller Implementierungen des alten Standards auszubessern?


    es gilt nunmal der Grundsatz: kein neues Feature ohne neue Bugs:D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • ganz einfach man unterdrückt z.B. auch gewisse Header des HTTP-Replies;

    Dann kommt man je nachdem in rechtliche Probleme auf dem Arbeitsplatz, scheinbar liest du den Link (der alles im Detail erklärt) nicht daher zitiere ich eine Stelle

    Code
    For example, privacy laws may prohibit
    middleboxes from intercepting banking traffic even if it is within
    the enterprise network and outbound network traffic is subject to
    inspection legally.
    
    There are several techniques that can be utilized.  Those techniques
    function with TLS 1.2 and earlier versions but not with TLS 1.3.

    Daher ist das Problem mit den Middle-Boxen oder Security Boxen oder wie man sie nennt nicht so trivial zu lösen. Deine Lösung wäre schlichtweg illegal in einigen Fällen, vor allem da du den Traffic aktiv manipulierst und daher nicht umsetzbar.

    ich antworte das mal mit einer allgemeinen Gegenfrage:


    macht es Sinn einen neuen Standard zu haben, bei der Implementierung von vorne zu beginnen, und bis man am Status von halbwegs fehlerfrei ist, Jahre verstreichen zu lassen, an Stelle die etwaigen noch vorhandenen Fehler aktueller Implementierungen des alten Standards auszubessern?

    Gegenfragen sind die besten Argumente8) Aber ja natürlich, wenn es z.B. die Sicherheit verlangt, sonst würden wir auch noch SSL in der Ursprungsversion nutzen ^^ Oder benutzt du noch "ursprüngliches" DES? Oder Firefox 1.0? Oder alte Betriebssystem-Kerne die keine Multi-Core Unterstützung haben? Nein natürlich nicht.

    Man hat TLSv1.3 ja nicht aus langeweile erfunden, sondern weil es technisch absolut notwendig war. Einige Probleme von TLSv1.2 stehen auch in dem verlinkten Dokument. Es gibt eine mittlerweile recht lange Liste an teils krassen Problemen (siehe Exploit-Liste unten), die meisten wurden (teils kreativ) gefixt, andere bestehen aber weiter (Downgrad-Attacken z.B.). Davon ab ist TLSv1.3 nicht halbfertig, sondern final fertig und es wurde mehrfach darübergeschaut von anerkannten Experten, erprobt im Massenbetrieb bei großen Anbietern (Facebook, Cloudflare, ...). Und an dem Standard wird auch seit Jahren gearbeitet, ist kein Schnellschuss.


    Und ganz von vorne hat man ja auch nicht begonnen, da sind Erfahrungen von Jahrzehnten reingeflossen, und der Standard ist produktiv einsatzbereit, wird er ja schon. Milliardenfach vermutlich. Auch die Bibliotheken sind einsatzbereit.


    es gilt nunmal der Grundsatz: kein neues Feature ohne neue Bugs

    Klar aber damit würgt man sämtlichen Fortschritt ab wenn man sich nur darauf beruft, davon ab ist gerade TLSv1.3 extrem gut getestet würde ich mal behauptet, da haben extrem viele Kryptographen ein wachsames Auge drauf gehabt ;) Bugs mag es sicher geben, aber die gibt es in anderen "seit Jahren erprobten" Bibliotheken/Protokollen auch...

    Die Liste wirksamer Exploits gegen TLS (Transport Layer Security), das Protokoll der Transportebene in HTTPS, umfasst inzwischen: Poodle, BEAST, CRIME, BREACH, DROWN und neuerdings ROBOT, von den verschiedenen Downgrade-Attacken wie FREAK und Logjam ganz zu schweigen. Die Liste nimmt scheinbar kein Ende und es kommen ständig neue Überraschungen hinzu — wie eben ROBOT


    Was mich nur stört ist das du TLSv1.3 als "schlecht", unausgegoren und heftig umstritten darstellst, was einfach sachlich falsch ist.

    aber TLSv1.3 ist heftigst umstritten;

    sodaß es momentan eigentlich nicht wirklich Sinn macht; auch wenn der RFC existiert, ausgegoren ist etwas anderes ...

    ich hab meine Zeifel - eben wegen der verschiedensten kontroversen Diskussionen - ob TLSv1.3 tatsächlich das bringt was manche

    evtl. nur hineininterpretieren;

    In der Form wie TLSv1.3 aktuell existierst, ist die allgemein anerkannte Meinung (siehe u.a. dein heise.de-Link) das es eine Verbesserung der Sicherheit darstellt (und schneller ist, effizienter ist, ...). Für Backdoors gibt es keinerlei Hinweise, vor der finalen Verabschiedung war es bereits bei großen Unternehmen im Einsatz, von unausgegoren kann in keinster Weise die Rede sein. Die Sicherheit steht im Fokus, da haben Security Box Hersteller halt man das nachsehen, was ich gut so finde!


    Daher wenn du TLSv1.3 aus persönlichen Gründen nicht magst, kannst du das gerne kundtun. Aber hier darzustellen das TLSv1.3 heftig umstritten ist, ist schlichtweg eine falsche Behauptung, genauso wie die Behauptung das es unausgegoren ist. Wenn du dann nur Unwissen preisgibst in Sachen Crypto und nicht mal den Unterschied zwischen den Versionen kennst, finde ich es bedenklich von dir solche Aussagen zu treffen, die andere vielleicht verunsichern. Einzig die Verbreitung der Clients muss noch besser werden (angeblich 63% was Browser angeht), was aber schnell gehen sollte bei den kurzen Zyklen der aktuellen Browser-Generationen und auch kein Grund ist es nicht serverseitig schon anzubieten. Cloudflare und Facebook bieten es jetzt schon im Regelbetrieb an.


    Von daher, wenn du "aus dem Bauch heraus" TLSv1.3 nicht magst, dann ist das so. Stell es dann aber bitte nicht so da das es technische Gründe gäb die es so nicht gibt, um andere nicht zu verunsichern. Ich kann jedem nur empfehlen sich TLSv1.3 anzuschauen und selbst zu nutzen :)

  • Dann kommt man je nachdem in rechtliche Probleme auf dem Arbeitsplatz, scheinbar liest du den Link (der alles im Detail erklärt) nicht daher zitiere ich eine Stelle

    ich habs nur ignoriert, weils mich zu Hause nicht berührt;

    Was mich nur stört ist das du TLSv1.3 als "schlecht", unausgegoren und heftig umstritten darstellst, was einfach sachlich falsch ist.

    so falsch wie Du es hinstellst ist es nicht, denn die vielen Meldungen, ob wahr oder falsch (Fake), die es dazu gab und vlt. noch gibt, kannst nicht ungeschehen machen;

    wir sind jetzt wahrscheinlich konträrer Meinung, aber im Blick auf all das in der Vergangenheit, wirst Dir schwer tun, es als gut zu bezeichnen; vor allem wegen folgendem: z.B. der RFC über SHA2 (RFC6234) liefert gleich eine Referenzimplementierung in Form von C Quellcodes mit; das ist etwas handfestes; da kannst mich überzeugen, indem Du mir sagst: "verwende SHA2 an Stelle von SHA1, das ist sicherer"; hingegen beim RFC f. TLS1.3 (RFC8446), welches bei genauerer Betrachtung nur eine theoretische Abhandlung ist (von einer Referenzimplementierung in Form von C Quellcodes keine Spur), wirst Dir schwer tun jemanden/mich zu überzeugen, daß diese oder jene Implementierung viel besser/sicherer ist, und derjenige/ich möge doch an Stelle von TLS1.2 das neue TLS1.3 einsetzen;


    es wurden tatsächlich bereits im Jahr 2014 die ersten Schritte zum TLS1.2 Nachfolger (= TLS1.3) gesetzt - zur Erinnerung das Jahr 2013 war das Jahr in dem Ed. Snowden mit den Enthüllungen der NSA in den Medien war; wie ich bereits sagte, es gab Diskussionen, Meldungen; wenn ich nur eine herauspicke: "Big banks want to weaken the internet’s underlying security protocol" (https://www.cyberscoop.com/tls…-financial-industry-ietf/)

    welches Motiv haben Banken, daß die Verschlüsselung schwächer ist, als geplant? (bei Behörden ist es mir klar, aber bei Banken)

    darauf zu Vertrauen, daß Implementierungen frei von solchen Dingen sind, habe ich eben keines;


    es gilt immer noch: Du kannst Dir Vertrauen nicht kaufen, Du mußt Dir das Vertrauen verdienen;


    ich hätte den RFC angesichts der Dringlichkeit (Ed. Snowden) und dem Startschuss dazu bereits im Jahr 2014 schon vor 2 Jahren erwartet, und nicht erst jetzt im Jahr 2018(!); es werden andere Dinge ja auch ziemlich schnell durchgepusht - mit teils negativen Folgen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Wenn man zu Fuß auf dem Heimweg um halb 1 nachts ist, auf der dunklen Straße nichts sehen kann ausser den Pixeln auf dem Handydisplay und einer flackernden Laterne in sechshundert Metern Entfernung, freut man sich umso mehr plötzlich „Profi“ neben seinem Usernamen stehen zu haben. Das wäre ohne die unzähligen Beiträge in diesem Thread nicht so schnell möglich gewesen :D

    Danke an netcup für die unwiderstehlichen Sonderangebote und nochmal ein riesiges Dankeschön an die liebe Community und ihre Hilfsbereitschaft :)

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Wie wichtig ist Ihnen eigentlich unsere doch recht hohe garantierte Mindestverfügbarkeit von 99,6% bei unseren VPS? Würde jemand von Ihnen VPS mit 98% Mindestverfügbarkeit kaufen, wenn der Preis dafür halbiert wäre?


    Mit freundlichen Grüßen


    Felix Preuß

    Ja, aber nicht standardmäßig, sondern als explizit wählbare Option. Für Spaßserver wäre das dann interessant, für (relativ) wichtige Projekte möchte ich aber die gewohnte Verfügbarkeit behalten.

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Moin,


    Wie wichtig ist Ihnen eigentlich unsere doch recht hohe garantierte Mindestverfügbarkeit von 99,6% bei unseren VPS? Würde jemand von Ihnen VPS mit 98% Mindestverfügbarkeit kaufen, wenn der Preis dafür halbiert wäre?


    Mit freundlichen Grüßen


    Felix Preuß


    wie schon einige vorher schrieben :


    Ja wäre interessant für Testszenarien.

  • Relativ;

    vergleiche nur mal die Ausgaben von


    host -t TXT 20140502._domainkey.liwest.at (1)

    host -t TXT mail._domainkey.ipv6help.de (2)

    host -t TXT mail._domainkey.ipv6home.eu (3)


    bei (1) kommt man kommt man mit UDP aus, obwohl die Keybitbreite die selbe ist wie bei (2)

    und wenn man im Editor die Ausgaben so verschiebt dass die beginnenen Anführungszeichen untereinander sind,

    dann ist der erste Block unterschiedlich lang(!)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Stimmt es, dass DKIM Keys im DNS nicht nach Format, sondern strickt nach 255 oder weniger ASCII-Zeichen getrennt / formatiert werden?

    „You may have more than 255 characters of data in a TXT or SPF record, but not more than 255 characters in a single string. [...] However to get around this limitation, per RFC 4408 a TXT or SPF record is allowed to contain multiple strings, which should be concatenated together by the reading application.“


    Quelle: https://kb.isc.org/docs/aa-00356

  • Ja, aber nicht standardmäßig, sondern als explizit wählbare Option. Für Spaßserver wäre das dann interessant, für (relativ) wichtige Projekte möchte ich aber die gewohnte Verfügbarkeit behalten.

    Jo, für viele, nicht produktive Systeme reicht das Dicke. Besser als irgend nen unwichtigen Dienst daheim zu hosten auf alle Fälle!


    Denke da gerade an weniger nützliche Dinge, wie nen TS3, nen BNC, oder einfach nur nen kleines Testsystem. Wenn der VPS mal nen paar Stunden offline ist, fällt das wahrscheinlich nicht mal auf ?

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • vmk nachdem was ich im Teletext aufgeschnappt habe und hier

    z.B. https://www.trend.at/geld/open…hre-bank-dritten-10349032

    Stichwort: Open Banking

    da ist es dann wurscht ob bei TLS jemand mitlesen kann oder nicht, hier werden

    garantiert Fehler gemacht, das wird garantiert gehackt ...;

    hier würde sich dann jeder doch TLS1.2 ohne dieser Richtlinie (sprich dieser Schnittstellen) wünschen

    http://eur-lex.europa.eu/legal…ELEX%3A32015L2366&from=EN


    auf das musst mal kommen, daß das


    for file in /var/local/files/*

    do

    cat $file |....

    done


    bei einem leeren Verz. fehlschlägt ..., mit


    if [ "$(ls -A /var/local/files/)" ]; then

    ...

    fi


    klappt es dann;


    was anderes:


    ich hab ein Simcity f. Linux entdeckt;

    die Files sind aus dem Jahr 2000, mit welchem Linux bekommt man das noch zum Laufen?


    kennt jemand ein Portal/eine Site, mit der man sporadisch ein FAX senden kann?

    (es darf etwas kosten aber kein Abo)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Man prüft korrekterweise auch immer mit -e oder -f innerhalb der Schleife, ob $file existiert… ;)


    Bei Bash kann man es sich deutlich einfacher machen, indem man gleich shopt -s failglob verwendet.


    In diesem Zusammenhang empfehle ich gerne diesen Link: https://sipb.mit.edu/doc/safe-shell/

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

    2 Mal editiert, zuletzt von KB19 ()

  • [netcup] Felix P. Keine Ahnung, ob daran Interesse besteht, aber ich lasse das einmal als Zitat hier…

    Siehe: phpBB.de-Newsletter I/2018

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