- 3 évig még biztosan nem rendelhetünk Xiaomi EV-t
- DIGI internet
- Agyi chipes gyártóba fektetett a kriptocég
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Az Apple iPadOS-t is megrendszabályozza az EU
- Milyen routert?
- Ingyenes vagy akciós szoftverek
- WLAN, WiFi, vezeték nélküli hálózat
- ASUS routerek
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
Új hozzászólás Aktív témák
-
nagyúr
Anelkul, hogy tulsagosan vedenem a GMailt (koztudottan nem kedvelem a szolgaltatast):
- ez egy nyilt forrasu, potencialisan auditalhato szoftvernek latszik
- a kulcsok lokalisan, a kliensnel tarolodnakManapsag is leteznek 'feltorhetetlen' titkositasok, ha ezt a szoftvert neves biztonsagi szakertok megnezik, es leokezzak, akkor valoszinuleg nem lesz vele nagy gond. (Ha emlekeztek, pl. a DUAL EC-PRNG-rol mar bevezetesekor sem gondoltak tul jokat a bizonsagi szakemberek.)
while (!sleep) sheep++;
-
nagyúr
> valamire való programozó szerintem ki tudja bogarászni belőle
Ez igy nem igaz azert. Attol, hogy valaki jo programozo, nem biztos, hogy meg tudja allapitani, hogy pl. egy veletlenszamgenerator tenyleg kriptografikusan biztonsagos PRNG-e vagy sem.
while (!sleep) sheep++;
-
nagyúr
Te most egy jovobeli, elkepzelt szcenariot kifogasolsz, ezzel nyilvan nem tudok vitatkozni, mindenki azt kepzel el, amit akar. (Egyebkent nem lesz, mert az onnantol pontosan olyan biztonsagos lenne, amilyen most -- ok sem nezhetik _total_ hulyenek a mediat, csak leegetnek vele magukat.)
while (!sleep) sheep++;
-
nagyúr
Oo, nem egeszen stimmel szerintem, amit mondasz. Amit ez a kiegeszites iger, az az, hogy ket GMail-es emailfiok kozott at tudsz kuldeni ugy egy uzenetet, hogy harmadik fel ezt nem olvashatja el. Ezt teljesitheti ezzel az architekturaval: a publikus kulcsodat akar papiron odadhatod a baratodnak, aki importalja a keyringbe, es onnantol kuldhetsz bizalmas uzeneteket. A kulcsok termeszetesen rendelkezhetnek lejarati idovel, ez szinten megoldhato 'egyszeruen'.
Szoval valojaban masodszor atgondolva tudhat kb. mindent, amit szeretnel. Trusted 3rd partyra meg szukseg van ahhoz, out-of-band kulcscsere nelkul elhihesd, hogy a masik fel tenyleg az, akinek mondja magat.
while (!sleep) sheep++;
-
nagyúr
> Az utobbit az, amit meg kell osztani es ennek a megosztasa nem jelent biztonsagi a problemat, a helyi tarolasnal nyilvan a titkos kulcsrol van szo.
En felteteleztem, hogy nem errol van szo, ill. hogy nem errol kerdez. A nyilvanos kulcs termeszetesen publikalhato es megoszthato, de ennek a megosztasnak a modja sem trivialis, mert ha valaki odaallit Alice-hoz, hogy 'en vagyok Bob, itt a nyilvanos kulcsom', akkor Alice-nek el kell hinnie, hogy Bob valoban az, akinek mondja magat, es ez a resz igenyel nemi kozremukodest valami trusted 3rd party reszerol (ugyebar pl. SSL certifikaciok eseten ezek a root certificate providerek). Ebben az esetben ez a fel a Google, aki igy vagy ugy de garantalni probalja, hogy ha bob@gmail.com-rol kapsz egy levelet, az tenyleg bob es nem valami man-in-the-middle. Ha Bob privat kulcsa kompromittalodik, akkor a Google-nek biztositania kell valamilyen mechanizmust arra, hogy a publikus kulcsat ervenytelenitsek, satobbi.
Tehat sztanozs-nak olyan ertelemben jogosak a fenntartasai, hogy az E2E pluginnek az SSL-certifikaciokhoz hasonlo mechanizmus kellene (minimum) implementalnia, hogy ezeket a funkciokat biztositsa.
Egy kritikus pelda egyebkent, Pali - ez a te hozzaszolasodra is tobbe-kevesbe valasz: ha ket GMail user meg sosem levelezett egymassal, es a Google-n kivul nincs mas ut ahhoz, hogy elerjek egymast, akkor nem nagyon van mod arra, hogy teljesen bizalmasan kommunikaljanak. A ket fel ugyanis publikus kulcsot kell, hogy csereljen, a publikus kulcsot pedig valahogy meg kell osztani egymassal. A publikus kulcs cserejekor a Google eljatszhatja azt, hogy Apk publikus kulcsot G1pk publikus kulccsal helyettesiti, es elkuldi B-nek. B elkuldi a sajat Bpk publikus kulcsat, amit a Google G2pk publikus kulccsal helyettesit, es innentol vegig MITM-t jatszik.
Legalabbis ha jol gondolom.
[ Szerkesztve ]
while (!sleep) sheep++;
-
nagyúr
Kozben megtalaltam a Wikipedian is, ha valakit meg erdekel:
Another potential security vulnerability in using asymmetric keys is the possibility of a "man-in-the-middle" attack, in which the communication of public keys is intercepted by a third party (the "man in the middle") and then modified to provide different public keys instead. Encrypted messages and responses must also be intercepted, decrypted, and re-encrypted by the attacker using the correct public keys for different communication segments, in all instances, so as to avoid suspicion. This attack may seem to be difficult to implement in practice, but it is not impossible when using insecure media (e.g. public networks, such as the Internet or wireless forms of communications) – for example, a malicious staff member at Alice or Bob's Internet Service Provider (ISP) might find it quite easy to carry out. In the earlier postal analogy, Alice would have to have a way to make sure that the lock on the returned packet really belongs to Bob before she removes her lock and sends the packet back. Otherwise, the lock could have been put on the packet by a corrupt postal worker pretending to be Bob, so as to fool Alice.
One approach to prevent such attacks involves the use of a certificate authority, a trusted third party responsible for verifying the identity of a user of the system. This authority issues a tamper-resistant, non-spoofable digital certificate for the participants. Such certificates are signed data blocks stating that this public key belongs to that person, company, or other entity. This approach also has its weaknesses – for example, the certificate authority issuing the certificate must be trusted to have properly checked the identity of the key-holder, must ensure the correctness of the public key when it issues a certificate, and must have made arrangements with all participants to check all their certificates before protected communications can begin. Web browsers, for instance, are supplied with a long list of "self-signed identity certificates" from PKI providers – these are used to check the bona fides of the certificate authority and then, in a second step, the certificates of potential communicators. An attacker who could subvert any single one of those certificate authorities into issuing a certificate for a bogus public key could then mount a "man-in-the-middle" attack as easily as if the certificate scheme were not used at all. Despite its theoretical and potential problems, this approach is widely used. Examples include SSL and its successor, TLS, which are commonly used to provide security for web browsers, for example, so that they might be used to securely send credit card details to an online store.
Ugyebar itt a potencialis MITM es a trusted 3rd party is a Google. Nyilvan eleg latvanyosan le lehetne vele bukni, ha megprobalkoznanak ezzel, tehat gyakorlatban en nem tartom ezt realis veszelynek (egy kulonallo csatornan A es B egyeztetnek a publikus kulcsokat, es egybol kiderulne a dolog).
while (!sleep) sheep++;
-
nagyúr
Ugy, hogy a kulcscsere pillanataban mar ott vagy. Tehat
A ket fel ezt gondolja:
A <-csatorna-> BValojaban:
A <- csatorna - C - csatorna -> BA elkuldi a publikus kulcsat B-nek, de ezt elkapja C. C general egy publikus kulcsot, elkuldi B-nek. B azt hiszi, hogy A publikus kulcsat kapta meg. Ugyanez lezajlik visszafele. Innentol A titkositott uzeneteket kuld B-nek, azt gondolvan, hogy B publikus kulcsaval titkosit, de valojaban C-jevel teszi ezt. Menetkozben C elkapja az uzenetet, dekodolja, (potencialisan megvaltoztatja,) ujrakodolja a sajat privat kulcsaval, es elkuldi B-nek. B dekodolja az uzenetet C publikus kulcsaval.
(Valojaban ez nem igy zajlik, mert a valo eletben a publikus/privat kulcsokat csak a handshake eseten hasznaljak, amikor elkuldik a szimmetrikus kulcsot a masik felnek, de a dolog nyilvan ettol meg ugyanugy sebezheto a fenti modon.)
Termeszetesen egy GMailen belulre korlatozott uzenetkuldo rendszernel a Google tokeletesen jatszhatna C-t, viszont egy masik csatornan keresztul torteno kulcs-egyeztetes gyorsan lebuktatna.
[ Szerkesztve ]
while (!sleep) sheep++;
-
-
nagyúr
válasz #06658560 #53 üzenetére
Ezert irtam azt, hogy 'masik csatornan'. Ergo ha az E2E MITM-ozve lenne, akkor ha ket Chrome felhasznalo mittudomen, Skypeon elkuldene egymasnak a publikus kulcsokat, es megneznek, hogy stimmel-e azzal, amirol a Chrome tud, akkor egybol kiderulne a dolog.
while (!sleep) sheep++;
Új hozzászólás Aktív témák
- Xiaomi Smart Band 8 - folyamatosan
- Motorola Edge 40 neo - színre és formára
- Politika
- Milyen okostelefont vegyek?
- A Samsung hazánkban is piacra dob idén egy friss Micro LED tévét
- Kínai, és egyéb olcsó órák topikja
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- eBay-es kütyük kis pénzért
- bitpork: Balatoni autós tali 2024
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...