Go 
Angular 
RabbitMQ Siemanko mały preview aplikacji desktop nad która pracuje i mam frajdę w wolnym czasie.
kilka cech które moge wymienic:
- Multiplatform (windows / macos / linux)
- Fully anonymous by not providing any data to signup, no email, no phone number required!
- Server-side: No logs on server, files retain at most until server reboot, there is no persistent data on server beyond registered users to perform sign-in
- Zero trackers/analitycs
- E2E encryption for text messages and media
- Proxy through tor or even connect to server only by exposed tor hidden service
- Client-side: no messages are stored on your pc, all data stays in memory until you close the app
- Voip call through webrtc p2p or proxy by coturn server
- Self hosting server
- Offline messages delivery (opt in)
- OpenSource (jak wyjdzie pierwsza stabilna beta)
tak jest to IM z tym ze różni się sporo od tych tradycjonalnych np nie ma tutaj historii wiadomości ani lokalnie ani na serwerze
@0xmarcin: tak radzi całość siedzi w pamięci procesu webview także nawet reload frontu czyści wszystko, tak z pewnością można ale nawet gdyby to wiadomości są szyfrowane RSA 4096bit a pliki aes gem 256.Mam tez w planach zrobić mały vulnerability assessment albo jakiś pen test np na serwerze akurat ludzie z mojego teamu się tym zajmują
myślałem, że to jakaś gra z tą Ziemią. A to tylko grafika przykładowa chyba.
Wygląda fajnie, ale przed zobaczeniem kodu ciężko coś mądrego powiedzieć. Mogę całą litanię pytań wrzucić, głównie do kryptografii ;). Masz trudne zadanie, bo benchmarkiem jest Signal, który jest standardem w rodzinie "bezpiecznych komunikatorów". Pytania z perspektywy klienta, zakładając że serwer jest niezaufany (co jest jedynym sensownym modelem kiedy mówimy o e2ee), np:
- w jaki sposób rozwiązujesz problem dystrybucji kluczy użytkownika? Tzn. czy mogę się zalogować na konto swojego użytkownika z innego komputera?
- w jaki sposób rozwiązujesz problem dystrybucji kluczy rozmówców? Tzn. co chroni użytkowników przed atakującym (albo serwerem) robiącym MITM i podsłuchującym/zmieniającym wiadomości?
- czy próbujesz w jakiś sposób ukrywać metadane przed serwerem (kto z kim i ile rozmawia)? Nie jest to proste zagadnienie więc pewnie nie, ale kto wie.
- czy zapewniasz w jakiś sposób (perfect) forward secrecy? Tzn. czy jeśli ktoś (np. złośliwy serwer) loguje całą moją komunikację i pewnego dnia kradnie mój klucz szyfrujący, czy mogę być spokojny że moje poprzednie rozmowy nie mogą zostać odszyfrowane?
- w tej samej sytuacji, czy jest jakiś sposób na recovery w tej sytuacji w przyszłości (backward secrecy) Tzn. jeśli ktoś jednorazowo wykradł mój główny klucz, to czy w przyszłości będzie mógł odszyfrować moje zaszyfrowane wiadomości jeśli je przechwyci?
- "wiadomości są szyfrowane RSA 4096bit" - dlatego ograniczenie wiadomości do 450 znaków? ;) Faktycznie szyfrujesz wiadomości bezpośrednio RSA, czy jednak wymieniasz nim jakieś klucze sesyjne i później już są szyfrowane symetrycznie?
Z innych kwestii parę losowych pytań:
- skoro signup jest w pełni anonimowy, nie martwisz się potencjalnym abuse (zakładaniem 1000 kont, wysyłaniem masowego spamu do innych, etc)?
- "there is no persistent data on server beyond registered users", a podczas działania? Bo to czy zapisuje dane to kwestia zaufania, ale skoro serwer coś widzi to potencjalnie mógłby zapisać (np. na request policji) - np. czy serwer "wie" kiedy kto jest online, i jakie ma zdjęcie profilowe (jeśli jest coś takiego)? Do tego dochodzą metadane o które wcześniej pytałem.
- Poza tym jak ten powyższ ficzer łączy się z "Offline messages delivery (opt in)" - zgaduję że muszą być trzymane na serwerze, ale nie liczą się bo to opt-in?
- Wbudowana integracja z TORem to fajny ficzer :). To używa systemowego tor czy jakiejś wkompilowanej implementacji? Można użyć z innym socks proxy niż tor?
A tak w ogóle to fajny projekt, klient ładnie wygląda i powodzenia :P
@szok: @cepa @cerrato https://wails.io/ + angular jesli chodzi o czesc desktop
@marcio: Czy Twoja apka i każda inna tworzona w Go+Wails działa na zasadzie WORE czy WOCA?
@andrzejlisek: tak szczerze nie mam pojecia czym sa te akronimy moglbys podac jakies konktretne info ?
@msm: postaram sie odpowiedziec na wszystkie pytania :)
1.) Nie nie ma takiej mozliwosci, prywatny klucz RSA jest generowany na twoim PC podczas rejestracji i nigdy nie opuszcza twojego PC. Aczykolwiek nic nie stoi na przeszkodzie samemu sobie zrobic export ~/.mchat na drugi pc i logowac sie na te samo konto, oczywiscie mozna byc online tylko z jednego urzedzenia (poki co nie jest to sprawdzane)
2.) kluczami (tylko publiczy RSA) mozna sie tylko wymienic gdy obydwaj uzytkownicy sa online e jeden z nich zaprosi drugiego, jako handle zostaje uzyty hash klucza publicznego, co do MITM no to wlasnie dlatego chcialbym jakis maly VA/PT ale teorytycznie wymuszajac tylko HTTPS i HSTS MITM nie powinno przejsc
3.) poki co nie, tzn tylko czesc samej wiadomosci i plikow zostaje zaszywrowana lokanie zanim zostanie wyslana na server, ale metadane maja jak najmniej info czyli tylko timestamp/fromUser/toUser/checksum/ttl/mim type
4.) Po pierwsze nie ma zadnej histori po stronie servera tzn nic nie zostaje zapisanie w zadnej bazie/redis/sqlite czy cokolwiek innego, server po prostu robi tylko za proxy zeby 2 uzytkownikow moglo miedzy soba wymieniac "eventy", tak jak pisalem wczesniej klucz prywatny RSA ktory zostaje uzyty do szyfrowania wiadomosci jak i key to szyfrowania plikow metoda AES GCM nigdy nie opuszcza twojego PC.Takze jest to sprawa uzytkownika co i jak bedzie robil se swoim PC
5.) nope, jak ktos ci wykradnie klucz to trzeba sie liczyc z tym ze musialbym sniffowac (https traffic) w tym samym czasie gdy wiadomosci zostaja wysylane po pozniej juz nie ma zadnych sladow
5a.) jedynym wyjatkiem poki co to sa offline messages (dlatego poki co jako opt-in po stronie servera) bo one siedza w rabbitmq no i metadane widac ale to mozna prosto rozwiazac syzfrujac jakimkolwiek aes zanim pojdzie do rabbitmq, wiadomo jesli ktos przedziurawi server no to mozna sie tylko pomodlic
6.) tak dlatego jest limit, tylko RSA w przypadku plikow najpierw zostaje wygenerowany klucz do szyfrowania AES potem ten klucz jest szyfrowany przez RSA (lokalnie) i dopiero potem zostaje wyslana wiadomosc
7.) poki co uzywa go garstka ludzi :D w planach poki co mam tylko jakis rate limiter jesli chodzi o wysylanie wiadomosci zeby nie moc floodowac
8.) nie ma zdjec profilowych ani zadnego typu informacji, dlatego jest mozliwosci postawienia sobie wlasnego servera jesli ktos nie ufa mojemu :) wystarczy byle jaki vps z 2GB ram
9.) tak jak pisalem wyzej punkt: 5a
10.) systemowy, teorytycznie jesli w settings podalbys jakikolwiek lokalny socks5 powinno dzialac (z ciekawosci sprobuje np lokinet) oczywiscie nie uzywajac TOR tracimy mozlisco laczenia sie z serverem przez *.onion i musimy sie laczyc przez server ktory ma jakis tam DNS przez clearnet
Dzieki i mam nadzieje ze moje wypociny da sie zrozumiec :D
@marcio: WORE - Wrice Once, Run Everywhere, czyli program, który piszesz raz, kompilujesz raz, a potem uruchamiasz na systemie, na którym chcesz, czyli dokąłdnie ten sam plik można uruchomić na Windows i na Linux. WOCA - Write Once, Compile Anywhere, czyli program, który raz piszesz, masz jeden projekt, ale potrzebne jest osobne skompilowanie wersji dla Windows, a potem osobne skompilowanie wersji dla Linux, każdy plik ma inny format. W przypadku OSX, to może być potrzebna osobna wersja dla x86 i osobna dla M1.
ah to trzeba bylo tak Od razu :D wails dziala w WOCA z tym ze mozna cross compilowac z macos/linux na windows ale wiadomo na osx trzeba miec macos
@marcio: dzięki za odpowiedzi! Mimo wszystko pociągnę temat dalej :D. Bo lubię temat kryptografii i E2EE szczególnie, a na liście ficzerów masz "E2E encryption".
teorytycznie wymuszajac tylko HTTPS i HSTS MITM nie powinno przejsc
Może to zabrzmi dziwnie, ale jeśli tworzysz aplikację E2EE to HTTPS nie powinien nic zmieniac w Twoim modelu bezpieczeństwa. W końcu komunikacja jest szyfrowana "end-to-end", czyli serwer nie jest w stanie jej przeczytać. Co więcej, jeśli serwer zostanie zainfekowany przez malware/przejęty przez NSA/zbackdoorowany przez Ciebie (i np. będzie robić MITM na każdym kroku), to dalej nie powinien być w stanie nic przeczytać. Więc zawsze zakładamy że serwer jest złośliwy i niezaufany. Tak działa np. GPG które jest jednym z najstarszych modeli komunikacji P2P, no albo Signal etc.
Może to brzmi jak paranoja, ale z drugiej strony jeśli trzeba ufać serwerowi żeby komunikacja była bezpieczna to mamy tak naprawdę zcentralizowany model bezpieczeństwa serwera a nie E2EE.
Po pierwsze nie ma zadnej histori po stronie servera tzn nic nie zostaje zapisanie w zadnej bazie/redis/sqlite czy cokolwiek innego, server po prostu robi tylko za proxy zeby 2 uzytkownikow moglo miedzy soba wymieniac "eventy",
Dlatego trochę się minęliśmy w komunikacji - jako użytkownik komunikatora E2EE nie pytam co serwer zapisuje, bo zakładam że właściciel serwera/NSA/GRU jest potencjalnie moim wrogiem i zapisuje wszystko co przechodzi przez ten serwer.
Jeśli szyfrujesz samym RSA, to jeśli ktoś ma malware na Twoim serwerze i sniffuje cały ruch a później wykradnie mój klucz RSA, to będzie w stanie odszyfrować wszystkie moje wiadomości które wysłałem wcześniej, oraz wszystkie wiadomości które wyślę w przyszłości. Nie jest to prawdą np. w przypadku Signala - ktoś kto ma malware na serwerze signala, sniffuje cały ruch, a później wykradnie mój klucz nie będzie w stanie odszyfrować żadnej wiadomości którą wysłałem wcześniej, oraz tylko kilka wiadomości które wyślę od tego momentu w przyszłości (dzięki czemuś co sie nazywa double ratchet).
Jeśli uważasz że te ataki są wydumane (ja się nie zgadzam, przypominam że konkurujesz z signalem ;) ), to z bardziej przyziemnych kwestii:
- Przy szyfrowaniu samym RSA jesteś prawie na pewno podatny na replay attack (przechwycenie ciphertextu i później wysłanie go drugi raz do tego samego odbiorcy)
- Przy szyfrowaniu samym RSA jesteś tak naprawdę podatny na sto rzeczy, w tym np. ataki homomorficzne, ale prawie żadna libka nie oferuje szyfrowania przez textbook RSA więc raczej tego nie robisz. Pewnie masz na myśli RSA-OAEP. Ale upewniłbym się że padding to OAEP a nie PKCS#1, bo ten drugi jest podatny na adaptive chosen-ciphertext attack (co może być problemem)
- Próbuję sobie zwizualizować protokół bez kodu i nie za bardzo mi to wychodzi. Jak wyglądają wiadomości które klient przesyła do serwera? Czy to coś w rodzaju:
{"fromUser": "msm", "toUser": "somekind", data=rsa.encrypt("hi there", somekind.pubkey)}
Skoro dane są szyfrowane kluczem publicznym odbiorcy (jak to w RSA), oraz "fromUser" i "toUser" są mniej lub bardziej publiczne (na 100% są znane serwerowi, a podejrzewam że wszystkim kontaktom też), to co chroni użytkowników przed serwerem spoofującym wiadomości (tzn. skąd odbiorca - somekind w tym przykładzie - wie że to msm wysłał wiadomość a nie atakujący). Jest gdzieś tam po drodze jeszcze jakiś podpis?
Ogólnie E2EE to trudny temat, możesz zobaczyć co napisał na ten temat Signal bo mają całkiem fajne papery:
- double ratchet
- x3dh
- sealed sender (to krok dalej i przykład ich trochę nowszego researchu)
Nie ma nic złego w kradzieży istniejącego protokołu, szczególnie że zrobił to np. WhatsApp, Messenger, Skype, albo Google :P.
@msm: https://www.rfc-editor.org/rfc/rfc4346#section-1 w sumie same TLS powinno nas chronic przed MITM w wiekszosci wypadkow. Serwer api nie akceptuje polaczen bez https.
w sumie same PGP/GPG tez uzywaja RSA jako jedna z metod.
Jeśli szyfrujesz samym RSA, to jeśli ktoś ma malware na Twoim serwerze i sniffuje cały ruch a później wykradnie mój klucz RSA
No tak ale to mowimy o znalezieniu jakiejkolwiek dziury na 2 roznych systemach, tzn nie jest to rzecz banalna pracuje w firmie ktora zajmuje sie cybersecurity wiec mniej wiecej wiem na czym polega i jak sie robia VA/PT black/grey/white box.
Jestem swiadomy ze nie moge konkurowac z roznymi nam znanymi IM. Ale sie duzo nauczylem jesli wlasnie chodzi o podstawy kryptografi
Kompilujac "fork" signal'a (android) bez czesci krypto wyciagalismy lokalnie z telefonu wszystkie dane na temat konwersacji z bazy sqlite razem ze wszystkimi plikami takze tutaj tez nie masz pewnosci ze na telefonie druga osoba ma signal-a "pochodzacego" z oficjalnej dystrybucji typu app store.
Co do reszty odpowiem ci wieczorem, w sumie jesli sie tym interesujesz i ci sie chce mozemy sie zgadac na jakis twoj pen test albo cos podobnego tak dla samej ciekawosci! oczywiscie to co sie da polepszyc bede chcial ulepszac :) w miare moich mozliwosci
Próbuję sobie zwizualizować protokół bez kodu i nie za bardzo mi to wychodzi. Jak wyglądają wiadomości które klient przesyła do serwera? Czy to coś w rodzaju:
mniej wiecej wyglada tak jak pokazales. Musimy tez zobaczyc to z innej strony, w moim przypadku nie interesuje mnie ukrywac (choc najlepiej byloby robic i to) kto z kim i kiedy rozmawia, interesuje mnie bycie anonimowym i to zeby wiadomosci/pliki nie byly wysylane RAW wlasnie zeby przy jakimkolwiek MITM/spoofing itp nie dalo rady lub w duzej mierze utrudnialo dojsc do orginalnego contentu.
Np signal uzywa nr telefonu czyli jako tako majac numer masz pewnosci w 99% z kim rozmawiasz bo numery anonimowe w unii europejskiej juz nie istnieja chyba od 2018 (sa tylko czeskie i byc moze jeszcze NL/UK)
Skoro dane są szyfrowane kluczem publicznym odbiorcy (jak to w RSA), oraz "fromUser" i "toUser" są mniej lub bardziej publiczne (na 100% są znane serwerowi, a podejrzewam że wszystkim kontaktom też), to co chroni użytkowników przed serwerem spoofującym wiadomości (tzn. skąd odbiorca - somekind w tym przykładzie - wie że to msm wysłał wiadomość a nie atakujący). Jest gdzieś tam po drodze jeszcze jakiś podpis?
Jest digital signature metoda hash-then-MAC ale czesc integrity musze jeszcze dokonczyc
P.S sorry ale pisze po polsku bardzo zadko wiec zdaje sobie sprawe ze moje wypociny moga byc "ciezkie" do przeczytania....
w sumie same TLS powinno nas chronic przed MITM w wiekszosci wypadkow. Serwer api nie akceptuje polaczen bez https.
TLS zabezpiecza połączenia do i z serwera, ale co jeśli to serwer robi MITM ;). To co wyróżnia szyfrowanie "end to end" to że nie musimy ufać serwerowi.
Co do reszty odpowiem ci wieczorem, w sumie jesli sie tym interesujesz i ci sie chce mozemy sie zgadac na jakis twoj pen test albo cos podobnego tak dla samej ciekawosci! oczywiscie to co sie da polepszyc bede chcial ulepszac :) w miare moich mozliwosci
Jeśli masz ochotę to możemy, można też przenieść rozmowę gdzieś poza mikroblog bo to nie jest chyba najlepsza forma do takich długich postów ;).
Np signal uzywa nr telefonu czyli jako tako majac numer masz pewnosci w 99% z kim rozmawiasz bo numery anonimowe w unii europejskiej juz nie istnieja chyba od 2018 (sa tylko czeskie i byc moze jeszcze NL/UK)
Tylko jeśli jesteś uczciwym obywatelem, jak masz coś do ukrycia to są sposoby na zarejestrowanie numeru na cudze dane ;).
@msm:
Tylko jeśli jesteś uczciwym obywatelem, jak masz coś do ukrycia to są sposoby na zarejestrowanie numeru na cudze dane ;).
No tak tylko ze majac juz same info na temat nr telefonu roznym agencja nie sprawia to wielkiego trudy cie namierzyc w tym sek dlatego ja wole uzywac session ktory jest jako tako forkiem signal ale dodaje anonimowosc. https://getsession.org/blog/phone-number-privacy
TLS zabezpiecza połączenia do i z serwera, ale co jeśli to serwer robi MITM ;). To co wyróżnia szyfrowanie "end to end" to że nie musimy ufać serwerowi.
No ok rozumiem ze nie mozna ufac zadnemu providerowi tak samo ja kto jest z vpn ze tez niby nie trzymaja logow ani nic a potem wiadomo jak to bywa
Ładnie wygląda, bo tylko tyle można napisać mając tylko screenshoty. A co do E2EE to niestety będziesz musiał się bardziej rozwinąć bo to niełatwy temat, szczególnie jeśli robisz coś customowego i nie korzystasz z OWS. No i też co robisz z kluczami prywatnymi? Tutaj też łatwo o wtopę https://www.techtarget.com/searchsecurity/answer/How-did-Signal-Desktop-expose-plaintext-passwords (edit) A widzę, że @msm już Cię męczy, to ja już w takim razie nie będę ;)
No i też co robisz z kluczami prywatnymi?
Tzn ?
Ładnie wygląda, bo tylko tyle można napisać mając tylko screenshoty
No to ze juz ladnie wyglada daje mi checi zeby drazyc dalej temat jako ze na codzien pracuje jako frontend dev 70%
No jest to tylko preview aplikacja dziala ale chce jeszcze poprawic w niej kilka rzeczy zeby mogla wyjsc na swiatlo dzienne. Z pewnoscia w kwestii E2E raczkuje ale jest to jeden z powodow dla ktorego ten projekt powstal
Tzn ? To znaczy, jeśli mamy mieć E2EE to klient sam zarządza swoimi kluczami prywatnymi, w jaki sposób je obsługujesz? Cały proces może być maksymalnie tak zabezpieczony jak Twoje klucze prywatne.
Nie rozumiem pytania....ale w fazie rejestracji jest generowana para kluczy rsa lokalnie, a przy polaczeniu sie z jakims uzytkownikiem wymieniany jest tylko klucz publiczny
Jak wygląda legalność takiej aplikacji? Czy prawo nie wymaga, aby nadawcę wiadomości dało się wyśledzić?
@piotrevic: Moim zdaniem nie ma takiego wymogu ani podstawy, żeby taki wymóg był. Poza tym, dla aplikacji nadawca to jest tylko adres IP, wszelkie nicki i nazwy to jest tylko dodatek, który każdy może sobie wymyślić. Z drugiej strony, mając adres IP, datę i godzinę, można od dostawców usług internetowych żądać danych o osobie, która miała ten IP w danej chwili. Aby się wybić z konkurencji, można zrobić dwie rzeczy: 1. nie rejestrować w żadnym logu adresów IP użytkowników, w razie czego i tak nie będzie możliwości wyśledzenia nadawcy. 2. dodatkowa usługa, że jeżeli do właściciela aplikacji wpłynie żądanie informacji o użytkowników od służby, to użytkownik będzie od razu poinformowany, że wpłynęło takie żądanie odnośnie jego osoby.
No tak tylko ze majac juz same info na temat nr telefonu roznym agencja nie sprawia to wielkiego trudy cie namierzyc
Miałem na myśli: przestępcy nie rejestrują się na swój numer telefonu. Wiedząc gdzie szukać, łatwo jest "załatwić" sobie numer telefonu na cudze dane (bez wiedzy tej osoby). Wtedy w razie czego policja przyjedzie pod zły adres.
Jak wygląda legalność takiej aplikacji? Czy prawo nie wymaga, aby nadawcę wiadomości dało się wyśledzić?
@piotrevic: jasne że nie wymaga, nie żyjemy w Chinach ;). Przynajmniej na razie.
@msm:
Miałem na myśli: przestępcy nie rejestrują się na swój numer telefonu. Wiedząc gdzie szukać, łatwo jest "załatwić" sobie numer telefonu na cudze dane (bez wiedzy tej osoby). Wtedy w razie czego policja przyjedzie pod zły adres.
Chodzi mi bardziej o to ze kazdy telefon i karta sim ma IMEI i IMSI te dane (na pewno IMSI) zostaja wysylane to wierz GSM wiec latwo jest zlokalizowac fizycznie telefon tak zreszta robi policja kiedy chce udowodnic ze ktos byl tu i tam w danym momencie
fajnie fajnie, a co w ogóle robi? to czacik a'la Slack?