Nachricht über TCP/IP

Wenn Du gerade ein künstliches Wesen erschaffen hast, dass zum ersten mal läuft und Du nicht willst, dass die Konkurrenz... ach lassen wir das...

Wenn man nicht die Identität beweisen kann, hilft Verschlüsselung nicht ganz soviel. Darum haben wir ja SSL. Warum also das Rad neu erfinden? Abgesehen davon, siehe oben.
Und warum A5, meinst Du das ironisch? Es erfüllt vielleicht seinen Zweck, aber wenn mich nicht alles täuscht ist es in Software relativ ineffizient. Und der Sicherheit sollte man auch nicht unbedingt vertrauen. Es gibt genug Alternativen, die mindestens genauso sicher sind.

Ich meinte den gesamten Beitrag ironisch.

Davon abgesehen meine ich schon, dass es sehr viel hilft, wenn ich nicht die Applikation eines anderen (darum geht es, nicht um Abfrage eines Forums) fernsteuern kann.

Eben. Die Login-Daten werden auch unverschlüsselt übertragen. Und nun?
Fahrlässigkeit seitens des Betreibers? Wir werden alle sterben.

Es stellt sich die Frage, welche Kommunikation genau stattfinden soll.
Für ein einfaches 'Content aktualisiert' worauf die App mit '-reloadData' reagiert halte ich für nicht so schützenswert, dass ich den Aufwand mit SSL und eigenem Zertifikatgedöns auf mich nehmen würde.
Vielleicht noch ne kleine SSH-Verbindung, sofern simpel möglich. Det wars aber auch.


Eigene Leidensgeschichte oder bist du durch diese Spionage reich geworden?

klausel schrieb:

Lucas de Vil schrieb:

Es stellt sich die Frage, welche Kommunikation genau stattfinden soll.
Für ein einfaches 'Content aktualisiert' worauf die App mit '-reloadData' reagiert halte ich für nicht so schützenswert, dass ich den Aufwand mit SSL und eigenem Zertifikatgedöns auf mich nehmen würde.

Kommt auf den Content an, gell?[…]

Zumal ja der große Vorteil darin liegen soll, die Meldung menschenlesbar zu übertragen. (Sonst macht telnet überhaupt keinen Sinn.) Hmm, was macht die App wohl damit? Anzeigen?

Ich würde jedenfalls testweise "ERSTER FUSSBALLCLUB KÖLN" an jedes iPhone übertragen, welches sich im Großraum Mönchengladbach befindet.

klausel schrieb:

zerm schrieb:

Ich sehe kein Problem mit dem Telnet Protokoll, abgesehen davon, dass es im Klartext überträgt. Wie auch viele andere Protokolle. Etwa HTTP. Dieses Forum. Lese ich auch unterwegs, mit iPhone, ohne SSL.

Das Problem von Telnet hast Du ja schon richtig erkannt. Es ist unverschlüsselt. Dassselbe gilt für HTTP. Wenn Du zu den Leuten gehört, denen Verschlüsselung egal ist, weil sie nichts zu verbergen haben, können wir die Diskussion hier beenden. Wenn nicht, dann erkläre mir mal bitte, warum unverschlüsselt der Standard sein soll. Was spricht gegen Verschlüsselung? Damit kommen wir zum nächsten Absatz.

Es gibt Daten, die nicht so sensibel sind, und diese muss man nicht verschlüsseln. Im Prinzip schadet natürlich eine Verschlüsselung in der Regel nicht, jedoch zieht sie unter Umständen andere Nachteile mit sich, wie etwa einen (unnötig!) höhere CPU Last. Ausserdem wird der Code komplizierter und unter Umständen auch anfälliger.
Gutes Beispiel ist dieses Forum, hier wäre eine Verschlüsselung absolut sinnfrei, weil ohnehin jeder auf den Inhalt zugreifen kann (abgesehen von den Zugangsdaten). Geht man davon aus, dass alle Nutzer ihre Passwörter ausschliesslich für dieses Forum verwenden, wäre eine Kompromittierung eines Accounts (welcher, durch Sniffing des Traffics auch unverschlüsselt ziemlich aufwändig ist!) kaum kritisch und das wäre schon das Worst-case-Szenario.

Dazu kommt, das wir uns fragen müssen, gegen welche Berdohung wir überhaupt sicher sein wollen. Es ist ja nicht eine binäre Entscheidung Verschlüsselt=Sicher oder Unverschlüsselt=Unsicher. Etwa den Traffic zu diesem Forum mitlesen können nur wenige, ausgewählte Personen - schon rein physisch. Entsprechend ist der Aufwand für einen Angreifer hier nicht zu vernachlässigen.
Das kann man aber alles weiter spinnen. Haben wir jetzt SSL Verschlüsselung mit Self-signed Cert, kann ein Angreifer einen MITM Angriff durchführen, also nichts gekonnt.
Haben wir korrekte Zertifikate, kann ein Angreifer den Server selbst kompromittieren (etwa auch durch physischen Zugriff, in dem er im Rechenzentrum einbricht). Also auch nichts gekonnt.
Ist nur der Server absolut bullet-proof, kompromittiert der Angreifer halt den Client-Rechner auf anderem Wege. Also auch nichts gekonnt.
Ist auch dieser absolut sicher, schickt er halt Schläger bei Deiner Mutti vorbei.
Schicken wir jetzt also unsere Mutti in Sicherheit, damit niemand sie bedrohen kann, um damit unser Passwort für osxentwicklerforum.de herauszugeben? Nein? Sollte doch aber unter Strafe vorgeschrieben werden, oder nicht?

klausel schrieb:

1. SSL erzeugt eine deutliche CPU Last. Darum gibt es etwa auch SSL-Hardwaremodule für grosse Server. Kann sich aber nicht jeder leisten. Also, SSL kostet viel Geld und verschmutzt die Umwelt (wenn das Rechenzentrum nicht Ökostrom verwendet).

Auf einem Hochlast-Webserver mit vielen parallelen Verbindungen erzeugt SSL in der Tat eine erhebliche Last. Da setzt man dann einen SSL-Terminator vor oder lässt es vom Load Balancer abfackeln. Ob Verschlüsselung im jeweiligen Kontext sinnvoll ist, entspringt dem spezifischen Risk Management. In Zusammenhang mit einer iPhone-App von einer "deutlichen" Last zu sprechen, ist allerdings Unsinn. Ab zum nächsten Absatz.

Achso, nur ein Server und nur ein Nutzer mit einem iPhone, oder was? Und dann ists doof, wenn doch ein paar mehr leute die App benutzen und der Server in die Knie geht?

klausel schrieb:

2. SSL kostet auch ordentlich Leistung auf dem iPhone. Also kürzere Akkulaufzeit und dadurch wieder Umweltverschmutzung.

Wie viele parallele SSL-Verbindungen wird eine App wohl aufbauen? Eine? Zehn? Hundert? Tausend? Zeig mal mir mal bitte die "ordentlich Leistung" durch eine SSL-Verbindung. Die Verkürzung der Akkulaufzeit in Minuten würde mich ebenso interessieren.
Der Hinweis auf Umweltverschmutzung ist nur Polemik. Wenn es danach geht, dürftest Du keinen Rechner verwenden und vor allen Dingen keine wertvolle Energie mit dem Posten sinnloser Beiträge in diesem Forum verbringen.

Das kommt auf die Anwendung an. Zur Leistung kann ich nichts sagen, da ich es nicht gemessen haben und es vom Profil der Anwendung abhängt. Ich schätze aber einfach mal, dass es nicht vernachlässigbar ist, vielleicht sogar um die 5%. Die Sache mit dem Umweltschutz ist natürlich etwas polemisch, aber verteilt auf alle iPhones Weltweit und alle Server, die auch diesen Mehraufwand betreiben müssen, kommt da schon etwas zusammen.

klausel schrieb:

3. SSL ist wenig sinnvoll, ohne korrekte Zertifikate. Die kann und will sich nicht jeder leisten. Oder willst Du behaupten, dass man schon durch SSL alleine plötzlich "sicher" ist? Das wäre auch entweder fahrlässig oder boshaft.

Wo habe ich geschrieben, dass SSL ohne ein von einer vertrauenswürdigen CA signiertes Zertifikat verwendet werden soll? Überdies erkläre mir mal, wo die Gefahr durch den Einsatz eines selbsterstellten und selbstsignierten Zertifikates liegt.

Du redest davon, das es fahrlässig sei, prinzipiell unverschlüsselt zu kommunizieren. Ich wollte nur darauf hinweisen, dass eine sinnvolle Verschlüsselung auch nicht "frei Haus" kommt.
Wenn Dir die Gefahr von selbst-signierten Zertifikaten nicht klar ist, disqualifizierst Du dich eigentlich für jede weitere Diskussion. Ich dachte, Kryptographie sollte zur Allgemeinbildung gehören, wie Du selbst getönt hattest?
Du kannst ja mal mit Chrome auf eine Webseite mit self-signed Cert gehen. Der erklärt Dir ganz gut in Ansätzen, was das Problem ist.

klausel schrieb:

4. Folglich ist abzuwägen, ob eine solche Verschlüsselung überhaupt notwendig ist.

Die Frage nach Verschlüsselung richtet sich primär nach dem Schutzbedarf und nicht nach windigen Argumenten wie CPU-Last und Umweltverschmutzung. Darüber hinaus bin ich ja noch auf die Antwort gespannt, warum "unsicher" die erste und "sicher" nur die zweite Wahl ist.

Ach? Ich hatte nichts anderes behauptet. Du wolltest unverschlüsselte Kommunikation unter Strafe stellen, ungeachtet des Schutzbedarfs.

klausel schrieb:

Das musst Du mir auch noch einmal genauer erklären. A5 ist jetzt sicherlich nicht die Krönung der Schöpfung, aber erfordert doch einiges an Aufwand (Kapital), um da durch zu kommen. IMSI-Catcher kann man sich auch für nicht ganz so wenig Geld bauen. Aber dennoch - Was für Bedrohungsszenarien siehst Du hier? Und glaubst Du, solche Angreifer lassen sich durch ein Self-signed SSL Cert irgendwie bremsen? Und warum sollte ich meinem ISP, irgendeinem ISP mehr trauen, als dem mobilen Transportweg?

Was hast ein IMSI-Catcher mit dem Problem dieses Threads zu tun? Das Vertrauen, dass Du Deinem ISP gegenüber entgegenbringst, liegt in diesem konkreten Fall darin, dass er den Transportweg schlichtweg nicht kompromittieren muss, um an sensible Daten zu gelangen. Der ISP hat daher mit diesem Beispiel genauso wenig zu tun wie der IMSI-Catcher. Im Rahmen eines Risk Managements wirst Du Deinen ISP sorgfältig ausgewählt haben und über entsprechende AGB oder SLAs sicherstellen können, dass er sorgfältig mit Deinen Daten umgeht. Dass Du dies mit den Leuten im selben Hotspot auch gemacht hast, wage ich stark zu bezweifeln, gerade in einer Zeit, in der das Sniffen von iPhone-Traffic zum Volkssport wird.

Ach, dir geht es um Hotspots. Ich dachte, Du meinst GSM/UMTS. Gut, hier wird es etwas problematisch, zugegeben. Aber wenn ich hier schon dem Hotspot kein deut vertrauen kann, sollte man auf alles gefasst sein. Hier bietet sich dann etwa eine VPN Verbindung an (die natürlich auch Last erzeugt etc. etc. aber für sämtliche Sniffer alle weiteren Informationen versteckt. Einfach nur SSL hat hier ja schon das Problem, dass Angreifer zumindest erfahren, oder raten können, auf welchen Seiten sich jemand herumtreibt. Je nach Geschick ist evtl. sogar ein MITM-Angriff machbar, müsste ich nochmal drüber nachdenken).

klausel schrieb:

Kommt auf den Content an, gell? Was passiert, wenn man das dämlichste aller Argumente ("KRYPTO IST NUR FÜR TERRORISTEN!!!!11) als Mantra seiner Arbeit verwendet, sieht man an der ePass-App. Sauber die Update-Funktion verkackt. Äh, Ausnahme? Nein!

Ich kann nur mit dem Kopf schütteln. Jetzt führst Du schon selbst die Ausweis-App an, die gezeigt hat, dass selbst mit korrekten Zertifikaten SSL nicht sicher ist, wenn man es falsch anstellt, und dann fragst Du allen ernstes

klausel schrieb:

Überdies erkläre mir mal, wo die Gefahr durch den Einsatz eines selbsterstellten und selbstsignierten Zertifikates liegt.

Du meinst, weil SSL bei falscher Nutzung auch unsicher sein kann, sollte man gleich unverschlüsselt übertragen? Etwas fatalistisch.

So gesehen hast Du natürlich recht.
Ich wollte aber darauf hinaus, dass wenn keine sensiblen Daten übertragen werden, also eine Verschlüsselung ohnehin nicht erforderlich ist, braucht man auch kein SSL, da es unter Umständen nur den Anschein von Sicherheit bringt, dafür aber Leistung, Akku und Nerven kostet. Genausogut könnte man seinen Datenstrom auch einfach mit 0xDEADF007 XORen.
Weil: Wenn meine Daten ohnehin nicht so Schutzbedürftig sind, liegt es nahe, als Entwickler keine grosse Sorgfalt walten zu lassen bei der Umsetzung des Protokolls. Damit habe ich dann aber rein gar nichts gekonnt, und kann es tatsächlich genausogut sein lassen. Um die tausenden "Hobby-Hacker" abzuschrecken reicht dann wirklich ein XOR mit 0xDEADF007

klausel schrieb:

Na, wo ist denn die Sicherheitslücke gegenüber der Verwendung eines vertrauenswürdig signierten Zertifikates? Mir wiederholt das Stellen der Frage vorzuwerfen, ist keine Antwort.

Aus meiner Sicht ist es recht einfach: selbst Zertifikate erstellen kann jeder. Ist ja der große Vorteil beim Selbermachen.

Wie erkennt jetzt der Anwender, dass das selbst erstellte Zertifikat vertrauenswürdig ist?
Kann ja jeder selbst erstellt haben.

Wenn die Sache auf deinem eigenen an eine feste IP gebundenen Server läuft, okay.
Mir kommen beim Thema 'selbst erstellte Zertifikate' wieder grauenhaft schreckliche Erinnerungen an Beiträge, in denen mittels DynDNS und selbst erstellten SSL-Zertifikaten die ultimativ unumgehbare Sicherheit gewährleistet werden sollte.

Fazit: Die Sicherheitslücke bei selbst erstellten Zertifikaten gegenüber die von 'vertrauenswürdig signierten' Zertifikaten ist dieselbe.
Falscher Umgang damit endet in einer Katastrophe.

Die Wahrscheinlichkeit, dass Herr 'Ich hab keine Ahnung von dem Scheiß, aber ich bin geizig und im Internet gibts ja etliche Tutorials für selbst erstellte Zertifikate' mehr Scheiß anrichtet als Herr 'Ich hab keine Ahnung von dem Scheiß, also wende ich mich gegen Bezahlung an ein Unternehmen, dass sich damit auskennt.' ist signifikant höher.

'Selber machen' verleitet Menschen sehr häufig zum Pfuschen. Das ist der Hauptnachteil, den ich an der Sache sehe.

klausel schrieb:

Die Frage ist gar nicht so abwegig. Das Vorgaukeln einer nicht vorhandenen Sicherheit kann mehr Schaden anrichten als fehlende Sicherheit, wenn letzteres bekannt ist.

Erinnert mich an die Airbag-Diskussion. Wüsste Mensch, dass statt Airbags ein 20cm langer, 15cm starker Metalldorn aus dem Lenkrad geschossen kommt, der einen sofort hinrichtet, würde die Fahrweise entsprechend angepasst. Es ist kein Zufall, dass mit steigender Sicherheit der Kraftfahrzeuge die Anzahl der Unfälle steigt.
Ich weiß nicht, wie eine Statistik schlimmer aussieht: 50 Unfälle im Jahr mit 200 Toten oder 200.000 Unfälle im Jahr mit 200 Toten.

Sicherheit erhöht immer auch die Risikobereitschaft. Ich weiß, dass die Kennwortübertragung ans Forum unsicher ist. Ich passe also besser auf, was ich tue.
Würde mir vorgegaukelt alles wäre perfekto verschlüsselt wäre ich vielleicht nachlässiger.

klausel schrieb:

zerm schrieb:

Es gibt Daten, die nicht so sensibel sind, und diese muss man nicht verschlüsseln.

Das ist die korrekte Formulierung. Die Fragestellung muss immer lauten: Ist es notwendig, diese Daten zu verschlüsseln? Die Fragestellung lautet aber leider immer noch allzu oft: Wozu brauche ich Verschlüsselung? Der Hinweis auf die Benutzung von Telnet für eine Client/Server-App ist eben genau diese falsche Fragestellung.

Kann ich nicht nachvollziehen. Du hast zum einen überhaupt erst den Sicherheitsaspekt ins Spiel gebracht, der mit dem Thema nichts zu tun hatte. Für die Entwicklung halte ich es durchaus für sinnvoll, unverschlüsselt zu beginnen, bis alles läuft, da man sich einiges an zusätzlichen Fehlerquellen erspart. Schon damit angefangen, dass man selbst, sofern man es richtig macht, den eigenen Traffic zwischen Client und Server nicht sniffen kann, um so Probleme aufzuspüren. Wenn das Protokoll steht, und die Anwendung funktioniert, kann man immernoch auf eine Verschlüsselung umstellen. Jemandem, der zu diesem Zweck Telnet empfiehlt, vorzuwerfen, das sei "fahrlässig" erschliesst sich mir nicht.

Anders sieht es natürlich aus, wenn man eine Anwendung entwickelt, die mit sensiblen Daten umgehen soll, und ausschliesslich Verschlüsselung in Frage kommt. Dann kann es durchaus sinnvoll sein, von Begin an damit zu arbeiten, um die zusätzlichen Aspekte gleich mit zu betrachten. Davon war hier aber nirgends die Rede.

klausel schrieb:

zerm schrieb:

Im Prinzip schadet natürlich eine Verschlüsselung in der Regel nicht, jedoch zieht sie unter Umständen andere Nachteile mit sich, wie etwa einen (unnötig!) höhere CPU Last. Ausserdem wird der Code komplizierter und unter Umständen auch anfälliger.

Gerade bei der Verwendung der Cocoa-API, bzw. CFNetwork ist die erhöhte Komplexität gegenüber dem Sicherheitsgewinn durch die Verschlüsselung durchaus zu vernachlässigen. Und auch das direkte Programmieren gegen OpenSSL ist nicht so aufwendig, als dass durch diesen Code Sicherheitslücken in der Applikation selber entstünden. Letzteres birgt wohlgleich die Gefahr der falschen Anwendung, und eine vermeindlich sicher SSL-Verbindung mit NULL-Ciphers bringt mehr Schaden als Nutzen.

Hier gibt es aber einige Dinge zu wissen und zu beachten, etwa das Prüfen der Zertifikate bzw. des Fingerprints. Dazu kommt, dass ein Debugging schwieriger wird (siehe oben). Das es nicht schwierig ist, wenn man sich auskennt, will ich gar nicht bezweifeln, aber von jedem Entwickler zu verlangen, sich in die Thematik einzuarbeiten, nur damit irgendwas abgesichert wird, was ohnehin niemanden interessiert, will ich so nicht unterschreiben.

klausel schrieb:

zerm schrieb:

Gutes Beispiel ist dieses Forum, hier wäre eine Verschlüsselung absolut sinnfrei, weil ohnehin jeder auf den Inhalt zugreifen kann (abgesehen von den Zugangsdaten). Geht man davon aus, dass alle Nutzer ihre Passwörter ausschliesslich für dieses Forum verwenden, wäre eine Kompromittierung eines Accounts (welcher, durch Sniffing des Traffics auch unverschlüsselt ziemlich aufwändig ist!) kaum kritisch und das wäre schon das Worst-case-Szenario. Dazu kommt, das wir uns fragen müssen, gegen welche Berdohung wir überhaupt sicher sein wollen. Es ist ja nicht eine binäre Entscheidung Verschlüsselt=Sicher oder Unverschlüsselt=Unsicher. Etwa den Traffic zu diesem Forum mitlesen können nur wenige, ausgewählte Personen - schon rein physisch. Entsprechend ist der Aufwand für einen Angreifer hier nicht zu vernachlässigen.

Wie Du selber schreibst, ist es keine binäre Entscheidung. Wie sieht es denn mit Wikipedia aus? Oder Google? Würdest Du da die SSL-Version verwenden? Ich schon. Es geht niemandem im selben Hotspot, und auch nicht den Proxy-Admin des jeweiligen, von mir verwendeten LAN etwas an, was ich bei Google suche oder welche Artikel ich gerade bei Wikipedia anschaue. Es geht nicht immer nur um Kompromittierung. Information Leakage kann eine schwerwiegende Sicherheitslücke sein, auch und häufig insbesondere bei scheinbar unbedeutenden Daten. Es sind die Puzzlestücke, aus denen ein gezielt vorgehender Angreifer sein Schwert schmiedet.

Ich habe das Gefühl, Du denkst, Du bist mit SSL immer auf der sicheren Seite. Hier gibt es noch tausend andere "Angriffsvektoren", etwa durch diese schönen 1x1px Bilder, um Nutzer zu tracken. Cookies und Referer. Damit kann man Dich trotz SSL immernoch wunderbar tracken, und macht das auch. Kannst ja mal beobachten, wie fleissig Amazon etwa so Daten sammelt. Da hilft aber auch kein SSL, ausser, dass es deinem Proxy-Betreiber nicht mehr so einfach fällt, aber den interessiert das ohnehin weniger als etwa Amazon. Und die haben, wie gesagt, andere Methoden.
Davon abgesehen empfehle ich Dir einen anonymen VPN Anbieter, wie etwa perfect privacy. Damit bist Du nicht auf SSL angewiesen, damit dein (W)LAN-Proxy-Betreiber nichts mitbekommt.

klausel schrieb:

zerm schrieb:

Das kann man aber alles weiter spinnen. Haben wir jetzt SSL Verschlüsselung mit Self-signed Cert, kann ein Angreifer einen MITM Angriff durchführen, also nichts gekonnt.

Das kann er auch mit einem von einer vertrauenswürdigen CA signierten Zertifikat. In beiden Fällen liegt es an der Toleranz der Applikation und des Users, ob der Angriff erfolgreich ist - Implementierungsfehler außer Acht gelassen (siehe NULL-Prefix-Bug).

Du wirst keine CA finden, die Dir ein Cert auf "www.microsoft.com" ausstellt. Wenn doch, schick mir bitte eine PM.
Und Toleranz der Anwendung ist "Nie eine Warnmeldung" gegen "Plötzlich eine Warnmeldung" im Falle von korrekten Zertifikaten und bei self-signed gibt es "immer eine Warnmeldung". Warum sollte man hier grosse Toleranz üben, wenn man doch so auf Sicherheit bedacht ist?

klausel schrieb:

zerm schrieb:

Haben wir korrekte Zertifikate, kann ein Angreifer den Server selbst kompromittieren (etwa auch durch physischen Zugriff, in dem er im Rechenzentrum einbricht). Also auch nichts gekonnt.
Ist nur der Server absolut bullet-proof, kompromittiert der Angreifer halt den Client-Rechner auf anderem Wege. Also auch nichts gekonnt.
Ist auch dieser absolut sicher, schickt er halt Schläger bei Deiner Mutti vorbei.
Schicken wir jetzt also unsere Mutti in Sicherheit, damit niemand sie bedrohen kann, um damit unser Passwort für osxentwicklerforum.de herauszugeben? Nein? Sollte doch aber unter Strafe vorgeschrieben werden, oder nicht?

Es wäre mir neu, wenn ein Programmierer innerhalb seines Programmes auf die physische Sicherheit eines RZ, die Hardware des Servers oder die Verschwiegenheit seiner Mutti Einfluss nehmen könnte. Diese Dinge sind bei der sicherheitstechnischen Betrachtung einer Applikation out-of-scope und somit nicht relevant.

Da gibt es so einen schönen Cartoon von xkcd, der alles sagt: xkcd.com/538/
Oder so: Nur weil ich irgendwo 4096bit RSA verwende, bin ich nicht automatisch absolut sicher vor allem und jedem. Wenn ich davon ausgehe, dass ich mit sehr sensiblen Daten umgehe, muss ich tatsächlich die Sicherheit des RZ und die Verschwiegenheit der Mutti beachten. Ist meines Wissens nach auch so üblich.
Hast Du eigentlich immer Pfefferspray dabei, wenn Du Dich in solchen öffentlichen Hotspots rumtreibst? Der Angreifer hätte ja deutlich einfacheres Spiel, dir eins überzubraten, da kannste Dein SSL sonstwohin stecken.
Kostet kaum Geld und man muss auf alles gefasst sein, wie Du weiter unten geschrieben hast.

klausel schrieb:

zerm schrieb:

Das kommt auf die Anwendung an. Zur Leistung kann ich nichts sagen, da ich es nicht gemessen haben und es vom Profil der Anwendung abhängt. Ich schätze aber einfach mal, dass es nicht vernachlässigbar ist, vielleicht sogar um die 5%.

Schätzen ist natürlich sehr fundiert für diese Argumentation. Prüfe es doch einfach nach. Installier Dir "Whatsapp" und jabber mal eine Stunde mit und eine Stunde ohne SSL. Und guck Dir zwischendurch mit iStat den Speicher an.

Auf meinem iPhone laufen kein Apps mehr (lange Geschichte...) Aber Du willst mich doch überzeugen, dass SSL rein gar keine Nachteile hat, oder?

(hihi, mehr als 10,000 Zeichen und das Forum will das nicht. Hier die Fortsetzung)

klausel schrieb:

zerm schrieb:

Wenn Dir die Gefahr von selbst-signierten Zertifikaten nicht klar ist, disqualifizierst Du dich eigentlich für jede weitere Diskussion. Ich dachte, Kryptographie sollte zur Allgemeinbildung gehören, wie Du selbst getönt hattest?
Du kannst ja mal mit Chrome auf eine Webseite mit self-signed Cert gehen. Der erklärt Dir ganz gut in Ansätzen, was das Problem ist.

Das ist keine Antwort auf meine Frage.

Soll ich den Text Copy&Pasten?

klausel schrieb:

klausel schrieb:

Ach? Ich hatte nichts anderes behauptet. Du wolltest unverschlüsselte Kommunikation unter Strafe stellen, ungeachtet des Schutzbedarfs.

In der Tat habe ich mich unklar ausgedrückt. Das Paradigma muss grundsätzlich "secure by default" sein. Und wenn man davon abweichen möchte, muss es dafür gute Gründe geben.

Aus diesem Grund verwendest Du auch OpenBSD im Hardcore-Sicherheits-Modus?

klausel schrieb:

klausel schrieb:

Ach, dir geht es um Hotspots. Ich dachte, Du meinst GSM/UMTS. Gut, hier wird es etwas problematisch, zugegeben. Aber wenn ich hier schon dem Hotspot kein deut vertrauen kann, sollte man auf alles gefasst sein.

Fast richtig. Man sollte nicht auf alles gefasst sein, man muss auf alles gefasst sein - was innerhalb des beeinflussbaren Bereiches liegt. Zumindest vorher beim Risk Manamangent. Ob man hinterher auch alles umsetzt, entscheidet der Herr mit dem Geldbeutel.

Huh? Du planst also vorher, wie Du deine Mutti in Sicherheit bringen kannst, falls die Bösen Menschen kommen, machst es dann aber doch nicht, weil Mutti in Urlaub zu schicken zu teuer ist?

Na, sind wir uns ja grösstenteils einig.
Ich denke aber immer noch, dass man gerne Telnet bzw. ein unverschlüsseltes Protokoll einem Einsteiger empfehlen kann. Und wenn man auf die Sicherheitsproblematik hinweisen will, kann man das gerne machen, aber es kam bei mir so rüber wie "Mit SSL bist Du absolut sicher und ohne kann jeder mitlesen", was nicht wirklich zutreffend ist.

Randbemerkung: Wenn Du eine CA findest, die immernoch ausschliesslich MD5 verwendet, kannst Du mir auch bescheid sagen