Strona 1 z 2 12 OstatniOstatni
Pokaż wyniki 1 do 10 z 11

Temat: Ssl

  1. #1

    Domyślnie Ssl

    jak dokladnie dziala SSL?
    dlaczego to jest bezpieczne?

    klient wysyla serverovi wiadomosc ABC
    server odsyja ja zakodowana RSA kluczem
    klient zna klucz, skad?


    o co chodzi?

    skad server/klient znaja swoje klucze, bez ich transmisji?
    co to sa certyfikaty?

    prosze odpowiedzcie na te pytania bo nic waznego nie moge znalezc.

  2. #2

    Domyślnie

    jak dokladnie dziala SSL?
    działa to na zasadzie szyfrów symetrycznych( najczesciej klucze prywatne ) lub szyfrow asymetrycznych( najczesciej klucze publiczne ).

    dlaczego bezpieczne
    bezpieczne sa dlatego , ze maja dobre metody kryptografii:

    szyfry symetryczne te pierwsze uzywaja szyfrowania opartego na przesuwania bitow( najczesciej DES ), dziala to w nastepujacy sposob:
    strony uzgadniaja dany szyfr ktory bedzie uzywany do kodowania danych i nastepnie wymiany danych.

    druga metoda szyfrowania jest nieco bardziej skomplikowana , zaklada ze transmisja danych uzywa 2 kluczy( prywatny( znany tylko jednej stronie ) oraz publiczny( ogolnie dostepny) ). dziala to w ten sposob:
    kazda ze stron generuje pare kluczy , nastepnie publikuje swoj klucz w sieci i nastepnie przy wymianie danych, jezeli A chce wyslac dane do B to dane beda szyfrowane kluczem B jesli bedzie odwrotnie to wiadomo, jezeli B chce miec pewnosc ze wymienia informacje faktycznie z A to moze prosic o zaszyfrowanie wymyslonego tekstu jego kluczem prywatnym. Jezeli A prawidlowo zaszyfruje tekst to B musi odpowiedziec tym samym, tyle ze musi zaszyfrowac to kluczem publicznym, jesli sie wszystko zgadza to wszystko sie powiodlo.
    Jezeli B po odebraniu wiadomosci od A chce zabezpiczyc sie przed sytuacja , w ktorej A zaprzeczy, ze wyslal wiadomosc, moze poprosic A o zaszyfrowanie jej dodatkowo swoim kluczem prywatnym. B bedzie w stanie to odszyfrowac uzywajac klucza publicznego i prywatnego i A nie bedzie mogl zaprzeczyc ze wyslal wiadomosc.

    to oczywiscie nie wszystkie metody tego protokolu, lecz wystarcza raczej na przekonanie cie do jej bezpieczenstwa.

  3. #3

    Domyślnie

    aha, no teraz rozumiem.

    A wysyla klucz publiczny B, B wykozystuje ten klucz do transmisji klucza symetrycznego wykozystywanego w transmisji danych.
    A odbiera klucz symetryczny zaszyfrowany asymetrycznie, odszyfrowuje go i zaczyna sie wlasciwa wymiana danych.

    w ten sposob B wygenerowalo klucz publiczny, i wyslalo go do A tak ze tylko A moze go odszyfrowac. Obie strony maja ten klucz, i nikt wiecej.

    any flaws?

  4. #4

    Domyślnie

    tak, nie moze tego nikt wiecej miec poniewaz maja bardzo dobra metode identyfikacji siebie wzajemnie.

  5. #5

    Domyślnie

    hmm
    zbyt skomplikowane



    zrobic jak powiedzialem:

    klient sie laczy z serverem
    klient generuje klucz publiczny i klucz prywatny
    server generuje klucz symetryczny
    klient wysyla klucz publiczny
    serwer szyfruje kluczem publicznym klucz symetryczny
    klient rozszyfrowuje klucz symetryczny
    obie strony znaja klucz symetryczny, wymiana danych z uzyciem klucza symetrycznego

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

    Domyślnie

    Zanim zaczniesz tworzyc kolejne teorie wez kur** przeczytaj dokumentacje!
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  7. #7
    Zarejestrowany
    Dec 2009
    Skąd
    ke?
    Postów
    162

    Domyślnie

    Ogólny schemat działania metod szyfrowania z kluczem publicznym jest następujący:

    * Każda ze stron generuje parę kluczy (publiczny+prywatny)
    * Każda ze stron publikuje swój klucz publiczny w sieci (jest on dostępny dla wszystkich)
    * Jeżeli A chce przesłać wiadomość do B to szyfruje ją kluczem publicznym B. Z własności algorytmu wynika, że tylko używając klucza prywatnego B można ją odtworzyć
    (to jest typowy schemat wymiany danych).
    * Jeżeli B chce mieć pewność, że wymienia informacje rzeczywiście z A, to może np. poprosić A o zaszyfrowanie pewnego tekstu jego kluczem prywatnym. Jeżeli B będzie w stanie odtworzyć tekst używając klucza publicznego A to znaczy, że rozmawia rzeczywiście z właściwym partnerem.
    (to jest typowy schemat autentyfikacji partnera)
    * Jeżeli B po odebraniu wiadomości od A chce zabezpieczyć się przed sytuacją, w której A zaprzeczy, że wysłał wiadomość, może poprosić A o zaszyfrowanie jej dodatkowo swoim kluczem prywatnym (a następnie kluczem publicznym B). B będzie w stanie ją odszyfrować (najpierw używając swojego klucza prywatnego, a następnie publicznego klucza A) i A nie będzie mógł zaprzeczyć, że wiadomość wysłał - wiadomość która dała się odszyfrować kluczem publicznym A musiała być zaszyfrowana jego kluczem prywatnym.
    (to jest typowy schemat podpisu cyfrowego)

    Źródło: http://muflon.photosite.pl/doc/progzesp/ssl.html

  8. #8
    Zarejestrowany
    Jul 2007
    Skąd
    C:\Perl\bin
    Postów
    1,578

    Domyślnie

    g3t_d0wn powinien podawac zrodlo zamiast kasowac polskie znaki i wystawiac jako swoje.
    War, war never changes.

  9. #9

    Domyślnie

    hehe , nie kasuje polskich znakow, nie czepiaj sie , bo z tego zrodla wlasnie uczylem sie o ssl gdyz musialem to znac do szkoly . Gdy pisze to ze swojej glowy to nie musze podawac zrodla .

  10. #10

    Domyślnie

    ok ja mam pytanie, o ile mozna przeslac informacje w sposob tajny od zera (bnez inego kanalu), to jak stwierdzic ze host jest faktycznie tym za kogo sie podaje, a nie haxorem wpietym w siec?

Strona 1 z 2 12 OstatniOstatni

Podobne wątki

  1. SSL - możliwe podsłuchanie?
    By zimi in forum Hacking
    Odpowiedzi: 5
    Autor: 10-15-2008, 22:25
  2. Ssl vpn ssh
    By drwal in forum Hacking
    Odpowiedzi: 27
    Autor: 09-24-2008, 09:27
  3. SSL + Vista + Modem = Problem
    By hes in forum Security
    Odpowiedzi: 1
    Autor: 07-31-2007, 09:44
  4. ssl w c++
    By 31337 in forum C/C++
    Odpowiedzi: 1
    Autor: 06-18-2007, 10:52
  5. SSL, PHP i socket.
    By 31337 in forum PHP/CGI/ASP/JSP/J2EE
    Odpowiedzi: 4
    Autor: 05-18-2007, 19:50

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