|
|
|
|
|
|
|
|
Steht schon in den pOT-News
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Snowblind1911
Moin... der Thread scheint ja leider etwas eingeschlafen zu sein, aber wisst ihr vielleicht wo ich nen Vortrag (oder ne generelle Einführung als Text) zur Sicherheit von Smartphones bekommen kann?
Schaue regelmäßig Vorträge von Defcon und dem Chaos Communication Congress (hab ich auch mal besucht). Das Thema scheint mir da irgendwie zu kurz zu kommen. Ich will vor Allem wissen, wie sich die Hauptunterschiede zu PCs (Appstores/signierte Software, keine Administratorrechte) bei unveränderten Geräten so auswirken. Hab da immer ne ziemlich negative Prognose im Kopf gehabt, und im aktuellen Logbuch Netzpolitik wird sich auch wieder geäußert a la "ja die kannste eh vergessen". Etwas Substanz die das untermauert/widerlegt wäre langsam mal gut.
| |
Naja, generell gilt für iOS: Keine Programme, die nicht von Apple signiert sind. Ohne hoch kritische Sicherheitslücke(n) (von der es mindestens noch eine ungepatchte gibt) also keine Gefahr.
Bei Android ist es in neueren Versionen ähnlich, aber halt immer noch deutlich offener. Das ist kein zwingender Nachteil, sondern einfach Designentscheidung.
Und im Vergleich zum PC? Kommt drauf an. Neuere OSX kann man so einstellen, dass sie ähnlich wie iOS funktionieren. Linux ist eh genau so offen, wie du es willst. Alle Lösungen, die ich für Windows gesehen habe, waren da so halbgar. Aber das kann sich in neueren Versionen geändert haben, MS ist da ja ziemlich dran.
Kurz gesagt: Das durchschnittliche Smartphone ist wahrscheinlich deutlicher sicherer als der durchschnittliche PC. Aber ich hätte auch keinen Bock meinen Rechner so einzustellen wie mein Smartphone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signal (ehem. Textsecure) gibt's nun (in closed beta Form) für den Desktop: https://whispersystems.org/blog/signal-desktop/
Vorerst leider nur als Chrome-App.
Wenn man sich über einen Ref-Link dort einträgt schiebt das den "bewerbenden" in der Schlange nach vorn. Eine seltsame Sache m.E., aber falls jemand mich nach vorne schieben möchte kann er sich gern über "meinen" Link eintragen, ansonsten ist der Link weiter oben der reguläre.
--
Übrigens kann ich berichten, dass Textsecure mit microGMS, Blankstore und so weiter ( hier und dort wunderbar ohne Google Apps funktioniert, ohne die Websockets-Route einzuschlagen.
|
|
|
|
|
|
|
|
|
|
|
Aber damit gehts doch trotzdem über die Google Server oder nicht? Was spricht gegen die WebSockets?
Ich finde Signal ja einerseits toll, aber warum GSM, PlayStore only und jetzt noch Chrome APP? 
|
|
|
|
|
|
|
|
|
|
|
|
Wie, keine Meldung hier, dass letsencrypt jetzt open beta ist?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MartiniMoe
Aber damit gehts doch trotzdem über die Google Server oder nicht? Was spricht gegen die WebSockets?
Ich finde Signal ja einerseits toll, aber warum GSM, PlayStore only und jetzt noch Chrome APP?
| |
Jein: Du kannst dein Handy halt ohne Gapps nutzen. Die Kommunikation geht meinem Verständnis nach über die Signal-Server, die Google-Server erledigen nur den Push-Kram (d.h. sagen deinem Handy, dass es auf dem Signal Server was abzuholen gibt.)
WebSocket führt (glaube ich, meine Erinnerung ist trüb) zu mehr Serverlast, und seitens Moxie nicht gern gesehen (im Rahmen der Fdroid-Sache u.ä.). microGMS steht er wohl laut irgend 'nem reddit-Kommentar von ihm schon wohlwollender gegenüber, ob das (-> microgms "in Signal direkt" dann vielleicht irgendwann mal in Fdroid landet bleibt zu hoffen).
---
Das finde ich auch immer etwas.. blöd. Es gibt für alles meist gute Begründungen, und selbst bei erstmal bedenklichem (die ZRTP-Key-Continuity, die plötzlich wegfiel) heißt es, das werde (besser) neu implementiert. Nur ist die Art und Weise, wie/wo sowas meist beantwortet wird auch echt diffus und manchmal barsch — das macht keinen guten Eindruck. Sicherlich haben die alle viel zu tun, und bei der Nutzerbasis kommt da wohl auch echt eine Menge an zeitfressenden Bugs, Issues-die-keine-sind usw. rein, irgendwo also nachvollziehbar, aber trotzdem eher blöd.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dieser Verbindung wird nicht vertraut 
|
|
|
|
|
|
|
|
|
|
|
|
Fefe ist halt zu cool um Geld für ein Zertifikat auszugeben.
|
|
|
|
|
|
|
|
|
|
|
Zertifikate sind halt nicht viel wert, wenn jeder Schurkenstaat (und viele andere unseriöse Zeitgenossen) eine eigene CA unterhält der dein Browser vertraut. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von keinerfari am 04.12.2015 18:20]
|
|
|
|
|
|
|
|
|
Welches meine These nicht falsifiziert. 
|
|
|
|
|
|
|
|
|
|
|
|
fefe ist wohl mad, dass niemand um CA Cert kehrt?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fefe so:
| | | Es gibt da etablierte Prozesse, mit denen kommen die Leute klar, und die funktionieren auch. | |
fefes komischer gatling-Webserver so:
Features des Servers laut fefe so:
| |
| Code: |
Quick-and-dirty SSL/TLS support |
|
Ich lolte hart.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von MartiniMoe am 04.12.2015 20:59]
|
|
|
|
|
|
|
|
|
| | Zitat von Stryker
Bei aller Abneigung die ich in letzter Zeit gegenüber El Fefe hege, möchte ich anmerken, dass ssllabs deswegen nen Fehler raushaut, weil es die CACert Root CA nicht kennt.
Das ist aber klar, wenn man weiss was CACert ist.
Man muss halt nachträglich deren Root CA installieren, damit deren Zertifikate funktionieren.
| |
Das mit CACert ist klar, aber es zeigt ja eben genau, dass diese "etablierten Prozesse" von denen er spricht für normale User nicht durchführbar oder überhaupt verständlich sind. Lets Encrypt macht halt genau das, wofür es steht: Es ermöglich jedem DAU seine Website zu verschlüsseln. Dass dazu dann ein gewisser Overhead nötig ist um den Usern Arbeit abzunehmen (durch dieses Python Script) kritisiert fefe aber dann und das verstehe ich nicht. Und dieses alberne Python-Startup-gebashe 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von MartiniMoe am 04.12.2015 22:49]
|
|
|
|
|
|
|
|
|
| | Zitat von Stryker
Bei aller Abneigung die ich in letzter Zeit gegenüber El Fefe hege, möchte ich anmerken, dass ssllabs deswegen nen Fehler raushaut, weil es die CACert Root CA nicht kennt.
Das ist aber klar, wenn man weiss was CACert ist.
Man muss halt nachträglich deren Root CA installieren, damit deren Zertifikate funktionieren.
Dass jemand ne statische Webseite für manuelles Beantragen des Zertifikates gebaut hat, ist wirklich gut. So hätte ich mir das von vornherein gewünscht.
Allerdings haben die ja gerade deswegen dieses Python-Skript gebaut, damit es so einfach wie möglich wird, TLS auszurollen.
| |
Naja, sollen die Zertifikate weiterhin 90 Tage gültig bleiben? Wäre mir zu dämlich, dann gebe ich lieber weiterhin meine 30 Dollar alle 3 Jahre bei Namecheap für mein Zertifikat aus, reicht mir und kein Prozess der irgendwo auf dem Server läuft.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm wirklich? Die Statsitik soll stimmen?
| | | Ninety days is nothing new on the Web. According to Firefox Telemetry, 29% of TLS transactions use ninety-day certificates | |
Das sind doch wohl bestenfalls Zertifikate zum Test, wer wechselt bitte schön alle 3 Monate seine Zertifikate aus? 
Wenn ich das richtig verstanden habe, muss ich bei Let's Encrypt also entweder das Tool verwenden welches für mich die Erneuerung erledigt oder ich muss alle 90 Tage da manuell rumfrickelen. Das wäre mir wirklich zu nervig und dafür einen extra Dienst laufen zu lassen von dem man nicht weiß was er ansonsten noch macht, naja...nett gemeint, für private Homepages die nix ausgeben wollen vielleicht ganz ok, aber irgendwie keine Alternative für "richtige" Zertifikate.
|
|
|
|
|
|
|
|
|
|
|
Ich bin mir auch noch nicht so ganz sicher wie ich das finde, aber zumindest
| | Zitat von [GMT]Darkness
und dafür einen extra Dienst laufen zu lassen von dem man nicht weiß was er ansonsten noch macht
| |
stimmt ja so nicht, ist ja quelloffen alles
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von MartiniMoe am 05.12.2015 1:04]
|
|
|
|
|
|
|
|
|
| | Zitat von [GMT]Darkness
aber irgendwie keine Alternative für "richtige" Zertifikate.
| |
Soll es ja auch nicht sein. Das ist für alle gedacht, die kein TLS nutzen, weil ihnen das beantragen eines richtigen Zertifikats zu umständlich/teuer ist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jemand schon Qubes OS ausprobiert?
Ich bin schon sehr gespannt bald mein Librem 15 in den Händen halten zu können. Dann gucke ich mir mal kurz PureOS an ehe ich dann Qubes drauf mache.
Finde das Konzept von Qubes absolut überzeugend und der Joanna traue ich zu, die Sache gut zu machen.
Wenn hier Interesse besteht kann ich mal etwas berichten in Zukunft. Sei es über das Librem, PureOS oder QubesOS.
|
|
|
|
|
|
|
|
|
|
|
Bin definitiv sowohl am Laptop als auch am OS interessiert! Bitte berichten 
|
|
|
|
|
|
|
|
|
|
|
Ok, wird gemacht
Kann noch etwas dauern, da ich nicht mal bisher die Lieferbestätigung von Crowd Supply bekommen habe. Ich rechne mit Ende Januar mit dem Laptop. Blöd, dass die 4k-Bildschirme zuletzt in den 15" verbaut werden :/
|
|
|
|
|
|
|
|
|
|
|
|
Es gibt KeePassDroid, das tut. Container über OwnCloud / DropBox / whatever synchronisieren ist auch kein Problem Mache ich seit einigen Monaten so.
|
|
|
|
|
|
|
|
|
|
|
Kurzes Update zum Librem 15:
Leider wird das vor Mitte/Ende April nicht fertig und somit vor Mai nicht bei mir eintreffen. Ganz schön krass 1 e1/2 Jahre auf einen Laptop zu warten. Ich glaube nicht, dass ich das noch mal tun würde. Zum Glück spielt mein 7 1/2 Jahre altes Macbook da mit. Das sollte so langsam aber sicher mal in den Ruhestand gehen.
Daher wird es den Post mit einer kleinen Vorstellung des Librem für alle Interessierten später geben als gedacht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MartiniMoe
Es gibt KeePassDroid, das tut. Container über OwnCloud / DropBox / whatever synchronisieren ist auch kein Problem Mache ich seit einigen Monaten so.
| |
Ich benutze Keepass2Android, Yubikey als 2. Faktor und synchronisiere das mittels Syncthing mit dem Rechner, dort dann Keepass. (kpcli hat leider die Yubikey-Möglichkeit nicht, sonst wäre das auch noch was für die Kommandozeile, aber das nur nebenbei)
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von FuSL
Falls es jemanden interessiert, seit kurzem kann GnuPG mit libgcrypt (git) nun auch Curve25519 zusätzlich zu Ed25519, sprich: Man kann nun Schlüssel generieren, die sichere Kurven verwenden.
Klappt mit:
gpg (GnuPG) 2.1.8
libgcrypt 1.7.0-beta262
| |
Wenn ich gerade schon hier bin:
Mit libgcrypt 1.6.5 (stable) und gpg 2.1.11 geht's nun auch.
| |
| Code: |
10:31 ❯ gpg --list-keys 0xFA3A46A03EEAE94D
gpg: using PGP trust model
pub ed25519/0xFA3A46A03EEAE94D 2016-02-13 [expires: 2016-02-20]
Key fingerprint = 46B7 5BA3 B47C 940E 682A BDB0 FA3A 46A0 3EEA E94D
uid [ultimate] Deine Mudda <deine@mudda.net>
sub cv25519/0x98D213CE2D1F643F 2016-02-13 [expires: 2016-02-20]
|
|
Jetzt müsste's nur noch mit dem Yubikey zusammen klappen /o\
|
|
|
|
|
|
|
|
|
|
Ich möchte einen USB-Stick verschlüsseln.
Das Programm sollte:
- auf Win und OSX laufen
- möglichst portabel sein (Verwendung ohne Installation, evtl. nur auf einer kleinen unverschlüsselten Partition abgelegt sein)
- am besten keine Adminrechte zum entschlüsseln benötigen
- am besten keine extra Treiber benötigen
Kennt da jemand etwas? Veracrypt hat einen Traveler Mode, das scheint in etwa das zu sein, was ich suche (braucht aber OSXFuse).
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von *tilt* am 14.02.2016 11:02]
|
|
|
|
|
|
| Thema: Verschlüsselung und Anonymität III ( Privatsphäre jetzt ) |
