Dnia czw, 02 sty 2003 at 15:55 GMT,
Adam Płaszczyca <_...@i...pl> napisał(a):
>> Więc nie ma możliwości zaatakować takiego połączenia.
>
> Tylko zauważ, że masz systuację taką, że przeglądarka łączy się do
> podstawiinego serwera, a ten do właściwego. I teraz serwer podstawiony
> udziela przeglądarce takich samych odpowiedzi jak serwer prawdziwy. Ma
> je od prawdziwego serwera, tylko przekazuje dalej.
>
> Czyli masz tak:
>
> Serwer banku <===== SSL ======> podstawiony INT0 <===nieszyfrowane==
> ===>podstawiony INT1 <==== SSL ===> przeglądarka.

To niemożliwe. Aby to było możliwe INT1 musiał by posiadać certyfikat
banku potwierdzony przez CA. Nie sądzisz chyba że Thawte wystawi ci
certyfikat na https://www.mbank.com.pl bez sprawdzenia kto, co i jak.

Nie ma możliwości przekazywać odpowiedzi od banku do przeglądarki - bo
są zaszyfrowana (to znaczy przekazywać możesz ale bez możliwości
poznania treści)

Nie ma możliwości rozbic transmisje SSL tak aby odpowiedzi z banku szły
zaszyfrowane tranzytem przez twoje maszyny INT0 i INT1. Transmisja zaś w
drugą stronę była odszyfrowana pomiędzy INT0 a INT1. Dlaczego? Klucze
się weryfikują trochę bardziej skomplikowanie, nie tylko czy on to
rzeczywiście on ale równiez potwierdzają sobie czy naprawdę rozmawiają
ze sobą bez pośredników. Wcięcie się w połączenie tylko z jednej strony
rozerwie to potwierdzenie. Kiedyś były dosyć szczegółowe dyskusje na ten
temat na pl.comp.security

>> albo udaje serwer banku - ale nie ma prawidłowego certyfikatu - więc
>> zdradzi ją alarm przeglądarki
>
> Udaje i serwer banku (dla przeglądarki) i przeglądarkę (dla serwera
> banku).
>
>> Podtrzymuje - tylko pewna przeglądarka może nas ochronić przed atakiem
>> na połączenie internetowe.
>
> NA powyższe żaden SSL nie pomoże.

Nieprawda - SSL to jeden z bezpiecznijszych i bardo dopracowanych
pomysłów. Z realizacją czasem bywa gorzej.

Jeśli cie nie przekonałem zrób followup-to pl.comp.security, może się
spece wypowiedzą.


--
------------------------------
Jurek