OCSP stapling uitgelegd: hoe controleer je of een SSL-certificaat nog geldig is?

Alles wat een begin heeft, heeft ook een eind. Voor een SSL-certificaat is dat niets anders. Bij het aanmaken van zo’n certificaat staat de geldigheidsduur vast. Maar wat als voor het verstrijken van de einddatum er een probleem is met het certificaat? Hoe communiceer je dat naar webbrowsers? Met OCSP stapling!

Met behulp van OCSP stapling de geldigheid van een certificaat controleren

UPDATE
Sinds 11 april 2017 hebben alle domeinnamen, subdomeinen, aliassen en pointers bij Antagonist gratis SSL en HTTP/2 gekregen. Dit geldt voor iedere klant, ongeacht hun webhostingpakket, inclusief Resellers. Lees hier meer!

Allereerst kan de geldigheidsduur van een certificaat verschillen. Er zijn certificaten met een geldigheidsduur van bijvoorbeeld drie jaar, maar ook met een geldigheidsduur van drie maanden. Een voordeel van een lange geldigheidsduur is natuurlijk dat je er al die tijd niet meer naar om hoeft te kijken. Maar wat als je op een gegeven moment niet wilt dat het certificaat nog langer geldig is? Bijvoorbeeld, doordat iemand anders de private key in handen heeft gekregen of omdat het domein van eigenaar verandert? Je wilt dan een certificaat intrekken.

Hoe trek je een certificaat in?

Als je jouw certificaat van je domein verwijdert, dan is deze natuurlijk weg. Echter, in het geval dat iemand anders jouw certificaat heeft weten te bemachtigen, is dat natuurlijk geen optie. Je wilt dan dat het certificaat niet meer geldig is. Je moet dus op een of andere manier aan de wereld laten weten dat je certificaat niet meer te vertrouwen is. Gelukkig bestaan hiervoor verschillende opties, waaronder:

  • Certifcate Revocation List (CRL);
  • Online Certificate Status Protocol (OCSP).

Verder lezen

File system caching bij Antagonist!

Caching is de laatste tijd een populaire term en wordt vaak in de algemene zin gebruikt. Deze techniek kan echter op verschillende niveau’s plaatsvinden, zoals op applicatie- of file system-niveau. Wanneer er gesproken wordt over caching voor een website, dan vindt dit plaats op applicatie-niveau. Daar gaan we het nu niet over hebben. Aan caching binnen applicaties kun je namelijk al een volledig artikel wijden, wie weet iets voor later 😉 We duiken daarom nu een stukje dieper in het file system-niveau, en dan specifiek file system caching!

Filesystem caching bij Antagonist: hoe werkt het exact?

File system caching wordt gebruikt om het opvragen en wegschrijven van bestanden te versnellen door veel opgevraagde bestanden of ‘blocks’ (tijdelijk) op een ander, veel sneller medium te plaatsen. Bij Antagonist maken we gebruik van een cachingmechanisme dat anders is dan traditionele systemen. Het is niet alleen anders, want anders is per definitie niet beter. De caching die wij gebruiken, is vele malen sneller. Sneller is wel beter!

Een woord vooraf
Dit artikel is behoorlijke ‘technische hardcore’. Om ervoor te zorgen dat het zo goed mogelijk is te volgen, heb ik het zo gestructureerd mogelijk opgezet. Handig om te weten, is dat er een aantal termen zijn die ik willekeurig door elkaar gebruik, maar waarmee ik hetzelfde bedoel:

  • blocks, files en bestanden;
  • lezen, leestransacties en reads;
  • schrijven, schrijftransacties en writes;
  • disk, harddisk, schijf en harde schijf;
  • werkgeheugen en RAM.

Read en write caching

Het cachen van bestanden (file system caching) kan worden onderverdeeld in twee categorieën, namelijk: lezen (read caching) en schrijven (write caching).

Verder lezen

Netneutraliteit: hoe zit het precies?

Nederland was één van de eerste landen met een netneutraliteitswet. Dit moment is men in de Europese Unie bezig een EU-brede wet te ontwerpen die de neutraliteit van het internet afdwingt. Hier zitten nogal wat haken en ogen aan. In dit blog leg ik daarom graag uit wat netneutraliteit is, wat de voor- en nadelen zijn en wat de nieuwe EU-brede wet inhoudt.

Netneutraliteit uitgelegd: hoe zit het precies?

Netneutraliteit is het principe dat internetproviders al het verkeer op hun netwerk gelijk behandelen zonder het te blokkeren, vertragen of anderzijds te verstoren. Op papier klinkt het als een goed idee, maar de werkelijkheid is complex. Er zijn namelijk goede redenen voor providers om verkeer dat aan bepaalde eisen voldoet, anders te behandelen dan de rest. Dit maakt het lastig om een goede neutraliteitswet te maken. Laten we beginnen met wat achtergrondinformatie.

Bandbreedte en latency

De snelheid waarmee data over het internet wordt verstuurd, kan worden opgedeeld in twee aspecten: de ‘bandbreedte’ en de ‘latency’. Met bandbreedte wordt de hoeveelheid data die per seconde via een internetverbinding verstuurd wordt, bedoeld. Veelal wordt dit in megabits per seconden of Mb/s gemeten. Met latency wordt de tijd bedoeld die tussen het moment zit, waarop de zendende partij begint met zenden en de ontvangende partij de eerste data ontvangt.

Dit is te vergelijken met een tuinslang. Stel, je hebt een tuinslang waar twee liter water per seconde uitstroomt. Het maakt niet uit of die slang 10 of 100 meter lang is, zodra het water gaat stromen komt er twee liter per seconde uit. Dit is de bandbreedte van de tuinslang. We kunnen die snelheid verhogen door een dikkere slang te gebruiken (mits de kraan het water kan leveren). Echter, ongeacht de dikte (bandbreedte) van de slang, duurt het even voordat er water uitstroomt zodra je de kraan aanzet. Dit is de latency.

Netneutraliteit uitgelegd: bandbreedte en latency

Op het internet geldt ongeveer hetzelfde. De afstand tussen zender en ontvanger is grotendeels bepalend voor de latency. Andere factoren die een rol spelen zijn: het aantal routers tussen zender en ontvanger en het medium dat wordt gebruikt (bijvoorbeeld een satellietverbinding die een hoge latency heeft).

Verder lezen

Een pikdonker en doodstil datacenter…

Afgelopen dinsdag, 23 juni 2015, gebeurde rond 8:30 uur het ergste wat een hostingprovider kan overkomen: er was een volledige black-out in één van de datacenters, waarin wij het merendeel van onze servers hebben geplaatst. Het gevolg: alle apparatuur down en tienduizenden klanten onbereikbaar. Een fantastisch begin van de dag. Het kan nóg erger: totale verwoesting van het datacenter in kwestie, maar dat was gelukkig niet aan de orde. Wat dan wel? Nou, een stroomstoring…

Stroomuitval in het dataceter: pikdonker en doodstil

Ik hoor het je denken: “Hè, wat?! Dat kan toch niet? Alles in zo’n datacenter is beveiligd, dubbel uitgevoerd, heeft noodaggregaten en zo?” Inderdaad, dat is er allemaal en in veel gevallen zelfs vierdubbel uitgevoerd. In theorie kan stroomuitval dus niet voorkomen. Echter, door de meest ongelukkige samenloop van omstandigheden gebeurde het toch. Een goed voorbeeld van hoe theorie en praktijk soms ver uit elkaar liggen.

Naast dat het voor iedereen zeer vervelend is, was het voor ons ook een ultieme proef of we spoedig konden herstellen van zo’n grote storing. Daarnaast was het de vuurdoop voor ons nieuwe platform, waarin duidelijk werd of het in de praktijk deed wat het moest doen. Omdat jij ook recht hebt op deze informatie, hebben we hieronder een gedetailleerd verslag geschreven.

Inhoudsopgave

  1. Antagonist zegt sorry!
  2. Klein team, veel klanten
  3. Prioriteit tijdens calamiteit
  4. Hoe kan dat dan, geen stroom?
  5. De gevolgen voor Antagonist
  6. Opstarten na stroomuitval
  7. Nazorg, totdat alles weer in orde is
  8. Wat is de schade?
  9. Communicatie
  10. Hoe gaan we dit voorkomen?
  11. One more thing…

Antagonist zegt sorry!

Maar eerst zeggen we: “Sorry!” Een storing is altijd hinderlijk. Helemaal als klanten er de dupe van worden. Door de stroomstoring in het datacenter heeft ons gehele platform er even uit gelegen. Al onze klanten hebben daardoor downtime ondervonden. Daarnaast hebben enkele klanten langer last gehad vanwege herstelwerkzaamheden.

Het ‘uitvallen’ van de stroom heeft dus een behoorlijke impact. Dat vinden we erg vervelend en daarom bieden we onze excuses aan. Dat is tevens één van de redenen voor dit blog. Daarnaast willen we je een eerlijk en helder inzicht geven in wat er precies is gebeurd.

Tijdens de storing hebben we regelmatig updates geplaatst. Het waren vooral beknopte berichten over de voortgang van de situatie en het herstel. Daarnaast hebben we twee ‘post incident’-berichten geschreven. Deze gaven inzicht in de toedracht. De werkelijke gevolgen zijn voor een buitenstaander wellicht lastig voor te stellen. Vandaar dat we je graag een kijkje in de keuken geven, hoe het er dinsdag aan toe ging.

Klein team, veel klanten

Antagonist heeft tienduizenden klanten en 12 medewerkers. Zodoende moet je tijdens een grote storing, als een geoliede machine te werk gaan. Alles moet vanzelfsprekend zijn, want tijd is er niet. Met een klein en hecht team moet je handelen vanuit instincten. Juist daarom vinden we het zo belangrijk dat een medewerker goed moet passen binnen ons team. Naast de juiste kennis en vaardigheden zoeken we dus naar de perfecte match.

Als het misgaat, dan is het heel simpel. Er zijn drie dingen die er toe doen. Eén: onze klanten moeten zo snel mogelijk weer online. Twee: voorkom zoveel mogelijk schade en dataverlies. Drie: zorg voor een vlotte en oprechte communicatie, waarin vragen van klanten zorgvuldig worden beantwoord.

Qua prioriteit ligt het ietsje ingewikkelder. De hoogste prioriteit is bij Antagonist altijd data-integriteit. Dat betekent dat we het voorkomen van dataverlies belangrijker vinden dan beschikbaarheid. Je hebt immers niets aan een website zonder data. Gelukkig hoeven we ons daar weinig zorgen over te maken. Gegevens worden veilig opgeslagen. De kans op dataverlies is daardoor zeer gering. Zodoende storten we ons, tijdens een storing, vrijwel direct op de beschikbaarheid.

Prioriteit tijdens calamiteit

Goed, het is dinsdagochtend en we zien dat er heel veel loos gaat. De oorzaak weten we niet. Er was weliswaar een sterk vermoeden dat het om een (deels) falende stroomtoevoer gaat, maar dat kunnen we niet bevestigen. Dat is erg naar. Want hoe kun je iets oplossen, als je het probleem niet kent?

Verder lezen

Nieuwe veilige webhosting bij Antagonist

Zoals in het artikel over DNSSEC van vorige week kon lezen, werken we hard aan verbeteringen die bijdragen aan veiligheid. Op het internet speelt beveiliging immers een steeds grotere rol en mag daardoor zeker niet onderschat worden. Denk bijvoorbeeld aan beveiligingslekken die toenemen, aanvallen die vaker plaatsvinden en misbruik dat blijft stijgen. Uiteraard doe je er zelf alles aan om je website zo goed mogelijk te beveiligen. Maar wat als iemand anders, al dan niet bewust, de zaak om zeep dreigt te helpen? Je wilt natuurlijk niet dat een lek in de website van je ‘virtuele buurman’ een beveiligingsrisico voor jouw website vormt.

Veilige webhosting: containerisatie bij Antagonist

Om te begrijpen wat de gevaren zijn die je bij webhosting tegenkomt, en wat we daartegen kunnen doen, zullen we eerst een stukje de geschiedenis in moeten gaan. Mocht geschiedenis je niet zoveel interesseren, dan heb je geluk. Ik heb er een apart ‘hoofdstuk’ van gemaakt, zodat je eventueel kunt overslaan.

De geschiedenis van hosting

Lang, lang geleden (in internet-tijd) was het zo, dat als je iets op het internet wilde laten zien je een eigen server moest hebben. Uiteraard een fysieke, want van virtualisatie hadden we nog niet gehoord. Dit was natuurlijk veilig, want je had een hele server voor je alleen. Het was echter erg moeilijk en duur. Toen kwamen er mensen en die zagen een gat in de markt. Zij kochten servers en richtten die in. Er werden meerdere websites op deze servers gezet, waardoor de kosten per website naar beneden gingen. Anderen konden daar dus gebruik van maken, zonder dat het erg moeilijk en duur was. Dit was het begin van shared webhosting.

Veilige webhosting: de geschiedenis

Qua veiligheid was er toen nog niet zo’n groot probleem, want veel websites bestonden uit statische HTML. Daarnaast werd er weinig actief geprobeerd om websites binnen te dringen om wat voor reden dan ook. In de jaren die hierop volgden, werd het internet groter en groter. De kracht en potentie van het internet nam enorm toe en daardoor werden websites steeds meer een interessant doelwit. Langzaamaan zagen dynamische websites het licht, met behulp van bijvoorbeeld PHP. Door de extra functionaliteit, steeg de populairiteit enorm. Echter, kwam het de veiligheid zeker niet ten goede.

Veiligheid van shared webhosting

Shared hosting groeit dus enorm, maar wordt ook onveiliger. Stap voor stap wordt gekeken naar oplossingen. Dit beveiligen gebeurt op verschillende niveau’s. In dit voorbeeld ga ik ervan uit, dat een website met behulp van PHP is geschreven.

Verder lezen