Beveiliging

HTTP inruilen voor HTTPS, dat stond nog op het lijstje. Ik heb dat net in orde gebracht. De S staat namelijk voor Secure. Met andere woorden, wanneer je rondstruint doorheen mijn blog, dan doe je dat vanaf nu veilig.

Waarom is dat belangrijk? Omdat er op het web ook mensen en organisaties zijn met minder goede bedoelingen. Wanneer mijn webserver een pagina naar jouw computer stuurt, dan wil je zeker zijn dat er tijdens het transport niet mee werd geknoeid. Dankzij HTTPS weet jouw computer automagisch dat de pagina die hij/zij ontvangt, ook daadwerkelijke de pagina is die oorspronkelijk werd verzonden.

Maar Matthias, kan je een voorbeeld geven van dergelijk “geknoei”? Wel, wanneer je surft op een “Free WIFI hotspot” – op hotel, in het station, luchthaven, restaurant,… – dan benader je het web via een toegang waarvan je niet weet of ze wel veilig is. Je stelt je vertrouwen in de uitbater van de hotspot. Voor niets gaat natuurlijk de zon op, en sommige uitbaters durven al eens advertenties te “injecteren” in webpagina’s die jij opvraagt. Daar zijn gedocumenteerde cases van. Ondanks dat dat overduidelijk een schending is van je privacy, is dat nog relatief tam. Vandaar is het immers maar een kleine stap om code te injecteren waarmee je computer kan worden gehackt. (Wat meteen ook een pleidooi is om niet zomaar op elk open, gratis netwerk te surfen!)

Bij HTTPS worden de pagina’s die jij opvraagt van een server, versleuteld verstuurd naar je browser. Enkel diegene met de juiste sleutel kan de pagina openen.

HTTPS is dus duidelijk een Goede Zaak. Matt Mullenweg kondigde onlangs aan dat bepaalde features in WordPress in de toekomst waarschijnlijk enkel nog met HTTPS zullen werken. Google gaat sneller beveiligde sites in zijn zoekresultaten tonen dan onbeveiligde websites. En vanaf 2017 gaat Chrome onbeveiligde sites “shamen”.  Met andere woorden, het wordt in de toekomst zelfs een basisvereiste om op het web te publiceren met versleuteling.

Waarom deed ik dat dan niet eerder? Om van HTTPS gebruik te maken met je bij een externe service een digitaal certificaat aanvragen. Dat certificaat kost doorgaans iets te veel om geen pijn te doen. Sinds kort is er een gratis alternatief dat zeer snel aan populariteit wint: Let’s Encrypt. Mocht je dus HTTPS op je weblog willen activeren: dan is dit wat je wil gebruiken.

Kijkt! De gasten van WordPress hebben eindelijk versie 2.5 vrijgegeven. En ze hebben gelijk hun eigen website in een nieuw kleedje gestoken. Ik heb het gisteren wat in het Barcamp Gent geweld uit het oog verloren.

Deze versie heeft de bijnaam Brecker gekregen. Een eerbetoon aan saxofonist Michael Brecker. Met deze versie slaat WordPress weer een heel nieuwe richting in. Usability all the way want vooral het Dashboard heeft een grote upgrade gekregen. En natuurlijk ook een pak nieuwe gebruikersfuncties (EXIF uit foto’s halen, few-click plugin upgrades, ingebouwde galleries, easy file-upload,…) Daarnaast werd er verder gewerkt aan optimalisatie en beveiliging.

Ik ga de nieuwe versie zelf eerst even lokaal uitproberen en een aantal dagen wachten voor ik zelf de upgrade uitvoer. De kat uit de boom kijken, heet dat dan. Dit is immers een flinke stap tegenover de versie 2.3.3 van WordPress. Als je zelf avontuurlijk genoeg bent, laat dan vooral niet na om te vertellen hoe de upgrade bij jou verliep.

* Update** Alle positieve ervaringen hier trokken mij over de streep. Ik ben ondertussen ook WP 2.5. Zonder problemen. Natuurlijk heb ik wel een backup genomen.

Wie wil er nu honderd paswoorden en accounts bijhouden? Niemand toch? Of je gebruikt telkens hetzelfde paswoord. Knappe koppen denken natuurlijk wat verder en kwamen met een oplossing: OpenID. Ideaal, zo leek het. Eén paswoord/login combo onthouden en de rest gebeurt automagisch op elke site die OpenID ondersteunt.

Maar is OpenID wel zo fantastisch? De voornaamste kritiek op OpenID valt samen te vatten als deze: “On the Internet, nobody knows you’re a dog.” Of beter, het decentrale karakter van OpenID betekent verzwakte de sterkte de identiteit die je claimt. Meer hierover vind je hier.

Los van die discussies, heb ik zelf uit harde ervaring geleerd dat OpenID niet het nirvana betekent. Mijn kritiek is eerder technisch van aard en beperkt zich tot het protocol zelf. De laatste maanden heb ik mij gebezigd met een OpenID plugin voor WordPress. Dat betekende dus een OpenID consumer implementeren en die koppelen met één van de API haken van WordPress. Om precies te zijn: in het wp-comments-post.php script. De OpenID specificatie leert ons dat alle oproepen tussen een consumer en een identity provider via HTTP GET requests moeten worden afgehandeld. Helaas hebben de makers van WordPress het bewuste script zo gepatched dat HTTP GET requests worden afgeblokt. Helaas betekent het ook meteen het afblokken van OpenID in comments op een propere manier. Ik kan via allerlei truken de nieuwe beveiliging omzeilen. Maar echt ideaal is dat niet.

Hadden de makers van WordPress die patch moeten doorvoeren? Vanuit het standpunt van beveiliging en anti-spam: zeker. Een script dat HTTP GET requests aanvaardt kan vrij gemakkelijk worden misbruikt. Zeker als het gaat om het dumpen van spam is er geen kunst aan om code te schrijven dat massaal HTTP GET requests afstuurt op onbeveiligde webscripts. Neen. Het probleem ligt in de OpenID specificatie. Die legt juist het gebruik van HTTP GET requests op en laat geen ruimte voor mogelijke alternatieven. In mijn ogen dwingt OpenID dus hier een mogelijk veiligheidsrisico af. Nochtans zijn er andere, betere alternatieven om data over HTTP door te sturen zonder gebruik te maken van de onveilige HTTP GET requests. Ik denk dan aan RPC protocollen zoals XML-RPC (er zit een XML-RPC module in WordPress!) en SOAP.

Persoonlijk sluit ik daarom dus liever mijn OpenID experiment voorlopig af en kijk ik de kat wat uit de boom vooraleer ik er verder mee ga.

Hm. Ik denk dat ik mijn router in de zeer nabije toekomst op de schopstoel ga zetten. Het is een D-Link 624+ met wireless. Ik had hem een tijdje na mijn iBook G4 gekocht. Het ding deed wat het moet doen maar de laatste maanden heb ik er niets als miserie mee. Mijn iBook verliest te pas en te onpas connectie met het ding en als ik iets langer weg ben, dan weigert het internet ook via UTP. Om nog maar te zwijgen van WPA beveiliging die volledig de mist in gaat. Het ding resetten is dan de enige oplossing.

Niet meteen ideaal. Ik ben dus op zoek naar een goede router waar een wireless op zit die probleemloos werkt met mijn iBook G4. Graag ook met flink wat opties. Linux based is zeker een plus. Iemand tips?

Bon. Nu mijn homebrew linux server hier in Antwerpen staat: tijd voor het betere werk. Naast de klassieke LAMP (met apache2) configuratie wilde ik eens iets anders doen. Iets wat écht nuttig is. En wat is nuttiger dan mijn e-mailproblemen onder handen nemen.

Aangezien ik nogal mobiel ben geraakt mijn e-mail al snel verspreid tussen mijn pc’s in Antwerpen en Brugge en mijn laptop. Om toch niet geconfronteerd te worden met een e-mailarchief dat ik ten allen tijde slechts deels kan benaderen (omdat een deel toevallig elders – onbeschikbaar – bewaard wordt) laat ik mijn mail op de mailserver van netsensei.nl staan. So far so good… maar die mailbox is niet oneindig groot en wanneer ik mijn mail dan toch ervan moet halen, dan kan ik elders niet zomaar terugvallen op de kopieën op de server.

Enter: een éigen mailserver waar ik onbeperkt mijn mails op kan bewaren. Twee avonden fiddelen met exim, procmail, fetchmail, imap en squirrelmail en ik heb het zo’n beetje bollen. Mijn mail wordt op gezette tijden afgehaald van netsensei.nl en bewaard in een mailbox op mijn linux server. Via imap kan ik binnen het netwerk in mijn studio met thunderbird op zowel mijn laptop als mijn desktop mijn mail benaderen. Buitenshuis kan ik via squirrelmail/webmail nog altijd mijn e-mail via een browser bekijken.

Blijven nog over: instellen dat ik ook met mijn thunderbird in Brugge mijn mail kan afhalen. Tricky aangezien particuliere relay servers niet graag gezien worden door ISP’s. Verder wil het remote (dus vanaf mijn desktop of laptop) zenden van e-mail via mijn mailserver niet echt lukken. Als ik inlog via SSH lukt me dit wel met mutt. En verder geraken de statusmessages van mijn server (gegeneerd door o.a. cron en logcheck) hopeloos vermengd met de mail van mijn netsensei.nl account. Met procmail zou dat te vermijden zijn, maar dat lukt voorlopig niet al te goed. En dan moet ik het zaakje ook nog eens op een deftige manier proberen te beveiligen.

Nog veel werk voor de boeg dus. Maar als me dit lukt, dan betekent het wel een substantiële verbetering van de huidige situatie. Hmz.

… dan wil dat zeggen dat het netwerk van de buren zojuist voor de bijl is gegaan.

Niet dat ik zo slécht ben, maar 64 bits WEP is zo 1999 en veel moeite was daar niet voor nodig. Een recente versie van Kismac en een beetje geduld. De rest heb ik te danken aan Tim Newsham!

Tip: wie toch zijn netwerk wil beveiligen, kies dan voor WPA!