OpenStreetMap.org jetzt verschlüsselt

Wow, +1! Danke auch für die Nachricht hier! Warten wir mal noch auf die API.

API funktioniert auch: Ich habe hier eine Web-Anwendung, die sich die Notes holt, bei der der Teil nun auch bei einem Aufruf über HTTPS funktioniert 🙂
Nur JOSM hat wohl noch Probleme. Vielleicht mal da einen Bug melden?

/e: Normale OSM-Objekte abrufen geht auch, OAuth scheint auch zu funktionieren

JOSM hatte ein bug im URL parsing. Ist aber bereits gefixed worden und nun funktioniert auch JOSM mit https.

Fuer iD ist https noch deaktiviert, da es noch resource von anderen Servern laedt die kein https koennen wie taginfo. Allerdings soll auch das demnaechst umgesetzt werden. Genauso wie das Forum auch in vorbereitung ist auf SSL umgestellt zu werden.

amm wrote:

JOSM hatte ein bug im URL parsing. Ist aber bereits gefixed worden und nun funktioniert auch JOSM mit https.

Das ging aber schnell. 🙂

Das Notes-Plugin scheint noch den gleichen Fehler zu haben:

GET https:/api.openstreetmap.org/api/0.6/notes

OAuth geht übrigens nicht über https:

INFO: POST https://api.openstreetmap.org/api/0.6/c … t/*/upload...
INFO: Authorization Required
Fehler: Error body: Couldn't authenticate you

Fehler: org.openstreetmap.josm.io.OsmApiException: ResponseCode=401, Error Body=<Couldnt authenticate you>
org.openstreetmap.josm.io.OsmApiException: ResponseCode=401, Error Body=<Couldnt authenticate you>

Viele Grüße,
whb

Was leider nur umständlich geht, ist Remote-Control mit Firefox. "Laden von gemischten aktiven Inhalten "http://127.0.0.1:8111 ... wurde blockiert". Das Whitelisting in Firefox ist leider auch immer nur für den aktuellen Seitenaufruf (bug 873349). Und einen Aufruf https://127.0.0.1:8111 mag JOSM anscheinend nicht (nicht verwunderlich). Das Problem liegt aber, meines Erachtens bei Firefox und unzureichenden Whitelisting-Möglichkeiten.

das forum funktioniert leider nicht mit https, vermutlich da der server nicht von osm gehostet ist. Es gibt ein selbstsigniertes Zertifikat, welches aber nur auf die standard-apache-seite weiterleitet. Vermutlich kommt wegen dem "bald" ein eigener forum-server (ist schon im osm wiki vorhanden: http://wiki.openstreetmap.org/wiki/Servers/clifford)

Ich hab bei Vespucci schon ein Issue gemacht damit sie https unterstützen, wie es scheint sieht der entwickler die sache aber nicht wirklich wichtig.

Vespucci has supported OAuth for a significant amount of time. There is no need to transmit passwords in the clear. Once the https API has stabilized, we will probably support it.

Bei der eingabemaske für passwörter steht sogar extra: Beachten Sie: Das Passwort wird unverschlüsselt gespeichert und übertragen!

Ich würde mal sagen dass man issues bei den verschiedenen osm-programmen aufmacht, die ein login unterstützen (falls https noch nicht unterstützt wird). Es ist jetzt nicht so, dass diese wichtige sicherheitsverbesserung von alleine an die ganzen programmierer durchdringt.

mfg, pointhi

pointhi wrote:

das forum funktioniert leider nicht mit https, vermutlich …

Siehe dazu den anderen Thread: Feedback » HTTPS full support.

pointhi wrote:

Vespucci has supported OAuth for a significant amount of time. There is no need to transmit passwords in the clear. Once the https API has stabilized, we will probably support it.

Bei der eingabemaske für passwörter steht sogar extra: Beachten Sie: Das Passwort wird unverschlüsselt gespeichert und übertragen!

Ich würde mal sagen dass man issues bei den verschiedenen osm-programmen aufmacht, die ein login unterstützen (falls https noch nicht unterstützt wird). Es ist jetzt nicht so, dass diese wichtige sicherheitsverbesserung von alleine an die ganzen programmierer durchdringt.
.........

Bei OAuth werden weder Login, noch Passwort unverschlüsselt übertragen, und dies ist auch seit längerem die Defaulteinstellung für neue Vespucci Installationen. M.a.W. du regst dich über ein Nicht-Problem auf.

Bei OAuth werden weder Login, noch Passwort unverschlüsselt übertragen, und dies ist auch seit längerem die Defaulteinstellung für neue Vespucci Installationen. M.a.W. du regst dich über ein Nicht-Problem auf.

Stimmt nicht, ich hab das aktuelle vespucci 9.4, und in den OAuth berechtigungen auf meiner OSM-Seite steht nichts von Vespucci. Mein Handy ist aber erst 2 Monate alt, und so sind die Apps auch erst vor kurzem installiert worden! Unter Server einstellungen ist im Standard-url kein https, und der haken bei "OAuth erlauben" ist nicht gesetzt! Ich hab das jetzt bei mir lokal geändert, beides sollte aber standardmäßig verwendet werden. Eigentlich sollte wie bei "OSMap Tuner" nur mehr OAuth, kein username/passwort bei programmen zur bearbeitung von OSM-Daten verwendet werden.

mfg, pointhi

pointhi wrote:

Bei OAuth werden weder Login, noch Passwort unverschlüsselt übertragen, und dies ist auch seit längerem die Defaulteinstellung für neue Vespucci Installationen. M.a.W. du regst dich über ein Nicht-Problem auf.

Stimmt nicht ...

Doch, ausser du hast zuerst eine uralt Version installiert (aus Gründen der Rückwärtskompatibiltät übernimmt Vespucci Settings die schon vorhanden sind) oder sonst was gemacht, dass du uns nicht sagst. Siehe auch http://code.google.com/p/osmeditor4andr … abase.java Zeile 86.

stimmt, ich nutze f-droid als app-store für OSS, welcher zu dem zeitpunkt mit der version noch zurückhinkte. Ein Info-Feld wo darauf aufmerksam gemacht wird dass man unsicher arbeitet hab ich aber nie zu gesicht bekommen (erinnere mich jedenfalls nicht daran, und wenn dann hätte ich es gleich aktiviert), und so werden wohl der großteil der user die vespucci vor August 2013 installiert haben (oder bei f-droid vor 24.01.2014) noch immer mit der alten methode authentifizieren, was einfach mal ins blaue geraten >80% der nutzer sein werden.

mfg, pointhi

pointhi wrote:

[...]so werden wohl der großteil der user die vespucci [...] noch immer mit der alten methode authentifizieren, was einfach mal ins blaue geraten >80% der nutzer sein werden.

Ich schaetze mal bei JOSM sieht es aehnlich aus. Dort ist die einfache Authentifizierung per cleartext username und password nach wie vor der default. Also nur wer was von OAuth weis und es aktiv einstellt kommt in den Genuss der erhoehten Sicherheit. Insofern wuerde ich auch bei JOSM vermuten das ein Grossteil der User bislang ein sehr unischere Methode verwendet haben. Insofern duerfte fuer JOSM die Einfuehrung von https fuer die API am meisten an Zugewinn bringen.

whb wrote:

gerade eben habe ich bemerkt, dass es möglich ist, verschlüsselt auf OpenStreetMap.org zu surfen und tatsächlich wurde vor wenigen Stunden TLS aktiviert:
http://blog.openstreetmap.org/2014/02/1 … r-privacy/

Solange diese elende Piwiki-Spyware auf openstreetmap.org eingebunden ist, dürfte sich der praktische Nutzen wohl in Grenzen handeln.
Piwiki ist per http eingebunden und dürfte damit wohl unverschlüsselt mitloggen, was Du Dir auf der Karte anschaust..

free_as_a_bird wrote:

Solange diese elende Piwiki-Spyware auf openstreetmap.org eingebunden ist, dürfte sich der praktische Nutzen wohl in Grenzen handeln.
Piwiki ist per http eingebunden und dürfte damit wohl unverschlüsselt mitloggen, was Du Dir auf der Karte anschaust..

Also für mich wird sie per https eingebunden: https://piwik.openstreetmap.org/piwik.js Immerhin ist das eine Analysesoftware, die bei openstreetmap läuft. Wäre google analytics eingebunden, wäre das eine ganz andere Sache (so wie beispielsweise bei den US-zentrierten iD-Entwicklern, die die aktuellste iD-Editor-Entwicklungsversion (hXXp://openstreetmap.us/iD/master/) bereitstellen).

aseerel4c26 wrote:

Also für mich wird sie per https eingebunden: https://piwik.openstreetmap.org/piwik.js

Hast ja recht.. Hatte mich verguckt, es ist https.

Am Sachverhalt änderts leider nur wenig: https verschlüsselt die Inhalte, alle Vögelchen auf der Leitung sehen aber weiterhin welche Urls Du aufrufst.
Anhand des OSM-Url-Formats, wie bspw. https://www.openstreetmap.org/#map=11/52.4194/13.2533, lässt sich dann ohne weiteres nachvollziehen, was Du gerade anschaust..
Die Metadaten lassen grüssen..

Von daher bleibe ich dabei, https bietet in diesem Zusammenhang hauptsächlich Pseudo-Sicherheit..

Die tiles mit https zu verschlüsseln ist für mich auch nicht ganz nachvollziehbar, bei der hauptseite dagegen werden bei jedem request unter anderem auch session-cookies übertragen, welche verschlüsselt sicher besser aufgehoben sind. Ein Verschlüsseln der genauen aufrufe von den einzelnen tiles wäre technisch sicher möglich, ob sinnvoll ist aber eine andere sache.

mfg, pointhi

free_as_a_bird wrote:

alle Vögelchen auf der Leitung sehen aber weiterhin welche Urls Du aufrufst.

Sie sehen welchen Server ich kontaktiere, nict die ganze URL.

free_as_a_bird wrote:

Anhand des OSM-Url-Formats, wie bspw. https://www.openstreetmap.org/#map=11/52.4194/13.2533, lässt sich dann ohne weiteres nachvollziehen, was Du gerade anschaust..

Was hinter dem "#" kommt, sähe man nicht mal wenn es unverschlüsselt wäre, das geht einfach nicht über die Leitung. Bei URLs der Form "lat=x&lon=y" sähe man es unverschlüsselt, mit https aber nicht.

Grüße, Max

pointhi wrote:

Die tiles mit https zu verschlüsseln ist für mich auch nicht ganz nachvollziehbar

Darüber liesse sich sonst ermitteln, ob du gerade z.B. die Umgebung eines Terroristen-Lagers betrachtest.

pointhi wrote:

Ein Verschlüsseln der genauen aufrufe von den einzelnen tiles wäre technisch sicher möglich, ob sinnvoll ist aber eine andere sache.

tile.openstreetmap.org unterstützt schon seit mehreren Tagen SSL 😉

maxbe wrote:

Sie sehen welchen Server ich kontaktiere, nict die ganze URL.

Richtig. Und das Erraten von Inhalten aufgrund der Größe sollte bei Kacheln sehr schwer sein, da alle etwa gleich groß sind. Und auch wenn man nur den weltweiten verschlüsselten Traffic erhöht oder die Nutzer ein Quäntchen für das Thema Verschlüsselung sensibilisiert, ist schon was gewonnen.

Weiter so!

pointhi wrote:

Die tiles mit https zu verschlüsseln ist für mich auch nicht ganz nachvollziehbar, bei der hauptseite dagegen werden bei jedem request unter anderem auch session-cookies übertragen, welche verschlüsselt sicher besser aufgehoben sind. Ein Verschlüsseln der genauen aufrufe von den einzelnen tiles wäre technisch sicher möglich, ob sinnvoll ist aber eine andere sache.

Ob einen das stoert oder nicht sei mal dahin gestellt. Aber in diversen NSA powerpoint Praesentationen wurde explicit darauf hingewiesen das google maps ein wichtige Datenquelle ist. Insofern glaubt zumindestens die NSA das in den maps Aufrufen wertvolle persoenliche Information enthalten sind.

Dennoch weit wichtiger duerfte sein endlich die Uebertragung von passwoertern im Klartext im Forum und per JOSM zu unterbinden. Denn so kann jeder klein Kriminelle im lokalen WLAN (z.B. im oeffentlichen hotspot) ohne Probleme das Passwort mitlesen. Und da nun mal viele (auch gegen die Empfehlungen) ihre Zugangsdaten wiederverwenden, kann dadurch schon ein echter Verlust entstehen und ist einfach nicht mehr Zeitgemaess.

Bei SPDY würde doch auch jeder Subrequest verschlüsselt sein. Ein Angreifer sieht also nur, dass einmalig eine Verbindung zu OSM aufgebaut wurde. Einziges Problem ist die Verteilung auf unterschiedliche Domains und Server.

derstefan wrote:

Und das Erraten von Inhalten aufgrund der Größe sollte bei Kacheln sehr schwer sein, da alle etwa gleich groß sind.

Wäre interessant zu untersuchen, ungeprüft würde ich das jedenfalls nicht behaupten. Vielleicht ist die Kombination "22221, 15448, 9496, 22493, 19901, 26685, 29469, 30141, 51895, 41911, 18669, 17437, 24589, 29549, 45767, 51255, 59079, 40114" (ein Bildschirm voll verschlüsselter München-Kacheln in Zoom 15, Reihenfolge beliebig) tatsächlich recht selten. Der Aufwand, das zu ermitteln und immer aktuell zu halten wäre hoch, aber "sauteuer" oder "irrsinnig aufwändig" ist ja kein Kriterium, hab ich in den letzten Monaten gelernt.

Grüße, Max

maxbe wrote:

Der Aufwand, das zu ermitteln und immer aktuell zu halten wäre hoch, aber "sauteuer" oder "irrsinnig aufwändig" ist ja kein Kriterium, hab ich in den letzten Monaten gelernt.

was derstefan in seinem Post wohl sagen wollte:

Jede verschlüsselte Seite - und sei die auch völlig harmlos - erhöht bei den "Interessenten" den Aufwand, überhaupt was rauszubekommen. Sie müssen dazu auch jeden "Quatsch" entschlüsseln um das DANACH verwerfen zu können. Wobei ich OSM natürlich nicht als Quatsch einstufen möchte 😉

Meine Worte: Jede HTTPS-Verbindung macht deren "Arbeit" schwerer.

Daher warte ich auf HTTPS auch bei dem Foren-Server.

Gruss
walter

Der einzige Grund, der gegen HTTPS spricht, ist, dass es rechenaufwändiger ist. Bei halbwegs modernen Prozessoren wird allerdings der Löwenanteil davon in Hardware gemacht, so dass man es in der Regel nicht merkt (und da spreche ich durchaus aus Erfahrung). Ich denke, in den meisten Fällen ist es einfach Träg- und Faulheit, die die Einführung behindert, oder eben die Kosten für ein gutes Zertifikat. Ich verstehe nicht, warum sich immer noch so viele Anbieter vor Verschlüsselung ziemen 🤔

Gruß

- Nadjita

Nadjita wrote:

Ich denke, in den meisten Fällen ist es einfach Träg- und Faulheit, die die Einführung behindert, oder eben die Kosten für ein gutes Zertifikat.

Ich betreibe ja auch meine eigenen Seiten und diese auf eigener Hardware. Technisch kein Problem auf HTTPS umzusteigen (ok, ein wenig Erfahrung fehlt da noch bei mir). Nur hab ich noch keine Zeit gefunden, ein günstiges aber gleichwohl von allen Browsern akzeptiertes Zertifikat zu bekommen.

Mal sehen, das Jahr ist noch lang (und die NSA ist immer -noch- dabei)

Gruss
walter

Ich zahle für meine Zertifikate 1,99€ pro Monat. Das finde ich gerade noch so erträglich. Ob das günstig ist, kann ich nicht sagen.

Nadjita wrote:

Ich zahle für meine Zertifikate 1,99€ pro Monat.

Wo? Edit: Also bei bei welchem Anbieter? Und wird das auch in allen Browsern unterstützt?

Nadjita wrote:

Ich zahle für meine Zertifikate 1,99€ pro Monat. Das finde ich gerade noch so erträglich. Ob das günstig ist, kann ich nicht sagen.

glaub schon. ich zahle 1€/Monat für Domain, 5€/Monat für IP4->IP6-Tunnel und 1€/Tag für Strom, da fallen die 2€ mehr wohl auch nicht ins Gewicht.

Wo?

Gruss
walter

Ich weiß nicht, ob ich das posten darf, oder ob sich dann jemand beschwert, dass es Werbung ist. Zumal ich zufällig auch noch beim Anbieter arbeite 😐

wambacher wrote:

Nur hab ich noch keine Zeit gefunden, ein günstiges aber gleichwohl von allen Browsern akzeptiertes Zertifikat zu bekommen.

Mal sehen, das Jahr ist noch lang (und die NSA ist immer -noch- dabei)

Sehr richtig. Ein unterschriebenes Zertifikat kostet leider Geld. Auf unserem Server kommt deshalb vorerst ein selbstsigniertes Zertifikat zum Einsatz. (Diskussion)

Die NSA & Co. werden niemals damit aufhören, weil: es geht. Aber wir können es ihnen richtig schön teuer machen.

Noch ein anderer Punkt: Wie seht ihr das? Soll ein Server automatisch auf https umleiten? Oder nimmt man damit dem Nutzer die Entscheidungsfreiheit?
Ich plädiere eigentlich für eine Zwangsumleitung, sofern das Zertifikat gültig unterschrieben ist, da die Nutzer moderner Browser keinen Klick mehr benötigen und vom Verhalten keinerlei Unterschiede sehen.

edit: word order

Nadjita wrote:

Ich weiß nicht, ob ich das posten darf, oder ob sich dann jemand beschwert, dass es Werbung ist. Zumal ich zufällig auch noch beim Anbieter arbeite 😐

schon mal was von PN gelesen?

derstefan wrote:

Noch ein anderer Punkt: Wie seht ihr das? Soll ein Server automatisch auf https umleiten? Oder nimmt man damit dem Nutzer die Entscheidungsfreiheit?
Ich plädiere eigentlich für eine Zwangsumleitung, sofern das Zertifikat gültig unterschrieben ist, da die Nutzer moderner Browser keinen Klick mehr benötigen und vom Verhalten keinerlei Unterschiede sehen.

auf jeden Fall! Das wollte ich schon am Anfang dieser Diskussion vorschlagen; mir fehlte nur der Fachbegriff für dieses Verfahren.

Gruss
walter

derstefan wrote:

Noch ein anderer Punkt: Wie seht ihr das? Soll ein Server automatisch auf https umleiten? Oder nimmt man damit dem Nutzer die Entscheidungsfreiheit?

Lis Dir mal das hier durch, davon halte ich mehr als von Zwangsumleitung. Also kurz gesagt: wer HTTPS anbietet, muss, finde ich, nicht HTTP anbieten.

wambacher wrote:

schon mal was von PN gelesen?

Hast Du scheinbar deaktiviert, ich kann Dir keine schreiben.

derstefan wrote:

Soll ein Server automatisch auf https umleiten?

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.

Nadjita wrote:

wambacher wrote:

schon mal was von PN gelesen?

Hast Du scheinbar deaktiviert, ich kann Dir keine schreiben.

Hier im Forum gibt's gar keine, und auf osm.org kann man sie nicht deaktivieren 😉

/e: typo

rayquaza wrote:

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

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 🙄

Nadjita wrote:

wambacher wrote:

schon mal was von PN gelesen?

Hast Du scheinbar deaktiviert, ich kann Dir keine schreiben.

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

rayquaza wrote:

Zum Zertifikat: Wenn man es irgendwie überprüfen kann

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. ;-)

Nadjita wrote:

Der einzige Grund, der gegen HTTPS spricht, ist, dass es rechenaufwändiger ist. Bei halbwegs modernen Prozessoren wird allerdings der Löwenanteil davon in Hardware gemacht, so dass man es in der Regel nicht merkt (und da spreche ich durchaus aus Erfahrung).

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.

maxbe wrote:

derstefan wrote:

Und das Erraten von Inhalten aufgrund der Größe sollte bei Kacheln sehr schwer sein, da alle etwa gleich groß sind.

Wäre interessant zu untersuchen, ungeprüft würde ich das jedenfalls nicht behaupten. Vielleicht ist die Kombination "22221, 15448, 9496, 22493, 19901, 26685, 29469, 30141, 51895, 41911, 18669, 17437, 24589, 29549, 45767, 51255, 59079, 40114" (ein Bildschirm voll verschlüsselter München-Kacheln in Zoom 15, Reihenfolge beliebig) tatsächlich recht selten.

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

whb wrote:

OAuth geht übrigens nicht über https: [JOSM-Ausgabe]

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.

Nadjita wrote:

rayquaza wrote:

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

Ja, aber man kann E-Mails über das Forum senden.

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.

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

Wohl erst ab einer zukünftigen so richtig.

Nahmd,

amm wrote:

Dennoch weit wichtiger duerfte sein endlich die Uebertragung von passwoertern im Klartext im Forum und per JOSM zu unterbinden. Denn so kann jeder klein Kriminelle im lokalen WLAN (z.B. im oeffentlichen hotspot) ohne Probleme das Passwort mitlesen. Und da nun mal viele (auch gegen die Empfehlungen) ihre Zugangsdaten wiederverwenden, kann dadurch schon ein echter Verlust entstehen und ist einfach nicht mehr Zeitgemaess.

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 <syn> meines Angriffsziels ein gefaktes <rst> 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)

Netzwolf wrote:

(3) Man in the middle.

Hier ist ein selbst unterschriebene Zertifikat tödlich.

[…]

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

Du hast verloren.

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

rayquaza wrote:

Wohl erst ab einer zukünftigen so richtig.

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

chris66 wrote:

rayquaza wrote:

Wohl erst ab einer zukünftigen so richtig.

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.

pointhi wrote:

.......
...., ich hab das aktuelle vespucci 9.4, .......

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/osmeditor4andr … tail?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.

amm wrote:

Das forum waere dann demnaechst glaube ich der letzt osm.org Service der nicht per https zu erreichen ist

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!

amm wrote:

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.

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/ … 65517.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

aromatiker wrote:

Sind die OSM-Server auch vom Hearbleed-Bug http://www.heise.de/newsticker/meldung/ … 65517.html betroffen ?

"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 … .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.

Es scheint hier irgendwie ein Misverständnis vorzuliegen. Das Fiese an heartbleed ist das es überhaupt nicht vom sicheren oder nicht-sicheren Betrieb der Dienste abhängt, wenn überhaupt ist es eher so, dass Betriebe die versucht haben alles möglichst sicher zu machen mehr davon betroffen sind. Weiter ist es nicht nötig irgendwo einzubrechen oder sonst irgendwie gross Spuren zu hinterlassen um den Fehler auszunutzen.

Das Forum ist anscheinend auch über https erreichbar, aber der Apache ist noch nicht zu Ende konfiguriert. Dürfen wir weiter auf Verschlüsselung hoffen? 🙂

Glenn Greenwald schildert in seinem druckfrischen Buch äußerst treffend, wie lange er aus reiner Faulheit mit der Verschlüsselung seiner privaten Kommunikation (v.a. Mail) gezögert hat und Snowden ihn (noch anonym) über Wochen und Monate dazu ermahnt hat. Dieses Verhalten ist bei wirklich jedem zu beobachten. Wir scheren uns nicht darum, weil es halt keine direkten, negativen Auswirkungen mit sich zieht. Bitte, bitte, verschlüsselt alles, was geht! 😎

derstefan wrote:

Das Forum ist anscheinend auch über https erreichbar, aber der Apache ist noch nicht zu Ende konfiguriert. Dürfen wir weiter auf Verschlüsselung hoffen? 🙂

AFAIK ist das Forum noch nicht gezügelt (d.h. auf OSMF Infrastruktur).

Passiert bald was? Ich bin es leid, Passwörter im Klartext zu übertragen! Langsam vergeht mir die Lust, mich hier nochmal einzuloggen. 😠

derstefan wrote:

Passiert bald was? Ich bin es leid, Passwörter im Klartext zu übertragen! Langsam vergeht mir die Lust, mich hier nochmal einzuloggen. 😠

Nimm halt ein andres Passwort als bei PayPal, dann ist es nicht so schlimm 😉