{"id":1029,"date":"2011-04-08T20:45:40","date_gmt":"2011-04-08T18:45:40","guid":{"rendered":"http:\/\/blog.benny-baumann.de\/?p=1029"},"modified":"2011-04-09T19:29:52","modified_gmt":"2011-04-09T17:29:52","slug":"sichere-updates","status":"publish","type":"post","link":"https:\/\/blog.benny-baumann.de\/?p=1029","title":{"rendered":"Sichere Updates"},"content":{"rendered":"

Heute hatte ich wieder einmal eine recht spannende Diskussion. Anlass dieser war, dass Palemoon in Version 4 einen Bug im Updater<\/a> hat, der dazu f\u00fchrt, dass auch vorhandene Updates nicht gefunden werden. An sich nicht weiter schlimm, k\u00f6nnte man meinen, denn das mit den Updatern haben schon ganz andere Leute nicht hinbekommen. Was mich an der Stelle aber etwas aufgeregt hat, war „die L\u00f6sung“ bzw. der vorgeschlagene W\u00fcrgaround: „Schaltet einfach SSL ab“. Gute Nacht, Sicherheit!<\/p>\n

Auf meinen Hinweis hin, bitte das Problem korrekt zu l\u00f6sen und statt die \u00dcberpr\u00fcfung auf SSL abzuschalten, korrekt SSL einzusetzen, entbrannte eine Diskussion, die wie \u00fcblich die 3 H\u00f6hepunkte hatte:<\/p>\n

    \n
  1. SSL ist zu teuer<\/li>\n
  2. Der Provider l\u00e4sst das nicht zu<\/li>\n
  3. Dann doch den Updater nicht nutzen<\/li>\n<\/ol>\n

    Okay, fangen wir mit dem ersten Argument an, da es, IMHO das am einfachsten zu entkr\u00e4ftende ist: SSL kostet nicht allzu viel und ist zudem sogar stellenweise kostenlos zu haben. Die wohl bekanntesten Beispiele hier sind CAcert<\/a> sowie StartCom<\/a>. Und auch wenn CAcert derzeit unter Windows in keinem Browser enthalten ist und StartCom (IMHO) nicht unbedingt vertrauensw\u00fcrdig ist, sind beides erst einmal M\u00f6gliche Kandidaten f\u00fcr SSL-Zertifikate. Von den anderen (g\u00fcnstigen) SSL-Zertifizierungsstellen wie GoDaddy und Comoda einmal abgesehen (zu deren Sicherheit es auch nicht unbedingt die r\u00fchmlichsten Aussagen<\/a> gibt). Viel wichtiger bei einer CA ist, dass ich ihr vertrauen kann. Und ich denke einmal, CAcert und StartCom sind – gegen\u00fcber CNNIC, Deutsche Telekom und DFN – da durchaus Unternehmungen, die Wert darauf legen, ihre Glaubw\u00fcrdigkeit zu behalten.<\/p>\n

    Bliebe der n\u00e4chste Punkt: Aber mein Provider l\u00e4sst keine ThirdParty-Zertifikate zu. Okay, dann wechsel ihn. Wenn ich leuten SSL auf meinem Server installiere, rechne ich den Aufwand f\u00fcr die Konfiguration und Wartung ab, nicht, dass ich ein Programm laufen lasse, was Zufallsdaten in Zufallsdaten transformiert, um komische Gleichungen zu erf\u00fcllen. Das \u00fcberlasse ich eben besagten vertrauensw\u00fcrdigen Stellen, denen auch andere Glauben, dass die durchgef\u00fchrte Berechnung irgendwas besagt. Einzig ein neutraler Hinweis, wer entsprechende Zertifikate ausstellt, wird auf Nachfrage erteilt. Solange die f\u00fcr die Konfiguration ben\u00f6tigten Daten stimmen, ist mir der Rest egal.<\/p>\n

    Womit wir beim Kernpunkt dieses Rants w\u00e4ren: Dann nutz den Updater doch nicht, wenn du deinem ISP nicht traust. Okay, dann schauen wir doch einmal: Der manuelle Download erfolgt auch ohne SSL und der Download ist nur via MD5- und SHA1-Hashes, die auf der (unverschl\u00fcsselten) Website zu finden sind, verifizierbar. Wem soll ich da vertrauen: Der Website kann ich das zumindest nicht, denn Manipulationen, z.B. an eben diesen Pr\u00fcfsummen, kann ich nicht erkennen.<\/p>\n

    Also, worum geht es bei SSL im Updater nun, wenn nicht um Verschl\u00fcsslung? Im Wesentlichen 3 Dinge:<\/p>\n

      \n
    1. Authentizit\u00e4t<\/li>\n
    2. Integrit\u00e4t<\/li>\n
    3. Vertraulichkeit<\/li>\n<\/ol>\n

      W\u00e4hrend Vertraulichkeit f\u00fcr die meisten der scheinbar wichtigste Punkt ist, so ist er in der Praxis eher in Ausnahmef\u00e4llen f\u00fcr einen reinen Updater interessant, davielfach bereits durch andere Nebenkan\u00e4le genug \u00fcber den Inhalt der Kommunikation bekannt ist. Wenn ein Computer beim DNS nachfragt, wo update.mozilla.com ist, verr\u00e4t dies mindestens einmal, dass eines von X Mozilla-Programmen auf dem Rechner l\u00e4uft; ganz unabh\u00e4ngig von der Verschl\u00fcsslung. Findet die eigentliche Anfrage dann nun unverschl\u00fcsselt statt, erf\u00e4hrt ein Angreifer zwar, um was f\u00fcr einen Software-Stand es sich handelt, kann aber (sofern die anderen Anforderungen erf\u00fcllt sind) nichts manipulieren.<\/p>\n

      Anders jedoch beim Scheitern der anderen beiden Forderungen: W\u00fcrde ein Angreifer versuchen, eine Authentifizierte Verbindung anzugreifen, m\u00fcsste er es schaffen, sich der Identit\u00e4t des Update-Servers zu bem\u00e4chtigen. Analog m\u00fcsste ein Angreifer zum Brechen der Integrit\u00e4t das Pr\u00fcfverfahren aushebeln, mit dem auf Manipulationen gepr\u00fcft wird.<\/p>\n

      L\u00e4sst man hier SSL weg, bzw. setzt dieses fasch ein, erlaubt man einem beliebigen Angreifer zu bestimmen, was ein Update-Client als Update akzeptiert. Fangen wir mit dem einfachen Download \u00fcber HTTP an, der nur \u00fcber eine MD5- oder SHA1-Pr\u00fcfsumme gesichert ist. Wir haben hier keine Vertraulichkeit und aber auch keine Authentizit\u00e4t. Ich kann also maximal pr\u00fcfen, dass ich den Virus korrekt heruntergeladen habe, da ich zwar wei\u00df, dass der Download korrekt ist, wenn die Pr\u00fcfsummen stimmen, woher diese kommen, also ob vom Autor der Software oder dem b\u00f6sartigen Angreifer, ist nicht bekannt. Hier fehlt also mindestens noch die Authentizit\u00e4tspr\u00fcfung, die jedoch mangels vorhandener Angaben nicht durchgef\u00fchrt werden kann.<\/p>\n

      Eine einfache M\u00f6glichkeit, dies zu erm\u00f6glichen, ist die Verwendung asymmetrischer Verfahren wie diese in GnuPG und zahlreichen anderen Kryptosystemen eingesetzt werden. Darunter \u00fcbrigens auch SSL. In der Regel findet man in solchen Systemen 3 Komponenten:<\/p>\n

        \n
      1. Hash-Verfahren zur Pr\u00fcfung von Integrit\u00e4t<\/li>\n
      2. Asymmetrische Verschl\u00fcsslung f\u00fcr Authentizit\u00e4t<\/li>\n
      3. Symmetrische Verfahren f\u00fcr Vertraulichkeit<\/li>\n<\/ol>\n

        M\u00f6chte man nun den HTTP-Download sicherer machen, muss man nicht zwangsl\u00e4ufig auf SSL aufsetzen: Es reicht bereits, wenn wir Integrit\u00e4t und Authentizit\u00e4t sicherstellen k\u00f6nnen. Und hierzu findet man an zahlreichen Stellen bereits eine m\u00f6gliche, sehr einfache, aber sehr effektive M\u00f6glichkeit: Die Nutzung von Signaturen durch beispielsweise GnuPG. Das wirft zwar ein Problem bzgl. „woher bekomm ich den korrekten Signatur-Schl\u00fcssel“, stellt aber bereits sicher, dass ich Manipulationen am Download erkennen kann und auch wei\u00df, dass dieser vom Autor kommt (oder auch halt nicht).<\/p>\n

        Streng genommen w\u00fcrde bereits dieses Verfahren auch f\u00fcr den automatisierten Updater ausreichen, stellt aber ein Problem bzgl. der Vertraulichkeit und des Datenschutzes dar, denn ohne Verschl\u00fcsslung kann hier jeder mitlesen, welche Version der Client anfordert bzw. welche Client-Version derzeit installiert ist. Letzteres l\u00e4sst sich zwar umgehen, indem man einfach blind erst einmal alle verf\u00fcgbaren Versionen abfragt und dann „offline“ die ben\u00f6tigten Updates entscheidet. Aber selbst dann ist anhand der gestellten Downloads (und ggf. z.B. Diffs) der bisherige Stand noch zu erraten.<\/p>\n

        Also: Nein, ich bin nicht paranoid; hat der Mann hinter mir gesagt … Es geht mir nur darum, dass man ein Kryptosystem in einer Software nicht broken-by-design baut, bzw. kaputt-repariert, wie es bei OpenSSL durch unbedachtes Patchen<\/a> geschehen war.<\/p>\n

        Und um es noch einmal kurz zusammenzufassen: SSL bei einem Updater dient nicht der Verschl\u00fcsslung, sondern dazu, dass auch das korrekte Update beim Endnutzer ankommt. Verschl\u00fcsslung ist da eher zweitrangig, weil die Updates ja eh \u00f6ffentlich bekannt ist.<\/p>\n

        \"Flattr<\/a><\/p>","protected":false},"excerpt":{"rendered":"

        Heute hatte ich wieder einmal eine recht spannende Diskussion. Anlass dieser war, dass Palemoon in Version 4 einen Bug im Updater hat, der dazu f\u00fchrt, dass auch vorhandene Updates nicht gefunden werden. An sich nicht weiter schlimm, k\u00f6nnte man meinen, denn das mit den Updatern haben schon ganz andere Leute nicht hinbekommen. Was mich an […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[29],"tags":[14,38,10,98,48,69,112,7,128,13,50,20],"class_list":["post-1029","post","type-post","status-publish","format-standard","hentry","category-software","tag-bugs","tag-datenschutz","tag-debian","tag-developement","tag-dns","tag-internet","tag-kryptographie","tag-links","tag-meinung","tag-patch","tag-ssl","tag-update"],"_links":{"self":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1029","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1029"}],"version-history":[{"count":3,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1029\/revisions"}],"predecessor-version":[{"id":1031,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=\/wp\/v2\/posts\/1029\/revisions\/1031"}],"wp:attachment":[{"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1029"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1029"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.benny-baumann.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1029"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}