HTTP-transportbeveiliging
Wanneer u HTTP gebruikt als transport, wordt beveiliging geleverd door een SSL-implementatie (Secure Sockets Layer). SSL wordt veel gebruikt op internet om een service aan een client te verifiëren en vervolgens vertrouwelijkheid (versleuteling) aan het kanaal te bieden. In dit artikel wordt uitgelegd hoe SSL werkt en hoe deze wordt geïmplementeerd in Windows Communication Foundation (WCF).
Basis-SSL
Hoe SSL werkt, wordt het beste uitgelegd via een typisch scenario, in dit geval de website van een bank. Op de site kan een klant zich aanmelden met een gebruikersnaam en wachtwoord. Nadat deze is geverifieerd, kan de gebruiker transacties uitvoeren, zoals rekeningsaldo's weergeven, rekeningen betalen en geld van het ene naar het andere account verplaatsen.
Wanneer een gebruiker de site voor het eerst bezoekt, begint het SSL-mechanisme met een reeks onderhandelingen, een handshake genoemd, met de client van de gebruiker (in dit geval de webbrowser). SSL verifieert eerst de banksite bij de klant. Dit is een essentiële stap, omdat klanten eerst moeten weten dat ze communiceren met de werkelijke site, en geen spoof die hen probeert te lokken in het typen van hun gebruikersnaam en wachtwoord. SSL voert deze verificatie uit met behulp van een SSL-certificaat dat wordt geleverd door een vertrouwde instantie, zoals VeriSign. De logica gaat als volgt: VeriSign-vouches voor de identiteit van de banksite. Omdat de browser VeriSign vertrouwt, wordt de site vertrouwd. Als u wilt controleren met VeriSign, kunt u dit ook doen door op het VeriSign-logo te klikken. Dat presenteert een verklaring van echtheid met de vervaldatum en aan wie het is uitgegeven (de banksite).
Om een beveiligde sessie te starten, verzendt de client het equivalent van een 'hallo' naar de server, samen met een lijst met cryptografische algoritmen die kunnen worden gebruikt voor het ondertekenen, genereren van hashes en versleutelen en ontsleutelen met. Als reactie stuurt de site een bevestiging en de keuze van een van de algoritmensuites terug. Tijdens deze eerste handshake verzenden en ontvangen beide partijen nonces. Een nonce is een willekeurig gegenereerd stukje gegevens dat wordt gebruikt in combinatie met de openbare sleutel van de site om een hash te maken. Een hash is een nieuw getal dat is afgeleid van de twee getallen met behulp van een standaardalgoritme, zoals SHA1. (De client en de site wisselen ook berichten uit om te bepalen welk hash-algoritme moet worden gebruikt.) De hash is uniek en wordt alleen gebruikt voor de sessie tussen de client en de site om berichten te versleutelen en te ontsleutelen. Zowel client als service hebben de oorspronkelijke nonce en de openbare sleutel van het certificaat, zodat beide zijden dezelfde hash kunnen genereren. Daarom valideert de client de hash die door de service wordt verzonden door (a) met behulp van het overeengekomen algoritme om de hash van de gegevens te berekenen en (b) vergelijkt deze met de hash die door de service wordt verzonden; als de twee overeenkomsten overeenkomen, heeft de client de zekerheid dat er niet met de hash is geknoeid. De client kan deze hash vervolgens gebruiken als sleutel om een bericht te versleutelen dat nog een nieuwe hash bevat. De service kan het bericht ontsleutelen met behulp van de hash en deze tweede-naar-uiteindelijke hash herstellen. De verzamelde informatie (niet-ces, openbare sleutel en andere gegevens) is nu bekend aan beide zijden en er kan een definitieve hash (of hoofdsleutel) worden gemaakt. Deze laatste sleutel wordt versleuteld verzonden met behulp van de volgende-naar-laatste hash. De hoofdsleutel wordt vervolgens gebruikt voor het versleutelen en ontsleutelen van berichten voor de rest van de sessie. Omdat zowel client als service dezelfde sleutel gebruiken, wordt dit ook wel een sessiesleutel genoemd.
De sessiesleutel wordt ook gekenmerkt als een symmetrische sleutel of een 'gedeeld geheim'. Het hebben van een symmetrische sleutel is belangrijk omdat het de berekening vermindert die aan beide zijden van de transactie is vereist. Als elk bericht een nieuwe uitwisseling van non-ces en hashes eiste, zouden de prestaties verslechteren. Daarom is het uiteindelijke doel van SSL om een symmetrische sleutel te gebruiken waarmee berichten vrij tussen de twee zijden kunnen stromen met een grotere mate van beveiliging en efficiëntie.
De vorige beschrijving is een vereenvoudigde versie van wat er gebeurt, omdat het protocol kan variëren van site tot site. Het is ook mogelijk dat zowel de client als de site zowel non-ces genereren die algoritmetisch worden gecombineerd tijdens de handshake om meer complexiteit en daarom beveiliging toe te voegen aan het proces van het uitwisselen van gegevens.
Certificaten en infrastructuur voor openbare sleutels
Tijdens de handshake verzendt de service ook het SSL-certificaat naar de client. Het certificaat bevat informatie, zoals de vervaldatum, de verlenende instantie en de URI (Uniform Resource Identifier) van de site. De client vergelijkt de URI met de URI die deze oorspronkelijk had gecontacteerd om een overeenkomst te garanderen, en controleert ook de datum en verlenende instantie.
Elk certificaat heeft twee sleutels, een persoonlijke sleutel en een openbare sleutel, en de twee worden een exchange-sleutelpaar genoemd. Kortom, de persoonlijke sleutel is alleen bekend bij de eigenaar van het certificaat, terwijl de openbare sleutel leesbaar is vanuit het certificaat. Een sleutel kan worden gebruikt voor het versleutelen of ontsleutelen van een digest, hash of andere sleutel, maar alleen als tegengestelde bewerkingen. Als de client bijvoorbeeld versleutelt met de openbare sleutel, kan alleen de site het bericht ontsleutelen met behulp van de persoonlijke sleutel. Als de site wordt versleuteld met de persoonlijke sleutel, kan de client ook ontsleutelen met de openbare sleutel. Dit biedt de klant de zekerheid dat de berichten alleen worden uitgewisseld met de eigenaar van de persoonlijke sleutel, omdat alleen berichten die zijn versleuteld met de persoonlijke sleutel kunnen worden ontsleuteld met de openbare sleutel. De site is ervan verzekerd dat het berichten uitwisselt met een client die is versleuteld met behulp van de openbare sleutel. Deze uitwisseling is alleen veilig voor een eerste handshake, maar daarom wordt er veel meer gedaan om de daadwerkelijke symmetrische sleutel te maken. Niettemin is alle communicatie afhankelijk van de service met een geldig SSL-certificaat.
SSL implementeren met WCF
HTTP-transportbeveiliging (of SSL) wordt extern geleverd aan WCF. U kunt SSL op twee manieren implementeren; de beslissingsfactor is hoe uw toepassing wordt gehost:
Als u IIS (Internet Information Services) als uw WCF-host gebruikt, gebruikt u de IIS-infrastructuur om een SSL-service in te stellen.
Als u een zelf-hostende WCF-toepassing maakt, kunt u een SSL-certificaat koppelen aan het adres met behulp van het hulpprogramma HttpCfg.exe.
IIS gebruiken voor transportbeveiliging
IIS 7.0
Zie Secure Sockets Layer configureren in IIS 7.0 als u IIS 7.0 wilt instellen als een beveiligde host (met SSL).
Zie Servercertificaten configureren in IIS 7.0 om certificaten te configureren voor gebruik met IIS 7.0.
IIS 6.0
Als u IIS 6.0 wilt instellen als een beveiligde host (met ssl), raadpleegt u Secure Sockets Layer configureren.
Zie Certificates_IIS_SP1_Ops om certificaten te configureren voor gebruik met IIS 6.0.
HttpCfg gebruiken voor SSL
Als u een zelf-hostende WCF-toepassing maakt, gebruikt u het hulpprogramma HttpCfg.exe .
Zie Een poort configureren met een SSL-certificaat voor meer informatie over het gebruik van het hulpprogramma HttpCfg.exe voor het instellen van een poort met een X.509-certificaat.