Átállt a végpontok közötti tikosításra a Facebook Messenger

HUP cikkturkáló

https://kuruc.info/r/20/277572/

  • 2726 megtekintés

( Elbandi v | 2024. 08. 27., k – 11:56 )

ennek tudja valaki a pontos mukodeset? hogy kerulnek at a kulcsok egyik geprol a masikra? mi akadalyozza meg az fb-t hogy a kulcsot lemasolja sajat maganak?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A facebookon nem tudom hogy megy, csak a tor hálózaton V3 esetén.

- van egy privát kulcs a gépeden

- van egy publikus kulcs a szerveren

Amikor kapcsolódni akarsz a TOR hálózaton egy onion service-hez, enkódolsz a privát kulccsal, amit a szerver a publikus kulccsal dekódolni tud.

Magyarul: kizárólag az képes elolvasni az üzeneteket, aki ismeri a kulcsokat.

TOR alatt a publikus és a privát kulcs is titkos.

A man-in-the middle kizárva, mert a publikus kulcsot kizárólag a szerver ismeri, a privát kulcsot meg kizárólag a kliens.

 

Gondolom a két végpont kulcspárt használ egymás között, de mindkettő titkos. Senki nem lát belőlük semmit, kizárólag a végpontok.

A hálózaton semmiféle információ nem elérhető a kulcsokról, amiket enkódolásra vagy dekódolásra használnak. Gondolom ennyi.

A TLS és az SSL komoly gondja a tanusítványokkal van. A man-in-the-middle támadásoktól nem véd meg.

- a titkosszolgálatok bármikor produkálnak neked megfelelő tanúsítványt a man-in-the-middle-höz

- csomó esetben még fel is törtek CA-kat (pl. Verisign) és onnantól az egész nem ér semmit

A TOR fizikailag elhelyez egy publikus kulcsot a szerveren, egy privát kulcsot a kliensen és ennyi.

Teljesen felesleges, mert vallási kérdésről van szó.

- az egyik ember hisz az USA jóságos kormányában és a becsületében

- a másik ember meg nem

Onnantól kezdve, hogy te más vallású vagy és nem hiszel már a CA-k megszentelt életében, más megoldásokat fogsz alkalmazni.

Ameddig egy irányba mész a kormányokkal, nem is lesz bajod. Nagyon jók a CA-k a rendszered védelmére, ameddig úgy ugrálsz, ahogy a magasságosok fütyülnek.

Viszont ahogy szembemész velük, bajba kerülhetsz. Az egész rendszer úgy épül fel, hogy nekik lejtsen a pálya.

1. A Verisignnál / Symantecnél más hiányosságok is bőven voltak. Nézz csak utána.

2. Attól, mert tudtál mutatni 1 példát, attól még nem lesz igaz az állításod minden CA-ra.

3. Tudtad értelmezni is a cikket?

A feltett kérdéseimre mikor kapok tőled választ?
- Mit csinálnak a cégen belüli CA-kal?
- HSM mond neked valamit?

Mindenki azt csinál cégen belül, amit akar.

Ha létrehozol egy saját CA-t, nem függesz senkitől, úgy kihúztad a probléma méregfogát.

Ugyanakkor a saját alkalmazottaid sem az életszentség mintaképei.

 

Nem a TLS kialakításával van a baj, hanem az egyes szereplők megbízhatóságával.

Egy biztonságos adatkapcsolat addig tart, ameddig a leggyengébb láncszeme.

Minél kevesebb emberben/hatóságban bízol, annál jobb. Minimalizálni kell a szereplők számát.

 

Úgy a TLS is képes megbízhatóan működni.

Egy kérdés: céges CA-t használsz és beállítod a Firefox alatt, hogy elfogadja.

 

Megnyitod a www.weblap.lan honlapot céges CA-val, probléma nélkül betöltődik.

 

Alapjáraton a Firefox más CA-t is elfogad, mondjuk ABC cég CA-ját. Nem távolítottad el a default CA-kat.

Man-In-The-Middle: a www.weblap.lan-t átirányítom a saját gépemre, viszont már ABC cég feltört CA-jával fogom aláírni.

Lecserélem a céges CA-dat egy másik megbízhatónak vélt partnerre, amelyet megtámadtam.

Észre fogod venni? Fel fog tűnni, hogy man-in-the-middle van?

Egyrészt kulcsszavak:
- CAA rekord
- DNSSEC

Másrészt kevered a szezont a fazonnal. A te általad felvázolt helyzet megvalósításához nem elég egy feltört CA. Nagyon nem.
1. El kell tudnod téríteni a DNS kéréseket.
2/a. Fel kell törnöd egy megbízható CA-t (ez lehet akár a céges is), ahol észrevétlenül kell tudnod kiállítani certet. ÉS/VAGY
2/b. Importálnod kell tudnod a Firefox böngészőmbe egy általad felügyelt CA-t, amivel aztán kiállítod a fake certet.

A DNS poisoning még esetleg sikerülhet - bár a mai rendszerek elég jól védettek ellene. De a 2/a és 2/b kivitelezése nem fog menni.

Nem sértésként mondom: Leírásod alapján nem értesz a PKI-hoz. Nincs ezzel semmi baj. Egy könyvet ajánlanék figyelmedbe (magyarul van, elmagyarázza az alapokat): https://berta.hu/e-szigno_book/

> 1. El kell tudnod téríteni a DNS kéréseket.

Minden nap ezt csinálom a rooteremen, mert így működik a pornószűrés. OpenWrt alatt elkapok minden üzenetet, ami az 53-as portra menne és átirányítom egy DNS-over-TLS portra.

Magyarul rohadt mindegy, hogy te a helyi hálózaton ukmumfuk.tutidns.com:53-as portra küldesz-e DNS kérést, az át lesz irányítva a CloudFlare felé, ahol pornószűrés van.

> 2/a. Fel kell törnöd egy megbízható CA-t

99% a valószínűsége, hogy a CIA meg tudja csinálni.

Én lepődök meg.

- számomra nem probléma az 53-as port átirányítása, főleg man-in-the-middle-nél nem

- a CIA számára meg nem probléma privát kulcshoz hozzájutni bármelyik CA-tól

Nem értem, hogy mit nem értetek. Persze ha megmagyaráznátok, megvilágosulhatnék, nade így sutyorgás mellett ez nem megy.

Te jó atyaég... Légy oly kedves térítsd el az 53-as portomat és írj át egy akamai.com címet. 

 

$ dig DS akamai.com +trace @172.64.36.1                                                                                                                                                                                                                                                  
; <<>> DiG <<>> DS akamai.com +trace @172.64.36.1        
;; global options: +cmd
.                       515738  IN      NS      a.root-servers.net.                                                                                   
.                       515738  IN      NS      b.root-servers.net.                                                                                   
.                       515738  IN      NS      c.root-servers.net.                                                                                   .                       515738  IN      NS      d.root-servers.net.
.                       515738  IN      NS      e.root-servers.net.
.                       515738  IN      NS      f.root-servers.net.
.                       515738  IN      NS      g.root-servers.net.
.                       515738  IN      NS      h.root-servers.net.
.                       515738  IN      NS      i.root-servers.net.
.                       515738  IN      NS      j.root-servers.net.
.                       515738  IN      NS      k.root-servers.net.
.                       515738  IN      NS      l.root-servers.net.
.                       515738  IN      NS      m.root-servers.net.
.                       515738  IN      RRSIG   NS 8 0 518400 20240909050000 20240827040000 20038 . dGT3/LbTsg+L2Uw3iV5IRd6MjPmPqCLwUyKdLoJJJTpZtDIm1D
KhFySn XXoxC6b+QvylGIIjZaFYseJuBeHHkt4LyE8JdxlZXE/0elQkKxhFTi7J T7Errb8LLuJJdEYZBaG4VcUEaiujSZ1c7AgbZdmBcFJVNK0mC+92gDlf hvBYI/RFGOILSSWexOIHP7V9vd2su
aCBqL4G7hw39sCIWoF+8kzWw2mQ H9Pyv3s0Feo7SiFeozIwY5a8WX7hjyKBQpccf35PoqxJHQVkK8Xoomom 5yYiP//95Zr4/DoEPg7NKPJp93c6x4Nf42DUSOrDIBAvNuapyxgLkwSq 2hkFbg==
;; Received 525 bytes from 172.64.36.1#53(172.64.36.1) in 20 ms    

com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.      
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.                    86400   IN      RRSIG   DS 8 1 86400 20240909170000 20240827160000 20038 . I9lgoZ+xUCxMGH0VVzagIX8STekqqdYRRoGS7/CWPuHlBdzXQPl
VWfz7 51WfLYrScaYBtG7cOU+v4rLpHi2VjUg+DqBZoXHP5Re6tlYD5yvn1Lzi iSn3PGXr3MjZNPPOBc6OxIb/z1Gw2xkjZMY+Kxa8Vsk/Nl2sqn+xMw+q 7Wv7cM3BXuSbIQxvALQVb8D6ZJZsJx
mVMHHSxajCanSXbJZPI0MGyflO 72gknLJrLWdPb5nZJo9vvwovVfGt+OgCu1UiL5YWTwgEuh0Q+tu5B0yX KxsHnUOaDaAhAUp6N93VtC/ymUbfUub/h2JBSV6uZv/VObKXdO5O2/n7 myMepQ==
;; Received 1170 bytes from 202.12.27.33#53(m.root-servers.net) in 36 ms

akamai.com.             86400   IN      DS      18256 8 2 2B4811DF95E7DCFE4E69AC1D1F687CD62BF0B0B478C52455D7C157C3 FB02348B
akamai.com.             86400   IN      DS      39889 8 2 68A1B153D655BFECD5A7B9F0604A5293329F7AC842E61C84C6A12D9A 8F8AD1E7
akamai.com.             86400   IN      RRSIG   DS 13 2 86400 20240901235959 20240825224959 59354 com. sTvigcAyrJB4DAWuUd3vqI5e/0pI2p2yfllmQTOLYm8VL2D
lLbQLnABF O7y6NnAgbrOoyIOJhs5N7yR5LGgpUg==
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      RRSIG   NS 13 1 172800 20240902025931 20240826014931 59354 com. Kxx11t7qzE5RTwZMzwuT3mW1bB5ccgxB17eL+QcUraWH8Q
1u79vy71QP IBQlPX80YpqD9zM+7HPdk7zbEq+0sQ==
;; Received 1129 bytes from 192.52.178.30#53(k.gtld-servers.net) in 32 ms

 

Épp erről kérdeztem. Feltűnik-e a felhasználónak, ha a tuti HSM-ed helyett egy feltört Verisign írja alá a szerveredet?

Tegyük fel, hogy a Firefoxnál mindkettő a megbízható tanúsítványok között van.

 

A kérdés, hogy muszáj-e nekem pont azt használni, amikor a Firefox 23 másikat is elfogad mellette.

Azt kérdeztem _hogy viszi el az NSA_ az _én_ privát kulcsomat a HSM-emről. Te azt állítottad van hozzáférése. 
Nem arról beszélünk, hogy egy titkosszolgálat ne tudna bármilyen névre tanúsítványt kiállítani akár röptében hanem a következőről:
- nem biztos, hogy te megbízol abban a tanúsítványkiadóban (https://crt.sh/?q=hup.hu)  /hogy értsd is, ha nincs listázva: bukta, akkor nem fogadjuk el. Ha listázva van, akkor lebukott, és erre monitort is beállíthatsz rá/
- ha nagyon biztos akarsz lenni, akkor magadnak csinálod a CA-t és szépen nem használod a többit és olyan privát kulcstárolót használsz amiről a privát kulcs nem nyerhető ki. 

Mondhatnám még tovább, de szaladsz körbe körbe mint a megkergült kutya a farkát üldözve, mivel ha nem tudsz válaszolni egy kérdésre, vagy felismered, hogy falhoz értél akkor "sallalla" akkor máshol csalok. De sajnos nem ismered az alapszettet sem.

Még egyszer, itt nem arról van szó, hogy az NSA le tudja e hallgatnia  te Facebook üzenetedet, hanem arra, hogy ha biztos akarsz benne lenni, hogy a te üzenetváltásodba nem lát belle egy ideig, akkor arra _van_ megoldás. 

Mert te úgy gondolod, hogy mindenkinek security szakembernek kellene lennie, akinek telefonja van.

Sajnállak, de az a TLS, ami a telefonommal jött, olyan, mint az EESZT. Csak az nem tudja olvasni, akit nem érdekel...

 

Persze én vagyok a hülye, hogy az Android 139 megbízható CA-ját faszságnak veszem, mert akár ki is kapcsolhatnám a család 5 telefonján egyesével mindet.

Csak ugye az emberek 99%-a nem fogja, ahogy az EESZT-ben sem korlátozták Náncsi néni indokolatlan hozzáférését a beteglapjukhoz.

 

Erre jön a TOR megoldása, hogy szarunk a tanúsítványaitokra és client authorization van végpontok közötti titkosítással.

Fizikailag felmásolod a kliensre és a szerverre is a kulcsokat és ez a neten nem jelenik meg, privát fájlok, így lehetetleníted el a Man-In-The-Middle-t.

Azert ne legyel meggyozodve a biztonsagodrol meg TOR hasznalata eseten sem. Csak elszantsag kerdese...

Lasd:

Valojaban azt van, hogy megbizol egy altalad nem ellenorizheto overlay halozatban. Sziuram, Koh-i-noor okosba?

Mert te úgy gondolod, hogy mindenkinek security szakembernek kellene lennie, akinek telefonja van.

Ezt írtam: "Az a kisebbik baj, hogy nem értesz hozzá, a nagyobbik, hogy azt hiszed igen." ez igaz az átlag felhasználóra is. Az átlag felhasználónak annyi a dolga, hogy használja azt amit beépítenek (CertTransparency kötelező pár éve és a böngészők el is várják és ellenőrzik)

Persze, nincs más dolgunk, mint megbízni a Govertment Root Certification Authority-ben és nem változtatni semmit. Haha.

Azért van kérdésem, ha egy CA képes MITM támadásra:

- Ki az a Government Root Certification Authority?

- Melyik kormányé (nyilván az USA-é)?

- Mi a fasz köze van ennek a kormánynak az én telefonomhoz?

Nem kéne Kim Jong Unnak is CA-t telepíteni a telefonomra?

 

Megbízni, mi?

A legjobb persze a Netlock Kft alapértelmezetten telepített tanúsítványa a telefonomon. Ők ugye becsületes magyar vállalkozók.

 

Jegyzett tőkéjük: 4 146 400 HUF

Utolsó létszáma: 72 fő

Nettó árbevétel: 3 226 963 EUR

 

És ugye ez a Netlock Kft bármikor képes MITM-et csinálni a telefonomon. Persze bízzunk meg bennük, hogy nem teszik. Gratulálok.

Fuss már újra neki, hogy ha pl. a Netlock kiállít a böngészők által elfogadott CA-jával egy valid certet mondjuk a hup.hu tartományra, akkor pontosan hogyan fog nálam az általuk üzemeltetett kamu hup.hu oldal (az általuk csinált kamu tanúsítvánnyal) megjelenni a böngészőmben ha a hup.hu-t beütöm a címsorba?

Az MITM nem a cert hamisítás, hanem a forgalom eltérítés. A cert hamisítás már csak akkor érdekes, ha sikerül a forgalmat magadhoz terelni, és még inkább hihetőnek akarsz tűnni. De hogyan fog az én gépem a Netlock által üzemeltetett web szerverre kapcsolódni a hup.hu elérése érdekében (ahelyett, hogy az igazi hup.hu webszerverre kapcsolódna)?

Erre...

A baj ott van, hogy adott egy bonyolult rendszer (IT), amelynek minden elemeben, beleertve a ket vegpotot es az elottuk ulo mokust, meg kell bizz.

A baj meg mindig ott van, hogy a nem altalam felugyelt vegpont (pl. ceges laptop, rajta a Windows es egyeb cuccok) cert kezelese alapbol megbizhatatlan. Pontosabban, abban bizom, hogy a vegpont tulajdonosa sajat maga altal fontosnak itelt valtoztatasokat hajtja rajta vegre. Kettonk erdeke nem feltetlen ugyanaz.

Bizalom nélkül nincs titkosított rendszer. Valakiben meg kell bízni, ellenkező esetben a darknet sorsára jutsz: senki senkit sem ismer, aztán abból bűnözés, meg erőszak lesz.

Mi a gond? Hogy szétkorrumpálódott a világ: a kormányzat, multinacionális vállalatok lehallgatnak, megfigyelnek, visszaélnek következmények nélkül, végül eljutsz odáig, hogy ők is csak játékosok a dark webből, az általuk nyújtott szolgáltatások pont úgy megbízhatatlanok, mintha egy random csávót kiválasztanál.

Bizalmi pozíciókba megbízhatatlan káderek kerültek, ezen pedig semmilyen kriptográfiai algoritmus nem segít.

Elmagyarázom:

- 1. kiloginolsz a hupból

- 2. megnyitod a webfejlesztő eszközöket a firefoxon

- 3. beloginolsz

- 4. visszakeresed, hogy mi ment a böngészőből kifelé és látni fogod az user nevedet és jelszavadat titkosítatlanul

- 5. a TLS csatornán a user neved és jelszavad titkosítatlanul utazik

 

Man-In-The-Middle:

- 1. kábel kihúz, router-szerű kütyü bedug, a kütyü lesz a middle

HUP <=> kütyü <=> Géped

- 2. A HUP felé kimenő forgalmat [92.119.122.43] eltereled

- 3. Létre hozol egy kamu szervert Netlock-os aláírással, ami semmit sem csinál, csak proxy-zik a HUP között

- 4. Azaz: van egy kapcsolat, ami TLS alatt futt, de a kütyüm már ClearText-nek látja

- 5. Monitorozod az átküldött adatokat, kilopod a jelszót

- 6. Beloginolsz vele és meghívsz mindenkit egy sörre

Dehogyis! Amit látsz a webfejlesztő konzolban, az még nem ment ki a gépedről! A gépedről már titkosítva fog kimenni, ezért hiába teszel akármilyen csodaeszközt a géped és a net közé! Erről szól a végpontok közötti titkosítás!

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Proxy szerver. Ezzel szórakozok a munkahelyemen, hogy teszteléshez eltérítem a forgalmat.

- a programunk megnyitná a  2345 portot

- kill-lel kinyomom a programot, azt megnyitom ugyanazt a portot és továbbítom máshová

Nincs olyan hónap, hogy ne csinálnék man-in-the-middle-t. Valahogy tesztelni is kell a saját gépemen, nyilván nem production-t támadok meg. Így megy egy rendes proxy.

 

Erre lenne jó a TLS tanúsítvány, amelyik aláírja, hogy valóban a szerverrel beszélgetek. De ugye nem muszáj a Verisign-nak kiállítani, amikor a Netlock is megcsinálja ugyanezt.

Az a szomorú számomra, hogy láthatóan ezt nem viccből írod, hanem komolyan.

A felépített TLS kapcsolaton soha semmi nem megy titkosítatlanul. Ez nem vita meg hit kérdése, hanem tény. A dev konzolban azt látod, ami még nem ment ki. Amikor kimegy, akkor kizárólag titkosítva megy a már felépített TLS linken. Nincs olyan, hogy titkosítatlan forgalom közlekedik a böngésző és a webszerver között a kapcsolatfelvétel, titkosítás egyeztetése, kézfogás után után. Ez nem tudom máshogy írni, minthogy ebből látszik, fogalmad nincs, hogyan működik a TLS, mi a handshake, hogyan megy végbe, és onnantól milyen módon megy - kizárólag titkosítottan - adatátvitel.

Az elég érdekes ötlet - még Tőled is -, hogy a gépem meg a hálózatom közé bedugsz egy eszközt. Valóban, így eltéríthető pofon egyszerűen a forgalom, de akkor rajta, gyere és próbáld meg bedugni azt az eszközt ténylegesen! De nem kell fáradnod, simán betörsz otthonról a Digi rendszerébe (már segítettem is, merre indulj!), kikeresed a nálam lévő végberendezést, és annak lecseréled a szoftverét egy olyanra, ami ezt tudja. Ja, hogy az nem olyan egyszerű, mint a filmeken...
Egyetlen egy olyan esetet mondj (bizonyítékkal), amikor Te így elhelyeztél eszközt (vagy feltörtél, átalakítottál), vagy más elhelyezett így eszközt nálad, és ellopta az adatod.

Az sem tiszta a rém egyszerű leírásodból, hogy pontosan mi módon jutsz Netlock által aláírt, hup.hu-ra szóló tanúsítványhoz? Pénzért, ha bemész, csak úgy nem adnak, mert nem tudod igazolni, hogy Tiéd a hup.hu. Automatikusan megint csak nem adnak, mert a világ felől a hup.hu az igazi helyre visz (az authorativ DNS-t nem írtad, hogy hozzáfértél és átírtad, és az automata CA-k onnan nézve keresik), csak az én gépemet trükközted meg, hogy mást lásson. Vagy betörsz a Netlock rendszerébe (is), és csinálsz ott magadnak ilyen certet?

Aztán miután mindez pikkpakk megvan, becsapódtam, nézem a kamu hup.hu oldalt. A jelszavamat akkor is csak a webszerverről tudod levenni, ugyanis a forgalmat nézheted, titkosított, egyedi session kulccsal, ami a TLS handshake alatt jön létre (tehát a cert privát kulcsának birtoklása sem segít). Így amit küldök, azt csak a kamu webszervereden tudod elolvasni, menet közben nem, a kütyüdön a titkosított adat jön-megy...

Részemről nem írom ezt le még egyszer máshogyan megfogalmazva, mert ha Te bármennyiszer leírod, hogy a TLS kapcsolaton titkosítatlanul megy bármi, attól még nem lesz igaz.

> Nincs olyan, hogy titkosítatlan forgalom közlekedik a böngésző és a webszerver között a kapcsolatfelvétel,

Nincs hát, csak melyik szerverrel veszed fel a kapcsolatot? A 88.77.66.55 szerverrel? Bármikor csinálok neked olyat otthon is. Semmi nem akadályoz az IP hamisításban. Csomó kínai cuccot így hackeltek, mert titkosítatlan ment az adat és egy Raspberry volt a túloldalon céges szerver helyett.

Rohadt mindegy, hogy a Raspberry-m és a géped között minden titkosítva megy. A tanúsítvány arra jó, hogy az efféle IP hamisítást kivédd.

Ugyanakkor ha a szerver privát kulcsait megszerzem, nincs az a security varázslat, ami a MITM-et megakadályozná. És láttam már céges repóban privát kulcsokat.

A szolgáltatód routerét el sem fogod érni. A man-in-the-middle-lel eléd rakom a saját routerem. 1 hálókábel helyett 2 lesz, mert középen vagyok.

Nem jut el a kérésed a szolgáltatóig, mert elakad nálam. Olyan, mintha beraknának eléd még egy routert.

Nálam otthon kettő router van (szolgáltató, utána openwrt), aztán minden úgy megy, mint előtte.

 

Jelenleg is eltérítem a DNS portra kimenő csomagokat a saját portomra, hogy legyen pornószűrés.

Magyarul nslookup www.index.hu 1.1.1.1-et eltérítem a saját DNS portomra, a localhost:53-ra.

 

A firewall rule annyi, hogy minden 53-as portra menő kérés a 127.0.0.1:53-ra fog ezután menni.

HOGYAN TESZED BE FIZIKAILAG AZ ESZKÖZÖDET AZ ÉN HÁLÓZATOMRA A GÉPEM UTÁN?

Leírtad már 100x, hogy semmit sem kell feltörni, Te a gépünk után közvetlen teszed a kütyüdet. HOGYAN? Beengedlek hozzám és csinálod? Titokban teszed be a záram feltörésével, és én nem veszem észre sem a betörést, sem azt, hogy valami nem úgy van ahogy eddig volt?

Érdekes ez a komment, mert Csab érvelésének a védelmében már ott tartunk, hogy majd az ISP korrupt embere teszi be a cuccot az én hálózatomba.

Arról megy itt a beszélgetés, hogy milyen egyszerű MITM-et csinálni bárhol, bárkinél, és Csab betesz egy eszközt a PC-m és a hálózatom közé és már kész is az MITM támadás. Szó nem volt arról, hogy itt fizet le embert, ott zsarol meg embert, stb., hogy elérje mindezt.

Sokan azon az állásponton vagyunk (én is), hogy természetesen meg lehet csinálni, de nagyon nem olyan egyszerű ez, mint ahogy itt le van írva Csab user által.

Természetesen megfelelő előkészítéssel és szakértelemmel, emberi erőforrással és anyagi háttérrel bármilyen rendszerhez lehet hozzáférést szerezni. Ezt jól bizonyítja pl. az xz lib-es supply chain támadás ami nemrégiben volt, meg a különböző ügynökségek (IT-tól teljesen független, sokkal régebbi) gyakorlata, miszerint beépítenek embert, vagy már bent levőt beszerveznek. Ugyan ezt magán emberek/szervezetek is megtehetik megfelelő anyagi és humán háttér esetén persze. Tehát senki nem mondja, hogy nem lehet MITM támadást sikeresen kivitelezni.

Szóval, kérdésedre válaszolva, bárhová, így hozzám is be lehet törtni (fizikailag és IT terén is), MITM áldozata is lehetek, stb. De nem ilyen egyszerűen, ahogy itt elhangzik, és az IT rendszerek nem ennyire szélsőségesen védtelenek, mint ahogy itt le van írva és a titkosítás az titkosítás ténylegesen, nem jönnek-mennek titkosítatlan adatok titkosítottnak hitt csatornákon.

Azért szerintem Csab alapvető kiindulási feltétele,  hogy a CAkba való trust nem kellene, hogy magától érthetődő legyen, az egyáltalán nem egy ostoba gondolat. Az egész környékének messze az a legbüdösebb része ez a trusted third party. A trustedből ugye következik, hogy hát ott nem technikai garancia van, hanem bizalom, hogy a processzek megfelelőek, és cserkész becsszó, hát HSM!. In reality meg a default trust storeok meg tele vannak egy vödör olyan dologgal, amiben valójában miért is akarnék én megbízni? Pl Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) , hát még a nevében is benne van, hogy kamu :D és hát viccet félretéve, miért akkora alusipka, ha én nem akarok megbízni mindenféle komcsi autoriter (vagy agresszív demokrata, izléstől függően, tök mindegy) államban? Eldönti a jeditanács, hogy ezek a jók, azt szevasz. És persze, az odamegyek bedugom, az naív, cserébe az, hogy simán lehet intermediate CAja (vagy akár root is röhögve, miért ne lehetne fedőszerv) állami szereplőnek azért egyáltalán nem irracionális gondolat. Az is tény, hogy elég sok helyen megvan az infrastruktúra, hogy forgalmat tereljenek el (itthon a fogadós oldalakkal tolták át, hogy a szolgáltatóknak át kell venni állami bgp hirtetéseket), szóval hát na.

Ráadásul a CAknak adott trust carte blanche? Tudom, tudom, de hát cert transparency. Ami a gyakorlatban azért mégis csak azt jelenti, hogy bárki állíthat ki, max észreveszem, (ha figyelem, meg ki tudom mazsolázni később analízisnál, ha nem figyeltem), esetleg most már a chrome hisztik miatta. Aminek egyébként az a vége, hogy nahát nahát, minden certet be kell írni a közösbe, így biztos ami tuti, nem fog lemaradni róla a gugli (meg az összes blackhat se, hogy most kell gyorsan ránézni, amíg még nem biztos, hogy össze van rakva rendesen :) ), ki kell exposeolni egy csomó olyat, amit egyébként valójában fölösleges lenne, mert rohadtul nincs szükség az egészhez trusted 3rd partyra.

És az a vonal pedig egyre gyengébb pl ettől, hogy én megoldjam házon belül magamnak, pedig de facto az lenne a biztonságosabb. A TTP szükséges rossz valójában, hogy valamennyire kényelmesen tudjon mégiscsak működni az egész. De valamiért olyat nem lehet konfigolni, hogy márpedig az a CA ilyen domain patternekre jó, nem mondhatom, hogy a cég saját CAja csak a .cegdomain-re fogadható el. Nem mondhatom, hogy ezt a konkrét CA-t pineljük be. Nem mondhatom, hogy pontosan ezt az egy certet pineljük be.

Mindez megfejelve olyan kriptikus faszom hibaüzenetekkel és nem ember nyelven adott TLS error pagekkel, ami az egész szakma szégyene.

Szóval én azért nem dobálnám olyan nagy lendülettel a hülye vagy követ, akkor se, ha aztán a hogyan kell csinálni rész kicsit egyszerűbb Csab fejében, mint a valóság.

Szerintem senki nem ezt vitatja, en is leirtam tobbszor, hogy a PKI-val igen sok problema van, de amugy itt kene lennie egy cost-benefit elemzesnek fejben, hogy mennyit er az adatod. A hupos accountomat boven ra merem bizni a Netlockra, vagy banom is en kire, a masik veglet meg nyilvan az, hogy kirugom az osszes root/intermediate CA-t a gepemrol, aztan annak a 2-3 weboldalnak a certjet manualisan lecsekkolom, amin a raketaindito-kodok mennek

A ketto kozott meg van egy csomo, racionalisnak tuno koztes opcio.

Szerintem senki nem ezt vitatja

Hát, akkor nem egy topicot olvasunk. Mert abban, amit én olvasok rögtön jött az alusipkás baromságozás, meg az idiótázást, mikor elővette a kolléga az NSAt beleláthat vonalat. A "HSM mond neked valamit", a most már van cert transparency, szóval mostmár minden jó. Ja meg DNSSec is (ahahhaaaaa hol? :D).

Mindezt nagy mellénnyel, mert a kolléga a technikát ugyan jobban érti, de a trust modellt, meg a kritikai gondolkodást láthatólag nem, ezért lovagolt inkább az előzőn. Pedig azért leírta Csab azokat is, csak hát könnyebb azon rugózni, hogy "bedugom a dobozomat", az mennyire kevés már.

Egyrészt nem tudom, abból lett valami? Baromi régről rémlik, de azt hiszem ott kezdtem elveszíteni az érdeklődésemet, amikor valami olyasmi volt, hogy majd a mozilla javasolja, hogy mit kéne beleírni a világ összes rootCA-jába, mert nem tűnt reálisnak :)

De -- bár értem, hogy pont ezt a példát tulajdonképpen kb pont megoldja -- de rossz helyen van. A kliens adja a trustot, azon az oldalon lenne értelme megmondani, hogy márpedig én ebben a CA-ban ilyen scopepal bízok meg. Az, hogy a CA mit mondd magáról, az ebben a kérdésben szerintem elég lényegtelen.

Ha jól rémlik, egyébként az is volt a proposalban, hogy hát ez csak ilyen véletlen mis-useok elleni failsafe. Érezzük ugye az iróniát, hogy egyrészről persze a CAknál minden rendben van, ők megbízhatóak, hát van nekik policyjük, másrészt azért beírnánk valamit, hogy ha mégiscsak sikerül kiállítani olyan certet, amiről azt mondták, hogy olyat sose fognak, arra legyen valami technikai limit azért :)

Egyrészt nem tudom, abból lett valami? Baromi régről rémlik, de azt hiszem ott kezdtem elveszíteni az érdeklődésemet, amikor valami olyasmi volt, hogy majd a mozilla javasolja, hogy mit kéne beleírni a világ összes rootCA-jába, mert nem tűnt reálisnak :)

Poszt-tolás előtt én is gyorsan rákerestem, 2020 körüli bejegyzésekben olyasmiket olvastam, hogy a böngészők támogatják, csak nem a root CA-ba kell beleírni, hanem az intermediate-be.

De -- bár értem, hogy pont ezt a példát tulajdonképpen kb pont megoldja -- de rossz helyen van. A kliens adja a trustot, azon az oldalon lenne értelme megmondani, hogy márpedig én ebben a CA-ban ilyen scopepal bízok meg.

Egyetértek, ezért is írtam a céges CA-val kapcsolatban, amit te ellenőrzöl.

Poszt-tolás előtt én is gyorsan rákerestem, 2020 körüli bejegyzésekben olyasmiket olvastam, hogy a böngészők támogatják, csak nem a root CA-ba kell beleírni, hanem az intermediate-be.

És vajon ezt megteszik? :)

Egyetértek, ezért is írtam a céges CA-val kapcsolatban, amit te ellenőrzöl.

Igen, bár azért user szemszögből még mindig csuklik egy kicsit ez :)

"hallottal mar arrol a fogalomrol hogy beepitett ember?"

Persze, a Harkonnenek csináltak ilyet Arrakeenben, amikor egy szerencsétlen flótást befalaztak egy fürkészvadász irányító konzollal, aki kis híján ki is csinálta Pault. De én kétlem, hogy nálunk bárki befalazott volna bárkit a pincébe, biztosan jelzett volna nekünk az ott lakó pszichopata sorozatgyilkos, aki eddig megölt mindenkit, aki kisebb nála. De minden rendben, van rá engedélye, elvégre inkább ő, mint az egerek. :-)

Teljesen gáz ez a beszélgetés,

1, Csab a világnézeti képét osztja meg a szálban nem technológiai kérdéseket tárgyal.
2, az ő elképzelése szerint van háttérhatalom ami a hárombetűsökben csúcsosodik ki
3, a hárombetűsek _mindent_ is tudnak a fentiek alapján, szóval náluk csak_norris erősebb
4, már csinált szegény ember MITM-t és mivel ő úgy áll a többi emberhez, hogy ő megvilágosodott, a többiek meg megtévesztettek, ezért az az alapvetés, hogy minden csak illúzió ami technológiai információt megosztunk vele. 
(természetesen azt sem érti, hogy sokkal kisebb költséggel jár és sokkal titkosabb, ha az adatokat maguktól az egyedi szolgáltatóktól kéri el, akiknek törvényi kötelezettsége ilyen megfigyelési rendszereket implementálni, nem kell baromkodnia MITM-el, az végpont-végpontot is az egyik végpont kompromittálásával fogja megfigyelni, ha megéri neki  )

A megbízhatóságnak van egy története, itt nem elsősorban a titkosítottság a kérdés, hanem az, hogy tudod e, kivel veszed fel a kapcsolatot. 
Eredetileg a tanúsítvány szolgáltatóknak ebben nagyon nagy felelőssége és szerepe volt, és mivel voltak visszaélések ezt átalakították. Ma kötelezettség a tanúsítvány kiadás átláthatóság, azaz ha nincs listázva a kiadott tanúsítvány és nincs SCT akkor már a böngésző eldobhatja a kapcsolatot.
Mivel mostanra felfogta, hogy van DNSSEC, SCT, és a végpontot nem lehet 20 évvel ezelőtti módszerrel átcseszni épp a kifogásokat keresi, mivel ez nem egyezik a világképével.

"A megbízhatóságnak van egy története, itt nem elsősorban a titkosítottság a kérdés, hanem az, hogy tudod e, kivel veszed fel a kapcsolatot."

Ez a legfontosabb mondat.

Pont ezt fogalmaztam meg itt: https://hup.hu/comment/3103796#comment-3103796

"Régen a GPG/PGP -nek is ez volt a rákfenéje, hogy ismerned kellett a partner kulcsát, és ezt vagy személyes kulcs cserélő partikon lehetett megtenni, vagy pedig a különféle "kulcskarikákat" lehetett egymással megosztani, és itt volt a bibi, mert ha egy valakiben megbíztál, pedig nem kellett volna, akkor máris bukta volt.

PKI ide vagy oda, a végén mindig oda jut az ember, hogy az a kérdés, hogy kiben bízik meg az ember."

Ahogy olvasom, a google a saját szervereitől megkérdezi Chrome alatt, hogy okés-e a CA.

Visszatértünk ugyanahhoz a kérdéshez: biztonságos-e, ha az internet a Google szerverein és alkalmazásain keresztül működik? Mi a garancia, hogy a Google nem él ezzel vissza?

A Google egy multinacionális vállalat. Nem kormányzati szerv, nem joghatóság, jófej hogy szól, de azért mégiscsak Pistával van egy szinten a kocsmából...

A Google önmagában egy rohadt nagy security hole, hogy minden adat rajta megy keresztül.

Egy frászt. Ha ez így lenne, akkor a filmekben a szemüveges hekker lány nem egy telefonnal nyomná fel rágózás közben, mondogatva, hogy gyerünk, gyerünk, míg fel nem bukkan egy tök szépen megdizájnolt zöld ACCESS GRANTED felirat a böngészőjében.

Ez tuti így van a valóságban is! :-)

Legjobb tudomásom szerint, ha én vagyok a céges tűzfal,
- ÉS a céges kliens gépre le van telepítve a megfelelő CA cert
- ÉS én vagyok az egyetlen kijárat, vagyis a DNS válaszokat is tudom módosítani

akkor azzal a CA -val alá tudom írni bármelyik weblapot azonosító kamu certet, és a böngésző el fogja fogadni.

De még ekkor is látni fogom a tanúsítvány láncban, hogy a gmail.com teljesen valid certjét 5 perce állították ki, és a saját cégem CA -ja írta alá, hogy jóvanazúgy.

Namost, ha a FB összekapcsol engem és Gipsz Jakabot, akkor kérdéses, hogy ezt hogyan teszi.
Ha a tőlem GJ felé menő adatfolyamba be tud állni, és csak rajta keresztül tudunk kommunikálni, akkor van esély, hogy Microsoft-skype módra ( https://arstechnica.com/information-technology/2013/05/think-your-skype-messages-get-end-to-end-encryption-think-again/ ) megnézze mi zajlik Gyöngyösön.

Ha viszont csak összekapcsol engem és a cél gépet (például UDP traversallal) és utána már egy teljesen más útvonalon beszélgetek közvetlenül a cél géppel, akkor ott kialakulhat egy egészséges kulcs csere amibe nem áll bele senki, vagyis a végén valóban p2p kapcsolat lesz.

Régen a GPG/PGP -nek is ez volt a rákfenéje, hogy ismerned kellett a partner kulcsát, és ezt vagy személyes kulcs cserélő partikon lehetett megtenni, vagy pedig a különféle "kulcskarikákat" lehetett egymással megosztani, és itt volt a bibi, mert ha egy valakiben megbíztál, pedig nem kellett volna, akkor máris bukta volt.

PKI ide vagy oda, a végén mindig oda jut az ember, hogy az a kérdés, hogy kiben bízik meg az ember.

Man-in-the-middle: kihúzom a géped netkábelét, elé rakom a middle szaromat és azt bedugom a hálózati csatlakozóba.

Felépítésében semmivel nem bonyolultabb, mint egy router. Innentől kezdve a teljes hálózati forgalmad rajtam, mint middle megy keresztül.

 

Csak annyit kell tennem, hogy 1 kábelt kihúzok és 2-t bedugok.

Csak annyit kell tennem, hogy 1 kábelt kihúzok és 2-t bedugok.

Egy proof of conceptet be tudnal errol mutatni? Nem kell semmi bonyolult, eleg ennyi hogy ha mondjuk errol a geprol, amirol ezt irom, ha felmegyek, mittudomen, az https://index.hu/ -ra, akkor a te certeddel ujracsomagolt valtozatot kapjan belole.

hat ha o nem is. de azert a tortenelemben volt parszor amikor nem arra meg a forgalom ahova kene: https://en.wikipedia.org/wiki/BGP_hijacking#Public_incidents

es kitudja hogy ebbol mennyi az ami mitm-nek indult, csak elk.rtak es kiderult.

jah es a bonusz:

February 2022: Attackers hijacked BGP prefixes that belonged to a South Korean cryptocurrency platform, and then issued a certificate on the domain via ZeroSSL to serve a malicious JavaScript file, stealing $1.9 million worth of cryptocurrency

mert ha jol ertem most arrol megy a vita, hogy lehet-e olyan hogy valaki elteriti az valami.com domaint, majd csinal hozza megfelelo certet, akkor utana arrol olyan fajlt szolgal ki amit akar.... 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az tiszta, hogy van ilyen, és megcsinálható. A vita nem erről megy.

A vita arról megy, hogy ez azért messze nem olyan egyszerű, mint ahogy Csab állítja-hiszi.
Meg arról, hogy a teljes PKI rendszer úgy szar ahogy van szerinte, mert az NSA-nak, CIA-nek, stb.-nek megvan az összes, böngészők által elfogadott legfelsőbb root CA privát kulcsa, és arra írnak alá certet amire csak akarnak.

nemkell az osszes, eleg csak egy olyant ami eleg sok bongeszoben benne van. volt ra pelda.

es de, a vita arrol megy hogyha elteritik a forgalmat (de meg elteriteni sem kell, eleg ha ISP-nel dolgozik egy beepitett halozatos ember), akkor a ssl/tls megved. szerinte nem ved meg. 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az SSL/TLS megvéd a lehallgatástól. Ezen kár vitázni.

Ami ellen nem véd, az a titkosítás előtt ellopott adat (a kliensről) meg a titkosítás feloldása után ellopott adat (a szerverről). Az ISP embere által megszerzett titkosított adatfolyammal semmit nem ér senki jellemzően. Nem is ott támadnak, mert annak feltörésénél van egyszerűbb mód is (ami még mindig nem egyszerű)...

Az MITM módszerrel elérheti, hogy a szerver oldal a fennhatósága alatt legyen, így a titkosítás feloldása után hozzáfér az adataimhoz. De ahogy fentebb is írtam, egy teljesen rejtett és sikeres MITM támadást nem olyan könnyű kivitelezni...

Soha nem mondtam, hogy egyszerű.

Az, hogy valami nem egyszerű, nem jelenti azt, hogy lehetetlen.

Az, hogy az emberek 99.999%-a képtelen feltörni a hálózatod, nem jelenti azt, hogy 20 perc alatt más nem fog bejutni.

A hatalmas csalásokat és károkozásokat nem parasztbácsik követik el. Teljesen hibás gondolat azt feltételezni, hogy ha 99.999%-ot kizársz, akkor biztonságban vagy.

Es akkor itt jon be az aranyos vedelem koncepcioja, hogy ha en tudom, hogy az adataim megerik a top 0,001% erofeszitest, akkor ennek megfeleloen allok hozza en is. Eddig vegig a PKI default mukodeserol beszeltunk. Ha tudom, hogy van egy appom, ami atomraketat indit, akkor oda pl. mehet a cert pinning, es akkor maris megint egy nagysagrenddel nehezebb a MITM, beepitett ember ide vagy oda.

Szerintem nem technikai oka van, csak uzleti dontes. A userek nagy resze talan a kerdest sem ertene. De nekem is csak kb 4-5 site jut eszembe, ahol valoban utanajarnek a certnek, nem pedig csak vakon leokeznam. 

A Let's Encrypt fele 90 napos certek pl. szinten adtak a szarnak egy pofont. Csak ugy ranezesre van mondjuk 200+ accountom elmentve jelszokezelobe, de legyen az hogy a felet hasznalom csak, az is akkor kb. napi egy lecserelt cert, egy ido utan mar mindenki csak nyomkodna a zold gombot, hogy persze, mehet az uj certtel a csatlakozas. Mint a 2FA fatigue.

Azt is miért nem lehet valahogy szabványosítani, és böngészőben megadni egy default választ, hogy ne kelljen már minden ványadt weboldalon ötöt kattintani, mire hozzájutok a tartalomhoz.

1. Cookie policy: messziről teszek rá, ki hogyan követi a tartalomfogyasztási szokásaimat / mindig csak a technikailag szükséges cookie-kat akarom használni / ahol van cookie, kuka. Úgyis nagy részben ugyanúgy válaszol az ember minden oldalon, akkor meg minek mindig megkérdezni. Ha kivételt akarok, majd kattintgatok egy kicsit.

2. Nem, nem akarok értesítéseket fogadni az oldalról.

3. Nem, nem akarok feliratkozni semmiféle hírlevélre. Írjátok ki a footerbe, majd kattintok, ha akarok.

4. Nem, nem akarok mobilappot letölteni egy random weboldal olvasásához.

5. Nem, nem akarok bejelentezni SSO-val. Van oldal, ami ezt is feltolja popupban.

Miért nem védendő jog a felhasználói élmény?

A valós kérdés szerintem az, hogy miként járnál utána, mit tekintesz valós, megbízható támpontnak?

Jelenleg ami első lépésként megoldható lenne, hogy a böngésző megjegyzi az aláíró CA-t, ha az változik, akkor figyelmeztet. Ez nem oldja meg, de csökkenti azon esetek számát, amikor felmerülhet valami esemény.

Esetleg DNS-ben (vagy más nyilvántartásban) egy bejegyzés, ami tartalmazza az adott címhez tartozó CA lenyomatát?

Esetleg kiterjeszteni a protokollt, hogy akár 2 CA aláírása is szükséges legyen az elfogadáshoz, ebben a címtárban tárolni ezen CA-k lenyomatát?

EU szinten a DNS jelentős védelmet fog kapni a következő években, így nem zárnék ki hasonló lehetőséget.

Mert túl sokat változik a cert. Egyre rövidebb lejáratú certeket adnak ki, korábban teljesen megszokott volt a hároméves lejárat, aztán nemrég olvastam valami olyan javaslatot, hogy fél évnél hosszabb ne legyen. Egyébként haláli, hogy milyen szolgáltatások mögött nincs normális certificate. Egyik kedvencem a RedHat server, amiről a frissítéseket lehet lehúzni, ha jól rémlik self-signed cert. Mivel nálunk (amíg még dolgoztam) a proxy is ellenőrzi a certificate-et, ezért rendszeresen eldobta, kivétellistára kellett tenni. A biztonság érdekében általában nem a hostot tettük kivétellistára, hanem magát a rossz certificate-et, aztán persze félévenként jöttek, hogy megváltozott, és megint nem működik, lehetett az újabbat is kivétellistára tenni.

Ez alapján a 'megváltoztt a cert' kb. hasonló automatikus y-t váltana ki, mint régen a sok selfsigned certre feljövő ablak.

Egyébként haláli, hogy milyen szolgáltatások mögött nincs normális certificate. Egyik kedvencem a RedHat server, amiről a frissítéseket lehet lehúzni, ha jól rémlik self-signed cert.

Ez van, mikor bekajálod, hogy a rendes cert az, amit valami rendes auth állít ki, és a self-signed az fújj rossz nem biztonságos. Miközben itt pont az van, hogy mivel a redhatnak rohadtul kontrollja van az összes kliens felett ebből a szempontból, nincs szüksége egy fölösleges kockázati tényező third partyra közé és az ügyfelei közé, azt a saját CA-t egy jól behatárolható feladatra használja, a trust modell így kevésbé kockázatos. Egyébként annyira nem értik, mit csináltak, hogy még a kliens is certekkel azonosítja magát ;)

ez MTLS, az viszont jellemzően nem működik akkor, ha a proxy SSL-t bont.

Ha szar a proxy :) De egyébként nem emlékszem, lehet, hogy a konkrét apt endpointon már nem az van, de valamit focizik vele a subscription manager. Néztem, mert valami konténer határon rángattam át, hogy mi is történik.

 Egyre rövidebb lejáratú certeket adnak ki, korábban teljesen megszokott volt a hároméves lejárat, aztán nemrég olvastam valami olyan javaslatot, hogy fél évnél hosszabb ne legyen

Ami egyébként viccesen azért van, mert így van megszépségtapaszolva az, hogy a revocation terítés valójában úgy szar, ahogy van. És hogy nem is merik használni még azt se, amit kell, lásd még Let's Encrypt CAA bug, ami után nem is tudom, 9 millió tanúsítványt kellett volna visszavonni, de nem merték.

Az SSL/TLS megvéd a lehallgatástól.

jo hat nekem nem tisztem megvaltoztatni a velemenyed. ha ezt _hiszed_ akkor hidd! :D

a tobbieknek azert jotanacs hogy ne doljenek be, onmagaban az tls/ssl keves, megfelelo technikaval lehallgathato az adat!

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A világ egyik legnagyobb állama kitiltotta a programunkat, mert túl erős volt benne a titkosítás.

Szóval a nekik szánt terméket le kellett butítani, hogy 7 nap alatt feltörhető legyen 20 évvel ezelőtt.

Repült az erős kriptográfia a kukába és csak ők mást kaptak.

Akkor még a többi ország magánéletével nem foglalkoztak, manapság már mindenkibe belekötnek.

Nem értesz hozzá, ezért a bizonytalan tudásodra alapozva hülyeségeket zagyválsz összevissza
Akkor hogy értsd:

1, Általánosságban, bármelyik programot meg lehet hülyíteni azzal, hogy a megbízható gyökértanúsítók által kiadott tanúsítvánnyal helyettesítik és csinálnak SSLi-t, te ennek egy részéig jutottál
2, Ez addig működik ameddig te nem alkalmazol extra biztonságot (saját CA / CAA)
3, Engem nem érdekel te mit gondolsz a világról, van a technológiai kérdések, meg nem technológia kérdések

A TLS és az SSL komoly gondja a tanusítványokkal van. A man-in-the-middle támadásoktól nem véd meg.

For what? Pont, hogy a MIM támadások ellen véd a TLS/SSL.

Amire te gondolhatsz, az a cégeknél alkalmazott TLS/SSL újracsomagolás. De az meg azért működik*, mert az alkalmazottak gépeire előzetesen felkerülnek a megfelelő tanúsítványok.

*: Sok esetben meg nem működik, ha a kliens rendes tanúsítvány ellenőrzést végez vagy ha mutual SSL/TLS van.

hat, volt olyan program, ami a regkey-t elkuldte a https://www.cegneve.com/check.php-nek, ami visszaadta hogy OK/NEMOK. egy jol iranyzott etc/hosts bejegyzes + sajat CA, es mar "regisztralva" is volt a program.... ennyit a MIM-rol \o/

nyilvan hulye volt a app gyarto, hogy nem csinalt tovabbi vedelmet (legalabb fix CA cert), de a puszta tls/ssl ennyit ert....

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Egy ideje már nem bízok a TLS-ben, mióta Wireshark-kal végignéztem, hogy mi megy rajta kifele.

A TLS cleartext átküldi a domain nevet, amit éppen olvasol. Magyarul a szolgáltató enkriptált adatokból is látja, hogy index.hu-t, telex.hu-t meg 444.hu-t olvasol.

 

Bocs, de az, hogy a TLS kiadja az összes internetes csomópontnak, hogy épp a csinoscicak.com-ot nézegetem, az nekem sok.

 

https://developers.cloudflare.com/ssl/edge-certificates/ech/

Sajna* még viszonylag ritka, de azért messze nem annyira.

De egyébként csak azért írtam, mert előadtad, hogy ez titkosítatlan, gondoltam szólok, hogy nem muszáj annak legyen.

*Valójában érdekes kérdés ez egyébként, mert nagyobb céges környezetekben bizony előjön az, hogy eddig megoldották a szűrést azzal, hogy belenéztek az SNIbe, de ha encryptált, akkor kénytelen lesz bontani, ami a usernek valójában privacy szinten jobban fáj. Miközben ja, a publikus interneten meg privacy szempontból jobb lesz.

... bár, a szolgáltatód úgyis látja a dns forgalmad, szóval a hovamészt így is tudja. És erre persze ott van a legyen dns over https, ami suprise suprise azt jelenti a gyakorlatban, hogy majd a google fogja tudni. Nahát :)

Ha rendes routered van, lehet DNS caching.

Köszi, tudom, nekem ez a szakmám :) Valójában cachel az OSed is, meg a browsered is, nem kell ezt elbonyolítani.

Gondolod, hogy az egyik oldalról küzdünk, hogy ne menjen ki annyi request, a másikon meg minden kurva lekéréshez csinálunk gy dns ping-pongot is?

Nem mindegy, hogy 1 db magyarnemzet.hu, 5000 db 444.hu, vagy 1 db magyarnemzet.hu, 1 db 444.hu.

Ha a szolgáltató látja, mit oldottál fel, akkor azt is, hogy mire, az alapján már tudja a forgalmadból, hogy 5000 db 444.hu és 1 db magyarnemzet.hu volt, szóval de, kb mindegy.

> Ha a szolgáltató látja, mit oldottál fel, akkor azt is, hogy mire, az alapján már tudja a forgalmadból, hogy 5000 db 444.hu és 1 db magyarnemzet.hu volt, szóval de, kb mindegy.

A CloudFlare-nek egy IP-címe van, szóval nincs kizárva, hogy a magyarnemzet és a 444 ugyanarra az IP címre megy.

Visszafelé bonyolultabb a dolog, mert csomó domain mappelődhet ugyanarra az IP-re, a szolgáltató meg annyit lát, hogy Cloudflare,

Telex

De a Telexhez tartoznak még az alábbi címek is:
2606:4700:20::ac43:47a0
2606:4700:20::681a:355
2606:4700:20::681a:255
104.26.2.85
172.67.71.160
104.26.3.85

Szóval miből gondolod, hogy a Cloudfare-nek 1 IP címe van? A 104.26.0.0/20 - ami elég sok IP címet takar a Cloudfare-é.

Miért ne találnám ki? Na jó, 10 mp-nél kicsit több idő kell hozzá.

Tessék egy weboldal a 3.161.119.64 IP cím mögött: https://statsradio.com

Mellesleg értelmetlen a kérdésfeltevés a split-horizon / split-view DNS beállítás esetén. Házi feladat: Nézz utána, hogy mire jó, miért használják. Utána térjünk vissza a témára.

nslookup www.blikk.hu
 

Non-authoritative answer:
www.blikk.hu    canonical name = vhost-www-blikk-hu-50496.accelerator.ringpublishing.com.
Name:   vhost-www-blikk-hu-50496.accelerator.ringpublishing.com
Address: 3.161.119.34
Name:   vhost-www-blikk-hu-50496.accelerator.ringpublishing.com
Address: 3.161.119.28
Name:   vhost-www-blikk-hu-50496.accelerator.ringpublishing.com
Address: 3.161.119.35
Name:   vhost-www-blikk-hu-50496.accelerator.ringpublishing.com
Address: 3.161.119.64

 

Mondtam, hogy végezd el a házi feladatod. Nem tetted meg.

Server:  cnss1.digicable.hu
Address:  193.110.57.4

Non-authoritative answer:
Name:    vhost-www-blikk-hu-50496.accelerator.ringpublishing.com
Addresses:  52.84.106.118
          52.84.106.108
          52.84.106.45
          52.84.106.22
Aliases:  www.blikk.hu

<Troll ON>
Sherlock, ovis játékot nem játszom most veled.

Az pedig nem egy újság, hanem egy digitális szemét generátor.

Kifejtős kérdés: Magyarázd meg kérlek, hogy miért kaptál te teljesen más IP címet a blikk.hu-ra, mint én.
Tuti, valami konteós választ fogsz lenyomni.

mar miert nem?

A sikeres közbeékelődéses támadáshoz a támadónak hozzá kell férnie a kommunikációs csatornához, képesnek kell lennie lehallgatni a rajta küldött üzeneteket és megakadályozni, hogy eljussanak a valódi címzetthez.

az elsot megoldotta az etc/hosts (nyilvan a routeren is megcsinalhattam volna), a masodikat meg a sajat cert. igazabol az elso csak azert kell hogy a masodikat sikeruljon megvalositani. es ha nem en futtatom az appot hanem ocsem, akkor az mar mitm? :D

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A vírusosdinak az a lényege, hogy minden szereplőt te irányítasz, de úgy csinálsz, mintha mégse.

A Commodore 64 alatt a Final Cartridge III is így törte fel a játékokat. Kívülről az E000-FFFF címtartományra erőszakkal berakott egy ROM-ot, és végrehajtott egy nem maszkolható IRQ-t (NMI). Ennek hatására a processzor elugrott az (FFFA) helyen található címpárra. Ezután semmi más dolga nem volt, mint kiírni a játékot floppy-ra a RAM-ból.

A játéknak persze fel sem tűnt az egész.

Abban a világban bementél a boltba és levetted a polcról a cartridge-t, ami feltörte a haverod játékát és elmentette a floppy-dra.

Ez feltételezés a tapasztalataid alapján. Ugyanakkor a Snowden ügy azt mutatja, hogy nem biztos, hogy eme feltételezés megállja a helyét.

Csomó kínai cuccnál a gyártó elfelejti levédetni a kódot, meg van JTAG is, amivel még debuggolni is tudod a processzort. Már ha nincs letiltva.

 

Az inverteremben ESP32 processzor ketyeg (2022-es gyártás). Miska bemászik a kertbe, kiszedi az inverter wifi jeladóját.

Szerinted ki tudja a chip EEPROM-jából olvasni a Wifi jelszavamat?

 

Arról az inverterről van szó, amelyik adatai hozzáférhetők a belső hálózatomon titkosítatlan HTTP kérésekkel. Azért tudom 10s pontossággal, hogy hogyan termel az inverter, mert az adott portot pollozom.

Nyitott az inverter vaktában egy dokumentálatlan portot az ESP32-n és tök jól elbeszélgetünk vele. Az Android app lett reverse engineer-elve, onnan derült ki, hogy a HTTP szervere milyen REST hívásokat fogad.

Hát, ha a wifi-d úgy van kialakítva, hogy különösebb hitelesítés nélkül a PSK ismeretében bárki bármivel rácsatlakozhat, és onnantól hozzáfér ezen keresztül a szenzitív adataidhoz, akkor ott nem a wifi-ben meg a kiolvasható EPROM-ban van a hiba, hanem az eredeti tervekben.

Nem véletlenül van, hogy pl. az IoT eszközöknek külön hálózat készül ott, ahol védendő adatok vannak, és nincs átjárás. Meg az sem, hogy ahol tényleg titkos adatok vannak, ott semmi módon nincs wifi-n dolgozás a mai napig.

A legtöbb féle támadási felületet lehet drasztikusan csökkneteni az elérhető technológiák, védelmek tényleges alkalmazásával addig a szintig, amikor már érdemesebb másik célpont után nézni, mint velem kínlódani.

De azt nem értem, hogyan jutottunk onnan, hogy szerinted a TLS kapcsolaton titkosítatlan név/jelszó megy addig, hogy az inverteredből kilopott EPROM tartalmával férnek a belső hálózatodhoz. Minek, ha a TLS úgy sem védett meg és ellopták már az elején a user/pass párost?

Amit itt írtál, az kriptográfiai szempontból hibás - ha jól értelmeztem az írásod. Előre jelzem: Nem ismerem a TOR működését.

Asszimetrikus titkosításnál
Privát kulcs: ezzel dekódolsz egy titkosított üzenetet
Publikus kulcs: ezzel kódolsz egy nyílt üzenetet

A publikus kulcsot titkosan tartani elég nagy hiba. Mert akkor visszakanyarodunk a szimmetrikus (pl: AES) titkosítások problémáihoz.

Az biztos, hogy a content filter továbbra is működik benne, vagyis a képek át vannak valahol vizsgálva. A nyaraláskor lefényképeztem egy romot amire sok graffiti féle volt fújva, köztük egy horogkereszt. Ha az a kép is az elküldendők közé lett berakva, az összes kép elküldését azonnal lenyomta és semmit se küldött el.

( vOrOn | 2024. 08. 27., k – 18:41 )

Egyet tudok — fehérorosz, hongkongi Telegram tudatos önálló véleménnyel rendelkező elhasználok tömegével meglepetésben részesültek bizonyos állítólagos tüntetéses események után.

Micsoda véletlen, nem ellenük, hanem értük jötték az állami szervek.

Érdekes módon, ezt a népszerű és "gamereknek, ájtit szeretőknek" szóló média nem nagyon hozta le.

Végpontok közötti titkosítás többmilliós felhasználó tábor mellet számomra úgy hangzik mint az ezer szűz kurva szeplőtlen megfogantatás tapasztalatai katonai táborokban százéves és napóleoni háborúk után. 

( hajbazer v | 2024. 08. 27., k – 18:50 )

Szerkesztve: 2024. 08. 27., k – 20:27

Átállt Áterőltette a felhasználóit, a webes Messenger kliens pedig azóta 2x-3x lassabb lett. Nem elég, hogy egy mondatból álló üzenet 25-30 <div>-ből áll, ezeket scrollozáskor folyamatosan unload-olja és újrakreálja, nehogy meglássák a gonosz™ hackerek™ a scroll bufferben, illetve legalább 2 CPU magot telibe mindenképp elzabáljon, máskülönben hiába dolgoztak volna a webökör babzsákfejlesztők a csiligány 13. generációs, 8 magos, 1 TB SSD-s, 64 GB RAM-os céges pénzen hajtott erőművük előtt.

Csinálhatta volna azt, hogy az új beszélgetéseket már így indítja, a meglévőknél pedig opcionáissá teszi. Egész tömegek panaszkodtak az áterőltetés mikéntjéről Reditten és különféle fórumokon, lévén, hogy a Facebook Helpdesk fórumja már évek óta bezárt.

A meglévő, de áterőltetett beszélgetések egyébként titkosítás nélkül maradnak meg a szerveroldalon, ezt bárki ellenőrizheti egy libpurple-facebook vagy bármilyen alternatív klienssel, ami a webes API-t használja, simán le fognak jönni az áterőltetési időpont előtti üzenetek.

A titkosított chatek egyébként minden kliensben, legyen az okostelefonos, webes stb. lassabban töltenek be, lassabban reagálnak, az egész felhasználói élmény lassabb, bloat-abb, erőforráspazarlóbb.

Alapesetben az E2EE üzeneteket mindig az eszközökön tárolják, ez böngészőben az offline storage-ot (site data), okostelefonon az alkalmazás privát tárhelyét jelenti. Ugyanakkor, ha valakinek nincs végtelen tárhelye, annak ajánlják a Secure™ Storage™ megoldásukat, ami alapvetően a szerveroldalon tárolt titkosított üzeneteket jelent. Aki így szeretné tárolni az üzeneteit, az létrehozhat egy PIN kódot, amivel (állítólag) egy hardveres HSM-et unlock-ol a kulcscsere idejére. Ezt akkor kell beírni, ha új eszközről lép be, hogy leszinkronizálódjanak a kulcsok, amikkel utána a folyamatosan cache-elt (tehát elsődlegesen már nem lokálisan tárolt) titkosított üzenetek dekódolhatók.

A Messenger a beszélgetéseket folyamatosan erőlteti át, nem azonnal és egyszerre mindet. A régebbi beszélgetések tipikusan később kerülnek áterőltetésre.

Még működő tipp azoknak, akikhez még nem csorgott le és nem szeretnék, hogy áterőltessék adott beszélgetésüket: Ha létrehozunk egy titkosított beszélgetést egy nem titkosítottból, akkor kettő lesz belőle és ezt a kettőt nem fűzik össze, marad külön. Így folytatható a kommunikáció szerveroldalon tárolt nemtitkosított csatornán. Onnan lehet tudni, hogy egy beszélgetés E2EE vagy nem, hogy webes felületen a beszélgetés linkjében simán /t/ vagy /e2ee/ jelenik meg. Ha egy sima /t/-s beszélgetéshez létrehozunk egy E2EE "párt" a ... -> Start end-to-end encrypted chat, akkor adott kontakt kétszer fog szerepelni a beszélgetések közt, egyszer az E2EE beszélgetésével, egyszer a titkosítatlannal. Kifejezetten hasznos, ha valaki alternatív klienssel használja a Messengert, ami nem támogatja a végponti titkosítást.

Akit bővebben érdekel a backend megoldás (kriptográfiailag érdekes): https://engineering.fb.com/wp-content/uploads/2023/12/TheLabyrinthEncry…

Ja, tök szemét Faszbuk. Mennyivel jobb volt titkosítatlanul, kínaiakon elkezdve, Észak-Koreán át, egészen az oroszokig mindenki követhette érdekfeszítve, hogy mit csetelsz.

A 2-3-szoros lassulás miatt nem panaszkodni, a másik topikban megmondtad, hogy neked elég a majdnem két évtizedes Turion, nem kellenek csillió gigaherzek, sok mega cache, meg AES utasításkiegészítés, zavarná a nyílt naturalista, kitárulkozó életrendedet.

Elárulom, hogy ma már minden végpontok között titkosít, Matrix, Discord, Telegram, Whatsapp, Signal, stb.. Eddig a Facse különcködött, mert a nyelve a hatóságok ánuszrózsájába volt beleszorulva, de észrevették magukat, hogy gáz. Lehet pár év múlva az Apple is eljut erre a szintre. Talán mostanra csak a Skype maradt ki, de azt a kutya nem használja.

Mondanám, hogy használj IRC-t, van belőle a kedvenced, jó kis terminálos verzió, de van GUI-s is. Szög egyszerű, plain text alapú, titkosítatlan. Senki nem kötelez rá, hogy Messengert használj.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem. Az IRC alapból nem definiálja, hogy min kell menjen az üzenet, csak a plain text alapú protokollt rögzíti. Az megint más, hogy minden magára adó IRC kliens ma már tudja az SSL/TLS opciót, akinek kell bekapcsolja, és azon ereszti át a forgalmat, de nem kötelező benne használni.

Én mindenkinek ajánlom ennek ellenére, hogy titkosítson. Mindenki, nem csak az IRC-sek, meg a Messengert használók. Sőt, én nagy híve vagyok az offline titkosításnak is, hogy teló, PC, NAS, külső meghajtó, stb. titkosítva legyen, csak az ott szokott elbukni, hogy sok átlag felhasználó képtelen azt felelősséggel kezelni, vagy kiragasztják a monitorra a jelszót, vagy a titkosítási kulcsot tartalmazó pendrive-ra írják rá, vagy ha nem írják fel sehova, elfelejtik a kulcsot, és bukják az adataikat.

Ez a TLS/SSL, meg 256 bites LUKS AES XTS már a 10 évvel ezelőtti duálcerkás fos laptopomnak se kottyant meg, alig lassított pár %-ot, olyannyira, hogy még mérni is nehéz volt, nem hogy emberileg érzékelni. A modern procikban van rá utasításkiegészítés is, ott meg konkrétan 0%-ot lassít.

Sőt, tovább mennék, a titkosításhoz, magánadatok védelméhez való jogot be kéne venniük nemzetközi emberi jogi szerződésekbe, és nemzeti alkotmányokba is, hogy ilyen diktatórikus országok se, mint az oroszok, kínaik ne tudják betiltani, meg biterősségre korlátozni, még csak ne is tehessenek rá kísérletet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A modern procikban van rá utasításkiegészítés is, ott meg konkrétan 0%-ot lassít.

Nem. Attól még pörög vele a CPU, hogy van rá utasításkészlet. De még egyszer mondom: Nem a titkosítás a legnagyobb bloat a történetben, hanem ahogy a webre átültették. Ha valamit nem fog semmilyen CPU 0%-ból megoldani, az a UI bloat.

ilyen diktatórikus országok se, mint az oroszok, kínaik ne tudják betiltani, meg biterősségre korlátozni, még csak ne is tehessenek rá kísérletet.

Mivel nem Kínában, nem Oroszországban és nem is Észak-Koreában élsz, így neked ezektől a diktatúráktól holmi kevés félnivalód van. Ellenben, a végponti titkosítást épp az olyan demokratikus™ országok akarják évente betiltani, de legalább meggyengíteni mint az Egyesült Királyság, aminek a területén megélhetési bevándorlóskodsz. Ez valahogy mindig "véletlenül" elkerüli a figyelmed.

Vagy ez is a brit politikusként tevékenykedő orosz, kínai ügynökök aknamunkája lenne?

Ja nem, csak a saját házad táján söprögetni túl kellemetlen lenne, ezért hirtelen az egész emberiséget elkezded félteni a végponti titkosítás hiányától, nehogy a kifejezetten demokratikus™ új nyugati "hazád" politikusait kelljen kritizálnod.

Igen, bocs, igazatok van, erre nem gondoltam, hogy ha már a szerver követeli meg a TLS-t, akkor kikapcsolva nem tudsz csatlakozni. Viszont így is vannak még szerverek, ahol nincs TLS, barlanglakók azt még használhatják.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ja, tök szemét Faszbuk. Mennyivel jobb volt titkosítatlanul, kínaiakon elkezdve, Észak-Koreán át, egészen az oroszokig mindenki követhette érdekfeszítve, hogy mit csetelsz.

A Meta látta és mindazok, akik a Metá-hoz beláttak. Emlékeztetnélek, hogy az üzenetváltások HTTPS-en mentek, tehát titkosítva voltak, csak nem végponti titkosítással. Azt harmadik félként csak a Meta látta és mindazok, akik a Meta belső rendszereihez hozzáfértek. Tehát gondolom, akkor a kínaiak, észak-koreaiak, meg az oroszok is ki-be járkálnak a Meta belső infrastruktúrájába, hasonlóképpen, ahogy az NSA, amit a nyugatbuzi kettős mércédnek köszönhetően nem említettél a felsorolásban. Mindeközben a valóság az, hogy nagy valószínűséggel csak az NSA fér hozzá tetszőleges időben és tetszőleges alkalommal ezekhez az üzenetekhez a Meta infrastruktúráján keresztül.

Az észak-koreai, orosz, kínai hackerek pedig szépen el fogják készíteni a saját megoldásukat, ami magán az eszközön fogja ezeket az üzeneteket dekódolni. Ezeket az appokat pedig Play Store-ban és egyéb helyeken fogják ártatlannak tűnő alkalmazásmázba csomagolva malware-ként terjeszteni, ahogy eddig is ez történt. Ha adott eszköz fölött uralmad van (pl. sebezhetőséggel ideiglenesen rootolt Android), akkor minden rajta működő dolog fölött uralmad van. Fogod a Messenger appot és lezipeled a belső alkalmazástárhelyét, majd kibányászod belőle a kulcsokat. Vagy screenshotolgatsz, amikor használatban van úgy, hogy az app ne vegye észre.

Szóval most ráhúztunk a HTTPS-re még egy titkosítási réteget, gyakorlatilag feleslegesen, hiszen a Meta még mindig azt rak a proprietary kliensébe, amit akar. Mivel nem open-source, senki nem fogja auditálni és senki nem garantálja, hogy a proprietary JS-bloat web Messenger, az asztali kliens Electron-bloat Messenger, vagy a proprietary webviewgánybloat Android és iOS Messenger nem fog majd tetszőleges, végponti titkosítással ellátott üzeneteket hazatelefonálni. Arról nem is beszélve, hogy ha valakinek nincs végtelen eszköztárhelye (pl. okostelefonon), akkor be fogja kapcsolni a Secure Storage-ot, ami azt jelenti, hogy az üzenetek a végponti titkosításhoz használt kulcsokkal titkosítva tárolódnak a Meta szerverein. Új eszköz feljelentkeztetése esetén le kell generálni az ideiglenes kulcsokat az adott eszköznek, amivel dekódolni tudja a szerveren tárolt üzeneteket, máskülönben elveszettnek tekinthetők az üzenetek. Hogyan oldotta meg ezt a Meta? Hát úgy, hogy meg kell adni egy PIN-kódot, amivel elvileg (!) egy HSM-et nyit fel, aminek segítségével majd előállít neked új eszközkulcsokat, amik nyitják a Secure Storage-ben lévő üzeneteket. Nem hinném, hogy kétmilliárd egyedi PIN-kóddal nyitható HSM lenne a Meta adatközpontjaiban. Azt sem hinném, hogy a Meta nem tud a Secure Storage-en tárolt üzenetekhez saját megoldással hozzáférni, ha akar. Csak ugye egy ilyen saját megoldásra már valószínűleg nem kötelezheti a hatóság, ő lobogtathatja a papírkát, hogy kérem itt végponti™ titkosítás™ van.

A Meta ezzel a húzásával egyértelműen a hatósági megkeresések alól akar kibújni. Nem azért, mert amúgy ez hozzáadott érték lenne, hiszen azért lehetett monopólium, mert egy kisebbségen kívül pont leszarta több milliárd ember, hogy miként vannak titkosítva az üzenetek. A Meta azért akart kibújni a hatósági eljárások alól, hogy ezzel is spóroljon a felmerülő költségein és esetleg egy kis marketingfennhangot majd adnak neki. Ugyanakkor, a webes és appos implementáció egy csiligány, kritikán aluli bloated szarkatyvasz lett, ami szintén mutatja, hogy a Meta ezt csak ki akarta pipálni, fejlődni valójában nem akart. Az általad felsorolt összes üzenetküldő alkalmazás jobb performance-t ad a Turion 64-emen, mint a Messenger bármelyik változata.

Az összes technikai lépés a Meta kezében van, még a végponton végzett titkosítás is a proprietary app által. Ez így egy drága illúzió, semmi több. Open-source huszárként neked kéne az első embernek lenned, aki az új rendszerrel kapcsolatban a kételyeit megfogalmazza, nem nekem. Mégis, mi az ami számodra megint a legfontosabb? Hajbazer XP-je és Turion 64-e. :D

A 2-3-szoros lassulás miatt nem panaszkodni, a másik topikban megmondtad, hogy neked elég a majdnem két évtizedes Turion, nem kellenek csillió gigaherzek, sok mega cache, meg AES utasításkiegészítés, zavarná a nyílt naturalista, kitárulkozó életrendedet.

A kezelőfelület nem a titkosítás miatt lett bloat, hanem a bloat webes implementáció miatt. Ami ugyanígy igaz a legtöbb JS-bloat webes szutyok fejlesztési trendjeire és ezt te is el szoktad ismerni. Tehát itt nem a Turion a hibás, hanem a webes bloat. Egy Turionnál 3x gyorsabb procin is érezni a lassulást. Komolyan mondom, menjél fel a messenger.com-ra, és nézd meg Developer Tools-ban, hogy néz ki egy darab üzenet, ami már önmagában egy <div>-fellegvár. Aztán gondolkodj el rajta, hogy amit látsz a képernyőn, mennyivel tudnád egyszerűbben újraírni. A webes Messenger az a kategória, amit ha akarsz sem tudsz bloat-abbra megírni.

Elárulom, hogy ma már minden végpontok között titkosít, Matrix, Discord, Telegram, Whatsapp, Signal, stb.

Egyrészt, a felsoroltak nem egyenlők a "minden" halmazzal. Másrészt, azért tegyünk különbséget azok között, akik kezdettől fogva E2EE indultak (Matrix, Telegram, Signal) kifejezetten ilyen céllal, és azok között, akik divatból és trendből csináltak valami szemfényvesztő megoldást (WhatsApp, Discord, Messenger), hogy ne veszítsenek usert a feltörekedett előbbi kategóriával szemben. Harmadrészt, trükkösen kihagytad a felsorolásból a Teams-et, a Google Chat-et, amit szintén sokszázmillió ember használ és nyoma nincs végponti titkosításnak a csetüzeneteknél, pedig egy Teams-en nagyobb eséllyel mennek át olyan információk (pl. üzleti titkok), amire ellenérdekelt titkosszolgálatok előszeretettel vadászhatnak.

Mondanám, hogy használj IRC-t, van belőle a kedvenced, jó kis terminálos verzió, de van GUI-s is.

Rendben, ha majd minden ismerősöm elérhető lesz IRC-n, akkor használok IRC-t. Nyilván nem kedvtelésből használok Messengert sem.

Alapvetően igazad van, amit felhozol az első bekezdésekben, de én továbbra is azt mondom, hogy jobb az E2EE. Így a szolgáltató sem tud a közhatalom nyomására semmi adatot kiadni, meg nem tud segíteni a cenzúrázásban. Az engem is zavar, hogy webesek meg Electron-alapúak ezek a chat/IM/VoIP megoldások, de ez az ára a platformfüggetlenségnek. Sokkal jobb, mint ha mindegyik csak Windows, Android, iOS, MacOS-re létezne, a többiek meg dögöljenek meg.

A Team egy szar, a Google Chat-et meg kb. a kutya sem használja.

IRC-re meg szoktasd rá az ismerősöket :D Sajnos az én ismerőseim is normik hozzá, pedig én preferálnám az IRC-t, nálam van is fent mindig valami kliens, jelenleg irssi.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( hnsz2002 v | 2024. 08. 27., k – 18:52 )

Használja még valaki?

"Sose a gép a hülye."

( ggallo | 2024. 08. 28., sze – 16:55 )

Akkor most Zuckerberg nem repülhet Franciaországba, vagy már átímélezte nekik a feloldó kulcsot, így nincs veszélyben?

( laysoft v | 2024. 08. 30., p – 17:29 )

Szerkesztve: 2024. 08. 30., p – 17:30

Mivel úgyis elment a topic szinte teljes mértékben a tls/ssl felé, ezért úgy gondolom témába vágó:

Vírusírtóval ellátott router a Netgear-től

Régen volt, de amúgy ez a módszer még ma is játszik? Mennyire gáz, milyen veszélyeket jelent?

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Két lehetőség van. Az egyik: mivel nem lát bele a forgalomba, és jelenleg a webes forgalom túlnyomó része https, szart se ér. A másik: felbontja a https forgalmat, és saját kulccsal aláírja, te pedig a saját tanúsítványt megbízhatónak állítod be a böngészőben. Ez esetben vagy a CPU fog megdögleni benne, vagy egy tetszőleges sérülékenység esetén valaki netán felnyomja, és onnantól az összes forgalmadat is látni fogja. Az is jó kérdés, hogy vajon minden mobileszközben fel tudod-e venni a tanúsítványt megbízhatónak, mit csinálsz azokkal az oldalakkal, amelyek így nem működnek (lesz néhány), és így tovább. SSL bontást nagyobb cégek proxyjában szoktak alkalmazni, és ott is rengeteg munka van vele.

Egy mondatban: otthoni célra értelmetlen.

Szerintem nem kell a böngészőben elfogadni a tanúsítványát, mert hasonlóan működhet mint az ESET. Egy NOD32-t futtató vindózon megnézek egy weboldalt, aminek Let's Encrypt állította ki az SSL tanúsítványát (tuti, mert én csniáltam), a böngésző pedig azt írja, hogy a tanúsítványt az ESET állította ki. Semmit sem kell elfogadni, alapból így megy.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Értem, szóval alapból nincs benne pl. a Firefox-ban az ESET tanúsítványa, telepítéskor next-next-finish berakja. Ettől az még elég gáz, hogy a titkosítatlan content átmegy a vírusirtón.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Jól látod, volt már ebből probléma. Én személy szerint (saját fennhatóság alatt, üzemeltetni hál istennek ilyet nem kell) ezeket a web protection sztárokat le szoktam verni, scanneljen csak fileokat, nézegessen proceszeket, a httpst ne bontsa, részben túl sokat nem ér, részben meg mikor mindenféle safe link faszomat injektál a Google keresés eredményekbe pl, azért még ideges is leszek.

Ja, hogy olyan is van, amikor nem csak olvassa, de még bele is szemetel és úgy küldi tovább mintha az lenne az eredeti? Szép új világ...

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( Raynes v | 2024. 08. 30., p – 23:06 )

Na, majd Cukorbergre is ráverik a bilincset a fhanszilyákok. Titkosítással segíti a pedofilokat és terrorpistákokat. Meg a telegram-alapítós csávó mellé cellatársnak, majd cellán belül kommunikálhatnak végpontok közötti titkosítással.

Amúgy a strucckutykurutty.info el van maradva, ez már 9 hónapos hír.

“The world runs on Excel spreadsheets.” (Dylan Beattie)