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ührt, dass auch vorhandene Updates nicht gefunden werden. An sich nicht weiter schlimm, könnte 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ösung“ bzw. der vorgeschlagene Würgaround: „Schaltet einfach SSL ab“. Gute Nacht, Sicherheit!
Auf meinen Hinweis hin, bitte das Problem korrekt zu lösen und statt die Überprüfung auf SSL abzuschalten, korrekt SSL einzusetzen, entbrannte eine Diskussion, die wie üblich die 3 Höhepunkte hatte:
- SSL ist zu teuer
- Der Provider lässt das nicht zu
- Dann doch den Updater nicht nutzen
Okay, fangen wir mit dem ersten Argument an, da es, IMHO das am einfachsten zu entkräftende ist: SSL kostet nicht allzu viel und ist zudem sogar stellenweise kostenlos zu haben. Die wohl bekanntesten Beispiele hier sind CAcert sowie StartCom. Und auch wenn CAcert derzeit unter Windows in keinem Browser enthalten ist und StartCom (IMHO) nicht unbedingt vertrauenswürdig ist, sind beides erst einmal Mögliche Kandidaten für SSL-Zertifikate. Von den anderen (günstigen) SSL-Zertifizierungsstellen wie GoDaddy und Comoda einmal abgesehen (zu deren Sicherheit es auch nicht unbedingt die rühmlichsten Aussagen gibt). Viel wichtiger bei einer CA ist, dass ich ihr vertrauen kann. Und ich denke einmal, CAcert und StartCom sind – gegenüber CNNIC, Deutsche Telekom und DFN – da durchaus Unternehmungen, die Wert darauf legen, ihre Glaubwürdigkeit zu behalten.
Bliebe der nächste Punkt: Aber mein Provider lässt keine ThirdParty-Zertifikate zu. Okay, dann wechsel ihn. Wenn ich leuten SSL auf meinem Server installiere, rechne ich den Aufwand für die Konfiguration und Wartung ab, nicht, dass ich ein Programm laufen lasse, was Zufallsdaten in Zufallsdaten transformiert, um komische Gleichungen zu erfüllen. Das überlasse ich eben besagten vertrauenswürdigen Stellen, denen auch andere Glauben, dass die durchgeführte Berechnung irgendwas besagt. Einzig ein neutraler Hinweis, wer entsprechende Zertifikate ausstellt, wird auf Nachfrage erteilt. Solange die für die Konfiguration benötigten Daten stimmen, ist mir der Rest egal.
Womit wir beim Kernpunkt dieses Rants wären: 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üsselten) 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üfsummen, kann ich nicht erkennen.
Also, worum geht es bei SSL im Updater nun, wenn nicht um Verschlüsslung? Im Wesentlichen 3 Dinge:
- Authentizität
- Integrität
- Vertraulichkeit
Während Vertraulichkeit für die meisten der scheinbar wichtigste Punkt ist, so ist er in der Praxis eher in Ausnahmefällen für einen reinen Updater interessant, davielfach bereits durch andere Nebenkanäle genug über den Inhalt der Kommunikation bekannt ist. Wenn ein Computer beim DNS nachfragt, wo update.mozilla.com ist, verrät dies mindestens einmal, dass eines von X Mozilla-Programmen auf dem Rechner läuft; ganz unabhängig von der Verschlüsslung. Findet die eigentliche Anfrage dann nun unverschlüsselt statt, erfährt ein Angreifer zwar, um was für einen Software-Stand es sich handelt, kann aber (sofern die anderen Anforderungen erfüllt sind) nichts manipulieren.
Anders jedoch beim Scheitern der anderen beiden Forderungen: Würde ein Angreifer versuchen, eine Authentifizierte Verbindung anzugreifen, müsste er es schaffen, sich der Identität des Update-Servers zu bemächtigen. Analog müsste ein Angreifer zum Brechen der Integrität das Prüfverfahren aushebeln, mit dem auf Manipulationen geprüft wird.
Lässt 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 über HTTP an, der nur über eine MD5- oder SHA1-Prüfsumme gesichert ist. Wir haben hier keine Vertraulichkeit und aber auch keine Authentizität. Ich kann also maximal prüfen, dass ich den Virus korrekt heruntergeladen habe, da ich zwar weiß, dass der Download korrekt ist, wenn die Prüfsummen stimmen, woher diese kommen, also ob vom Autor der Software oder dem bösartigen Angreifer, ist nicht bekannt. Hier fehlt also mindestens noch die Authentizitätsprüfung, die jedoch mangels vorhandener Angaben nicht durchgeführt werden kann.
Eine einfache Möglichkeit, dies zu ermöglichen, ist die Verwendung asymmetrischer Verfahren wie diese in GnuPG und zahlreichen anderen Kryptosystemen eingesetzt werden. Darunter übrigens auch SSL. In der Regel findet man in solchen Systemen 3 Komponenten:
- Hash-Verfahren zur Prüfung von Integrität
- Asymmetrische Verschlüsslung für Authentizität
- Symmetrische Verfahren für Vertraulichkeit
Möchte man nun den HTTP-Download sicherer machen, muss man nicht zwangsläufig auf SSL aufsetzen: Es reicht bereits, wenn wir Integrität und Authentizität sicherstellen können. Und hierzu findet man an zahlreichen Stellen bereits eine mögliche, sehr einfache, aber sehr effektive Möglichkeit: Die Nutzung von Signaturen durch beispielsweise GnuPG. Das wirft zwar ein Problem bzgl. „woher bekomm ich den korrekten Signatur-Schlüssel“, stellt aber bereits sicher, dass ich Manipulationen am Download erkennen kann und auch weiß, dass dieser vom Autor kommt (oder auch halt nicht).
Streng genommen würde bereits dieses Verfahren auch für den automatisierten Updater ausreichen, stellt aber ein Problem bzgl. der Vertraulichkeit und des Datenschutzes dar, denn ohne Verschlüsslung kann hier jeder mitlesen, welche Version der Client anfordert bzw. welche Client-Version derzeit installiert ist. Letzteres lässt sich zwar umgehen, indem man einfach blind erst einmal alle verfügbaren Versionen abfragt und dann „offline“ die benötigten Updates entscheidet. Aber selbst dann ist anhand der gestellten Downloads (und ggf. z.B. Diffs) der bisherige Stand noch zu erraten.
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 geschehen war.
Und um es noch einmal kurz zusammenzufassen: SSL bei einem Updater dient nicht der Verschlüsslung, sondern dazu, dass auch das korrekte Update beim Endnutzer ankommt. Verschlüsslung ist da eher zweitrangig, weil die Updates ja eh öffentlich bekannt ist.
I fully understand your point of view, but you have clearly misunderstood a few things:
1) The SHA1 mention on twitter is the fact that in the update.xml file, a checksum is enclosed. The actual update (.mar) can be served over an unencrypted connection and (as is the case) from a different server. The actual integrity of the downloaded file is secured, in that case. If the update XML file can be trusted, then so can the resulting download, no matter where it’s pulled from.
2) The MD5 and SHA1 checksums on the actual download page are there merely for the same purpose: to check the integrity of the download; not to provide any other kind of security.
3) Serving the update XML from a secure server is preferred, of course, but switching hosting providers just for that isn’t that easy, nor is setting up a reliable server for the XML data elsewhere (I could host it on a box in my home, but that’s hardly reliable). Pale Moon is a project run on donations only, and web space that allows the use of SSL is expensive, no matter which hosting service you look at (unless you know of something that I don’t). The website is run on a (very) cheap virtual hosting package; already more of an investment than what is returned from the users. Monetizing the website to pay for the hosting? I hate ads. I’d rather serve XML in the clear than put ads on the site.
4) SSL in this case would only be useful if the certificate offered by the server is checked against a certificate that is trusted implicitly – meaning it will have to be a certificate that is locally available. If Pale Moon were to do the same, it means using a built-in CA certificate as well, which in most cases requires a level 1 CA – free certs are almost never available that close to the root certificates and always use intermediate CAs. If trusting an outside source, the SSL-secured website might as well be served by an attacker using a certificate chain that verifies correctly – but you still wouldn’t know if that would be the real version of the website or not. Anyone can get an SSL certificate free of charge, as you indicate yourself, from certain providers.
5) If you believe that someone at your ISP would go out of their way to hijack your connection to http://www.palemoon.org, serve you a believable copy of the website, just so you download a malicious version of a free and open source browser created by someone with no monetary gain from the project, then I really do think you are being a bit paranoid. Where’s the motive?
6) This kind of verification has not been enforced in the past (up to FF 4.0 there was no enforced security check with a hard failure if not https verified), so why is this suddenly such a big issue? Simple: FF 4.0 uses update-downloads „in the background“, checking and downloading updates to the browser silently (which really is something that anyone should be wary of). This poses a risk for roaming users as wireless networks are more often vulnerable in that respect, and you would be at risk every time a check is made and (falsely) answered, downloading malware without knowing it – On top of that you would even have it installed the next time you start your browser. OF COURSE, in such a situation, it is extremely important that the downloaded software is trusted. However, Pale Moon does NOT use this kind of updating, and only checks for possible version updates, then presents users with the choice to download. As such, serving people malware through the update process without them knowing becomes quite impossible.
In short: I agree it would be -better- to serve the update XML from a secure location, but I don’t have the resources to make this happen.
Pale Moon is released to the public in the hope that it is useful; if you need to use a browser in a restricted high-security environment, Pale Moon is not for you, and you should use something else.
MC
PS: Adding a PGP signature with fresh keys will only be useful if other people sign it and indicate their trust on the key – so it would probably be good, to support your own point, if you sign the key yourself with an indication of your level of trust in it.
Kommentar by Moonchild — 08.04.2011 @ 22:29:32
A small comment regarding the few points you brought up here:
1) I know that the SHA1 in the XML is the one that has to be protected since it starts a chain of trust for all the other integrity checks
2) Yes. I can check the integrity of the downloaded file, but they don’t tell me anything about its authenticity. It’s the same thing as with the update.xml here: If you can’t trust the checksums to be correct you just verify correctness of the downloaded virus 😉
3) If it’s only the lack of the SSL-enabled webspace I probably can help you. Regarding refinancing you might have a look at Flattr. BTW: I don’t like ads either (and that’s why my pages are ad-free too).
4) That’s why I mentioned CAcert (unfortutnally not in the default CAs, BUT that’s where you have control over with Pale Moon) or StartCom (They are in the trusted certs for IE AND Mozilla, thus would do in this case). Both of those providers do a basic validation of the person to at least have control over the domain. Thus If I request a certificate for palemoon.org I’d also have to have control over one of the RFC-mentioned adresses (webmaster@domain.tld or the one from Whois).
5) Even though Palemoon is not yet as well-known as other projects like Firefox you still can’t deny that hijacking the update process of a program or the connection is beneficial if you can trick the user into downloading some malware. And it doesn’t have to be my ISP that is tinkering with the connection. There have been attemps (one by the Chinese last year was quite remarkable in that) that redirected a third of the global internet traffic through China. Other attemps on blocking Youtube in Turkey caused global outages because of they announced the wrong routers. It hasn’t to be my own ISP that is mocking with my traffic, but it can be anyone who sits between my computer and your server. And by the way: hijacking connections to insert other content has been done in at least 3 different ways:
And just to be sure: The first two ways are commonly used and wide-spread applications.
6) As detailled above it’s not only „wireless networks“ that have to be seen as untrusted but also everything that’s not under your control, like public (wired) networks, your university’s network, the internet.
The fact that Pale Moon doesn’t to „in-the-background“ updates is in this case less a question of security but privacy and should be understood as such. The point that having the user confirm the update to malware version „Pale Moon 4.0.3“ (as could have been faked due to the broken integrity/authenticity chain is not much better: The updater only tells you „There is an update to“ but once your security is broken when retreiving this information, that’s absolutely worthless.
P.S.: I’ll send you a mail regarding keysigning. But please consider also publishing your (public) key on your website so other people can verify it too.
Kommentar by BenBE — 09.04.2011 @ 17:56:49