Slo-Tech - V WhatsAppu je podobno kot v še nekaj drugih aplikacijah za hipno sporočanje vgrajeno šifriranje od pošiljatelja do prejemnika (end-to-end), s čimer se tehnično preprečuje prisluškovanje. Facebook ne more prestrezati komunikacije niti je izročiti na primer organom pregona, ker to ni tehnično izvedljivo. Lahko pa bi seveda komunikacijo prestrezali na samem viru, ugotavlja Facebook.
Facebook želi v WhatsApp uvesti sistem za avtomatiziran nadzor komunikacije, ki bi iskal in filtriral neprimerne vsebine. Šlo bi za sistem, ki bi bil sicer lokalno nameščen na napravi (denimo na pametnem telefonu), a bi se ves čas posodabljal z novimi ključnimi besedami in algoritmi, in sproti pregledoval vse, kar bi uporabnik napisal, še preden se to šifrira. Če bi zaznal kakšne kršitve pogojev uporabe ali kaj drugače neprimernega, bi vsebino še pred šifriranjem posredoval tudi v Facebookove strežnike.
Na ta način v resnici šifriranje postane nepomembno. Njegova funkcija namreč ni zgolj zaščita komunikacije pred vpogledi naključnih kriminalcev, temveč zaščita pred vsakršnimi vpogledi, torej tudi ponudnika storitve in organov pregona. V novem sistemu je namreč trivialno dodajati nove in nove pogoje, ali pa na zahtevo oblasti komunikacijo posameznika v celoti posredovati, še preden se ta šifrira.
Za zdaj še ni jasno, ali se bo nov sistem dejansko uvedel. Kaže pa, da šifriranje in tajnost občil še zdaleč nista tako samoumevna, kot bi si želeli. Stranska vrata ju zlahka premagajo.
Spet 24 kur pika cum? Koliko mrtvih? So storilce že identificiral?
Facebook ne more prestrezati komunikacije niti je izročiti na primer organom pregona, ker to ni tehnično izvedljivo.
Lahko prestreza komunikacijo, in jo tudi posreduje naprej.
Ključno vprašanje je; ali jo lahko dešifrira.
Moje skromno mnenje je, da tisti, ki izda Root CA certifikat, lahko dešifrira ves promet, ki je šifriran s certifikati, izdanimi "pod" to vejo. Sam to nisem 100%.
Npr. www.sslforfree.com in letsencrypt.org oba uporabljata isti Root CA: apps.identrust.com/roots/dstrootcax3.p7c
In tisti, ki si lasti privat key od zgornjega Root certifikata, lahko dešifrira ves promet vseh sajtov, ki uporaljajo certifikat izdan od njih.
Matthai, a drži to? Lastiš si Root CA private key, izdaš subordinate/issuing CA, ta potem izda web certifikat in ga uporablja za HTTPS. In ta HTTPS promet lahko dšifriraš, ker imaš Root CA private key.
Ker kolikor se spomnim (tudi v praksi), ima Microsoft dve licence za CA server; standard in enterprise. In enterprise omogoča KRA (Key Recovery Agent); se pravi če uporabnik zakriptira fajl, in potem zgubi cert (private key), gre do admina in mu ta naredi recovery key-a. In to bi lahko načeloma naredil tudi za web strežnik.
Bi moral en tak scernarij probat pa EasyRSA...
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Drugače pa kompromitiran CA ti lahko olajša MITM napad. Obstajajo pa tudi mehanizmi, ki otežijo MITM tudi če je CA kompromitiran. Recimo certificate pinning.
Prvo kot prvo, noben drug APP vam ne bo nic nucal, ce bo ven prislo, da "moras" imeti na OSju instaliran dodaten program, ki skozi skenira vse kar ti natipkas in to primerja z keywordi in algoritmi.. Citiram: "Šlo bi za sistem, ki bi bil sicer lokalno nameščen na napravi ".. Ergo, mas lahko desetkrat vse sifrirano, ce to nekdo ze prej gleda preden sifriras je kurc..
In tisti, ki si lasti privat key od zgornjega Root certifikata, lahko dešifrira ves promet vseh sajtov, ki uporaljajo certifikat izdan od njih.
Matthai, a drži to? Lastiš si Root CA private key, izdaš subordinate/issuing CA, ta potem izda web certifikat in ga uporablja za HTTPS. In ta HTTPS promet lahko dšifriraš, ker imaš Root CA private key.
Ne, ker CA nima tvojega privatnega ključa subordinate certifikata. Če pohekajo CA, potem lahko podpišejo kateri koli certifikat, da so ga kao oni izdali. Ne morejo pa kar dobiti privatnih ključev že izdanih certifikatov.
Ne, ker CA nima tvojega privatnega ključa subordinate certifikata. Če pohekajo CA, potem lahko podpišejo kateri koli certifikat, da so ga kao oni izdali. Ne morejo pa kar dobiti privatnih ključev že izdanih certifikatov.
Evo to nisem 100%, da drži.
Namreč, na MS CA/PKI sistemu vem, da je možno izdan nov certifikat (npr. za web strežnik) z istim ključem (privat key-em). In to lahko admin sam naredi.
Plus, da vsaj v MS CA, ki je integriran v AD, lahko narediš recovery certifikata z privat key-em, brez vednosti uporabnika. Se pravi, privat key-i so shranjeni tudi na strežniku in admin lahko pride do njih.
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Zanima me več o tem. Kje so luknje Telegrama? (Mene je v njegovo varnost namreč prepričalo dejstvo, da se ga v Rusiji trudijo blokirati, vsi poznamo zgodbo ... ).
Telegram's security model has received notable criticism by cryptography experts. They criticized the general security model of permanently storing all contacts, messages and media together with their decryption keys on its servers by default and by not enabling end-to-end encryption for messages by default. Pavel Durov has argued that this is because it helps to avoid third-party unsecure backups, and to allow users to access messages and files from any device. Cryptography experts have furthermore criticized Telegram's use of a custom-designed encryption protocol that has not been proven reliable and secure.
Mislim, da je treba nekaj pripomniti, ker se mi zdi, da vsi iscete nek wunderwaffe, zanemarjate pa glavno "postavko":
- Firma X (telegram, whatsapp, viber,...) je podjetje z n zaposlenimi, serversko farmo, velikim zakupljenim bandwidthom. - Ponuja aplikacijo za varno komuniciranje in to zastonj, iz filantropskih razlogov.
A ste normalni? Seveda, da lahko berejo vaso komunikacijo! Ne glede na fantasticne algoritme, ki jih ponujajo, in naivce zavajajo, da so "varni", celoten njihov bussiness model stoji na branju sporocil. Lahko implementirajo ne vem kaksno end-to-end enkripcijo, z ne vem kaksnimi vse krilaticami, na koncu bojo s svojim public keyem (poleg z naslovnikovim) encryptali simetricni kljuc (za AES18290 v CTR-CBC-NT modu) in ga dodali v header. In na poti skozi streznike dekriptirali.
Edin za silo varen nacin komunikacije je v celoti open source resitev, ce pa rabite omrezje, pa IRC in spet open source plugin za clienta. Zakaj? Maksimalno preprost protokol zawrapan v ssl/tls in kot tak preprosto preverljiv, tako, da se je preprosto skoncentrirati samo na enkripcijo znotraj njega (sicer sem pa 90% preprican, da telegram zadaj goni irc server network)
Vse closed source, private server resitve so samo pesek v oci in vec je tehnoloskega bullshita vmes, bolj vam nekdo mece mivko z lopato v fris.
Aja, pa naj ob tej priliki posljem v pi*ko materino vse preklete providerje mobilne telefonije, ker nalasc gonijo mobilna omrezja za NATom in namenoma onemogocijo phone 2 phone komunikacijo brez arbitra. Dejansko bi lahko bilo vse skupaj p2p pa nalasc podjebavajo.
Ne, ker CA nima tvojega privatnega ključa subordinate certifikata. Če pohekajo CA, potem lahko podpišejo kateri koli certifikat, da so ga kao oni izdali. Ne morejo pa kar dobiti privatnih ključev že izdanih certifikatov.
Evo to nisem 100%, da drži.
Namreč, na MS CA/PKI sistemu vem, da je možno izdan nov certifikat (npr. za web strežnik) z istim ključem (privat key-em). In to lahko admin sam naredi.
Plus, da vsaj v MS CA, ki je integriran v AD, lahko narediš recovery certifikata z privat key-em, brez vednosti uporabnika. Se pravi, privat key-i so shranjeni tudi na strežniku in admin lahko pride do njih.
Ne drži. CA se uporablja IZKLJUČNO za podpisovanje certifikatov. Če odjemalec zaupa CA, bo posledično zaupal tudi tvojemu certifikatu. Torej, v tem primeru gre za "zaupanje" in ne "šifriranje". Kako pa kreiraš certifikat? Najprej generiraš svoj zasebni ključ, ki ga NE POŠLJEŠ NIKAMOR. Pošlješ pa sign request, ki ga potem CA podpiše in kreira certifikat.
Skratka, samo s CA private key ni šanse, da dešifriraš nekaj, kar je bilo zakriptirano s tvojim zasebnim ključem.
"Yesterday, I blogged about a Facebook plan to backdoor WhatsApp by adding client-side scanning and filtering. It seems that I was wrong, and there are no such plans" https://www.schneier.com/blog/archives/...
Mislim, a vi celo verjamete, da so vse te aplikacije, ki ponujajo end-to-end šifriranje varne?
Šifrirni protokol je znan, promet gre čez strežnike, v aplikaciji ste vpisali nek phrase za šifriranje, ta phrase se prenese na drugo stran za dešifriranje in še kar sanjate, da je to varno?
Vsak tak promet lahko nekdo dekodira če hoče, saj pozna vse parametre. Samo ste/smo premalo pomembni, da bi vam to počeli ...
"Life is hard; it's even harder when you're stupid."
Mislim, a vi celo verjamete, da so vse te aplikacije, ki ponujajo end-to-end šifriranje varne?
Šifrirni protokol je znan, promet gre čez strežnike, v aplikaciji ste vpisali nek phrase za šifriranje, ta phrase se prenese na drugo stran za dešifriranje in še kar sanjate, da je to varno?
Vsak tak promet lahko nekdo dekodira če hoče, saj pozna vse parametre. Samo ste/smo premalo pomembni, da bi vam to počeli ...
duckduckgo: asymmetric cryptography
Da se. Samo tega closed source aplikacije s cudovitimi smeskoti ne bojo pocele pravilno. Gre se za zasluzek, ne varnost.
Šifrirni protokol je znan, promet gre čez strežnike, v aplikaciji ste vpisali nek phrase za šifriranje, ta phrase se prenese na drugo stran za dešifriranje in še kar sanjate, da je to varno?
Jest mislim, da mors tle nekje zacet, pol pa k bos tole vse predela, pa lahk prides nazaj in se bomo pogovarjal naprej. :)
... 