Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering
De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de VS.
Dit nummer werd uit het Engels vertaald door:
Verder werkten mee:
Onverschrokken binnenstappend in het territorium van dubbelcijferige versienummers heeft Apple Mac OS X 10.4.10 uitgegeven, een onderhoudsupdate die meer ondersteuning voor RAW-afbeeldingen toevoegt, problemen met Bluetooth en USB oplost en nog een paar andere zaken. De delta-update vanaf 10.4.9 is verkrijgbaar via Software-update of hij kan gedownload worden voor Intel-gebaseerde Macs (een download van 72 MB) en PowerPC-gebaseerde Macs (een download van 25 MB). Een gecombineerde update (van maar liefst 293 MB voor Intel-Macs en 165 MB voor PowerPC-Macs) kan elke versie van Mac OS X 10.4 updaten.
Deze nieuwe versie van Tiger lost een probleem op waarbij een Bluetooth-koptelefoon niet op de juiste manier uit de Bluetooth-voorkeuren verwijderd werd, het verbetert de betrouwbaarheid bij het gebruik van de Apple Remote na het ontwaken uit de sluimerstand en wanneer externe USB-schijven geactiveerd worden, en het herstelt een probleem met het TomTom GO 910 GPS navigatie-apparaat op Intel-gebaseerde Macs. Ook problemen met vervorming en verkleuring van DNG-afbeeldingen zijn opgelost, en er is ondersteuning voor RAW-afbeeldingen die gemaakt zijn met de volgende camera's: Panasonic DMC-LX1, Panasonic DMC-LX2, Leica M8, Leica D-LUX 2, Leica D-LUX 3, Fuji S5 Pro, Nikon D40x en Canon EOS 1D Mk III. Het uitgavebericht claimt een betere compatibiliteit met Mathematica 6 op 64-bit Macs en een reparatie voor een specifiek probleem met verdwijnende beeldjes bij het importeren van video vanaf een DV-camera, en nog wat veranderingen.
Mac OS X Server 10.4.10 is ook uitgebracht als een delta-update voor PowerPC-gebaseerde Macs (een download van 58 MB) en als een gecombineerde update in universeel binaire (een download van 391 MB) en PowerPC-(een download van 218 MB)-versies.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Ik heb me voorgenomen om aanstaande vrijdag in de rij te gaan staan om een iPhone te kopen. Gelukkig heb ik een zakelijk motief om dit te doen, ik verdien namelijk mijn geld met schrijven over computertechniek. Verder was ik net toe aan een 'smartphone' toen Steve Jobs in januari het grote iNieuws wereldkundig maakte. Mijn huidige telefoon, die al vier jaar oud is, had in de gaten dat er veranderingen zaten aan te komen, en hield er gelijk mee op. Hij wist dat het een aflopende zaak was.
Ik zal foto's maken in het University Village winkelcentrum in Seattle, waar zich zowel een door AT&T zelf uitgebate AT&T-winkel als een Apple Store bevinden. Als je de foto's die ik daar maak - ik hoop dat ik ze ter plekke meteen kan uploaden via een gratis WiFi-netwerkverbinding of een mobiele dataverbinding - wilt bekijken, kun je naar de volgende Flickr fotogroep gaan. Je kunt daar ook je eigen iPhone-foto's toevoegen. Mocht je geïnteresseerd zijn, er is ook een RSS-feed waar je je op kunt abonneren.
Ik heb geen flauw idee of de rij mensen die een iPhone willen kopen uit 20 personen zal bestaan, of tot om de volgende straathoek zal reiken. Ik vermoed dat veel belangstellenden bij de Apple Store het ding vooral willen uitproberen; de klanten bij de AT&T winkel zullen veelal potentiële kopers zijn. Het zou zomaar kunnen dat ik achter het net vis, en op een latere datum terug zal moeten komen.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Met de introductie van de iPhone aanstaande heeft Apple alweer een nieuwe mogelijkheid aangekondigd: een YouTube-programma dat YouTube-filmpjes direct op je iPhone kan downloaden en vertonen. (Al eerder kondigde het bedrijf aan dat de iPhone met betere batterijen uitgerust zou worden en een glazen in plaats van een kunststof scherm zou krijgen; zie "Apple kondigt iPhone-veranderingen aan," 18-06-2007.) Verder gaf Apple een al eerder beloofde update voor de Apple TV vrij waarmee het mogelijk wordt om YouTube-filmpjes af te spelen (zie "Apple TV krijgt harde schijf van 160 GB en YouTube-downloads," 04-06-2007).
YouTube (eigendom van Google) is bezig om zijn verzameling filmpjes om te zetten in het H.264-bestandsformaat. Daarom neem ik aan dat de Apple TV en de iPhone rechtstreeks van deze H.264-stromen gebruik gaan maken, omdat YouTube-filmpjes normaliter als Flash-bestanden worden verspreid.
Het persbericht van Apple noemt ook H.264-video bij het bespreken van de Wi-Fi-mogelijkheden van de iPhone; dit zou er op kunnen wijzen dat de YouTube-downloads behoorlijk groot zouden kunnen zijn. Dat is geen probleem zolang de filmpjes via Wi-Fi bekeken worden, maar het binnenhalen over een mobiele dataverbinding zou wel eens in de papieren kunnen gaan lopen. Noch Apple, noch AT&T hebben al mededelingen gedaan over de prijsstelling van de telefoon- en datadiensten voor de iPhone.
De Apple TV 1.1 update repareert ook een mogelijk veiligheidslek in het UPnP IGD- (Internet Gateway Device besturings-)protocol dat het mogelijk maakte dat een derde van buitenaf een 'denial-of-service' aanval kon doen. De update is alleen rechtstreeks via de Apple TV te verkrijgen, niet als afzonderlijke download. Om de update te installeren moet je, vanuit het hoofdmenu van het apparaat, 'Settings' kiezen en dan 'Update Software'. Op dit moment is niet bekend of deze update ook nog andere aanpassingen of verbeteringen bevat.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Eind vorige week gaf Apple Security Update 2007-006 uit om twee fouten te verbeteren in de WebCore- en WebKit-code waarop Safari en vele andere web-gebruikende Macintosh-programma's gebouwd zijn. De details zijn niet belangrijk, maar beide misbruiken vereisen dat de gebruiker verleid wordt om een met slechte bedoelingen gemaakte webpagina te bezoeken, en ze benadrukken dus het advies om je bewust te zijn van wat voor soort websites je leest. Security Update 2007-006 is verkrijgbaar via Software Update en als een alleenstaande download voor Mac OS X 10.3.9 (2,2 MB) en voor Mac OS X 10.4.9 of later in zowel PowerPC- (2,7 MB) als universeel binaire (4,5 MB) versies. Let wel op: als je de Safari 3 bèta geïnstalleerd hebt, zul je Security Update 2007-006 niet zien verschijnen in Software-update.
Dat komt omdat Safari 3 Beta Update 3.0.2 de foutverbeteringen van Security Update 2007-006 al bevat. Het richt zich verder op twee andere beveiligingsproblemen, één die specifiek is voor de Windows-versie van Safari 3 en een andere die zowel Macintosh- en Windows-gebruikers van de bèta-uitgave van de webbrowser kan aangaan. Apple beweert ook dat de eigenschappen van Safari 3.0.2 de stabiliteit verbeteren en een betere WebKit-ondersteuning bieden voor Mail, iChat en Dashboard (verscheidene TidBITS-redactieleden moesten de installatie van de aanvankelijke bèta van Safari 3 ongedaan maken vanwege irritante interacties met iChat). De 9,5 MB grote Safari 3 Beta Update 3.0.2 is alleen verkrijgbaar via Software Update, hoewel je met het downloaden van een nieuwe exemplaar van de Safari bèta ook de reparaties krijgt.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Ambrosia Software heeft Snapz Pro X 2.1 uitgebracht, waarmee het populaire programma voor het maken van schermafbeeldingen van stilstaande en bewegende beelden nu universeel binair is voor betere prestaties op Intel-Macs. Andere veranderingen zijn het over de gehele breedte verbeteren van de prestaties, ondersteuning voor compressiesessies met QuickTime, compatibiliteit met de nieuwste Mac OS X 10.5 Leopard bèta en de terugkeer van de mogelijkheid van "Save Later" wanneer opgenomen films worden nabewerkt. Verder wordt er ook een aantal fouten aangepakt. De update is gratis voor geregistreerde gebruikers; de download is 11,8 MB. Nieuwe exemplaren van Snapz Pro X kosten $30 wanneer je alleen met stilstaande beelden werkt, of $70 wanneer je het ook voor bewegende beelden wilt gebruiken.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Als je het begin van elke TidBITS-aflevering niet steeds zorgvuldig leest, heb je misschien nog niet gezien dat onze sponsor Small Dog Electronics regelmatige exclusieve aanbiedingen voor TidBITS-lezers heeft. Deze week gaan ze nog een stap verder en geven ze een blauwe 4 GB iPod nano (opgeknapt) met een Mophie-hoes weg, samen $136,99 waard. Deelnemers die niet tot de gelukkige winnaars behoren, krijgen een korting op een identieke iPod met Mophie-hoes, dus vergeet niet om je in te schrijven op de DealBITS-pagina.
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
SSL (Secure Sockets Layer) en TLS (Transport Layer Security) zijn systemen om internetcommunicatie te beveiligen, in het bijzonder het webbrowsen. Preciezer gezegd gebruiken zij versleuteling waarmee ze voor confidentialiteit (privacy) en identificatie (autorisatie) zorgen.
Er zijn drie hoofdversies van SSL; de vierde versie werd herdoopt tot TLS versie 1. SSL en TLS zijn gebaseerd op versleuteling en ontcijfering met een publieke sleutel, eenvoudige identificatie-informatie en relaties gebaseerd op vertrouwen. Tezamen maken deze drie elementen SSL/TLS geschikt voor de beveiliging van een breed scala aan internetcommunicaties.
Als je bezorgd bent over 'phishing'-bedrog [vissen naar gevoelige informatie - nvdv] en identiteitsdiefstal (en tot op zekere hoogte behoort iedereen dat te zijn), dan kan dit artikel je helpen om te begrijpen hoe een van de belangrijke vormen van bescherming tegen online-criminelen werkt. Voor websitebeheerders kan informatie over het werken met SSL/TLS en certificaten nuttig zijn voor zowel het leveren van privacy en beveiliging als om te beslissen of het opportuun en nuttig is om je eigen digitale certificaat aan te schaffen. Zo'n certificatie is in wezen een electronische garantie van een betrouwbare autoriteit dat jouw site legitiem is en onder toezicht staat van een erkende organisatie.
Om een SSL/TSL-verbinding te maken moet één of beide partijen een certificaat hebben, dat de begin- en eindatum van de geldigheid bevat, de naam van het gecertificeerde object en een digitale "handtekening" die de geldigheid bevestigt. Naast deze identificatiefunctie zijn certificaten ook gekoppeld aan een "privésleutel" die gebruikt wordt voor versleuteling (zie hieronder). In HTTPS-communicatie (versleuteld webbrowsen, aangeduid door URL's die beginnen met "https"), levert de server altijd een certificaat; de ontvanger (client) kan dat ook doen, hoewel client-certificaten nog niet gebruikelijk zijn.
Versleuteling met een publieke sleutel: de verkorte versie -- Reguliere (symmetrische) versleuteling werkt door gebruik te maken van een sleutel (een wachtwoord) om de tekst wiskundig om te zetten in abracadabra. Alleen hetzelfde wachtwoord kan gebruikt worden voor het omgekeerde proces om de oorspronkelijke tekst weer terug te krijgen. Symmetrische versleuteling vereist echter dat beide partijen het wachtwoord kennen, alsmede de algoritmes voor versleuteling en ontsleuteling, en dat ze het wachtwoord voor iedereen geheimhouden. Dit werkt natuurlijk niet op grote schaal: het is onmogelijk om iedere persoon of organisatie waarmee wordt gecommuniceerd te bezoeken, een nieuw geheim wachtwoord te maken en dat wachtwoord te gebruiken om met die partij te communiceren. Het opstellen en bijhouden van een uniek en geheim wachtwoord voor elke bank, verkoper op internet en groepssite zou uiterst ingewikkeld zijn.
Daarentegen gebruikt encryptie met publieke sleutels (ook wel asymmetrische of privésleutel-cryptografie genoemd) gepaarde sleutels (een "publieke" en een "privé"-sleutel), waarvan de een de werking van de ander kan opheffen. Met andere woorden, gegevens die versleuteld zijn met een publieke sleutel kunnen alleen ontcijferd worden met de bijbehorende privésleutel, en gegevens die versleuteld zijn met een privésleutel kunnen alleen ontcijferd worden met de publieke sleutel die daar bij hoort. Dit is een vreemd concept voor hen die bekend zijn met symmetrische encryptie, maar het is erg nuttig, omdat gepaarde sleutels verschillende problemen wat betreft privacy en identificatie oplossen.
Bezit van een privésleutel kan een identiteit "bewijzen": in de regel kan alleen de maker van een privésleutel daarmee versleutelen en ontcijferen (privésleutels worden nooit gedeeld). Bij wijze van supersimpel voorbeeld, stel je een klant voor van de Citibank die haar privésleutel gebruikt om haar rekeningnummer te versleutelen en dat verstuurt naar www.citibank.com. Als Citibank haar publieke sleutel in een bestand heeft staan en dat heeft gekoppeld aan een rekening, geeft een succesvolle ontcijfering de verzekering dat degene die het versleutelde rekeningnummer heeft verstuurd de juiste klant is - privésleutels zijn veel moeilijker te stelen of te vervalsen dan handtekeningen van inkt op papier. Het is mooi meegenomen dat digitale handtekeningen onmiddellijk over het internet werken.
Digitale handtekeningen hebben een hoogst ongewoon kenmerk. De meeste geheimen lekken uit als ze te veel gebruikt worden, maar digitale handtekeningen (en privésleutels in het algemeen) worden waardevoller bij veelvuldig gebruik, omdat ze geloofwaardigheid opbouwen. In de publieke-sleutelterminologie heet dit "vertrouwen". Privésleutels beginnen zonder enig vertrouwen, aangezien niemand weet dat een specifieke privésleutel feitelijk bij een bepaalde persoon hoort, en ze kunnen op een aantal manieren vertrouwen opbouwen:
In werkelijkheid is het sturen van rekeningnummers geen goed gebruik van encryptie, want als een aanvaller zowel de versleutelde "codetekst" (waarvan we moeten aannemen dat die onderschept kan worden - als we wisten dat niemand onze communicatie kon aftappen, hadden we geen encryptie nodig!) als de onversleutelde "gewone tekst" kent, zou het hem kunnen helpen een correlatie te vinden tussen de twee en zo de versleuteling te doorbreken. Echte encryptie heeft echter de neiging om veel willekeurige nummers en tijdelijke sleutels te gebruiken, ter verdediging tegen "bekende gewone tekst"-aanvallen.
Helaas is het eigenlijke proces van versleutelen en ontcijferen met behulp van privé- en publieke sleutels nogal langzaam: het is veel ingewikkelder rekenwerk dan conventionele algoritmes met een enkele sleutel, vanwege de exotische wiskundige fundamenten van asymmetrische algoritmes bij encryptie met publieke sleutels. De meeste encryptiesystemen met publieke sleutels (inclusief SSL/TLS) versleutelen de gegevens die uitgewisseld moeten worden feitelijk met symmetrische encryptie, wat snel en efficiënt is. Asymmetrische encryptie wordt gereserveerd voor het uitwisselen van de symmetrische sleutels voor kortdurend gebruik. De toegevoegde waarde is dat deze combinatie crypto-analyse onmogelijk maakt doordat er geen grote hoeveelheden gegevens die met een enkele sleutel zijn bewerkt (die geanalyseerd zouden kunnen worden) worden verstuurd. Symmetrische sleutels worden alleen voor korte tijd gebruikt en daarna weggegooid, terwijl asymmetrische sleutels alleen worden gebruikt voor de uitwisseling van symmetrische sleutels, eerder dan voor gegevens van gebruikers.
Stel je dit geïdealiseerde en vereenvoudigde voorbeeld voor:
We mogen hierbij niet vergeten dat ik dezelfde procedure kan gebruiken met veel verschillende websites, waarbij ik de sessiesleutels na gebruik weggooi en dezelfde privésleutel voor al mijn communicatie kan hergebruiken.
Zoals ik al zei is dit een geïdealiseerd voorbeeld van hoe het online aanmaken van een bankrekening zou kunnen werken. Banken en klanten wisselen voor het aanmaken van een nieuwe bankrekening niet echt hun publieke sleutels uit, maar werken nog altijd met wachtwoorden en soms ook andere methoden zoals krasvellen met wachtwoorden en fysieke wachtwoordgenerators, zogenaamde "hard tokens" (voorbeelden hiervan zijn de digipas en de SecurID sleutelhanger). In de toekomst zou de uitwisseling van publieke sleutels als onderdeel van het openen van rekeningen een sterke cryptografische identificatie en beveiligde communicatie kunnen bieden. In de bankwereld zijn sommige onderdelen momenteel al in gebruik voor onderlinge communicatie, maar doorgaans niet voor communicatie met de klant.
Maar hoe identificeert het hebben van een publieke en een privésleutel mij? Iedereen zou een set sleutels kunnen genereren en zo maar een identiteit kunnen aannemen. Certificaten zijn één van de mogelijke antwoorden op deze vraag. Een certificaat combineert drie elementen: 1) identificatie, 2) een publieke sleutel en 3) externe verzekering. We zullen nu zien hoe deze elementen kunnen worden gecombineerd om sleutels nuttig te maken in de echte wereld.
Wie vertrouw je? Als je weet dat een publieke sleutel eigenlijk niet meer dan een groot getal is, hoe kan een publieke sleutel dan in verband worden gebracht met een persoon of een bedrijf? Ik zou een certificaat kunnen aanmaken en beweren dat het van de paus is. Er moet met andere woorden een vorm van controle zijn. SSL/TLS doet dit met vertrouwde certificaatautoriteiten, waarbij een vertrouwde partij garant staat voor een bepaald certificaat. Elke webbrowser heeft zijn eigen bundel vertrouwde "root"-SSL/TLS-certificaten, en de browser vertrouwt elk certificaat dat ondertekend is door een van deze root-certificaten.
Bovendien kunnen de entiteiten die de eigenaar zijn van deze certificaten ("certificaatautoriteiten" of "CA's") hun vertrouwen delegeren aan andere bedrijven, waarbij "intermediaire" certificaten worden ondertekend die dan ook worden vertrouwd om andere certificaten te ondertekenen; deze hiërarchie van vertrouwen wordt een "certificaatketen" genoemd. Zolang je alleen websites bezoekt die zijn gecertificeerd door CA's die (rechtstreeks of onrechtstreeks) door je browsers vertrouwd worden, hoef je je hier geen zorgen over maken. Maar als je buiten de lijnen wilt kleuren, wordt het wel wat ingewikkelder.
CA's zijn natuurlijk niet de enige manier om vertrouwen te wekken. PGP/GPG (Pretty Good Privacy/GNU Privacy Guard, populaire gereedschappen voor cryptografie met publieke sleutels) werkt met een concept van een "web van vertrouwen", waarbij in plaats van commerciële autoriteiten de gebruikers zelf elkaars publieke sleutels ondertekenen.
SSL voor surfers -- In de echte wereld wordt SSL/TLS om twee redenen gebruikt: privacy en identiteitsgarantie. Ten eerste helpt de encryptie te voorkomen dat criminelen bij elektronische communicatie kunnen meelezen, en het voorkomt vooral dat wachtwoorden worden opgevangen die toegang bieden tot e-mail, PayPal, bankrekeningen, enz. Ten tweede bieden SSL/TLS-certificaten een vrij goede garantie dat een website met het hangslotpictogram van de browser echt en betrouwbaar is.
Wie gevoelige informatie invoert op een website, ongeacht of dat nu een kredietkaartnummer, telefoonnummer, adres of een anonieme tirade is, controleert best of hij "https" in de url ziet staan en zou waarschuwingen over verlopen certificaten, certificaten met een verkeerde naam of andere niet-vertrouwde certificaten ernstig moeten nemen. Als je browser je over een site waarschuwt, neem die waarschuwing dan **alsjeblieft** ernstig op, en beslis of dit betekent dat je ergens anders heen moet gaan of dat je verdergaat met je ogen goed open.
Helaas zijn er gemakkelijker manieren om met SSL/TLS beveiligde websites aan te vallen dan door de versleuteling echt te kraken. Dit kan bijvoorbeeld ook door een nieuwe site te maken met een naam die sterk lijkt op een echte populaire site (in een vreemd alfabet kunnen zij visueel zelfs niet te onderscheiden zijn van de echte naam), of door een hangslotpictogram op de webpagina te zetten. De browser geeft dit pictogram gewoonlijk weer buiten de HTML-zone, en een vergrendeld slot binnen de HTML-zone van de pagina is bedacht door iemand die wilt dat je deze site vertrouwt, maar geen garantie van je browser dat deze site te vertrouwen is. Soms zien de mensen niet dat het slot op de verkeerde plaats staat en vertrouwen zij de site blindelings. De teleurstelling volgt vaak niet lang daarna.
Om de SSL/TLS-certificaatdetails te zien van een website, benader je de site in een webbrowser (URL's van SSL/TLS-websites beginnen met "https://") en klik je op het hangslotpictogram (Safari toont deze in de rechterbovenhoek, Firefox en Internet Explorer gebruiken de rechteronderhoek). Apples certificaat voor https://store.apple.com/ is bijvoorbeeld uitgegeven door het "VeriSign Trust Network" en ondertekend door "VeriSign, Inc". Dat VeriSign-certificaat is op zijn beurt weer ondertekend door VeriSigns "Class 3 Public Primary Certification Authority". Het "Class 3"-rootcertificaat wordt tegenwoordig door de meeste browsers vertrouwd. In Mac OS X kun je dit certificaat in Sleutelhangertoegang zien, in de "X509Anchors"-sleutelhanger (SSL/TLS-certificaten zijn gebaseerd op de X.509-standaard voor digitale certificaten). Firefox slaat zijn bundel X.509-rootcertificaten op in zijn programmapakket, omdat Firefox de Apple sleutelhanger niet gebruikt. Omdat het Class 3-certificaat ingebouwd is, zien Safari- en Firefoxgebruikers het hangslotsymbool in plaats van enge waarschuwingen bij het benaderen van SSL/TLS-sites die geautoriseerd zijn door dat Class 3-certificaat, zoals https://store.apple.com/.
SSL/TLS is niet beperkt tot het beveiligen van websites. Om veiliger te zijn kan e-mailcommunicatie ook versleuteling toepassen en SSL/TLS is een van de eenvoudigste manieren om dit te bewerkstelligen. Helaas is er een grote variatie in SSL/TLS-ondersteuning en server-naar-server SMTP-verbindingen worden zelden versleuteld. Aan de andere kant ondersteunen Apple Mail, Apples .Mac-maildienst en Mac OS X Server alle SSL/TLS voor veilige IMAP, hoewel .Mac helaas geen SSL/TLS-ondersteuning heeft voor webmail. Om een Mail-account te configureren om SSL/TLS te gebruiken voor het ophalen van e-mail, open je de Voorkeuren, klik je op Accounts, kies je het gewenste account en klik je op de tab Geavanceerd. Vink daar "Gebruik SSL" aan. Als je mailserver werkt via een aparte IMAP/SSL- of POP/SSL-poort (zoals Mac.com), geef dan het juiste poortnummer op (993 voor IMAP/SSL of 995 voor POP/SSL). Om het versturen van mail te versleutelen, klik je op de tab Accountinformatie, dan op de knop Serverinstellingen onder "Server uitgaande post (SMTP)" en vink je optie "Gebruik Secure Sockets Layer (SSL)" aan. Als je een speciale poort nodig hebt voor SMTP, is dat waarschijnlijk 587 (dit werkt voor Mac.com).
[Bekijk afbeelding]
[Bekijk afbeelding]
Verkrijgen van een certificaat voor je site -- Om een beveiligde website op te zetten, heb je eerst een publiek/privé-sleutelpaar nodig. Houd je privésleutel geheim en deel deze nooit met een ander. Vervolgens combineer je de publieke sleutel met je identificatie-informatie, waaronder de domeinnaam en eigenaar van de site, om een "certificate signing request" (CSR) [verzoek tot ondertekening van een certificaat - nvdv] te creëren. CSR's zijn zelf niet bruikbaar voor versleuteling, maar het proces van het ondertekenen van een CSR creëert een X.509-certificaat, dat een site identificeert en de claim van betrouwbaarheid (de ondertekening), en verbindt de publieke sleutel van de site met de privésleutel (normaliter opgeslagen in een afzonderlijk bestand).
Als een CA (meestal een commercieel beveiligingsbedrijf) een CSR ontvangt, wordt die bekeken om vast te stellen of het verzoek acceptabel is. Is het juist opgesteld? Is het verzoek gedaan door een klant die de autorisatie heeft om verzoeken voor die domeinnaam uit te geven en die in goede financiële doen is? Als het verzoek alle controles van de CA doorstaat, die erg kunnen variëren tussen de verschillende organisaties, voegt de CA aanvullende informatie toe zoals de uitgifte- en verloopdatum (hetgeen verzekert dat oude certificaten niet oneindig doorlopen en ook dat de CA's geld blijven verdienen) en ondertekent het geheel (CSR-gegevens, CA-gegevens en de door de klant verstrekte publieke sleutel). Dit leidt tot het certificaat, dat de CA dan terugstuurt naar de klant, geformatteerd voor de specifieke software die de aanvrager gebruikt. Componenten van Mac OS X Server (om precies te zijn de ingebouwde Apache-webserver, Cyrus- en Postfix-mailservers en Jabber-chatserver) gebruiken allemaal dezelfde certificaatformaten en kunnen certificaten uitwisselen. Een certificaat is natuurlijk nutteloos zonder de bijbehorende privésleutel (gemaakt met de CSR), omdat het certificaat gebaseerd is op een specifieke publieke sleutel.
Omdat de CA's garant staan voor de identiteit van de eigenaar van het certificaat, hebben ze de neiging kieskeurig te zijn over de details van het certificaatverzoek. Een spelfout in een naam kan de uitgifte van een certificaat vertragen en aanvragen voor certificaten onder verschillende bedrijfsnamen kan zelfs nog lastiger worden.
Omdat mensen ondertekende certificaten vertrouwen bij het identificeren van websites en de bescherming van de vertrouwelijkheid, moeten SSL/TLS-sleutels (het geheime gedeelte) geheim en veilig gehouden worden. Als je sleutel verloren gegaan is, kan het je in het beste geval een paar honderd dollar kosten en ben je offline tijdens het aanvragen van een gloednieuwe CSR, privésleutel en certificaat. In het slechtste geval, als een vijandige partij (een cracker, een FBI-agent, of je ex) een kopie bemachtigt van je SSL/TLS-certificaat en privésleutel, kan die of zich voordoen als de echte site, of alle vermeend veilige communicatie ontrafelen die naar die site gezonden wordt, de droom van elke "phisher". Er is een standaard van de federale overheid van de Verenigde Staten (FIPS 140) die beschrijft hoe om te gaan met het beveiligen van dergelijke vertrouwelijke gegevens. De standaard beschrijft hardware waarmee niet geknoeid kan worden en autorisatie voor meerdere partijen, maar de meeste mensen beveiligen hun privésleutels met of een wachtwoord dat opgegeven moet worden om de SSL/TLS-dienst te starten na een herstart, of door eenvoudigweg de computer te beschermen die de niet-versleutelde sleutel bevat, waarmee opnieuw gestarte computers het uitvoeren van SSL/TLS-diensten kunnen hervatten (inclusief HTTPS-websites) zonder menselijke interventie. Dit is belangrijk om over na te denken dat bij de eerste stappen in SSL/TLS en dit geldt in het bijzonder voor certificaat-autoriteiten.
Als je privésleutel gestolen wordt, krijg je een heel gecompliceerde situatie. Als je je auto- of huissleutels verliest, is dat vervelend, maar sloten vervangen is rechttoe rechtaan. Het equivalent bij SSL/TLS is het herroepen van het certificaat, daarna moet je doorgeven dat het sleutelpaar gecompromitteerd is en anderen informeren om het niet meer te gebruiken. Jammer genoeg is een dergelijke herroeping om verschillende redenen buitengewoon lastig. Ten eerste moet een herroeping even zorgvuldig worden behandeld als de ondertekening van een certificaat - het zou immers niet acceptabel zijn als een concurrent het SSL/TLS-certificaat van Amazon zou kunnen herroepen. Bovendien, de privésleutel is slechts in heel beperkte kring bekend: wat doe je dan als de computer waar de enige kopie van de sleutel op staat, wordt gestolen? Tenslotte bevat het ontwerp van SSL/TLS helemaal geen aannames of eisen over tijdslimieten, maar wanneer een certificaat eenmaal gecompromitteerd is, dan moet het wel worden herroepen voordat iemand met het gestolen certificaat en de sleutel fraude kan plegen. Gevolg is dat er weliswaar veel herroepingssystemen bestaan, maar dat ze nauwelijks worden gebruikt.
Als je privésleutel gestolen wordt, krijg je een heel gecompliceerde situatie. Als je je auto- of huissleutels verliest, is dat vervelend, maar sloten vervangen is rechttoe rechtaan. Het equivalent bij SSL/TLS is het herroepen van het certificaat, daarna moet je doorgeven dat het sleutelpaar gecompromitteerd is en anderen informeren om het niet meer te gebruiken. Jammer genoeg is een dergelijke herroeping om verschillende redenen buitengewoon lastig. Ten eerste moet een herroeping even zorgvuldig worden behandeld als de ondertekening van een certificaat - het zou immers niet acceptabel zijn als een concurrent het SSL/TLS-certificaat van Amazon zou kunnen herroepen. Bovendien, de privésleutel is slechts in heel beperkte kring bekend: wat doe je dan als de computer waar de enige kopie van de sleutel op staat, wordt gestolen? Tenslotte bevat het ontwerp van SSL/TLS helemaal geen aannames of eisen over tijdslimieten, maar wanneer een certificaat eenmaal gecompromitteerd is, dan moet het wel worden herroepen voordat iemand met het gestolen certificaat en de sleutel fraude kan plegen. Gevolg is dat er weliswaar veel herroepingssystemen bestaan, maar dat ze nauwelijks worden gebruikt.
Alles over certificaat-autoriteiten -- Een certificaat-autoriteit is verantwoordelijk voor de controle dat elke aanvraag inderdaad afkomstig is van de entiteit die in het certificaat wordt omschreven, dat die organisatie ook de wettige eigenaar is van het domein, en dat de aanvrager bevoegd is om de aanvraag in te dienen. De details van wat hiervoor vereist is en hoe dat worden gecontroleerd verschillen sterk van de ene CA tot de andere.
Er bestaan veel CA's, maar het is lastiger om met een nieuwe CA te werken dan met een meer gevestigde autoriteit. "Meer gevestigd" betekent in dit geval gebundeld met meer browsers, want als een browser op een site met een onbekend certificaat komt, laat hij een met opzet angstaanjagende waarschuwing zien die zegt dat de veiligheid niet gegarandeerd is. Niemand wil dat dit het eerste is waar een gebruiker die op zijn website komt tegenaan loopt - vooral als het om online-verkoop gaat. Dit geldt evenzeer voor zelf ondertekende certificaten, en voor certificaten die zijn ondertekend door private CA's (zoals universiteiten en bedrijven voor intern gebruik), en voor certificaten die zijn ondertekend door startende commerciële CA's die nog niet zijn gebundeld met de specifieke browser van de gebruiker.
Microsoft introduceerde met Internet Explorer 7 "Extended Validation" (EV) voor "High Assurance" SSL/TLS certificaten. Hiermee worden additionele controles op alle EV-CSR's en websites uitgevoerd met de bedoeling een beetje orde te scheppen in het soms nogal chaotische aanbod aan CA's en CA-huisregels. Mozilla heeft verklaard dat Firefox EV-certificaten zal ondersteunen en men verwacht dat Safari dit ook gaat doen. Deze certificaten zijn natuurlijk duurder. EV-certificaten worden door de CA's bijzonder op prijs gesteld, omdat dit een gelegenheid is om de prijs van de certificaten weer te verhogen, nadat ze eerder door concurrentie omlaag waren gegaan.
Alles over certificaat-autoriteiten -- Een certificaat-autoriteit is verantwoordelijk voor de controle dat elke aanvraag inderdaad afkomstig is van de entiteit die in het certificaat wordt omschreven, dat die organisatie ook de wettige eigenaar is van het domein, en dat de aanvrager bevoegd is om de aanvraag in te dienen. De details van wat hiervoor vereist is en hoe dat worden gecontroleerd verschillen sterk van de ene CA tot de andere.
Er bestaan veel CA's, maar het is lastiger om met een nieuwe CA te werken dan met een meer gevestigde autoriteit. "Meer gevestigd" betekent in dit geval gebundeld met meer browsers, want als een browser op een site met een onbekend certificaat komt, laat hij een met opzet angstaanjagende waarschuwing zien die zegt dat de veiligheid niet gegarandeerd is. Niemand wil dat dit het eerste is waar een gebruiker die op zijn website komt tegenaan loopt - vooral als het om online-verkoop gaat. Dit geldt evenzeer voor zelf ondertekende certificaten, en voor certificaten die zijn ondertekend door private CA's (zoals universiteiten en bedrijven voor intern gebruik), en voor certificaten die zijn ondertekend door startende commerciële CA's die nog niet zijn gebundeld met de specifieke browser van de gebruiker.
Microsoft introduceerde met Internet Explorer 7 "Extended Validation" (EV) voor "High Assurance" SSL/TLS certificaten. Hiermee worden additionele controles op alle EV-CSR's en websites uitgevoerd met de bedoeling een beetje orde te scheppen in het soms nogal chaotische aanbod aan CA's en CA-huisregels. Mozilla heeft verklaard dat Firefox EV-certificaten zal ondersteunen en men verwacht dat Safari dit ook gaat doen. Deze certificaten zijn natuurlijk duurder. EV-certificaten worden door de CA's bijzonder op prijs gesteld, omdat dit een gelegenheid is om de prijs van de certificaten weer te verhogen, nadat ze eerder door concurrentie omlaag waren gegaan.
De prijzen variëren flink tussen de verschillende certificaatauthoriteiten. VeriSign is één van de grootste en duurste: het vroeg vorig jaar $1.000 voor een 128-bits certificaat, of $1.500 met EV. Toen Thawte onder de prijzen van VeriSign ging zitten en daarmee het marktaandeel van VeriSign bedreigde, kocht VeriSign Thawte op, maar het merk bleef bestaan en goedkopere certificaten aanbieden. Thawte vraagt $700 of $900 (met of zonder EV) voor 128-bits certificaat dat een jaar geldig is, maar het installeren van een Thawte-certificaat is ingewikkelder omdat er een intermediair certificaat geïnstalleerd moet worden; dit lijkt een poging van VeriSign om te zorgen de goedkopere Thawte-certificaten minder handig in het gebruik zijn dan die van VeriSign. Recentelijk bedreigde GeoTrust de populariteit van VeriSign toen het 128-bits certificaten ging aanbieden voor $180 (ook voor een jaar), en opnieuw kocht VeriSign de concurrent op, waardoor die niet meer onder de prijs van de VeriSign EV-certificaten kon gaan zitten. Toch bestaan goedkopere opties nog steeds, zoals RapidSSL, waar een certificaat slechts $62 kost.
Omdat certificaten zo duur zijn, bieden CA's verschillende kortingen op langlopende certificaten of op de aanschaf van meerdere certificaten tegelijkertijd, en wanneer je een certificaat wilt verlengen is dat meestal goedkoper. De meeste CA's sturen dan ook herinneringen aan hun gebruikers om te vernieuwen voordat de certificaten verlopen, en meestal kun je ook vóór het verlopen van het certificaat het al vernieuwen zonder dat je ongebruikte tijd kwijt bent. Als je te laat bent, kan dat pijnlijk zijn omdat bezoekers van je website dan gevraagd worden of ze de website in kwestie vertrouwen. Je kunt natuurlijk ook zelf de verloopdata van de certificaten in een agenda zetten.
Alle CA's bieden dezelfde basale dienst van het ondertekenen van CSR's om vertrouwde certificaten aan te maken, maar er zijn veel variabelen, zoals de reputatie van een CA, de complexiteit van het certificeringsproces, het gemak van installatie en gebruik van certificaten, het gebruiksgemak bij de toegang tot gecertificeerde sites en de huisregels van de CA. In een poging om hun prijzen te verantwoorden, bieden veel CA's garanties voor de integriteit van de certificaten (en op die manier voor de bijbehorende websites), zoals het Secured Seal-programma van VeriSign.
Welk soort certificaten zou je moeten gebruiken? Publieke online-winkelsites en sites die omgaan met zeer gevoelige informatie zouden 128-bits commerciële certificaten moeten gebruiken. De details van welk certificaat je moet aanschaffen zijn afhankelijk van de site zelf, maar het is de moeite waard om in gedachten te houden dat de belangrijkste verschillen zitten in het vertrouwen van de bezoeker (EV-certificaten, goed bewaarde sleutels, enzovoort) en het gebruiksgemak voor de beheerder, terwijl het feitelijke proces van ondertekenen vrijwel hetzelfde is voor alle CA's. Denk eraan dat je de privé- en publieke sleutels zelf levert; de CA stelt zich garant voor de eigenaar van een certificaat, maar is niet betrokken bij de versleuteling. All 128-bits SSL/TLS-certificaten zijn cryptografisch gezien gelijk, hoewel de verschillende browsers EV-sites verschillend behandelen.
Alternatieven voor commerciële CA's -- Er zijn alternatieven voor het betalen van tot $1.500 per jaar aan een CA om je certificaat getekend te krijgen. Allereerst kun je zelf een nieuw CSR aanmaken en dit gebruiken om zichzelf te ondertekenen; zo'n 'zelf-ondertekend' certificaat kent niet de verzekering van authenticiteit door een derde partij, maar geeft wel precies dezelfde beveiliging als een "echt" certificaat met een ondertekening. Wanneer je slechts één of twee domeinen hebt (certificaten zijn over het algemeen gebonden aan domeinnamen), of sites waarbij het vertrouwen van de consument niet erg belangrijk is, is het gebruik van zelfgetekende certificaten een goede optie. Het is perfect voor persoonlijke sites, waarvoor een paar honderd dollar wellicht weggegooid geld is. Zelfs voor sites die geen SSL/TLS-toegang bieden is de beveiliging van de beheerderstoegang (voor het updaten van blogs, het online bekijken van statistieken, enzovoort) een perfect gebruik voor zelfondertekende certificaten.
Wanneer je veel sites hebt, bij bijvoorbeeld een universiteit of een bedrijf, is het wellicht verstandiger om je eigen CA te creëren en die te gebruiken voor het ondertekenen van individuele certificaten, zodat je helemaal geen CA-kosten hebt. Het nadeel is dat bezoekers aan je sites te maken krijgen met veiligheidswaarschuwingen in hun browsers, en je certificaat handmatig moeten vertrouwen. De procedures voor het omgaan met privé-CA's verschillen van browser tot browser, en omdat criminelen ook hun eigen CA's kunnen aanmaken, maken sommige browsers het met opzet moeilijk om zo'n CA te vertrouwen. Gebruikers hoeven dat echter maar één keer te doen en krijgen daarna nooit meer een waarschuwing over onbetrouwbare certificaten, tenzij ze een andere browser of computer gaan gebruiken, dan moeten ze het proces herhalen.
Als je voor deze weg kiest, zou je eerst serieus moeten nadenken over zowel de electronische als fysieke veiligheid van de sleutel van je root-certificaat, en daarbij backups en veranderingen in je personeelsbestand niet vergeten. CA zijn is gelukkig niet veel ingewikkelder dan een certificaat zelf ondertekenen, hoewel het helpen van gebruikers bij het installeren van root-certificaten in sommige browsers met opzet gecompliceerder gemaakt is dan het eenvoudigweg vertrouwen van een zelfondertekend certificaat.
Het opzetten van je eigen privé-CA kost niets: het gratis OpenSSL kan het allemaal doen. Het vraagt tijd om de procedures te leren en extra inzet voor de beveiliging van de root-sleutel, die de veiligheids-spil is voor alle afgeleide certificaten. De details vallen buiten het bereik van dit artikel, maar er zijn meerdere online bronnen als startpunt, en de procedure kan vrij doeltreffend geautomatiseerd worden.
OpenSSL omvat CA.pl, een Perl script om deze taken te automatiseren; het is effectief maar niet perfect. Omdat ik ontevreden was over CA.pl en de manuele procedures, heb ik twee simpele scripts gemaakt, cert.command om nieuwe certificaten te maken en te ondertekenen en sign.command om bestaande certificaten te ondertekenen. Bij beide scripts geef ik de hostnaam twee keer, voer ik het wachtwoord van de root-sleutel in, en druk een aantal keren op Return; de rest gaat automatisch.
Zeker in mijn conclusies -- SSL/TLS is natuurlijk niet de enige manier om web- en e-mailcommunicatie op het internet te beveiligen, maar het doet iedere dag zijn nuttige werk voor miljoenen mensen en beschermt kredietkaartnummers, online bankverkeer, e-mail en meer. Voor gewone gebruikers wekt het zien van het hangslotpictogram en van "https" in URL's het vertrouwen dat SSL/TLS ons beveiligt. Alhoewel de technologie achter SSL/TLS beslist onder cryptografie valt (het software-equivalent van atoomfysica), zijn de kosten en inspanning die nodig zijn voor de implementatie binnen het bereik van alle administrateurs die in staat zijn een webserver te bedienen.
[Chris Pepper is een Unix System Administrateur in New York City. Hij is nog steeds in zijn schik dat Mac OS X een prima management-werkstation gebleken is voor de Unix-systemen waar hij mee werkt. In Chris zijn onzichtbare signatureblok staat "Het web bewerken, met één pagina tegelijk". Na zijn hoofd gebroken te hebben over de onderwerpen die in dit artikel besproken worden, heeft Chris een aanvullend artikel geschreven over hoe het CA.pl-script van OpenSSL te gebruiken (waaronder met Mac OS X) om SSL/TLS-certificaten te beheren. Ook heeft hij een paar dubbelklikbare scripts ontwikkeld die helpen bij het laten draaien van een eigen CA.]
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
[De discussies waarnaar verwezen wordt zijn in het Engels, daarom hebben we de titels niet vertaald - Tb-NL.]
Demand for iPhone -- Is het doel van Apple om 10 miljoen iPhones tegen het eind van 2008 te verkopen een realistisch aantal, of is het aantal opzettelijk laag om zeker te zijn dat Apple dit doel zal bereiken? En wanneer zullen we iPhones in andere landen zien? (13 berichten)
1Passwd Eases Password Pain -- Als reactie op een artikel van Joe Kissell over 1Passwd bespreken lezers Palm-synchronisatie. (8 berichten)
Thoughts spurred by Loki, Google Street Views, etc. -- Gaan deze locatiebewuste programma's over de schreef in jouw persoonlijke privacy? (2 berichten)
Replacing Eudora -- Mail? Thunderbird? En is er iets dat gemakkelijk Eudora's mogelijkheid kan nabootsen om specifieke berichten in nieuwe vensters te openen wanneer ze binnenkomen? (7 berichten)
YouTube Comes to iPhone and Apple TV -- Heeft er iemand een probleem gehad met Apple TV en een router die UPnP niet aan heeft staan? (1 bericht)
imagining iPhone -- Een lezer fantaseert over winkelen in de toekomst, waarin specifieke gegevens worden verstuurd naar iemand zijn iPhone terwijl die persoon aan het winkelen is. (2 berichten)
imagining iPhone -- A reader imagines a future buying experience where custom data is piped into one's iPhone while shopping. (2 berichten)
Bladwijzer bij: del.icio.us | digg | reddit | Slashdot | Yahoo! MyWeb
Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering
