Baas over je eigen e-mail (deel 3 van 3)

  • May 18, 2017
  • 0

 In de twee vorige delen van deze workshop legden we uit hoe je met Postfix, Dovecot en Roundcube je eigen mailserver en webmail-client installeert. Toch ontbreekt er nog één belangrijke component in die setup: encryptie. In dit laatste deel van de workshop gaan we dus aan de slag met SSL-certificaten.

 

Over de werking van SSL- of TLS-encryptie hebben we in het verleden al vaker geschreven. In zijn meest eenvoudige vorm dient TLS-encryptie enkel om te verhinderen dat een derde partij de communicatie tussen jouw client en een server kan lezen. Gebruik je wel eens een publiek toegankelijk WiFi-netwerk en surf je naar websites zonder SSL-encryptie? Dan kan de beheerder van dat netwerk je zonder veel moeite afluisteren! Beschikt de server echter over een SSL-certificaat met bijbehorende private key, dan wordt er een beveiligde verbinding opgezet met de client. Het SSL-certificaat bevat immers de public key van de server. De client encrypteert data met die public key, waarna enkel de server die data kan decrypteren met zijn private key. Tijdens die zogenaamde TLS-handshake berekenen zowel de client als de server een tijdelijke encryptiesleutel (de session key) om de rest van de communicatie te versleutelen. In principe is het nu onmogelijk voor derden om de communicatie tussen client en server af te luisteren, tenzij er weer net een bug is opgedoken in OpenSSL. Lees ook zeker ons artikel over Perfect Forward Secrecy uit 2014 eens na op http://bit.ly/1WeOPAH. TLS zonder Perfect Forward Secrecy is immers niet zo veilig als vroeger werd aangenomen.

 

Self-signed

 Ben je alleen geïnteresseerd in encryptie voor Postfix, Dovecot en Roundcube? Dan volstaat in feite een zogenaamd self-signed certificaat. Dat is een certificaat waarbij de uitgever (Issuer) identiek is aan de server (Subject). In Debian maak je zulke certificaten aan met de tool make-ssl-cert, onderdeel van het pakket ssl-certs. Het configuratiebestand vind je in /usr/share/ssl-cert/ssleay.cnf, al hoef je dat wellicht niet aan te passen. Het resulterende certificaat vind je standaard in /etc/ssl/certs/ssl-cert-snakeoil.pem en de private key in /etc/ssl/private/ssl-cert-snakeoil.key. Het Subject van dit certificaat is de fully qualified domain name van je server. Het nadeel van een self-signed certificaat is, dat elke client het certificaat expliciet moet aanvaarden bij de eerste verbinding. Moderne browsers geven ook behoorlijk afschrikwekkende waarschuwingen in dat geval. In de praktijk is dit dus geen ideale oplossing, zeker niet als ook minder technisch aangelegde mensen jouw mailserver gebruiken.

 

Certificate Authority

 Een tweede (en zeker niet minder belangrijk!) doel van TLS-encryptie is om de client zekerheid geven, dat hij met de juiste server communiceert. Wat voor nut heeft het immers om vertrouwelijke gegevens te encrypteren, als je ze naar de verkeerde server stuurt? Met een self-signed certificaat heeft de client geen enkele garantie over de identiteit van de server. Iedereen kan immers een self-signed certificaat maken voor bijvoorbeeld www.paypal.com. Om die reden zijn de Certificate Authorities (CA’s) in het leven geroepen. Een CA is een onafhankelijke derde partij, die de identiteit van de aanvrager controleert voor elke certificaat-aanvraag. Zo kunnen enkel werknemers van Paypal een certificaat voor www.paypal.com registreren. Er is een beperkt aantal CA’s, dat door alle besturingssystemen vertrouwd wordt: de zogenaamde Root CA’s. Voor certificaten uitgereikt door die Root CA’s krijg je geen waarschuwing te zien in je browser. Dit is de meest eenvoudige oplossing voor eindgebruikers, maar officiële SSL-certificaten zijn zelden gratis.

 

Als tussenoplossing voor thuisgebruik kun je jouw eigen Certificate Authority opzetten. Je moet het certificaat van jouw CA dan éénmaal importeren op al je devices. Daarna maak je zoveel certificaten aan als je wilt en worden ze zonder meer aanvaard door al jouw devices. Het opzetten van een CA-infrastructuur is wel tamelijk complex, als je niet erg vertrouwd bent met encryptie. Bovendien vinden andere gebruikers van jouw mailserver het misschien vervelend dat ze jouw CA-certificaat moeten importeren. Sinds een aantal jaren kun je echter bij StartCom terecht voor gratis SSL-certificaten voor persoonlijk gebruik. In de rest van deze workshop tonen we hoe je SSL-certificaten aanvraagt bij StartCom en hoe je ze gebruikt op je server.

 

StartSSL

 StartSSL is een dienst van StartCom, die verschillende types SSL-certificaten aanbiedt. Wij zijn hier met name geïnteresseerd in de gratis certificaten, maar we lopen toch even door de verschillende producten:

 StartSSL Free of Class 1: gratis voor persoonlijk gebruik, geldig voor één jaar, slechts één hostname per certificaat. StartCom controleert enkel of de aanvrager ook daadwerkelijk de domeinnaam bezit, waarvoor een certificaat wordt aangevraagd.

  • StartSSL Verified of Class 2/3: StartCom controleert jouw identiteit (Class 2) en eventueel die van het bedrijf waarvoor je certificaten wilt aanmaken (Class 3). Beide controles kosten $60, waarna je een onbeperkt aantal certificaten kunt aanmaken. Meerdere hostnames per certificaat en wildcards zijn mogelijk.

  • StartSSL Extended Validation of EV: dit is de meest uitgebreide vorm van identiteitscontrole, maar enkel interessant voor grote bedrijven of organisaties.

     

    Er kleeft overigens wel één nadeel aan StartSSL Free, want je moet $25 betalen om een geldig certificaat terug in te trekken. StartCom heeft daarvoor veel kritiek gekregen na het Heartbleed-schandaal. Gebruikers van een gratis dienst moesten immers plots betalen om van een potentieel onveilig certificaat af te komen. Houd dit even in het achterhoofd als je meerdere StartSSL-certificaten aanmaakt!

     

    Verificaties

    Maak om te beginnen een nieuwe account aan bij StartSSL. Je krijgt dan een persoonlijk client certificaat, dat je in je browser moet installeren. Met dat certificaat kun je nadien inloggen op StartSSL’s Control Panel. Het Control Panel bestaat uit 3 tabbladen: Tool Box, Certificates Wizard en Validations Wizard. We starten in het laatste tabblad. Daar vind je vijf verschillende identiteitscontroles, gaande van Email Address Validation en Domain Name Validation tot Extended Validation. Voor StartSSL Free hoef je alleen de eerste twee controles door te lopen. Je bevestigt je e-mailadres door dit in te voeren in de eerste wizard. StartSSL stuurt je daarop een e-mail met een verificatiecode, die in je het volgende scherm moet invullen. Heb je Postscreen geactiveerd op jouw mailserver, dan moet je dit mogelijk meermaals proberen, alvorens het lukt. Wacht wel steeds een tiental minuten tussen de verschillende pogingen.

     

     

    Is je e-mailadres gevalideerd, open dan de Domain Name Validation wizard. Hier vul je het top level domain in, waarvoor je certificaten wilt aanvragen. Heeft jouw server bijvoorbeeld de naam mail.jouwnaam.nl, dan kies je jouwnaam.nl. Vervolgens stuurt StartSSL een verificatiecode naar één van de volgende e-mailadressen:

 

  • postmaster@jouwnaam.nl

  • hostmaster@jouwnaam.nl

  • webmaster@jouwnaam.nl

  • het e-mailadres dat in de WHOIS-database is opgenomen voor jouw domeinnaam (dit is niet altijd jouw persoonlijke e-mailadres, want het kan ook dat van je domain registrar zijn).

     

    Beide validaties zijn trouwens slechts 30 dagen geldig. Wil je daarna een nieuw certificaat aanmaken, dan moet je de validatieprocedure opnieuw doorlopen.

     

    Certificates Wizard

    Is je domeinnaam gevalideerd? Open dan de Certificates Wizard (tweede tabblad). Bij Certificate Target kies je Web Server SSL/TLS Certificate. In de volgende stap stelt StartSSL voor om een private key te genereren voor jou. We raden je ten stelligste af om dat te doen! TLS-encryptie is immers waardeloos als jouw private key in verkeerde handen valt. Ook al vertrouw je StartCom, je weet niet of ze jouw private key ergens bewaren. Is dat het geval, dan zou die key bij een aanval op hun infrastructuur in handen van derden kunnen vallen. Het is dus veiliger om zelf je private key aan te maken op jouw server. Klik daarvoor op “Skip” om je eigen Certificate Signing Request (CSR) te uploaden. Afbeelding 2 bevat de benodigde commando’s om een nieuwe private key aan te maken én een CSR met de bijbehorende public key.

     

    De inhoud van het .csr-bestand plak je in StartSSL’s webpagina. Vervolgens kies je het gewenste Subject voor je certificaat. Het Subject zat in feite reeds in de CSR, maar StartSSL negeert dit (de CSR dient enkel om jouw public key over te nemen). Uiteraard kun je alleen Subjects kiezen onder een top level domain, dat je reeds gevalideerd hebt! Tot slot krijg je een tekstvenster met daarin je certificaat. Kopieer en plak dit in een bestand op je server met extensie .crt. Nadien vind je al je certificaten terug via Toolbox > Retreive Certificate.

     

     

     

     

    Certificate chain

    De verschillende StartSSL-certificaten zijn niet ondertekend door het StartCom Root CA, maar door een tussenliggend CA-certificaat. Voor de meeste clients is dat geen probleem, maar sommige applicaties geven toch nog waarschuwingen bij dergelijke certificaten. Dat los je op door de hele keten van certificaten te configureren op je server. Voor een StartSSL Free-certificaat ziet die er als volgt uit: StartCom Root CA -> Class 1 Intermediate Server CA > jouw eigen certificaat. Het StartCom Root CA kun je zelfs weglaten, want dat is sowieso op elk systeem voorgeïnstalleerd. Het tweede certificaat download je via Toolbox > StartCom CA Certificates. Dat bestand (sub.class1.server.ca.pem) kopieer je dus ook naar je server. We zullen verderop nog zien op welke locatie alle bestanden precies horen.

     

    Tot slot nog een laatste tip: met het commando uit afbeelding 4 krijg je een leesbare versie van je certificaat. Dat is handig om bijvoorbeeld het Subject van een certificaat op te zoeken of te controleren hoe lang het nog geldig is.

     

     

    Dovecot

    Na installatie bevat Dovecot al een self-signed certificaat (/etc/dovecot/dovecot.pem) en een private key (/etc/dovecot/private/dovecot.pem). Je kunt die bestanden overschrijven of gewoon nieuwe bestanden aanmaken. Vergeet niet om het Class 1 Intermediate Server CA op te nemen in het certificaatbestand én de private key enkel leesbaar te maken voor de root-user (zie afbeelding 5). Vervolgens voegen we een imaps-listener toe in /etc/dovecot/conf.d/10-master.conf. Schakel zeker ook de unencrypted imap-listener uit voor het publieke IP van je VPS. De imap-listener zou enkel nog op 127.0.0.1 mogen draaien, voor verbindingen via Roundcube. De communicatie tussen Roundcube en Dovecot hoeft immers niet geëncrypteerd te zijn, aangezien die de server niet verlaat. (Voor de encryptie tussen Roundcube en clients is Apache verantwoordelijk.) Tot slot passen we /etc/dovecot/conf.d/10-ssl.conf nog aan. Dat bestand bevat onder andere de locaties van het certificaat, de private key en de te gebruiken ciphers. In afbeelding 6 zie je een voorbeeldconfiguratie. De laatste regel is niet vereist, maar schakelt Perfect Forward Secrecy in, indien de client dit ondersteunt. Via http://bit.ly/1P6jnPv kun je die regel kopiëren en plakken in je configuratie. Herstart Dovecot na alle wijzigingen en probeer dan met je client te verbinden op poort 993 mét SSL/TLS-ondersteuning (geen STARTTLS).

     

     

     

    Postfix

    De TLS-configuratie voor Postfix is iets complexer. Postfix functioneert immers als client (voor uitgaande mail) én als server (voor inkomende mail). Kopieer om te beginnen het certificaat en de private key voor Dovecot naar een locatie onder /etc/postfix, bijvoorbeeld /etc/postfix/ssl. Voeg vervolgens de configuratie uit afbeelding 7 toe aan /etc/postfix/main.cf. De regels die beginnen met smtp dienen voor Postfix als client en die met smtpd voor Postfix als server. Zowel SSLv2 als SSLv3 schakelen we in elk geval uit, omdat die oudere versies onvoldoende beveiliging bieden. De belangrijkste optie is tls_security_level: die bepaalt of én wanneer TLS-encryptie gebruikt wordt. Voor Postfix als client is TLS niet vereist (smtp_tls_security_level = may). Ondersteunt de externe mailserver TLS, dan zal Postfix dit inschakelen. Is dat niet het geval (en dat geldt nog voor veel mailservers!), dan valt Postfix terug op een plaintext-verbinding. Verder gebruiken we de voorgeïnstalleerde Root CA’s uit /etc/ssl/certs om certificaten van externe mailservers te verifiëren.

     

    De optie smtpd_tls_security_level (voor Postfix als server) mag je zeker niét instellen in main.cf. Voor inkomende mail van externe mailservers willen we immers hetzelfde gedrag als smtp_tls_security_level: TLS indien mogelijk, plaintext indien niet. Maar voor verbindingen met de submission-service op poort 587 willen we uiteraard wél TLS afdwingen. Doen we dat niet, dan worden de wachtwoorden van jouw mailgebruikers gewoon in plaintext verstuurd. Om smtpd_tls_security_level apart te configureren voor verschillende services moet je in /etc/postfix/main.cf zijn. In afbeelding 5 uit deel 1 van deze workshop legden we uit welke wijzigingen je moest doorvoeren aan dat bestand. Vervang die wijzigingen door die uit afbeelding 8 om TLS-encryptie in te schakelen. Met smtpd_tls_security_level=encrypt bij de submission-service weigeren we plaintext-verbindingen. Elders staan we zowel plaintext- als TLS-verbindingen toe. Herstart Postfix en herconfigureer je mailclients om STARTTLS te gebruiken (het poortnummer blijft hetzelfde). In /var/log/mail.log zie je voor elke verbinding of die beveiligd is met TLS of niet en welke cipher gebruikt wordt. De optie tls_preempt_cipherlist=yes zorgt trouwens voor Perfect Forward Secrecy, indien de client dit ondersteunt.

     

     

     

    Apache

    Tot slot schakelen we ook TLS-encryptie in voor Apache. In Debian of Ubuntu doe je dat als volgt:

  • activeer de ssl-module: a2enmod ssl

  • voeg de volgende regel toe aan /etc/apache2/ports.conf (gebruik uiteraard het correcte IP-adres van jouw server!):

     

    Listen :443

    NameVirtualHost 37.252.124.113:443

    NameVirtualHost 37.252.124.113:80 (indien nog niet aanwezig)

     

  • plaats het oorspronkelijke certificaat (dus zonder de Class 1 Intermediate Server CA erin), de private key en het bestand sub.class1.server.ca.pem in een aparte directory, bijvoorbeeld /etc/apache2/ssl

 

  • maak een aparte vhost-configuratie aan voor de hostname, waarvoor je het certificaat gemaakt heb. Het voorbeeld uit afbeelding 9 kUn je gebruiken, indien je Roundcube manueel (dus niet via je package manager) geïnstalleerd hebt in /var/www/roundcube. Plaats dit in een nieuw bestand onder /etc/apache2/sites-available, bijvoorbeeld test.filipvervloesem.be

  • activeer de nieuwe vhost: a2ensite test.filipvervloesem.be

  • herstart Apache

     

     

    Surf nu naar het domein van je certificaat (test.filipvervloesem.be in ons voorbeeld) en je wordt onmiddellijk doorverwezen naar de HTTPS-website. Daarvoor is de Redirect permanent-regel in de eerste vhost-definitie verantwoordelijk. Alleen op die manier ben je er zeker van dat iedereen de geëncrypteerde versie van jouw webmail gebruikt. Wil je Apache’s ssl-module verder configureren, open dan het bestand /etc/apache2/mods-enabled/ssl.conf. Om Perfect Forward Secrecy te activeren, voeg je bijvoorbeeld de opties uit afbeelding 10 toe. (De ellenlange lijst ciphers bij SSLCipherSuite kan je kopiëren van http://mzl.la/1hxvtXv.)

     

     

    Dit was het laatste deel in onze workshop over het configureren van je eigen mailserver. We hopen dat we genoeg informatie gegeven hebben om je snel op weg te helpen. Wil je jouw configuratie nog verder aanpassen? Dan kun je terecht in de man-pages en configuratiebestanden van Postfix, Dovecot en Roundcube, want die bevatten een schat aan informatie. Veel succes ermee!