Bezpieczeństwo i uwierzytelnianie: SSL vs SASL

Question

Rozumiem, że protokół SSL łączy algorytm szyfrowania (np. AES, DES, itp.) Z metodą wymiany kluczy (np. Diffier-Hellman), aby zapewnić bezpieczne szyfrowanie i identyfikację między dwoma punktami końcowymi w dniu niezabezpieczona sieć (np. Internet).

Rozumiem, że SASL jest protokołem MD5/Kerberos, który w dużym stopniu robi to samo.

Moje pytanie: jakie są plusy i minusy wyboru i jakie scenariusze są bardziej korzystne? Zasadniczo, szukam wskazówek, których należy przestrzegać przy wyborze SSL lub zamiast tego w SASL. Z góry dziękuję!

Answer 1

Trudno jest porównać SSL/TLS i SASL, ponieważ SSL/TLS to protokół komunikacyjny, natomiast SASL to framework, zintegrowany z innymi protokołami. (W rzeczywistości, możesz użyć obu jednocześnie w pewnych okolicznościach.)

Poza tym wspomniałeś o protokole Kerberos, który jest rzeczywiście protokołem uwierzytelniania (który może być używany z SSL/TLS lub SASL lub niezależnie zarówno). Wydaje się, że Twoje pytanie sugeruje, czy używać Kerberos jako jednego z głównych problemów podrzędnych, które powinieneś wybrać jako pierwsze.

SASL jest zasadniczo warstwą pośrednią, umożliwiającą wtykowe systemy uwierzytelniania i bezpieczeństwo danych w istniejących protokołach aplikacji (np. LDAP, SMTP, Subversion, ...), chociaż protokoły te muszą być świadome tego rozszerzenia (np. SMTP auth) . To, czy i jak zapewnia bezpieczne uwierzytelnianie i szyfrowanie danych, zależy w dużej mierze od tego, co jest używane w tym środowisku. Oto przykład z svnserve documentation: "Wbudowany mechanizm CRAM-MD5 nie obsługuje szyfrowania, ale DIGEST-MD5 ma". Jeśli chcesz używać protokołu Kerberos z SASL, będziesz potrzebował innego poziomu niezależności: GSS-API (który jest najczęściej używany z Kerberos, ale może również zezwalać na inne mechanizmy). (Zauważ, że GSSAPI w kontekście SASL zdaje się sugerować, Kerberos i tak, w przeciwieństwie do swoich GS2 successor.)

Ogólnym celem jest SSL/TLS, aby zabezpieczyć komunikację (integralność i poufność) pomiędzy klientem a serwerem. Klient powinien zawsze sprawdzać tożsamość serwera SSL/TLS i zapewnia mechanizmy sprawdzania tożsamości klienta przez serwer. To, co może zrobić, zależy również od sposobu jego skonfigurowania. SSL/TLS jest najczęściej używany z certyfikatami X.509: w ten sposób przeglądarka może sprawdzić tożsamość serwera HTTPS. Serwery można również skonfigurować tak, aby żądały od klienta korzystania z certyfikatu w celu identyfikacji (uwierzytelnianie za pomocą certyfikatu klienta). Jeśli jednak chcesz używać protokołu Kerberos, możesz użyć TLS Kerberos cipher suites. Jest to znacznie mniej powszechne, ale są one implemented in the JSSE.

Jego implementacje zwykle zapewniają interfejsy API podobne do tych, które uzyskuje się dzięki zwykłym połączeniom TCP: w języku Java, po skonfigurowaniu, można w mniejszym lub większym stopniu użyć wartości SSLSocket, tak jak w przypadku zwykłego Socket. Nie wymaga to szczególnej świadomości przez protokół znajdujący się na górze gniazda, chociaż niektóre protokoły mają jawne polecenia przełączania się na SSL/TLS z połączenia zwykłego (Implicit v.s. Explicit SSL/TLS). Może również zapewnić uwierzytelnianie. W Javie JSSE jest domyślną implementacją SSL/TLS, która daje dostęp do SSLSocket (lub SSLEngine, jeśli jesteś wystarczająco odważny).

Czasami warto czytać „When to use Java GSS-API vs. JSSE”, który jest podobny do „SASL vs. SSL/TLS” (chociaż nie wydaje się, aby zostały zaktualizowane przez jakiś czas, ponieważ JSSE robi wsparcia Kerberos szyfrów teraz, przynajmniej od Oracle Java 6).

Przyznam, że wiem mniej o SASL niż o SSL/TLS, ale szyfrowanie danych za pośrednictwem SASL brzmi, jakby to było więcej pracy. Wygląda na to, że nie ma pewnych funkcji SSL/TLS, takich jak Perfect Forward Secrecy offered by EDH cipher suites. Istnieje example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial: musisz zawijać/rozwijać dane jawnie, czego nie musiałbyś robić, gdy używasz SSLSocket s.

Myślę, że należy przede wszystkim zdecydować, który mechanizm uwierzytelniania ma zostać użyty: Kerberos, certyfikaty X.509 lub coś innego. Będzie to miało większy wpływ na twoją ogólną architekturę, a oba mogą być używane z SASL i SSL/TLS (bardziej, jeśli użyjesz SASL z mechanizmem EXTERNAL, gdy będziesz na szczycie połączenia SSL/TLS).

• Kerberos jest bardzo scentralizowany. Klient musi mieć możliwość skontaktowania się z KDC w celu uwierzytelnienia, oprócz możliwości skontaktowania się z serwerem aplikacji. Klienci będą również musieli być skonfigurowani do korzystania z tego KDC. Z punktu widzenia użytkownika mogą używać haseł.
• X.509 jest bardziej zdecentralizowany. Jednak może być konieczne wdrożenie urzędu certyfikacji (lub użycia komercyjnego) dla certyfikatów użytkownika. Użytkownicy będą musieli otrzymać certyfikaty i klucze prywatne, które mogą być dla niektórych zbyt skomplikowane.

JAAS wchodzi w to, ponieważ jest to ogólne środowisko Java do obsługi uwierzytelniania i autoryzacji. Jest ściśle powiązany z pojęciem menedżerów bezpieczeństwa. To daje pojęcie Subject and Principal. Nie jest to bezpośrednio związane z protokołami ani komunikacją, ale raczej ze sposobem modelowania uwierzytelniania i autoryzacji w aplikacji. (Daje ci standardowy zestaw klas, aby to zrobić.)

(Generalnie proponuję przejść przez Java reference documents, które wspominają o słowach, których szukasz: JGSS, SASL, ..., chociaż są niekoniecznie łatwe do odczytania.)

Answer 2

SASL nie jest protokołem, ale warstwą abstrakcji dla niektórych mechanizmów uwierzytelniania. Jeśli używasz Digest-MD5 lub GSS-API jako mechanizmu SASL, możesz poprosić SASL o całkowite zaszyfrowanie ruchu danych. To jest na przykład to, co robię, aby rozmawiać z serwerami Active Directory. Nie potrzebujesz SSL. Jaki jest twój przypadek użycia. Proszę opracuj!

Answer 3

SSL vs SASL

To prawda, że ​​SASL nie jest protokołem ale warstwa abstrakcji. Prawdą jest również, że SSL i SASL zapewniają podobne funkcje. Oba zapewniają uwierzytelnianie, podpisywanie danych i szyfrowanie.

Protokół SSL jest wykonywany w warstwie transportowej i jest zwykle normalnie przezroczysty dla protokołu pod spodem. Na przykład możesz używać protokołu SSL w protokole LDAP lub HTTP. Jednak w niektórych przypadkach konieczna jest modyfikacja istniejących protokołów, aby przejść do trybu bezpiecznego. Na przykład protokoły POP3 i IMAP zostały rozszerzone, aby uzyskać polecenie STARTTLS w celu zainicjowania korzystania z protokołu SSL. Pod tym kątem jest to podobne do tego, co robi SASL.

Z drugiej strony wiele protokołów zostało również rozszerzonych w celu zapewnienia możliwości SASL. Here to lista protokołów. Ponownie, POP3 i IMAP są dwoma z nich i używają różnych poleceń do zainicjowania uwierzytelniania.

Kiedy zatem powinniśmy używać SSL i kiedy powinniśmy używać SASL?

Oczywistą różnicą między SSL i SASL jest to, że SASL pozwala wybrać różne mechanizmy do uwierzytelnienia klienta, podczas gdy SSL jest w pewnym stopniu związany z uwierzytelnianiem na podstawie certyfikatu. W SASL możesz używać GSSAPI, Kerberos, NTLM itp.

Z powodu tej różnicy, są pewne sytuacje, po prostu bardziej intuicyjnie jest używać SASL, ale nie SSL. Na przykład aplikacja kliencka używa protokołu Kerberos do uwierzytelniania użytkownika końcowego. Twój serwer musi uwierzytelnić klienta. Ponieważ twoja aplikacja kliencka ma już poświadczenia Kerberos (w terminologii Kerberos, bilet), sensowne jest używanie poświadczeń Kerberos do uwierzytelniania z serwerem. Oczywiście zawsze możesz skonfigurować SSL, aby zrobić to samo. Oznacza to jednak, że oprócz istniejącej infrastruktury protokołu Kerberos konieczne jest skonfigurowanie inforamcji Urzędu certyfikacji i korelacja certyfikatu klienta z poświadczeniami Kerberos. Jest to wykonalne, ale wymaga dużo pracy.

Czasami trzeba użyć niektórych funkcji, które są dostępne tylko w mechanizmie SASL, ale nie w protokole SSL. Na przykład, Kerberos pozwala przekazać bilet od klienta do serwera, aby serwer mógł użyć tego biletu do wysłania zapytania do pewnych zasobów w imieniu klienta. Typowym przykładem jest serwer aplikacji i baza danych. Aplikacja kliencka uwierzytelnia się z serwerem aplikacji, a serwer aplikacji musi zapytać bazę danych o zachowanie klienta przy użyciu poświadczeń klienta. SSL nie może zapewnić tej funkcji, ale obsługuje ją Kerberos. W takim przypadku musisz wybrać używanie SASL.

W niektórych przypadkach użytkownik chce korzystać z SSL, ale nie z SASL. Na przykład rozszerzenie protokołu nie jest opcją lub chcesz zaszyfrować każdy pojedynczy pakiet wymieniony przy użyciu protokołu.

Jak GSSAPI dotyczą Kerberos i SASL

Według tego wiki page zarówno GSSAPI i Kerberos są obsługiwane mechansim w SASL. GSSAPI to ogólny interfejs programistyczny. Chodzi o to, aby program piszący aplikacji korzystał z jednego wspólnego interfejsu API do uwierzytelniania, szyfrowania itp., Niezależnie od tego, jaki protokół jest używany. GSSAPI wdraża Kerberos. Możesz więc użyć GSSAPI do uwierzytelniania Kerberos.

Jak JAAS dotyczą SASL

Szczerze mówiąc, nie jestem ekspertem Java. Z tego, co czytam, wynika, że ​​JAAS to tylko plug-inowy framework uwierzytelniania. Uważam, że pomysł jest podobny do GSSAPI. Ma zapewnić jeden interfejs programowania niezależnie od tego, jakiej metody uwierzytelniania używa. Podczas gdy GSSAPI koncentruje się na uwierzytelnianiu i bezpiecznej wymianie wiadomości, JAAS koncentruje się na uwierzytelnianiu i autoryzacji. Nie znajduję żadnych dowodów na to, że JAAS jest również jednym z mechanizmów SASL. Uważam, że powinny istnieć pewne klasy pomocnicze z biblioteki Java, pomagające w implementacji niestandardowych mechanizmów SASL. Wdrażając niestandardowy mechanizm SASL, może warto korzystać z JAAS.