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
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.
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.
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.
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?
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.
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.
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?
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.
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.