Szyfrowanie SSL a kwestia bezpieczeństwa

Witam.

Oto moja rozmowa z GPT i jej wynik który chciałbym skonsultować.

Czy mogę zamiast SSL zastosować szyfrowanie inne (własne) powiązane serwer - strona?

GPT - "Teoretycznie możesz opracować i zastosować własne szyfrowanie między serwerem a stroną, jednak jest to bardzo ryzykowne i niezalecane. SSL/TLS to standardy, które zostały zaprojektowane przez ekspertów kryptografii, przeszły wiele testów bezpieczeństwa i są używane na całym świecie do zabezpieczania komunikacji w internecie. Tworzenie własnego systemu szyfrowania niesie za sobą wiele zagrożeń i trudności:

1 - Brak standardów i audytów: SSL/TLS to otwarte standardy, które zostały sprawdzone przez tysiące specjalistów i przeszły niezliczone audyty bezpieczeństwa. Twoje rozwiązanie szyfrowania nie będzie miało takiego wsparcia i audytów, co może oznaczać, że będzie mniej bezpieczne..."

JA - "który z tych tysiąca specjalistów weźmie odpowiedzialność za wyciek?"

GPT - "Żaden z "tysięcy specjalistów" pracujących nad protokołami SSL/TLS nie bierze bezpośredniej odpowiedzialności za ewentualny wyciek danych. Odpowiedzialność za bezpieczeństwo aplikacji oraz za stosowanie odpowiednich rozwiązań leży po stronie właściciela serwera, administratora sieci lub firmy zarządzającej daną stroną."

Mowimy o wielomegabajtowej bibliotece (ogromnym rozmiarze).

Jak żyć?

Może te wszystkie wycieki co są regularnie to przez ssl ?

Myślę że jesteś w błędzie. Po pierwsze jak zmusisz przeglądarki to wdrożenia twojego standardu ? Jak zaimplementujesz o sam pewnie będzie miało to tyle dziur na które nie zwrócisz uwagi że gimnazjalista skryptami z neta to złamie. Mam wrażenie ze masz przeświadczenie ze wszystko co zrobisz sam będzie lepsze. Ja się tego wyzbyłem po 6 miesiącach pracy w IT

Adin napisał(a):

Myślę że jesteś w błędzie. Po pierwsze jak zmusisz przeglądarki to wdrożenia twojego standardu ? Jak zaimplementujesz o sam pewnie będzie miało to tyle dziur na które nie zwrócisz uwagi że gimnazjalista skryptami z neta to złamie. Mam wrażenie ze masz przeświadczenie ze wszystko co zrobisz sam będzie lepsze. Ja się tego wyzbyłem po 6 miesiącach pracy w IT

Ja nie mówię o tworzeniu własnego protokołu podpiętego pod przeglądarkę (to raczej mało możliwe) ale innych rozwiązań - np. korzystaniu z kilku kanałów komunikacji. Albo operowaniu na czasie.

Albo operowaniu na czasie

Czyli co dokładnie miałeś na myśli?

Ja to operowanie na czasie rozumiem tak, że jak już dojdzie do jakiegoś wycieku czy innego incydentu to cofamy się w czasie do momentu przed zdarzeniem i wyłączamy na chwilę serwer, który był ofiarą ataku. W ten sposób do ataku nie dojdzie i kosztem chwilowej niedostępności uratujemy serwis przed wyciekiem danych. A do tego, wnioskując z różnych dziwnych teorii autora wątku, są duże szanse, że naprawdę właśnie to miał na myśli ;)

A tak całkiem serio - pomysł jest odklejony, ciężko potraktować to na serio.

Nikt nie weźmie odpowiedzialności za złamanie SSL'a. Czasem to się zdarza. Tak samo jak nikt nie odpowie za to, że mimo poduszek powietrznych, ABS i pasów bezpieczeństwa, czasem w wypadku ludzie się łamią lub giną. To są jedynie środki zwiększające szanse na przeżycie/zmniejszające konsekwencje zdarzenia, ale nie ma żadnej gwarancji. Tak samo jak nie da się zrobić serwisu odpornego na ataki i włamania. A do tego - te próby mogą następować różnych stron/na różne sposoby.

Można wdrożyć jakieś swoje zabezpieczenia, ale będzie to raczej szyfrowanie E2E, a SSL jest szyfrowaniem transportu/komunikacji, także nie mieszajmy pojęć. SSL jest wspierany przez przeglądarki, więc ciężko by było zastąpić je czymś swoim. A nawet jeśli - to musiałbyś np. w przeglądarkach klientów (albo w ich systemach) dodawać jakieś pluginy, doinstalowywać aplikacje czy certyfikaty - żeby w ogóle to mogło jakkolwiek działać. Także nie tędy droga.

Uważam, że obecne standardy są na tyle bezpieczne, że nie one są problemem. Większość wycieków czy dziur wynika z niedbałości programistów i/lub adminów - nie wgrano aktualizacji, nie sprawdzono tekstu zanim poszedł do bazy, nie sprawdzono ACL'a itp.

To jest pomysł z tej samej półki co napisanie systemu operacyjnego w asemblerze :)
Ci co nie mają prawdziwych problemów zaczynają je sobie wymyślać ;)
Niech OP nie idzie tą drogą

Jakość odpowiedzi takiego chatGPT jest proporcjonalna do jakości pytania czyli skorelowane z jakimiś funkcjami poznawczymi promptującego.

Zastanawiam się czy ty wiesz czym jest SSL, secure socket layer to po prostu warstwa dodatkowa dająca tunel dzięki, któremu osoby, które podsłuchają twoją rozmowę to dostaną dane z bardzo dużą entropią, ale też nie wszystko jest szyfrowane w ramce, szyfrowanie jest zaraz po połączeniu tcp, czyli niższe warstwy są widoczne.

Strona jak ma wyciek danych, może to być przez użytkownika, np. moderator wrzuca screeny z adresami ip userów
Czy ktoś dał proste hasło, albo był jakiś błąd na stronie co zrobił dump bazy danych np. sql injection to te dane bezpiecznie do porywacza trafią bezpiecznym połączeniem.

Z raportu ostatniego jak złapali przestępców w dark necie gdzie masz warstwy cebuli czyli łączysz się przez wiele serwerów ciągle szyfrując warstwę za warstwą to pochwalili się tym, że dysponowali ponoć połową nodów czyli węzłów w sieci tor, przez co analizowali co wpływa i gdzie wypływa, nie wiedzieli co dam są za dane, ale mieli różnego rodzaju metadane czyli wielkości payloadów, czas kiedy wysyłany i kiedy dotarł czyli z pewnym prawdopodobieństwem można wykryć z jakiego węzła przyszedł, a także do jakiego dostawcy internetu czy innego vpn pochodzi.
W sumie z tora to tylko przestępcy korzystają.

johnny_Be_good napisał(a):

Czy mogę zamiast SSL zastosować szyfrowanie inne (własne) powiązane serwer - strona?

Żadne szyfrowanie w którym nadawca i odbiorca są znani nie jest bezpieczne, wręcz przeciwnie - jest dużo mniej bezpieczne niż jego brak.

Dlatego też w takich wypadkach na krytycznych kanałach (np. komunikacja z agentami wywiadu) stosuje się książki kodowe. Szyfr który wygląda jak zwykła dyskusja o dupie maryni gwarantuje najwyższe bezpieczeństwo.

O to mi chodziło żuczki

Czy dobrze widzę, że dodajesz jakiś zobfuscowany ciąg znaków, który zawiera jakieś dane? Czy ten ciąg jest albo generowany przez js, albo przez niego dekodowany...?

Możesz dodać własne szyfrowanie ponad ssl (w warstwie aplikacji). Istnieje sporo sprawdzonych, mocnych algorytmów szyfrowania, zarówno symetrycznych, jak i asymetrycznych, nad którymi pracowały najtęższe mózgi świata matematyki - wystarczy je użyć z odpowiednio długimi kluczami (np. RSA 4096).

ŁF napisał(a):

Czy dobrze widzę, że dodajesz jakiś zobfuscowany ciąg znaków, który zawiera jakieś dane? Czy ten ciąg jest albo generowany przez js, albo przez niego dekodowany...?

Możesz dodać własne szyfrowanie ponad ssl (w warstwie aplikacji). Istnieje sporo sprawdzonych, mocnych algorytmów szyfrowania, zarówno symetrycznych, jak i asymetrycznych, nad którymi pracowały najtęższe mózgi świata matematyki - wystarczy je użyć z odpowiednio długimi kluczami (np. RSA 4096).

Ja to tak robię

Johny, zaskakujesz mnie. Film "jak prawidłowo przechowywać dane na serwerze" pokazuje jakiś klon szyfru Cezara. Technologia poszła od tego czasu trochę do przodu...
Wydajność CRUD na danych - żadna.
Zgubiłeś typy danych i nazwy kolumn.
Podatność na złamanie szyfru - bardzo wysoka, wystarczy znajomość danych przed i po (https://www.crypto-it.net/pl/ataki/index.html). To raczej takie security by obscurity niż szyfrowanie. Porównaj to z RSA użytym w SSL, niby algorytm znany, a da się złamać tylko przez brute force, które przy odpowiednio długim kluczu (4096b+) trwa tysiące lat (albo - jeśli Chińczycy nie kłamią - wymaga użycia komputera kwantowego).
Nie używasz hasła/klucza, zatem złamanie algorytmu raz powoduje trywialnie łatwe odkodowanie każdych zaszyfrowanych nim danych.
Co, jeśli masz jeden rekord albo ilość inną, "niewygodną" dla Twojego algorytmu?
JS użyty w drugim filmie woła o pomstę do nieba. Zmienna o wdzięcznej nazwie "tmp" w obiekcie window to tylko czubek góry lodowej. Dekodując dane po stronie klienta w zasadzie kompromitujesz (w sensie angielskiego słowa compromise) swój algorytm.

Możnaby użyć np. JSONa i zaszyfrować go profesjonalnym algorytmem (np. 3DES), ale po co? Skoro trzymasz dane na serwerze, to wystarczy zabezpieczyć ich źródło przed dostępem z zewnątrz. Wystarczy baza danych dostępna tylko w sieci lokalnej + API + mocne hasło do VPN/konsoli do zarządzania. Dane będą bezpieczne, a dostęp do nich szybki.

Co do bezpiecznego przesyłania danych, to za wyjątkiem ataku man-in-the-middle (w praktyce trudnego do przeprowadzenia) SSL gwarantuje to (asymetryczny algorytm).

Podsumowując - wyważasz szeroko otwarte drzwi. Przy okazji ćwiczysz mięśnie, ale robiąc takie filmy jak wyżej pokazujesz niedoświadczonym programistom złe praktyki.

ŁF napisał(a):

Podsumowując - wyważasz szeroko otwarte drzwi. Przy okazji ćwiczysz mięśnie, ale robiąc takie filmy jak wyżej pokazujesz niedoświadczonym programistom złe praktyki.

Chyba kpisz, nie rozumiesz w jak ogromnym obszarze operujesz a zaraz za nim jest czas.

Panie, ja bym swojego RBAC nie pisał, a Ty tu o własnym szyfrowaniu i wyparciu TLS...

A możesz odnieść się do konkretnej wypowiedzi? Nikt tu nie kpi, masz czarno na białym wytknięte wady Twojego rozwiązania, zamiast się do nich odnieść, to obrażasz interlokutora. Świadczy to o Twoim braku zrozumienia problemu i o towarzyszących Ci błędach poznawczych. Spoko, to normalne gdy uważasz, że odkryłeś coś wielkiego, a tu ktoś pokazuje Ci, że jest dokładnie odwrotnie, ale dyskusja na poziomie wymaga przytaczania argumentów, a nie obrażania się czy obrażania rozmówcy.

Rozumiem, że time to business is money i time is money, ale Twoje rozwiązanie to tylko strata takiego czasu. Nikt nie zapłaci Ci za taki algorytm, acz rozumiem, że jego stworzenie nauczyło Cię nowych rzeczy.

ŁF napisał(a):

A możesz odnieść się do konkretnej wypowiedzi? Nikt tu nie kpi, masz czarno na białym wytknięte wady Twojego rozwiązania, zamiast się do nich odnieść, to obrażasz interlokutora. Świadczy to o Twoim braku zrozumienia problemu i o towarzyszących Ci błędach poznawczych. Spoko, to normalne gdy uważasz, że odkryłeś coś wielkiego, a tu ktoś pokazuje Ci, że jest dokładnie odwrotnie, ale dyskusja na poziomie wymaga przytaczania argumentów, a nie obrażania się czy obrażania rozmówcy.

Rozumiem, że time to business is money i time is money, ale Twoje rozwiązanie to tylko strata takiego czasu. Nikt nie zapłaci Ci za taki algorytm, acz rozumiem, że jego stworzenie nauczyło Cię nowych rzeczy.

Podesłać Ci zaszyfrowany tą metodą 5 MB plik żebyś go odczytał?

Nie jestem specjalistą od kryptografii, ale algorytm do dekodowania sam udostępniłeś...
Zresztą, co to miałoby udowodnić? Że umiesz pisać czytelny kod, czy że operacje CRUD na takich danych będą wydajne, a może że Twój algorytm (który upubliczniłeś i do którego udostępniłeś dekoder) jest trudny do złamania?

Johny, próba dalszej dyskusji z Tobą nie ma sensu. Nie odnosisz się do argumentów, ignorujesz pytania, za to zarzucasz innym niewiedzę. A miałem Cię za człowieka na poziomie.

PS na filmie pokazujesz, że wartość "34" kodujesz do "234", ale wartość "12-06-2021" o długości 10 znaków kodujesz do "1012-06-2021". Długość zapisujesz raz na jednym bajcie, raz na dwóch, co uniemożliwia prawidłowe zdekodowanie dowolnych danych, bo

• albo "234" dekodujesz do "4" + 22 znaki śmieci, a kolejne pola się nie zdekodują lub zdekodują nieprawidłowo,
• albo "1012-06-2021" dekodujesz do "0" (jeden znak po pierwszym "1"), potem kolejne pole "2" (jeden znak po drugim "1"), a potem całość.wybucha, bo długość opisuje "-".
  Nie widzisz tu błędu? A jak zapiszesz jedno pole z 1000 jedynek? "411111(...)111"? Takie pole da się zdekodować i prawidłowo, i nieprawidłowo.

ŁF napisał(a):

Nie jestem specjalistą od kryptografii, ale algorytm do dekodowania sam udostępniłeś...
Zresztą, co to miałoby udowodnić? Że umiesz pisać czytelny kod, czy że operacje CRUD na takich danych będą wydajne, a może że Twój algorytm (który upubliczniłeś i do którego udostępniłeś dekoder) jest trudny do złamania?

Johny, próba dalszej dyskusji z Tobą nie ma sensu. Nie odnosisz się do argumentów, ignorujesz pytania, za to zarzucasz innym niewiedzę. A miałem Cię za człowieka na poziomie.

PS na filmie pokazujesz, że wartość "34" kodujesz do "234", ale wartość "12-06-2021" o długości 10 znaków kodujesz do "1012-06-2021". Długość zapisujesz raz na jednym bajcie, raz na dwóch, co uniemożliwia prawidłowe zdekodowanie dowolnych danych, bo

• albo "234" dekodujesz do "4" + 22 znaki śmieci, a kolejne pola się nie zdekodują lub zdekodują nieprawidłowo,
• albo "1012-06-2021" dekodujesz do "0" (jeden znak po pierwszym "1"), potem kolejne pole "2" (jeden znak po drugim "1"), a potem całość.wybucha, bo długość opisuje "-".
  Nie widzisz tu błędu? A jak zapiszesz jedno pole z 1000 jedynek? "311111(...)111"? Takie pole da się zdekodować i prawidłowo, i nieprawidłowo.

o którym piszesz? Zamiana bitów czy ten drugi z tworzeniem tablic wielowymiarowych?