iOS WLAN anlassen

NJay schrieb:
Aber woher willst du an den Handshake kommen, wenn der nicht stattfindet, weil das gegenueber kein gueltiges Zertifikat hat?
was hat denn jetzt bitte das eine mit dem anderen zu tun? selbst wenn der server ein valides zertifikat präsentiert und der client daraufhin eine gesicherte verbindung aufbaut, ist besagtes zertifikat nicht notwendig, um die verbindung nachträglich zu entschlüsseln bzw. es ist nicht möglich die verbindung mit hilfe des zertifikats zu entschlüsseln, da es nunmal öffentliche daten sind.
 
Du brauchst aber schon den privaten Schlüssel um die Daten zu entschlüsseln und das hat i.d.R. nur der entsprechende Werbserver
 
und genau an den kommst du nicht ran, da der niemals übertragen wird und nicht teil des zertifikats ist.
 
Ja genau.... Das ist doch genau der Punkt. Der öffentliche Schlüssel bringt dir doch rein garnichts, wenn du nicht den entsprechenden Dechiffrierung-Schlüssel hast.

Sobald eine Verbindung über TLS gesichert ist, kann lediglich der entspreche Webserver die Verbindungen lesen.... Bei TLS 1.2 wird der SNI nicht mitverschlüsselt, ab 1.3 jedoch schon.

Der Zielserver bringt mir jedoch auch nicht viel bzw. mit seeeeeeeeeehr viel Aufwand.
 
IT-T0bi schrieb:
Ja genau.... Das ist doch genau der Punkt. Der öffentliche Schlüssel bringt dir doch rein garnichts, wenn du nicht den entsprechenden Dechiffrierung-Schlüssel hast.

genau, daher wirst du mir dann sicherlich zustimmen, dass diese aussage falsch ist:

NJay schrieb:
Zitat von Sebbi:
wenn man den gesammten Handshake etc mitließt, kann man auch die Verschlüsselung wieder rückgänging machen.
Nicht ohne passendes Zertifikat.

:)
 
  • Gefällt mir
Reaktionen: IT-T0bi
0x8100 schrieb:
was hat denn jetzt bitte das eine mit dem anderen zu tun? selbst wenn der server ein valides zertifikat präsentiert und der client daraufhin eine gesicherte verbindung aufbaut, ist besagtes zertifikat nicht notwendig, um die verbindung nachträglich zu entschlüsseln bzw. es ist nicht möglich die verbindung mit hilfe des zertifikats zu entschlüsseln, da es nunmal öffentliche daten sind.
Wie willst du an die daten des Handshake kommen? Wenn dud azwischen sitzt und den handshake abwartest bringt dir das nicht viel, da ich ja eben den ersten teil des handshakes ueber das zertifikat verschuesselt an den server senden kann. Diese Daten kannst du als Mitm nicht lesen, also bekommst du auch den Handshake nicht mit.
 
NJay schrieb:
Wie willst du an die daten des Handshake kommen?
brauch ich nicht. es geht nur um deine aussage, dass mit hilfe des zertifikats bei vorhandensein des handshakes die verbindung entschlüsselt werden könnte.
 
0x8100 schrieb:
brauch ich nicht. es geht nur um deine aussage, dass mit hilfe des zertifikats bei vorhandensein des handshakes die verbindung entschlüsselt werden könnte.
?

Ich verstehe nicht worauf du hinaus willst. Meine Aussage war lediglich, dass dir zwischen mit und dem Webserver zu stehen nichts bringt, da ich den Webserver über sein Zertifikat authentifizieren kann. Du kannst zwar alles mitschneiden, kannst es aber nicht lesen, solange du nicht an das private Zertifikat des Servers kommst. Und das tust du als mitm nun Mal nicht einfach so.
 
NJay schrieb:
Meine Aussage war lediglich, dass dir zwischen mit und dem Webserver zu stehen nichts bringt, da ich den Webserver über sein Zertifikat authentifizieren kann.
das ist nicht deine aussage aus #32. zudem gibt es kein "privates zertifikat". es gibt einen privaten schhlüssel - ein zertifikat ist immer öffentlich.
 
Also Leute keinen Streit....
Selbst als Mitm bringt es dir nichts, wenn es TLS verschlüsselt ist und der entsprechende Schlüssel beim Server liegt. Natürlich kannst du den Traffic mitschneiden, bringt dir ohne den Algorithmus nichts.... Allgemein TLS ist sicher und kann zum aktuellen Datum nicht wirklich (bzw. nur mit jahrelangem Aufwand) entschlüsselt werden. Natürlich gibt es Negativbeispiele, sowie du dich via shodan.io in zahlreiche Hosts einloggen kannst...


Wer will der Kann!
 
0x8100 schrieb:
das ist nicht deine aussage aus #32. zudem gibt es kein "privates zertifikat". es gibt einen privaten schhlüssel - ein zertifikat ist immer öffentlich.
Da hältst du dich jetzt am wording fest. Ich meinte den private Key des certs.
 
@NJay

du kennst den Ablauf des Handshakes ja? wenn nicht: https://upload.wikimedia.org/wikipe..._two_way_authentication_with_certificates.svg von https://de.wikipedia.org/wiki/Transport_Layer_Security

wenn ich die Kommunikation belauschen und danach entschlüsseln wollen würde, würde ich die daten im meinen Hotspot mitschniffen und dann wie folgt den UNVERSCHLÜSSELTEN Handshake auswerten:

  • RNc und RNs aufzeichnen - damit hab ich die Randomnummern der beiden Seiten
  • dann das Serverzertifikat + Puplic Key des Server - wie der Name schon sagt - braucht man ja auch
  • dann kommt der Puplic Key des Clientes - braucht man ja
  • dann das pre-master-secret - ist ja verschlüsselt mit dem Puplic Key des Servers
  • hash over all previous messages signiert mit den Private Key des Cients - oh der Private Key des Cients, nice

so also nun wird ja auf beiden seiten das Master-Secret berechnet aus RNc und RNs sowie PMS - hey ich habe alles um das auch zu errechnen -> ich würde nun meinen, ich kann mit meinen MS die verbindung entschlüsseln.
 
Zuletzt bearbeitet:
ein it Mensch fragt, was ein iPhone so alles macht wenn das wlan läuft und es kommen 53 Beiträge über Verschwörungstheorien, Zertifikate und Windows spezifische sicherheitslücken und keiner kommt auf die Idee, das iOS a) update sucht und b) iCloud aktualisiert und c) Energie verbraucht und die restliche Zeit auf „hey Siri“ lauscht und sonst in Energiesparmodus verweilt?
 
chrigu schrieb:
ein it Mensch fragt, was ein iPhone so alles macht wenn das wlan läuft

sry aber hast du den ersten Beitrag gelesen? Da wurde nach "Meine Frage ist nun, wie hoch ist die Wahrscheinlich eines Angriffs unter iOS?" gefragt.

und iOS macht das nur wenig anders als andere Smartphones und setzt auf die gleichen Protokolle. Die Frage wurde zwar schon beantwortet, aber dennoch gibt es ja noch bei einigen Unklarheiten, wie manche Vorgänge durchaus ausgenutzt werden können. Und leider gibt es immer wieder genug kriminelle Energie, die sich daran bereichern will, zumal einige Sachen ohne viel knowhow durchführbar sind, da es ausführliche Todos oder schon fertige scripte im Deepweb frei verfügbar sind.
 
  • Gefällt mir
Reaktionen: brianmolko
Sebbi schrieb:
  • hash over all previous messages signiert mit den Private Key des Cients - oh der Private Key des Cients, nic
Nein, du hast damit nicht den private Keyd es clients,. Du hast eine mit dem private Key signierte Nachricht. Die sagt nur aus, dass garantiert diese Person die Nachricht geschickt hat. Du kannst daraus NICHT den private Key ableiten.
Sebbi schrieb:
  • dann das pre-master-secret - ist ja verschlüsselt mit dem Puplic Key des Server
Das kannst du nicht elsen. da es mit dem public key verschluesselt ist, brauchst du den private Key, um es zu entschluesseln.


Bei asymmetrischer cypto gibt es generell einen Public und einen Private Key. Eine mit dem einen Key verschluesselte Nachricht kann NUR mit dem ANDEREN key entschluesselt werden.

Bedeutet: Eine mit dem Public Key des Servers verschluesselte Nachricht kannst du nicht entschluesseln, wenn du nicht seinen private Key hast.

Die Man in the middle Probleme hat man dann, wenn man keinen "Vertrauensanker" hat, also kein public Zertifikat des Servers. Dann kannst du immer noch verschluesseln, aber du weisst eben nicht, ob du wirklich mit dem Gespraechspartner sprichst. Ein von einer dritten Partei signiertes Zertifikat behebt dieses Problem. (Unter der annahme, dass du der dritten Partei vertraust)

TLS hatte shcon einige Luecken, aber nur weil man eben in einem oeffentlichen WLAN ist, ist noch nicht jede Verbindung komprimmitiert.
 
IT-T0bi schrieb:
Ich habe die WLAN-Funktionalität auf dem Handy angelassen.
iOS verbindet sich nicht automatisch mit unbekannten WLAN‘s.
Deshalb kein Grund zur Sorge. Wenn du das WLAN über das Kontrollzentrum vermeintlich ausschaltest, dann aktiviert es sich nach einem Standortwechsel oder am nächsten Tag um 7 Uhr eh wieder von allein.
Um es komplett zu deaktivieren bitte in den Einstellungen machen.
Ergänzung ()

NJay schrieb:
Ja, aber eigentlich aller traffic ist ja mittlerweile eh per TLS verschluesselt, so einfach mitlesen ist da nicht.
Manche Apps sind aber immer noch unverschlüsselt bei der Datenübertragung.
Ergänzung ()

Sebbi schrieb:
Denn ein Angreifer könnte, wenn er unbedingt jemanden schaden möchte, einen WLAN Hotspot mit genau der gleichen SSID auf machen und das Gerät würde sich auch darauf verbinden, wodurch man in the middle Angriffe möglich wären.
Dann entweder WLAN komplett deaktivieren oder einfach VPN konfigurieren.
Wobei ich die Wahrscheinlichkeit ziemlich gering einschätze, dass jemand die gleiche SSID konfiguriert. Aber natürlich ist es eine „Lücke“. Da kannste dann aber soweit gehen, dass jemand ARP-Spoofing verwendet…
 
Zuletzt bearbeitet:
Nobody007 schrieb:
Manche Apps sind aber immer noch unverschlüsselt bei der Datenübertragung.
Sowas sollte man sowieso nicht nutzen, auch nicht im Heimischen WLAN.
 
Zurück
Oben