OpenStreetMap.org jetzt verschlüsselt

Hast Du scheinbar deaktiviert, ich kann Dir keine schreiben.

Ich finde, dass man einfach generell Protokoll-relative URIs nutzen sollte, sofern der Zielserver SSL unterstützt und nur bei Seiten, bei denen es sehr empfehlenswert ist (Login z.B.) einen Redirect setzen. Den Rest sollte HSTS erledigen (Danke für die Erinnerung @Nadjita).

Zum Zertifikat: Wenn man es irgendwie überprüfen kann (iirc gibt’s da irgendwas mit Signatur mithilfe eines PGP-Keys?) und man von der Zielgruppe erwartet, mit einer entsprechenden “Fehler”-Meldung umgehen zu können, (oder ausreichend Bedeutung hat um damit Druck auf CAs und Browser-Entwickler auszuüben) finde ich, dass eine Unterstützung der relativ zentralisierten CAs unnötig ist.

Hier im Forum gibt’s gar keine, und auf osm.org kann man sie nicht deaktivieren :wink:

/e: typo

Ja, aber man kann E-Mails über das Forum senden. Egal, ich nehme OSM, danke für die Idee, bin ich gar nicht drauf gekommen :roll_eyes:

sorry, nicht über das forum sondern www.openstreetmap.org/user/wambacher

Zum selbst-unterschriebenen Zertifikat: Selbst wenn man es nicht überprüft: gegen einen Angreifer, der NUR Lauschen kann und nicht manipulieren kann, schützt es schon komplett. Außerdem, selbst im Falle des manipulierfähigen Angreifers: er weiß nicht sicher, ob du es geprüft hast. Folglich, wenn er nicht riskieren möchte aufzufliegen, muss er annehmen, dass du es geprüft hast. (Vorstehendes nimmt an, dass der Angreifer keine gefälschten, aber “gültigen” – aka Populär-CA – Zertifikate selbst ausstellen kann oder die Ausstellung bei einer CA erzwingen kann)

Ein selbstunterschriebenes kann in der bestimmten Situation von gefälschten, aber gültigen Zertifikaten gar gleich gut wie Populär-CA-Zertifikate sein: wenn man das Zertifikat ab der ersten Verbindung festnagelt (certificate pinning), so wie es bei SSH üblicherweise gemacht wird. An Populär-CA-Zertifikate zu kommen, ist zwar für uns schwierig, ist für gewisse MITM-fähige Akteure aber auch im eigentlich nicht berechtigten Fall möglich.

Immer aber gilt, dass eine wieauchimmer verschlüsselte Verbindung sicherer ist, als eine unverschlüsselte (sofern nicht die Unvorsichtigkeit beim DAU vorm Bildschirm durch übersteigerte Sicherheitsvorstellung steigt). Wo wir auch schon bei Problem wären: der vorm Bildschirm. :wink:

Man kann diese Erfahrung auf OSM bestaetigen. Ein paar Tage bevor https auf osm.org eingefuehrt wurde, wurde es bereits auf den tile servern eingerichtet. Testeshalber wurden dann ca 20% aller Tile Aufrufe ueber https gelenkt um den Effekt auf Performance zu testen. Der Effekt war nicht wirklich sichtbar. Selbst auf dem Deutschen Tileproxy, der mit bis zu 90 Mbit/s eine der am staerkst belasteten proxys im CDN ist hat man auf den munim graphen absolut keinen unterschied in der CPU Nutzung gesehen. Sowohl vorher als auch nachher benoetigt Squid nur ein paar wenige % CPU Auslastung um die Kacheln auszuliefern.

Bei anderen Diensten die weniger Traffic verursachen duerfte der Unterschied wohl noch gerinnger sein. Insofern ist Performance in den aller meisten Faellen heutezutage nicht mehr ein relevante entscheidungs Grund fuer oder gegen https.

Zusätzlich könnte man das evtl. weiter einschränken, wenn man betrachtet wie lange der Server zum Ausliefern (=>Rendern) braucht.

Hat das schon jemand mit etwas anderem als JOSM testen können? Also ist das Problem beim API-Server oder bei JOSM? Meine Anwendung braucht das derzeit noch nicht, weshalb mein “OAuth scheint auch zu funktionieren” oben sich nur auf den Empfang eines OAuth-Tokens ohne weitere Tests bezog.
/edit: Benutzereinstellungen abrufen geht, also vermutlich eher ein Problem bei JOSM.

OT: Das habe ich so selbstverständlich deaktiviert dass ich da nicht dran gedacht habe :wink:

Blöde Frage, aber was bringt es denn, JOSM per https anzuschließen? Letztlich sieht man ja anhand deiner Einträge im Benutzerkonto was du bearbeitet hast. Oder verstehe ich da was falsch?

Wenn man nicht OAuth nutzt überträgt JOSM derzeit das Kennwort unverschlüsselt, JOSM prüft regelmässig ob du eine PN erhalten hast, welche Objekte du herunterlädst (und damit z.B. wie und wie schnell man arbeitet, ausserdem kann man JOSM auch für anderes nutzen) wird normalerweise auch nicht veröffentlicht. Und natürlich weil es geht.

Ab welcher Version von JOSM geht das? Und wo kann man das einstellen.

Wohl erst ab einer zukünftigen so richtig.

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.

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