HTTP Transport Security
När du använder HTTP som transport tillhandahålls säkerheten av en SSL-implementering (Secure Sockets Layer). SSL används ofta på Internet för att autentisera en tjänst till en klient och sedan för att tillhandahålla konfidentialitet (kryptering) till kanalen. Den här artikeln förklarar hur SSL fungerar och hur det implementeras i Windows Communication Foundation (WCF).
Grundläggande SSL
Hur SSL fungerar förklaras bäst genom ett typiskt scenario, i det här fallet en banks webbplats. På webbplatsen kan en kund logga in med ett användarnamn och lösenord. När användaren har autentiserats kan den utföra transaktioner, till exempel visa kontosaldon, betala fakturor och flytta pengar från ett konto till ett annat.
När en användare först besöker webbplatsen påbörjar SSL-mekanismen en serie förhandlingar, så kallade handskakning, med användarens klient (i det här fallet webbläsaren). SSL autentiserar först bankkontot till kunden. Detta är ett viktigt steg eftersom kunderna först måste veta att de kommunicerar med den faktiska webbplatsen, och inte en förfalskning som försöker locka dem att skriva in sitt användarnamn och lösenord. SSL utför den här autentiseringen med hjälp av ett SSL-certifikat som tillhandahålls av en betrodd utfärdare, till exempel VeriSign. Logiken går så här: VeriSign går i god för bankplatsens identitet. Eftersom webbläsaren litar på VeriSign är webbplatsen betrodd. Om du vill kontrollera med VeriSign kan du också göra det genom att klicka på VeriSign-logotypen. Det framlägger ett meddelande av äkthet med dess förfallodatum och vem det utfärdas till (bankplatsen).
För att initiera en säker session skickar klienten motsvarigheten till ett "hej" till servern tillsammans med en lista över kryptografiska algoritmer som den kan använda för att signera, generera hashar och kryptera och dekryptera med. Som svar skickar webbplatsen tillbaka en bekräftelse och dess val av en av algoritmernas paket. Under denna inledande handskakning skickar och tar båda parter emot nonces. En nonce är en slumpmässigt genererad del av data som används, i kombination med webbplatsens offentliga nyckel, för att skapa en hash. En hash är ett nytt tal som härleds från de två talen med hjälp av en standardalgoritm, till exempel SHA1. (Klienten och platsen utbyter också meddelanden för att komma överens om vilken hash-algoritm som ska användas.) Hashen är unik och används endast för sessionen mellan klienten och platsen för att kryptera och dekryptera meddelanden. Både klienten och tjänsten har den ursprungliga nonce och certifikatets offentliga nyckel, så båda sidor kan generera samma hash. Därför validerar klienten hashen som skickas av tjänsten av (a) med hjälp av den överenskomna algoritmen för att beräkna hashen från data och (b) jämföra den med den hash som skickas av tjänsten; om de två matchar har klienten en försäkran om att hashen inte har manipulerats. Klienten kan sedan använda denna hash som en nyckel för att kryptera ett meddelande som innehåller ännu en ny hash. Tjänsten kan dekryptera meddelandet med hjälp av hashen och återställa den här andra till sista hashen. Den ackumulerade informationen (nonces, offentlig nyckel och andra data) är nu känd för båda sidor, och en slutlig hash (eller huvudnyckel) kan skapas. Den här sista nyckeln skickas krypterad med hjälp av den näst sista hashen. Huvudnyckeln används sedan för att kryptera och dekryptera meddelanden under resten av sessionen. Eftersom både klienten och tjänsten använder samma nyckel kallas detta även för en sessionsnyckel.
Sessionsnyckeln kännetecknas också som en symmetrisk nyckel eller en "delad hemlighet". Att ha en symmetrisk nyckel är viktigt eftersom det minskar den beräkning som krävs av båda sidor av transaktionen. Om varje meddelande krävde ett nytt utbyte av nonces och hashvärden skulle prestanda försämras. Därför är slutmålet med SSL att använda en symmetrisk nyckel som gör att meddelanden kan flöda fritt mellan de två sidorna med en högre grad av säkerhet och effektivitet.
Den tidigare beskrivningen är en förenklad version av vad som händer, eftersom protokollet kan variera från plats till plats. Det är också möjligt att både klienten och platsen både genererar nonces som kombineras algoritmiskt under handskakningen för att lägga till mer komplexitet och därmed skydd i processen för att utbyta data.
Certifikat och infrastruktur för offentlig nyckel
Under handskakningen skickar tjänsten även sitt SSL-certifikat till klienten. Certifikatet innehåller information, till exempel dess förfallodatum, utfärdande utfärdare och webbplatsens URI (Uniform Resource Identifier). Klienten jämför URI:n med den URI som den ursprungligen hade kontaktat för att säkerställa en matchning och kontrollerar även datum och utfärdande utfärdare.
Varje certifikat har två nycklar, en privat nyckel och en offentlig nyckel, och de två kallas för ett exchange-nyckelpar. I korthet är den privata nyckeln endast känd för certifikatets ägare medan den offentliga nyckeln kan läsas från certifikatet. Antingen nyckel kan användas för att kryptera eller dekryptera en sammandrag, hash eller annan nyckel, men bara som motsatta åtgärder. Om klienten till exempel krypteras med den offentliga nyckeln kan endast platsen dekryptera meddelandet med hjälp av den privata nyckeln. På samma sätt kan klienten dekryptera med den offentliga nyckeln om platsen krypteras med den privata nyckeln. Detta garanterar klienten att meddelandena endast utbyts med den privata nyckelns ägare eftersom endast meddelanden som krypterats med den privata nyckeln kan dekrypteras med den offentliga nyckeln. Webbplatsen är säker på att den utbyter meddelanden med en klient som har krypterats med hjälp av den offentliga nyckeln. Det här utbytet är dock endast säkert för ett inledande handskakning, vilket är anledningen till att mycket mer görs för att skapa den faktiska symmetriska nyckeln. All kommunikation beror dock på att tjänsten har ett giltigt SSL-certifikat.
Implementera SSL med WCF
HTTP-transportsäkerhet (eller SSL) tillhandahålls externt till WCF. Du kan implementera SSL på ett av två sätt. Den avgörande faktorn är hur programmet hanteras:
Om du använder IIS (Internet Information Services) som WCF-värd använder du IIS-infrastrukturen för att konfigurera en SSL-tjänst.
Om du skapar ett lokalt WCF-program kan du binda ett SSL-certifikat till adressen med hjälp av verktyget HttpCfg.exe.
Använda IIS för transportsäkerhet
IIS 7.0
Information om hur du konfigurerar IIS 7.0 som en säker värd (med SSL) finns i Konfigurera Secure Sockets Layer i IIS 7.0.
Information om hur du konfigurerar certifikat för användning med IIS 7.0 finns i Konfigurera servercertifikat i IIS 7.0.
IIS 6.0
Information om hur du konfigurerar IIS 6.0 som en säker värd (med SSL) finns i Konfigurera Secure Sockets Layer.
Information om hur du konfigurerar certifikat för användning med IIS 6.0 finns i Certificates_IIS_SP1_Ops.
Använda HttpCfg för SSL
Om du skapar ett lokalt WCF-program använder du verktyget HttpCfg.exe .
Mer information om hur du använder verktyget HttpCfg.exe för att konfigurera en port med ett X.509-certifikat finns i Så här konfigurerar du en port med ett SSL-certifikat.