Zabezpieczenia transportu HTTP
W przypadku korzystania z protokołu HTTP jako transportu zabezpieczenia są zapewniane przez implementację protokołu Secure Sockets Layer (SSL). Protokół SSL jest powszechnie używany w Internecie do uwierzytelniania usługi na kliencie, a następnie w celu zapewnienia poufności (szyfrowania) kanału. W tym artykule wyjaśniono, jak działa protokół SSL i jak jest on implementowany w programie Windows Communication Foundation (WCF).
Podstawowy protokół SSL
Jak działa protokół SSL, najlepiej opisano w typowym scenariuszu, w tym przypadku w witrynie internetowej banku. Witryna umożliwia klientowi logowanie się przy użyciu nazwy użytkownika i hasła. Po uwierzytelnieniu użytkownik może wykonywać transakcje, takie jak wyświetlanie sald kont, płacenie rachunków i przenoszenie pieniędzy z jednego konta do innego.
Gdy użytkownik po raz pierwszy odwiedza witrynę, mechanizm SSL rozpoczyna serię negocjacji nazywanych uściskiem dłoni z klientem użytkownika (w tym przypadku przeglądarką internetową). Protokół SSL najpierw uwierzytelnia witrynę banku dla klienta. Jest to niezbędny krok, ponieważ klienci muszą najpierw wiedzieć, że komunikują się z rzeczywistą witryną, a nie fałsz, który próbuje zwabić ich do wpisywania nazwy użytkownika i hasła. Protokół SSL wykonuje to uwierzytelnianie przy użyciu certyfikatu SSL dostarczonego przez zaufany urząd, na przykład VeriSign. Logika jest następująca: VeriSign ręczy za tożsamość witryny banku. Ponieważ przeglądarka ufa VeriSign, witryna jest zaufana. Jeśli chcesz sprawdzić element VeriSign, możesz to zrobić również, klikając logo VeriSign. To przedstawia oświadczenie o autentyczności wraz z datą wygaśnięcia i tym, do kogo jest wystawiona (strona bankowa).
Aby zainicjować bezpieczną sesję, klient wysyła odpowiednik "hello" do serwera wraz z listą algorytmów kryptograficznych, których może użyć do podpisywania, generowania skrótów i szyfrowania i odszyfrowywania za pomocą. W odpowiedzi witryna wysyła potwierdzenie i wybór jednego z zestawów algorytmów. Podczas tego początkowego uzgadniania obie strony wysyłają i odbierają nonces. Nonce to losowo wygenerowany fragment danych używany w połączeniu z kluczem publicznym lokacji w celu utworzenia skrótu. Skrót to nowa liczba, która pochodzi z dwóch liczb przy użyciu algorytmu standardowego, takiego jak SHA1. (Klient i lokacja wymieniają również komunikaty w celu uzgodnienia algorytmu skrótu do użycia). Skrót jest unikatowy i jest używany tylko do sesji między klientem a lokacją w celu szyfrowania i odszyfrowywania komunikatów. Zarówno klient, jak i usługa mają oryginalną wartość inną niż i klucz publiczny certyfikatu, więc obie strony mogą wygenerować ten sam skrót. W związku z tym klient weryfikuje skrót wysłany przez usługę przez (a) przy użyciu uzgodnionego algorytmu w celu obliczenia skrótu z danych i (b) porównując go z hashem wysłanym przez usługę; jeśli dwa są zgodne, klient ma pewność, że skrót nie został naruszony. Następnie klient może użyć tego skrótu jako klucza do zaszyfrowania komunikatu zawierającego kolejny nowy skrót. Usługa może odszyfrować komunikat przy użyciu skrótu i odzyskać ten skrót drugi do ostatniego. Skumulowane informacje (inne niż, klucz publiczny i inne dane) są teraz znane obu stronom, a ostatni skrót (lub klucz główny) można utworzyć. Ten ostatni klucz jest wysyłany zaszyfrowany przy użyciu skrótu następnego do ostatniego. Klucz główny jest następnie używany do szyfrowania i odszyfrowywania komunikatów w pozostałej części sesji. Ponieważ zarówno klient, jak i usługa używają tego samego klucza, jest to również nazywane kluczem sesji.
Klucz sesji jest również scharakteryzowany jako klucz symetryczny lub "wspólny klucz tajny". Posiadanie klucza symetrycznego jest ważne, ponieważ zmniejsza obliczenia wymagane przez obie strony transakcji. Jeśli każdy komunikat zażądał nowej wymiany wartości nonces i skrótów, wydajność ulegnie pogorszeniu. W związku z tym ostatecznym celem protokołu SSL jest użycie klucza symetrycznego, który umożliwia swobodny przepływ komunikatów między obiema stronami z większym stopniem bezpieczeństwa i wydajności.
Poprzedni opis jest uproszczoną wersją tego, co się stanie, ponieważ protokół może się różnić od lokacji do lokacji. Istnieje również możliwość, że zarówno klient, jak i lokacja generują nietypowo połączone algorytmowo podczas uzgadniania, aby zwiększyć złożoność, a tym samym ochronę procesu wymiany danych.
Certyfikaty i infrastruktura kluczy publicznych
Podczas uzgadniania usługa wysyła również certyfikat SSL do klienta. Certyfikat zawiera informacje, takie jak data wygaśnięcia, urząd wystawiający oraz identyfikator URI (URI) witryny. Klient porównuje identyfikator URI z identyfikatorem URI, z którą pierwotnie skontaktował się w celu zapewnienia dopasowania, a także sprawdza datę i urząd wystawiający.
Każdy certyfikat ma dwa klucze, klucz prywatny i klucz publiczny, a dwa są nazywane parą kluczy wymiany. Krótko mówiąc, klucz prywatny jest znany tylko właścicielowi certyfikatu, podczas gdy klucz publiczny można odczytać z certyfikatu. Klucz może służyć do szyfrowania lub odszyfrowywania skrótu, skrótu lub innego klucza, ale tylko jako sprzeczne operacje. Jeśli na przykład klient szyfruje przy użyciu klucza publicznego, tylko lokacja może odszyfrować komunikat przy użyciu klucza prywatnego. Podobnie, jeśli lokacja szyfruje się przy użyciu klucza prywatnego, klient może odszyfrować przy użyciu klucza publicznego. Zapewnia to klientowi pewność, że komunikaty są wymieniane tylko z właścicielem klucza prywatnego, ponieważ tylko komunikaty zaszyfrowane za pomocą klucza prywatnego można odszyfrować przy użyciu klucza publicznego. Lokacja jest pewna, że wymienia komunikaty z klientem, który zaszyfrował przy użyciu klucza publicznego. Ta wymiana jest bezpieczna tylko w przypadku początkowego uzgadniania, dlatego znacznie więcej odbywa się w celu utworzenia rzeczywistego klucza symetrycznego. Niemniej jednak cała komunikacja zależy od usługi z prawidłowym certyfikatem SSL.
Implementowanie protokołu SSL za pomocą usługi WCF
Zabezpieczenia transportu HTTP (lub SSL) są udostępniane zewnętrznie w usłudze WCF. Protokół SSL można zaimplementować na jeden z dwóch sposobów; decydującym czynnikiem jest sposób hostowania aplikacji:
Jeśli używasz usług Internet Information Services (IIS) jako hosta WCF, użyj infrastruktury usług IIS do skonfigurowania usługi SSL.
Jeśli tworzysz własną aplikację WCF, możesz powiązać certyfikat SSL z adresem przy użyciu narzędzia HttpCfg.exe.
Korzystanie z usług IIS na potrzeby zabezpieczeń transportu
IIS 7.0
Aby skonfigurować usługi IIS 7.0 jako bezpieczny host (przy użyciu protokołu SSL), zobacz Konfigurowanie protokołu Secure Sockets Layer w usługach IIS 7.0.
Aby skonfigurować certyfikaty do użycia z usługami IIS 7.0, zobacz Konfigurowanie certyfikatów serwera w usługach IIS 7.0.
IIS 6,0
Aby skonfigurować usługi IIS 6.0 jako bezpieczny host (przy użyciu protokołu SSL), zobacz Konfigurowanie protokołu Secure Sockets Layer.
Aby skonfigurować certyfikaty do użycia z usługami IIS 6.0, zobacz Certificates_IIS_SP1_Ops.
Używanie protokołu HttpCfg dla protokołu SSL
Jeśli tworzysz własną aplikację WCF, użyj narzędzia HttpCfg.exe .
Aby uzyskać więcej informacji na temat konfigurowania portu przy użyciu certyfikatu X.509 za pomocą narzędzia HttpCfg.exe, zobacz How to: Configure a Port with an SSL Certificate (Instrukcje: konfigurowanie portu przy użyciu certyfikatu SSL).