Udostępnij za pośrednictwem

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ść strony internetowej banku. Ponieważ przeglądarka ufa VeriSign, witryna jest zaufana. Jeśli chcesz skonsultować się z VeriSign, możesz to zrobić, 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, który jest używany w połączeniu z kluczem publicznym strony do utworzenia skrótu. Hasz to nowa liczba, która jest wyprowadzana z dwóch liczb przy użyciu standardowego algorytmu, takiego jak SHA1. (Klient i witryna wymieniają również wiadomości, aby uzgodnić, który algorytm skrótu ma zostać użyty). Skrót jest unikatowy i jest używany tylko podczas sesji między klientem a witryną do szyfrowania i odszyfrowywania wiadomości. Zarówno klient, jak i usługa mają oryginalną liczbę jednorazową oraz 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 odczytać wiadomość przy użyciu skrótu i odzyskać ten przedostatni skrót. Skumulowane informacje (liczby jednorazowe, klucz publiczny i inne dane) są teraz znane obu stronom i można utworzyć ostateczny skrót (lub klucz główny). Ten ostatni klucz jest wysyłany zaszyfrowany przy użyciu skrótu przedostatniego. 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łby nowej wymiany nonces i skrótów, wydajność ulegałaby 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 witryna generują nonce, które są algorytmicznie połączone podczas wymiany kluczy, aby zwiększyć złożoność, a tym samym ochronę procesu przesyłania danych.

Certyfikaty i infrastruktura kluczy publicznych

Podczas uzgadniania połączenia 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órym pierwotnie się skontaktował, aby zapewnić zgodność, a także sprawdza datę oraz instytucję, która go wydała.

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. Każdy z kluczy może być użyty do szyfrowania lub odszyfrowywania skrótu, hasha lub innego klucza, ale tylko jako przeciwne operacje. Na przykład, jeśli użytkownik szyfruje przy użyciu klucza publicznego, tylko strona internetowa może odszyfrować komunikat przy użyciu klucza prywatnego. Podobnie, jeśli strona szyfruje za pomocą 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. Witryna jest pewna, że wymienia komunikaty z klientem, który użył klucza publicznego do zaszyfrowania wiadomości. Ta wymiana jest bezpieczna tylko podczas początkowego uzgadniania, dlatego robi się znacznie więcej, aby utworzyć rzeczywisty klucz symetryczny. 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

USŁUGI 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.

USŁUGI 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).

Zobacz także