Odczytanie hasła z certyfikatu

[linux_aa]

niech ktos wbije do serwera WWW i wykradnie Twoj cert SSL

Nie musze wbijac, serwer sam wysyla certyfikat jako czesc handshakea. Klucz prywatny to inna sprawa. Jestem pewien, czytalem o tym milion razy, analizowalem dump wiresharka, i zostale mi do pelni wiedzy tylko wlasna implementacja ktora sobie jednak narazie odpuszcze bo x509 prosty nie jest.

A nawet jak wbuje sie na serwer, i bede chcial klucz prywatny a bedzie on zabezpieczony w jakis sposob, to przeciez serwer uzywa klucza prywatnego do deszyfrowania danych, wiec jest dostepny w pamieci serwera. Moze bede mial prawa do procesu httpd moze i nie. Ale jaki ma sens szyfrowanie klucza prywatnego, skoro jesli bede mial prawa do pliku, to rozniez i do procesu i jego pamieci..

i powiedz mi jak teraz ktokolwiek moze sprawdzic czy wszedl na prawdziwa strone czy nie?

Nawet majac klucz prywatny, nie moge przeciez zmienic DN w certyfikacie. Musualbym rowniez hacknac jego dns albo permanentnie sie zainstalowac na jego serwerze.

To Ty drążyłeś temat falg ACK w TCP?

Kazdy pakiet musi byc powiazany z obiema stronami, dlatego ack jest wymagany jesli ida dane. Po to zeby bylo wiadomo co druga strona dostala i kiedy w stosunku do pakietu ktory wysyla. No i bez ack window size tak nie koniecznie bylo by fajne, mozna by albo zignorowac to pole, albo zignorowac tylko wtedy jak nie bedzie wieksze niz ostatnie.

[TQM]

Widzisz... zakladasz ze serwer a raczej aplikacja ktora on hostuje dziala jako ten sam user co moze odczytac certyfikat w hostingach kupionych gdzies tam to bedzie czesty przypadek ale robiac solidna konfiguracje wiekszosc ludzi z ktorymi wspolpracuje robi podzial uprawnien. Skrypty PHP na przyklad odpalane sa jako user ktory jest ich wlascicielem, certyfikat nalezy do root'a albo do apacza (powiedzmy ze to apache). Wtedy nic nie zdzialasz przynajmniej do czasu az nie zmienisz usera.

Druga kwestia - zmiana DN - oczywiscie masz racje ale... nie musisz wcale hakowac DNSow aby dzialac jako dana strona. Wystarczy ze jestes po drodze gdzie (kocham darmowe sieci WiFi hihihi) albo masz proxy wpiete tak ze mozesz selektywnie przechwycic ruch... tylko jesli jestes w stanie przechwycic ruch to nie potrzebujesz certyfikatow SSL tak na dobra sprawe bo wielu userow mozna zlapac prostszymi sposobami, nie zblizajac sie nawet do tematu TLS/SSL


Tak czy inaczej (wracajac do glownego tematu tego watku w ktorym autor nadal nie okreslil o co dokladnie pyta) - przechwycenie negocjacji TLS/SSL nic nie daje bo calosc jest tak zrobiona aby i tak nie dalo sie odczytac danych ktore sa przesylane - umozliwienie poufnego przeslania danych w obecnosci obserwatora to glowny cel uzywania TLS/SSL - linux_aa opisal jak to dziala...
Jesli chodzi o haslo ktorym moze byc "zabezpieczony" certyfikat to sniffing nadal nic nie dahe bo to haslo nie jest przesylane w ogole.

Chyba wyczerpalismy temat?

[TQM]

Ok... nasza rozmowa z linux_aa toczyla sie nieco na privie wiec aby wszyscy mieli mniej wiecej to samo...
procedura negocjacji kluczy wyglada tak SSL and TLS

Sa podane oba warianty - gdy tylko serwer ma certyfikat i kiedy klient ma swoj certyfikat (to co pisalem wczesniej). Cala sztuka rozbija sie o przeslanie klucza symetrycznego pakujac go w wiadomosc zaszyfrowana asymetrycznie (krok 5) i nakazanie serwerowi (krok 6) kontynuowanie rozmowy przy uzyciu szyfrowania symetrycznego z kluczem ktory wlasnie dostal. Na zakonczenie dla pewnosci klient informuje serwer o zakonczeniu negocjacji (krok 7) ale ta informacja jest juz przeslana szyfrem symetrycznym - jesli serwer odebral wiadomosc i zdekodowal to znaczy ze klucz dostal... i wtedy mamy krok 8 - serwer potwierdza ze cala komunikacja jest juz szyfrowana.

Mowiac o sniffingu 'hasel' - klient wysyla da serwera klucz szyfrujacy (symetryczny) ale przed wyslaniem szyfruje go kluczem publicznym serwera. Teraz aby odczytac ten kluicz symetryczny z wysnifowanego komunikatu musimy najpierw miec klucz prywatny serwera - tadaaaaa, ot cala filozofia Podsluchac mozna ale nic to nie daje.