OpenStreetMap.org jetzt verschlüsselt

Nahmd,

Man kann nach den Möglichkeiten eines Angreifers staffeln:

(1) reines Mitlesen.

(in großem Stil durch Anzapfen eines Unterseekabels)

Da reicht verschlüsselte Übertragung per https, auch mit einem selbstunterschriebenen Zertifikat.
Das Zertifikat ist wichtig gegen Man in the middle - den haben wir hier aber nicht.

(2) Mitlesen und Pakete einfügen können.

Das ist die Situation im lokalen WLAN.

Das Pakete einfügen können ermöglicht einen eher sozialen Angriff, der das Kommunikationsbedürfnis des Angriffsziels ausnutzt:
ich sabotiere jeden https-Verbindungsaufbau, indem ich auf das meines Angriffsziels ein gefaktes seines Peers einfüge. Da ich ob der Nähe schneller bin als der Server, scheitert jeder https-Verbindungsaufbau.

Ist das Kommunikationsbedürfnis meines Angriffsziels hoch genug, wird er auf http: wechseln (diverse Software macht das automatisch), und damit zu meinem Opfer.

Security sollte verbindlich sein, Security als Option ist keine wirklich gute Wahl. Ergo: unter http: nur noch einen erklärenden Text anbieten, aber kein Login mehr zulassen. Das ist aber unbequem und wird deshalb nicht gemacht. Und so wird mein Angriffsziel mein Opfer.

(3) Man in the middle.

Hier ist ein selbst unterschriebene Zertifikat tödlich. Aber selbst mit einem offiziellen Zertifikat bleibt der Angriff nach (2) möglich, sogar noch perfider: nachdem ich mein Angriffsziel zur Nutzung von http genötigt habe, kann ich ihm eine Seite unterjubeln, auf der ich darauf hinweise, dass der https-Dienst ausgefallen ist und temporär bitte http benutzt werden soll. Und selbst wenn der Server ausschließlich https anbietet: Opfer → [http] → (böser Wolf) → [https] → Server; mein Opfer hat wieder verloren.

Also: https ist eine feine Sache, wirkliche Sicherheit vermittelt es aber nur in Verbindung mit einer Schulung der Nutzer.

(3a) Man in the middle durch Schlapphut&Co:

Du hast verloren. Jedenfalls wenn keine Client-Zertifikate genutzt werden.

Alldieweil sich unter den gesammelten Daten des Dienstes mit hoher Wahrscheinlichkeit auch solche befinden, mit denen man einen Mitarbeiter der Zertifizierungsstelle – ähem – dazu “überreden” kann, ein beliebiges Zertifikat zu unterschreiben.

Gruß Wolf (heute inkarniert als Miesmacher)

Naja, jeweils nicht mit certificate pinning (was z.B. per Browser-Addons verfügbar ist und in manchen Browern für manche populäre/gut zahlende Seiten auch schon eingebaut ist), sofern du irgendwann mal die Chance hast, das richtige Zertifikat zu bekommen. Das gilt auch eingeschränkterweise wenn dir dies erst zukünftig möglich sein sollte, falls der Angreifer sich nicht erlauben kann aufzufliegen.

Nahmd,

ich gehe von Otto Normalnutzer und Standardsoftware out of the Box aus.

Und da ist Schulung das Ein und Alles.

Sonst endet die Sicherheit der genialsten Kryptografie bereits am nächsten Hotspot.

Gruß Wolf

Moin,
es wird zwar die meisten hier nicht tangieren, aber wenn ich mal schnell was mit Potlatch editiere und danach wieder auf OpenStreetMap klicke, ist meine Verschlüsselung weg. Ist das ein Bug oder ein Feature? Und ist das nur bei mir so?

Gruß Thomas

Ich kann den editor (ID und Potlatch) auch nicht mit https aufrufen (werde zu http weitergeleitet). So ist es nicht verwunderlich dass man beim zurückgehen zu der Hauptseite auf http bleibt.

Ich würde zu einem Bug, oder einer noch nicht vollständige migration nach https tendieren. Wüsste aber nicht, wo man da jetzt ein issue erstellen soll.

mfg, pointhi

Ok, wenn man OAuth nicht nutzt scheint es in der josm-latest (6853) zu funktionieren.

17378569xy.jpg800×345 72.7 KB

Sollte eigentlich seit gestern Nachmittag tun, lag nicht an JOSM sondern an der Server Config.

Noch ein OT Hinweis, ich finde F-Droid ja gut, aber kommentarlos einen x-beliebigen selbst produzierten Build aus dem Repository als “aktuelle” Version zu bezeichnen ist wohl etwas gar irreführend. Es gibt überhaupt erst seit vorgestern einen “offiziellen” Test/Beta Build von 0.9.4 und die ist noch weit von einem Release weg. Die Version die von F-Droid verteilt wird scheint mindestens ein ernsthaftes Problem zu haben (hier nicht nachvollziehbar), man ist also vermutlich mit vorgenanntem Testbuild besser bedient.

ok, ich hatte vor meinem post ein wenig auf dem repository von vespucci herumgeschaut, aber google code ist für mich so undurchsichtig dass ich mich am builddatum orrentiert habe. Wenn es eine unstable build ist, ok, ich hatte bisher jedenfalls keine probleme mit dieser version.

https ist übrigens durch neuesten commit hinzugefügt worden: http://code.google.com/p/osmeditor4android/source/detail?r=687, das wäre jetzt die version 0.9.4r687.

mfg, pointhi

Hallo,

wenn ich die Mapnik-Karte mit https aufgerufen habe, funktioniert die Fernbedienung von JOSM nicht mehr - kann also den Kartenauschnitt nicht über “Bearbeiten mit externem Editor” nicht über diesen Klick öffnen, was in der unverschlüsselten Variante noch ging.

Gibt’s dafür eine Lösung ohne das ‘s’ in der URl zu entfernen und die Karte dafür erstmal unverschlüsselt aufzurufen?

Franz

Es gibt bereits einen Bugreport dafür. Der Grund ist, dass aktuelle Webbrowser auf über HTTPS geladenen Seiten viele Zugriffe ohne SSL blockieren und der “Webserver” in JOSM kein SSL kann oder zumindest kein Zertifikat hat.

taginfo.openstreetmap.org ist nun auch per https zu erreichen.

Damit duerfte iD nun auch einen Schritt naeher sein Verschluesselung zu unterstuetzen.

Das forum waere dann demnaechst glaube ich der letzt osm.org Service der nicht per https zu erreichen ist, aber das soll ja auch bald kommen.

nominatim.osm.org fehlt auch noch.

Ich würde mir wünschen, dass die Webinterfaces standardmäßig auf https weiterleiten. Die Kachelserver dagegen sollten weiterhin auch über Port 80 erreichbar bleiben, ohne Redirect.

Vielen Dank für die gute Arbeit!

Wie sieht es denn aus? Können wir mit https im Forum rechnen? Jedes unverschlüsselte Byte ist ein Byte zu viel für die Neugierigen!

Sind die OSM-Server auch vom Hearbleed-Bug http://www.heise.de/newsticker/meldung/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html betroffen ?

zumindest jetzt nicht mehr: http://possible.lv/tools/hb/?domain=openstreetmap.org. Das Zertifikat ist jedenfalls erst vor kurzem ausgestellt worden, also waren die osm-server vermutlich auch betroffen, und es ist ein neues Zertifikat erstellt worden.

mfg, pointhi

“auch”, du kannst davon ausgehen, dass im wesentlichen -alle- Dienste die über SSL angeboten wurden betroffen waren, der einzige Unterschied ist wie schnell Updates und neue Zertifikate eingespielt wurden. Da es Berichte gibt, dass praktisch unmittelbar nach dem bekanntwerden des Problems, auf Konten eingebrochen wurde, ist das vernünfitige Verhalten sobald neue Zertifikate für ein Dienst eingerichtet wurden, seine Passwörter zu ändern.

Die Zertfikate für openstreetmap.org und die Tilecaches wurden heute am frühen Abend ersetzt, also … siehe oben.

Simon

PS: das Forum wird noch nicht von der OSMF betrieben.

Die SSL-Konfig der servers schaut relativ gut aus: https://www.ssllabs.com/ssltest/analyze.html?d=openstreetmap.org&s=193.63.75.103 Perfect Forward Secrecy ist wenn möglich aktiviert. Damit wird zumindest ein nachträgliches entschlüsseln von verbindungen so gut wie unmöglich. Ich frag mich nur, warum nur Diff-Hellman, und nicht auch Eliptische Kurven dafür verwendet werden.

Auch ist ein SHA1 verschlüsseltes zertifikat eigentlich nicht mehr als sicher zu betrachten, auch wenn 90% aller websiten so eines verwenden. 3DES ist meines wissens auch nicht mehr auf den stand der zeit. Villeicht sollte man mal ein wenig darüber diskutieren, ob eine änderung der ssl konfiguration nicht überlegenswert ist. OSM ist jetzt sicher nicht schlecht verschlüsselt, aber meinem (wenigen) kryptographischen Wissens nach könnte man noch ein wenig mehr schaffen. Ich könnte mich aber auch in der hinsicht irren.

mfg, pointhi

Soweit ich weis war die Luecke in den OSM Servern innerhalb weniger Stunden nach bekannt werden gepatched. Auch bei bekannt werden von Sicherheitsluecken in Rails sind die OSM admins normalerweise sehr schnell mit dem einspielen von Patches! Passwoerter werden auch mit starken hash Funktionen (SHA512 mit ein paar tausend Iterationen) abgesichert und auch die mailserver verwenden wo moeglich TLS um den Verkehr und deren Metadaten abzusichern. insgesammt wuerde ich eigentlich von einem ziemlich hohen Schutzstandard bei OSM sprechen und die Admins nehmen das Thema Sicherheit ziemlich ernst.

Der Grund wieso die Hauptseite nicht ECDHE unterstuetz sondern nur DHE ist das Apache 2.2, welches teil von Ubuntu 12.04 LTS ist, dieses nicht beherrscht. Die tileserver, die auf Squid basieren verwenden hingegen ECDHE und sind mit TLS 1.2 auch auf dem neuesten standard. 3DES wird lediglich mit IE6 verwendet und liegt eher am Browser als am Server.

Auf wie das Zertifikat abgesichert ist hat OSM so weit ich weis auch keinen Einfluss sondern liegt an der verwendeten CA.