Strona 2 z 2 PierwszyPierwszy 12
Pokaż wyniki 11 do 18 z 18

Temat: bezpieczna wymiana danych

  1. #11
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    SSL/TLS zalatwia wszystko... na prawde nie wiem po co sie tak meczysz.
    Po to wymyslono SSL/TLS aby byla mozliwosc bezpiecznej wymiany kluczy w sytuacji gdy atakujacy moze slyszec transmisje. Dzieki temu jak dziala SSL/TLS (uzycie PKI) atakujacy moze przechwycic negocjacje klucza a i tak nie wie jaki klucz ustalono... dalej jeci crypto symetryczne dla danych ale bez klucza to wiadomo co dalej.

    Poza tym wynegocojowny raz klucz symetryczny mozna w cache wsadzic (i tak sie czesto robi) aby pominac kolejna negocjacje z uzyciem crypto asymetrycznego. Najczesciej spotykam serwery ktore pozwalaja trzymac klucz symetryczny przez 5 minut od ostatniego uzycia i wymieniaja go chyba co 1h w najgorszym razie.

    polaczenie 1 - asymetryczne crypto, generujemy klucz symetryczny, dane leca w crypto symetrycznym
    polaczebie 2 minute poziej - przedstawiamy klucz z cache'a i jesli serwer przyjmie to lecimy od razu dane, bez asymetrycznej negocjacji

    na prawde wydaje mi sie ze niepotrzebnie marnujesz czas

    HINT: Crypto jest jak wino - im starsze tym lepsze (bo sprawdzone przez wiele lat i wiemy czego oczekiwac). Jesli ktos pisze wlasne crypto nie bedac zawodowcem w tej dziedzinie, to dla mnie to nie jest powazna osoba - robi 'security by obscurity' i ma falszywe poczucie bezpieczenstwa (zgubna sprawa), kod jest nieprzenosny (koszmar do utrzymania i aktualizacj) i skomplikowany (niepotrzebnie).

    Tak - ja tez popelnialem takie bledy ale wyroslem z tego i im szybciej ludzie zrozumieja ze wlasne algorytmy szyfrowania to zla droga, tym lepiej dla wszystkich.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  2. #12

    Domyślnie

    Dla mnie koszmar to apache+openssl+php na linuxie. Kiedys probowalem postawic serwer na tym (bo nauka 'jak to dziala' byla by zalosna zwazywszy na skomplikowanie plikow/calych katalogow plikow) i nie dalem rady. Skozystalem z gotowca na windows.

    SSL uzywa jakis certyfikatow, ja nie chce sie w to bawic, nie rozumiem tego. Co nie znaczy ze nie chce tego w koncu zrozumiec!
    Pozatym komunikacja ssl zawiera tony opcji, jest skomplikowana, wg mnie bez sensu!

    RSA rozumiem, wiem jak napisac kod, jak generowac klucze i ich uzywac. Teraz musze sie nauczyc jeszcze jakiegos symetryka, mysle ze blowfish albo 3des?
    Ostatnio edytowane przez linux_aa : 12-27-2010 - 14:19

  3. #13
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Ok - rozumiem o co chodzi... i chyba moge nieco pomoc z ta czescia SSL

    CO do Apache+SSL to sprawa jest standardowa - dziala swietnie prosto z pudelka i bez zbednych kombinacji. Jesli masz na prawde wieksze potrzeby (jak cache kluczy albo akceleracja SSL/TLS) to musisz doczytac. Zgodze sie ze SSL/TLS jest skomplikowany i ma w cholere opcji ale ma to swoje uzasadnienie - proste rzeczy robi sie prosto, skomplikowane sa wykonalne.

    PHP nic nie wie o SSL w sumie bo i po co - to jezyk do aplikacji web generalnie. Jesli wykonujesz zapytania do stron SSL ze swojego kodu to calosc dzieje sie praktycznie przezroczyscie jesli nie potrzebujesz np autoryzowac klienta (swojego skryptu) za pomoca kluczy SSL... i tutaj dochodzimy do ogromnej zalety SSL/TLS - autentykacja i autoryzacja uzytkownikow :-)

    Masz swoj serwis, dosc duzy... tworzysz API (REST/SOAP/cokolwiek) i udostepniasz tylko zaufanym osobom... API dziala po SSL z prywatnym kluczem ktory sobie sam wygenerowales. Normalnie apache nie sprawdza kto sie laczy ale wymusza polacenie po SSL aby dane byly szyfrowane w trakcie przesylu. Jedna czy dwie linie wiecej w konfigu (doslownie kopiuj-wklej z dokumentacji) i od tej porty Apache wymaga aby klient przestawil swoj klucz SSL jesli chce sie polaczyc... i teraz zaczyna sie zabawa - klucz klienta musi byc wystawiony przez to samo CA co klucz serwera (a wiec Ty musisz dac klientowi klucz SSL ktory pozwoli mu sie podlaczyc do serwera) - masz pelna kontrole nad tym kto uzywa Twojego API i Twojego serwisu.

    Piszac wlasne rozwiazanie powiedz mi prosze jak chcesz np zablokowac klientowi dostep do tego teoretycznego API? W przypadku SSL/TLS wystarczy ze odwolasz certyfikat (CRL - Certificate Revocation List) i serwer WWW wie gdzie ten CRL sie znajduje (URL najczesciej jest zapisany w samym certyfikacjie wystawionym przez CA) i klient juz nie moze sie podlaczyc do serwera - elegancko zabrales mu dostep, pozostawiajac dostep dla wszystkich pozostalych klientow Doslownie tak to sie robi w duzych systemach, ktore musza regularnie wymieniac dane gwarantujac ze wiesz ktos sie laczy i ze ta 'osoba' jest tym za kogo sie podaje.

    Przemysl to jeszcze raz - moim zdaniem oplaci Ci sie posiedziec nieco i nauczyc o SSL/TLS i jak to dziala. Wszyscy tego uzywaja wiec nie jest to takie zle
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  4. #14

    Domyślnie

    Jesli chcialbym miec kontrole kto uzywa mojego api, to bym stworzyl podwojna autoryzacje.
    Klient sprawdza serwer, i serwer sprawdza klienta. Kazdy klient mialby oddzielny klucz.
    Jak chcialbym odwolac klientowi dostep, zniszczylbym jego klucz i niebylby on wstanie przejsc autoryzacji.

    *autoryzacja polega na tym, ze 1 strona wysyla niezazsyfrowane dane, a druga je szyfruje.

    Co do ssl, zalozmy taki hipotetyczny scenariusz, ze ktos przez pare lat bedzie lapal pakiety wymieniane miedzy serwerem a klientami. Zbierze terabajty danych zaszyfrowanych szyfrem symetrycznym. Zmieni sie admin tego serwera, a ten nowy postanowi wprowadzic pare zmian, np zainstaluje dziurawe ftp badz zapomni zmienic defaultowego hasla. Hacker ktory zapal pakiety wbija sie na serwer, kradnie klucz prywatny/deszyfrujacy (ten klucz ktory potwierdza tozsamosc serwera) i deszyfruje swoje dane.

    Moj sposob by to wykluczym, byl by on w stanie tylko poznac klucze publiczne/szyfrujace i bloki kontrolne wysylane od klienta do serwera.



    Kolejna sprawa, co jesli ktos zlapie pakiety, i bedzie je przestawial przed transmisja? Albo wogule nie wysle niektorych danych. Albo najzwyczajniej modyfikowal? Albo nawet wymusi uzycie starego klucza, choc co do tego nie jestem pewien.


    Piszac wlasna implementacje wiem co musze zrobic by spelnic zalozenia danej sesji. Kozystajac z SSL nic nie wiem.


    Swoj sposob ciagle modyfikuje z zaleznosci od tego co przyjdzie mi do glowy, wiec jeszcze chyba nie mam finalnej wersji:
    (server ma tajny klucz sluzacy do deszyfrowania danych, jest to jedyny klucz tajny na poczatku, publiczny jest publicznie dostepny)
    - klient sie laczy z serwerem
    - klient tworzy blok danych, nazwijmy go D
    - klient generuje pare kluczy, i szyfruje klucze publicznym kluczem serwera. D moga zostac plaintextem.
    - klient wysyla szyfrogram
    - serwer deszyfruje klucz od klienta, i szyfruje nim D. W ten sposob udowadnia, ze faktycznie dostal go - osoba po srodku nie zna tego klucza, a jak go zmieni to D sie nie zgodzi.
    - serwer doklada swoj wygenerowany klucz (zaszyfrowany razem z D, kluczem wygenerowanym przez klienta), i wysyla paczke to klienta
    - klient w tym momencie ufa serwerowi (do po rozszyfrowaniy D sie zgadza), wiec szyfruje D nowym kluczem ktory dostal i wysyla sam D do serwera.
    - serwer ufa klientowi, bo D sie zgadza
    - opcjonalnie 1 strona wysyla 2giej klucz symetryczny, by juz nie uzywac 2 asymetrycznych
    - obie strony wtorza sume kontrolna D, i umieszczaja ja w kazdym pakiecie. Jak pakiet nie zawiera poprawnej sumy - pochodzi od kogos z przeszlosci/rownoleglej sesji.
    - obie strony rowniez mieszczaja 64bitowy counter, i kazdy pakiet inkrementuje go, jak bedzie sie mial przekrecic, trzeba zmienic klucz.
    - obie strony rozniez tworza podpis cyfrowy kazdego pakietu, na wypadek jakby ktos w nim grzebal.
    - komunikacja przebiega z uzyciem klucza symetrycznego, dodanej checksumy D (anti-replay), podpisu pakietu (validation), countera (anti-replay/drop). Jak by sie counter mial przekrecic, to klucz symetryczny jest odnawiany, wiec podpis sie zmienia i pakiety ze starej sesji beda nicniewarte.

    Czy jest sens robic to w ten sposob? Czy ssl to potrafi? Czy popelnilem jakies bledy w rozumowaniu?

  5. #15
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Sorry, nawet nie czytam calej logiki jaka proponujesz bo juz na starcie nie ma to sensu :-/

    Cytat Napisał linux_aa
    Jesli chcialbym miec kontrole kto uzywa mojego api, to bym stworzyl podwojna autoryzacje.
    SSL to zalatwia poprzez parametr CN (z tego co pamietam) w certyfikacjie...
    Cytat Napisał linux_aa
    Klient sprawdza serwer, i serwer sprawdza klienta. Kazdy klient mialby oddzielny klucz.
    SSL to zalatwia - serwer moze sprawdzac klucz klienta - to to co napisalem, chyba 2 linijki w konfigu apacza

    Cytat Napisał linux_aa
    Co do ssl, zalozmy taki hipotetyczny scenariusz, ze ktos przez pare lat bedzie lapal pakiety wymieniane miedzy serwerem a klientami. Zbierze terabajty danych zaszyfrowanych szyfrem symetrycznym.
    Zywotnosc klucza symetrycznego jest ograniczone... jesli ktos nawet zbierze TB danych to beda one zaszyfrowane tysiacami roznych kluczy symetrycznych i atakujacy nie bedzie w stanie powiedziec ktore dane ktory klucz...

    Cytat Napisał linux_aa
    Zmieni sie admin tego serwera, a ten nowy postanowi wprowadzic pare zmian, np zainstaluje dziurawe ftp badz zapomni zmienic defaultowego hasla. Hacker ktory zapal pakiety wbija sie na serwer, kradnie klucz prywatny/deszyfrujacy (ten klucz ktory potwierdza tozsamosc serwera) i deszyfruje swoje dane.
    To nie ma znaczenia bo klucze publiczny/prywatny sa uzywane tylko do negocjacji klucza symetrycznego ktory nie jest zapisany z danymi - jego zywotnosc jest za krotka zwyczajnie.
    Poznanie klucza prywatnego w SSL/TLS pozwoliloby w przypadku przechwycenia negocjacji zdeszyfrowanie jej i poznanie klucza symetrycznego - to dotyczy kazdego mechanizmu uzywajacego klucza prywatnego i publicznego - nie tylko SSL/TLS.

    To co proponujesz nie przyniesie Ci zadnej korzysci poza tym ze masz wlasna implementacje ktora:
    - nie jest zgodna z niczym innym na swiecie
    - jest zle zoptymalizowana (kiepska wydajnosc, ogromne obciazenie CPU na kazdej operacji)
    - nie posiada wiekszosci funkcjinalnosci ktora jest oferowana przez juz istniejace i dokladnie sprawdzone technologie (standardowe metody szyrowania - symetryczne i asymetryczne)

    Podstawowa zasada - pisanie wlasnego crypto to rownia pochyla - mozna leciec tylko w dol... dlatego ludzie majacy glowe na karku sie za to nie biora. Popytaj po sieci jesli mi nie wierzysz - kazdy powie ze tworzenie wlasnego crypto to "zly pomysl".

    Raczej pomysl jak wykorzystac juz istniejace PKI do spelnienia swoich zalozen projektowych. Oszczedzisz mase czasu i unikniesz wielu problemow.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  6. #16
    Zarejestrowany
    Jul 2008
    Skąd
    /dev/random
    Postów
    556

    Domyślnie

    Cytat Napisał linux_aa Zobacz post
    RSA rozumiem, wiem jak napisac kod, jak generowac klucze i ich uzywac. Teraz musze sie nauczyc jeszcze jakiegos symetryka, mysle ze blowfish albo 3des?

    Nie obraz sie ale piszesz ze konfiguracja apache + php to koszmar. Jak dla mnie jest to przyjemne i szybkie zajecie, a powiem ci ze kupe lat mimo uzywania Slackware sam kompilowalem to + inne pakiety z zrodel aby dopasowac pod siebie. Teraz gentoo w wielu sprawach mnie wyrecza Dlaczego takie podejscie bo wlasnie nie lubie gotowych pakietow ktore dosc czesto robione sa aby byly uniwersalne.

    Teraz wspominasz o RSA i mowisz o jego prostocie , a masz tutaj problem bigintow o ktorym wspomnialem. Myslisz o bezpieczenstwie, a wspominasz tak samo o 3DES... Inna sprawa ze nie ma sie co uczyc tych algorytmow odnosnie blowfisha i twofisha wszystko masz opisane na stronie Schneier on Security lacznie z przykladowa implementacja w roznych jezykach.

    Tak jak wspomnial TQM naucz sie stosowac dobrze i w pelni gotowych rozwiazan, bo wymyslasz sam kolo i to w dodatku bardziej przypominajace wielokat

    Naprawde aby samodzielnie implementowac takie rozwiazania trzeba miec spora wiedze i duzo praktyki. Do tego nigdy nie masz pojecia na ile to jest pewne, a zdziwic mozna sie bardzo szybko jak ktos to zlamie przez bledy w implementacji.

    Sam implementowalem takie roziwazania ale byl to najczesciej dodatkowe zabezpieczenie lub brak mozliwosci uzycia gotowego rozwiazania (np. soft na mikrokontrolery jednoukladowe). Do tego do tej pory mam watpliwosci co do pewnosci tych rozwiazan, ale tutaj zakladam ze jest to lepsze niz plain, zreszta w kilu implementacjach po czasie sam znalazlem bledy i niedociagniecia po glebszej analizie. Co najgorsze w chwili projektu wydawalo nam sie to super bezpieczne, a nowe spojrzenie na problem po czais pokazuje ile sie zrobilo baboli i czlowiek sam z siebie sie smieje...

    Naprawde kryptografia to cholernie trudny temat i nie wiele osob to tak naprawde potrafi ogarnac, jesli myslisz ze to ogarniasz to jestes w wielkim bledzie i za malo wiesz. Proponuje czytac i czytac w tym temacie i zawsze pozostanie niedosyt.

    Tak jak wspomnialem skupiasz sie na nie tych problemach co trzeba jesli chodzi o bezpieczenstwo


    Co do ssl, zalozmy taki hipotetyczny scenariusz, ze ktos przez pare lat bedzie lapal pakiety wymieniane miedzy serwerem a klientami. Zbierze terabajty danych
    Widzisz tutaj dochodzimi do pewnej kwestji bezpieczenstwo to nie tylko algorytmy, ale najczesciej najslabsze ogniwo czyli czlowiek. Dlatego w bezpiecznych systemach sam uzyty algorytm kryptograficzny to jedynie kropla w morzu. Inna sprawa to na serwerach podbietych do sieci publicznej na ile jest to mozliwe nie trzyma sie istotnych danych.

    Dlatego mowie ze pomijasz wiele bardzo istotnych kwestji jesli chodzi o bezpieczenstwo danych... Co z tego ze masz super bezpieczna wymiane danych, jak dobiora ci sie do nich inna droga i nikt nawet nie skupi sie nad lamaniu tego co leci szyfrowane.

    Potem u kogos na kompie pojawi sie kod przypominajacy cos takiego (z zycia wziety przyklad ktory lamalem):

    Kod:
        unsigned int ecx = (unsigned int)PA[0] ^ *Word1;
        unsigned int eax = (unsigned int)SB[0x100 + ((ecx & 0x00FF0000) >> 16)];
        eax += (unsigned int)SB[(ecx & 0xFF000000) >> 24];
        eax ^= (unsigned int)SB[0x200 + ((ecx & 0x0000FF00) >> 8)];
        eax += (unsigned int)SB[0x300 + (ecx & 0x000000FF)];
        eax ^= (unsigned int)PA[1];
        eax ^= *Word2;
    
        unsigned int ebp = eax;
        unsigned int ebx = (unsigned int)SB[0x100 + ((ebp & 0x00FF0000) >> 16)];
        ebx += (unsigned int)SB[(ebp & 0xFF000000) >> 24];
        ebx ^= (unsigned int)SB[0x200 + ((ebp & 0x0000FF00) >> 8)];
        ebx += (unsigned int)SB[0x300 + (ebp & 0x000000FF)];
        ebx ^= (unsigned int)PA[2];
    i na tym konczy sie wlasne wymyslanie bezpieczenstwa... tak a propo to u gory to "modyfikowany" przez "specjalistow" blowfish i po co to im bylo... jak implementacja calego systemu byla do dupy. I powiem ze to jest cos co dotyczy duzej i znanej w calej polsce firmy.
    Ostatnio edytowane przez tom : 12-27-2010 - 22:28
    --
    ToM's Super Fix IT "No Fucking Problem"

  7. #17

    Domyślnie

    tom, a moglbys mi podac jakis przyklad z tych twoich zlych implementacji? Jak tworzyles system, byles pewien ze byl bezbledny, a pozniej znalazles w nim dziury. Moglbys mi podac przyklad jakiego typu to byly dziury?

    I o co chodzi z tymi bigintami o ktorych 2gi raz wspominasz? O to ze nie bede wstanie sprawdzic ze liczba jest pierwsza?


    jak nie chce modyfikowac zadnych algorytmow! Nie znam sie na tym dobrze, i tak mam problemy z ogarnieciem szyfru, jedynie zmienic chce sposob wymiany danych! blowfish/rsa pozostana w swojej oryginalnej implementacji!


    Aha, wracajac do SSL w koncu znalazlem dobre zrodlo o certyfikatach i chyba je rozumiem. Tylko jak pozniej jest uzgadniany klucz symetryczny? Klient ma tylko public serwera z certyfikatu, i w jaki sposob strony wymieniaja klucz? Moglbym sobie 'wymyslec' cos i zrobic pewne zalozenia ale chce wiedziec jak wyglada rzeczywistosc... Czy jest to DH + jakis token/pozniejsze sprawdzanie?


    I jeszcze 1 sprawa, jak wyglada sprawa podpisywania plikow PE pod windowsem (drivery i exeki, o ile jest jakas roznica)? Szukalem i nic! Jedynie to znalazlem sdk signtool/makecert, to dziala, ale jak? Jak uzyje tego u siebie, musze instalowac certyfikat zeby system zaakceptowal plik. A jakos inne programy dzialaja w magiczny sposob i nie wymagaja instalacji certow.
    Jak to jest zrobione? Zalozmy ze chcyalbym podpisac swoj soft, musze kupic cert od MS, gdzie znajde jakis opis tych certow?
    I chyba po kupieniu certa nie dostaje klucza szyfrujacego/prywatnego, bo moglbym go rozdac i kazdy by podpisywal jak chce.
    No chyba ze MS tworzy mi certyfikat, dodaje w nim klucz publiczny tylko dla mojego kodu, ja dostaje klucz prywatky(szyfrujacy), dolaczam cert do pliku PE, podpisuje plik kluczem prywanym i viola. Ale to tylko mojew domysly, ktore chce skonfrontowac z rzeczywostoscia.
    Ostatnio edytowane przez linux_aa : 12-28-2010 - 12:12

  8. #18
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Co do negocjacji - poczytaj jak dziala TLS - tam wszystko znajdziesz.

    Podpisywanie aplikacji odbywa sie osobnym zestawem kluczy - podobnie jak SSL - dostajesz certyfikat wydany przez CA (centrum autoryzacji - chyba tak to sie tlumaczy na Polski)... klucz tego CA jest w windowsach wpisany i wszystko co podpisano kluczem podpisanym przez takie CA bedzie OK, to co podpiszesz innym kluczem bedzie olewane i wywali blad.

    Tak to dziala w ogromnym uproszczeniu - szukaj 'code signing certificates'
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

Strona 2 z 2 PierwszyPierwszy 12

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj