Pytanie:
Wymiana DHE i uwierzytelnianie klienta
Jeff Ferland
2011-08-01 20:07:36 UTC
view on stackexchange narkive permalink

Jeśli serwer ma znany klucz publiczny i wymiana Diffiego-Helmana jest wykonywana i podpisywana przez ten klucz, czy jest jakaś korzyść z uwierzytelnienia klienta przed ustanowieniem bezpiecznego kanału zamiast po ustanowieniu bezpiecznego kanału? Wydaje mi się, że podpisanie tylko jednej strony giełdy nadal zapobiega atakowi typu man-in-the-middle.

Zainspirowany https://stackoverflow.com/questions/6156227/does- the-certificate-a-ssl-connection-state-points-to-change-if-and-load-a-new-ce

Trzy odpowiedzi:
Thomas Pornin
2011-08-01 20:28:25 UTC
view on stackexchange narkive permalink

Uwierzytelnianie klienta jest korzystne dla serwera. Zapobieganie występowaniu pośrednika to odrębna sprawa.

Jeśli wymiana kluczy wykorzystuje DH z podpisem serwera (w odniesieniu do klucza publicznego, który jest znany klientowi ) wtedy klient jest chroniony przed pośrednikiem: klient ma silne wyobrażenie o tym, z kim powinien rozmawiać, a podpis serwera zapobiega podszywaniu się pod serwer w jakikolwiek sposób (np. jako "pośrednik", co jest po prostu szczególnym rodzajem podszywania się).

Bez uwierzytelnienia klienta serwer nie wie, kto się z nim kontaktuje. Reszta protokołu (np. SSL / TLS) nadal będzie zapewniać ochronę przed atakami w następującym sensie: będzie to ten sam klient przez całą sesję i żadna inna strona nie może szpiegować zawartości danych lub zmienić dane w niewykryty sposób. W związku z tym „pośrednik” (na przykład: atakujący, który działa jako przekaźnik, odszyfrowując i ponownie szyfrując dane w locie) jest unikany, ponieważ klient zweryfikował podpis z serwera i dlatego używał „właściwego” klucza Diffiego-Hellmana, chroniąc atakującego przed wymianą kluczy.

Uwierzytelnianie klienta jako podpis, obliczane przez klienta z jego własnym kluczem prywatnym i odpowiadający kluczowi publicznemu znanemu serwerowi, może pomóc w zapobieganiu pośrednikowi w przebiegłej sytuacji, gdy klient nie (głupio) nie sprawdza podpisu z serwera. Nic nie może powstrzymać tego kretyńskiego klienta przed połączeniem się z fałszywym serwerem, ponieważ niczego nie sprawdza, a zatem można go dowolnie sprzeniewierzyć. Jednak uwierzytelnianie klienta jest wystarczające, aby serwer upewnił się, że jeśli klient w ogóle z nim rozmawia, zrobi to w bezpieczny sposób.

Kluczową kwestią jest tutaj kwestia definicji. Co to jest „mężczyzna w środku”? Jest to przypadek, w którym atakujący podszywa się pod zamierzonego peera (aby był to „prawdziwy środek”, atakujący podszywa się pod serwer w odniesieniu do klienta i klienta w odniesieniu do serwera). Ma to sens tylko wtedy, gdy istnieje „zamierzony peer”. Jeśli serwer nie dba o to, kto się z nim kontaktuje, nie ma pojęcia „pośrednika”.

W zwykłym scenariuszu HTTPS klient jest uwierzytelniany za pomocą hasła: klient musi od razu porozmawiać z odpowiednim serwerem (używając certyfikatu serwera), ponieważ klient nie chce nikomu wysyłać swojego hasła. Serwer po prostu chce mieć ciągłość : jeśli otrzymał poprawne hasło przez tunel SSL, to tunel jest dobry i taki pozostanie.

gowenfawr
2011-08-01 20:23:50 UTC
view on stackexchange narkive permalink

Cóż ... tak, korzyść jest dokładnie taka: uwierzytelnianie klienta.

W dzisiejszym podstawowym przypadku, certyfikat serwera służy do uwierzytelniania serwera („Verisign twierdzi, że to naprawdę amazon .com ”) i skonfigurować szyfrowanie (zapobiegające podsłuchiwaniu i pośredniczeniu).

Ponieważ jest rzadko używane, ludzie nie myślą o możliwości uwierzytelnienia klienta. Jest ku temu praktyczny powód, którym jest to, że „użytkownik” klienta (człowiek) może uzyskać dostęp do serwera z dowolnej liczby „maszyn” klienckich (komputerów), a jeśli używane są klucze klienta, muszą one być bezpiecznie dystrybuowane do wszystkich je, komputery klienckie muszą być względnie zaufane, itd. itd. Ale scenariusze istnieją , w których użycie uwierzytelniania klienta (SSL) ma sens.

Jeśli karty inteligentne kiedykolwiek zdarzyły się, wtedy widziałbyś to wszędzie. Ale nie zrobili tego. (Albo po prostu jeszcze nie, szczerze mówiąc nie wiem).

bethlakshmi
2011-08-01 20:24:53 UTC
view on stackexchange narkive permalink

Tylko uwierzytelnianie serwera zapewni klientowi, że rozmawia z serwerem. Zapewni serwerowi, że klient, który wykonał uzgadnianie, jest klientem wykonującym komunikację. Nie przekazuje serwerowi żadnych innych informacji - innymi słowy, serwer nie będzie wiedział, kim jest klient.

W niektórych przypadkach może to być w porządku - na przykład, jeśli logowanie odbywa się przez nazwa użytkownika / hasło po skonfigurowaniu sesji.

To nie wystarczy, jeśli masz sytuację, która wymaga uwierzytelnienia klienta za pomocą kryptograficznego potwierdzenia klucza prywatnego. W takich przypadkach należałoby albo dodać transmisję wyższego poziomu, w której klient coś podpisał, albo wymagać autoryzacji klienta podczas konfiguracji sesji SSL.

Wszystko zależy od aplikacji.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...