15-06-2018, 16:23 door Anoniem: Enige probleem met de werkwijze http://nctv.nl -> https://nctv.nl -> https://www.nctv.nl is dat je dus 2 certificaten nodig hebt?
Ja en nee ;-)
Ja, het is verstandig om de hoofdsite en elke subsite van een certificaat te voorzien, en dat is een must als je op de hoofsite de directive "includeSubDomains" gebruikt.
Nee, in principe is 1 certificaat genoeg, mits je maar elke domeinnaam erin opneemt. Het certificaat van security.nl is bijvoorbeeld geldig voor zowel "www.security.nl", "secure.security.nl" als "security.nl". Een andere aanpak, zoals bijv. xs4all.nl toepast, is gebruik maken van een wildcard certificaat, namelijk "*.xs4all.nl". Belangrijk om te weten is dat die asterisk slechts voor 1 niveau van subdomains staat, dus "www.xs4all.nl", "service.xs4all.nl" en "webmail.xs4all.nl" kunnen uit de voeten met hetzelfde certificaat, maar het certificaat geldt niet voor bijv. "mijn.service.xs4all.nl".
Een belangrijke overweging hierbij is dat het inzetten van hetzelfde certificaat op meerdere servers (met verschillende domeinnamen) betekent dat op elke server dezelfde private key staat. Als
één van die servers gehacked wordt (hoe meer verschillende servers, hoe groter de kans daarop), moet je er waarschijnlijk vanuit gaan dat de private key gestolen is. Tenzij je (grote?) risico's wilt nemen, zul je een nieuw sleutelpaar moeten genereren, een nieuw certificaat moeten aanvragen en
op elke server de private key en het certificaat moeten vervangen. Een
weloverwogen besluit zou dus kunnen zijn om
niet slechts één certificaat in te zetten, maar meerdere.
Je kunt ook overwegen om
meerdere wildcard certificaten in te zetten, bijv. van verschillende leveranciers (en met verschillende rootcertificaten). Valt er dan een keer een leverancier om (zoals Diginotar destijds) dan kun je snel schakelen zonder meteen nieuwe sleutelparen te moeten genereren en certificaten te moeten bestellen (een wildcard certificaat is niet per definitie onveilig: dat wordt het pas als je het op meerdere servers inzet, omdat het risico op verlies van de bijbehorende private key toeneemt). Aan de andere kant moet je wel een goede administratie bijhouden welk certificaat waar is geïnstalleerd, want ze lijken allemaal sprekend op elkaar. O.a. fingerprint (meestal een SHA-1 of SHA256 hash over de binaire "ASN.1" versie van het certificaat) verschilt natuurlijk, dus die zou ik als identifier gebruiken.
TERZIJDE: er zijn cloud-hosting-providers die hergebruik van certificaten tot in het extreme doortrekken, zoals ik in augustus vorig jaar meldde in
https://isc.sans.edu/forums/diary/Malicious+script+dropping+an+executable+signed+by+Avast/22748/#40100, toen ik ontdekte dat een https server certificaat bleek te zijn uitgegeven voor een enorme reeks sites
die helemaal niks met elkaar te maken hadden (behalve, vermoedelijk, een gemeenschappelijk hosting server). Daaronder bevonden zich de counter terrorism site van de Australische overheid (een site met ondertussen een eigen certificaat, maar nog wel mixed content) en een criminele site die malware verspreidde. Aanvankelijk dacht ik dat het om een onterecht uitgegeven certificaat ging, maar dit bleek "volgens de regels" (yeah right) te zijn gebeurd - zie ook het comment van Jana Jurik van CDN77.com onder mijn bijdragen. Een bijzonder trieste zaak dat certificaatuitgevers meewerken aan dit soort praktijken...
Naar aanleiding van jouw vraag vroeg ik mij af hoeveel van de eerder door mij onderzochte servers al een certificaat
hebben dat het hoofdomein (zoals nctv.nl) ondersteunt. Dat heb ik vanmiddag en zojuist verder onderzocht, de uitkomsten daarvan zijn als volgt:
Resultaten van mijn tweede onderzoekOpnieuw uitgevoerd aan de keukentafel, met uitsluitend Firefox ESR - met een "F12 debug window" open. Iedereen kan dit doen lijkt me, en zeker beheerders...
1) Hoofddomeinen met ondersteuning voor https en HSTSHier gaat het dus om sites waarbij de beheerders
bijna alles goed gedaan hebben, maar een essentieel aspect over het hoofd hebben gezien. Namelijk dat als een bezoeker
nctv.nl intikt, en zij daarvandaan meteen naar
https://www.nctv.nl/ wordt doorgestuurd, de browser
dus nooit https://nctv.nl/ aandoet, en daar dus geen HSTS header van ontvangt. Met als gevolg dat elke volgende keer dat de bezoeker weer
nctv.nl intikt, haar verbinding kan worden gekaapt - zonder dat de gebruiker daar foutmeldingen en/of waarschuwingen bij hoeft te ontvangen en de site als twee druppels water op de echte kan lijken. En indien de aanvaller haar doorstuurt naar een erop lijkende domeinnaam, kan deze natuurlijk ook van een geldig certificaat zijn voorzien. Doordat je geldige sites als "gemeentemaastricht.nl" ziet zal het niemand verbazen als je word doorgestuurd naar bijv.
https://gemeente_maastricht.nl/ of
https://maasticht.nl/ en dat de bezoeker niet weet dat gemeente_maastricht.nl niet van de gemeente Maastricht is resp. over de spelfout in het tweede geval heenkijkt.
Nb. als je als bezoeker de eerste keer (en daarna minstens 2x per jaar) handmatig naar
https://sitenaam.nl/ surft, kun je tussendoor redelijk veilig volstaan met het intikken van
sitenaam.nl - omdat HSTS daarvan in de HSTS-database van jouw browser is opgeslagen. Wel hartstikke jammer natuurlijk dat
bezoekers hier handwerk voor moeten verrichten...
Het gaat hierbij om de volgende sites:
Gemeentes: https://aalsmeer.nl/,
https://alblasserdam.nl/,
https://breda.nl/,
https://delft.nl/,
https://denhaag.nl/,
https://helmond.nl/,
https://lv.nl/,
https://woerden.nl/Overheidwebsites: https://belastingdienst.nl/,
https://tweedekamer.nl/,
https://overheid.nl/,
https://nctv.nl/Winkels: https://ns.nl/Beheerders van bovenstaande sites hoeven dus slechts vanuit de
https://www.sitenaam.nl/ website de browser op te dragen whatever op te halen vanaf het hoofddomain (
https://sitenaam.nl/ dus).
2) Hoofddomeinen met ondersteuning voor https echter zonder HSTSDeze domeinen sturen (op dit moment) geen HSTS header mee, maar hebben wel een certificaat dat zowel voor minstens
www.sitenaam.nl als voor
sitenaam.nl geschikt is. Het heeft echter geen zin om af en toe naar
https://sitenaam.nl/ te surfen (zoals bij 1 hierboven beschreven), want er wordt niks toegevoegd aan de HSTS database van jouw browser.
Het gaat hierbij om de volgende sites:
Gemeentes: https://alphenaandenrijn.nl/,
https://heerenveen.nl/,
https://rotterdam.nl/,
https://venlo.nl/Overheidwebsites: https://politie.nl/Winkels: https://wehkamp.nl/,
https://zalando.nl/,
https://bol.com/,
https://ah.nl/,
https://anwb.nl/Banken: https://binck.nl/,
https://icscards.nl/,
https://knab.nl/,
https://rabobank.nl/Certificaatverkopers: https://argeweb.nl/,
https://combell.nl/,
https://globalsign.nl/,
https://versio.nl/Verzekeraars: https://cz.nl/,
https://nn.nl/Om hun sites echt veilig te maken (los van eventuele andere zaken, waar ik nu niet naar gekeken heb), zullen beheerders hetzelfde moeten doen als bij groep 1 hierboven vermeld, maar
daarnaast zullen zij het hoofdomein
https://sitenaam.nl/ een fatsoenlijke HSTS header moeten laten meesturen (bij voorkeur met "includeSubDomains" daarin).
3) Hoofddomeinen met DEFECTE ondersteuning voor https (een HSTS header krijgt de browser niet te zien)Deze sites hebben geen geldig certificaat voor het betreffende hoofdomein, maar ondersteunen wel https verbindingen. Daardoor krijg je bij hen (op het moment van schrijven) een certificaatfoutmelding (probeer gerust door erop te klikken):
Gemeentes:
https://aalburg.nl/,
https://aalten.nl/,
https://arnhem.nl/,
https://apeldoorn.nl/,
https://leidschendam.nl/,
https://voorburg.nl/Overheidwebsites:
https://bkr.nl/Certificaatverkopers:
https://symantec.nl/:
symantec.nl uses an invalid security certificate. The certificate is only valid for the following names: symantec.com, norton.com, account.norton.com, careers.symantec.com, customercare.symantec.com, de.norton.mobi, downloads.guardianedge.com, emea.symantec.com, eu.store.pgp.com, jobs.symantec.com, mostdangeroustown.com, mynortonaccount.com, na.store.pgp.com, nortonaccount.com, nortonlearninghub.com, nukona.com, row.store.pgp.com, ssl.symantec.com, store.pgp.com, uk.store.pgp.com, www.account.norton.com, www.emea.symantec.com, www.mostdangeroustown.com, www.nortonaccount.com, www.nortonlearninghub.com, www.nukona.com, www.pgp.com, www.ssl.symantec.com, www.symantec.co.jp, www.symantec.co.uk, www.symantec.fr, www.symantec.de, www.symantec.it, www.symantec.com.au, www.symantec.com.br, www.symantec.mx, www.symantec.es, www.symantec.ca, www.symantec.hk, www.symantec.co.in, www.symantec.tw, www.symantec.sg, lifelock.jobs, www.lifelock.jobs, et.symantec.com Error code: SSL_ERROR_BAD_CERT_DOMAIN
en
https://verisign.nl/:
verisign.nl uses an invalid security certificate. The certificate is only valid for the following names: verisign.asia, verisign.biz, verisign.ch, verisign.co.in, verisign.co.jp, verisign.co.uk, verisign.com, verisign.com.au, verisign.com.br, verisign.com.cn, verisign.com.es, verisign.com.hk, verisign.com.sg, verisign.com.tw, verisign.com.vn, verisign.de, verisign.dk, verisign.es, verisign.fr, verisign.hk, verisign.in, verisign.info, verisign.jobs, verisign.mobi, verisign.name, verisign.net, verisign.org, verisign.pro, verisign.se, verisign.sg, verisign.tel, verisign.tw, verisign.us, verisign.vn, verisigninc.com, www.verisign.asia, www.verisign.biz, www.verisign.ch, www.verisign.co.in, www.verisign.co.jp, www.verisign.co.uk, www.verisign.com, www.verisign.com.au, www.verisign.com.br, www.verisign.com.cn, www.verisign.com.es, www.verisign.com.hk, www.verisign.com.sg, www.verisign.com.tw, www.verisign.com.vn, www.verisign.dk, www.verisign.es, www.verisign.fr, www.verisign.hk, www.verisign.in, www.verisign.info, www.verisign.jobs, www.verisign.mobi, www.verisign.name, www.verisign.net, www.verisign.org, www.verisign.pro, www.verisign.se, www.verisign.sg, www.verisign.tel, www.verisign.tw, www.verisign.us, www.verisign.vn, www.verisigninc.com Error code: SSL_ERROR_BAD_CERT_DOMAIN
Tot zover het "respect" dat deze laatste twee hebben voor Nederlanders...
4) Hoofddomeinen met GEHEEL GEEN ondersteuning voor https, noch voor HSTS (alleen http dus)Overheidwebsites: https://uwv.nl/: "Unable to connect"
Winkels: https://cena.nl/: "Unable to connect"
Verzekeraars: https://achmea.nl/: "Unable to connect" (terwijl http://achmea.nl/ hoopvol -doch zinloos- meestuurt: "Strict-Transport-Security: max-age=31536000; includeSubDomains")
https://zilverenkruis.nl/: "Unable to connect" (terwijl http://zilverenkruis.nl/ hoopvol -doch zinloos- meestuurt: "Strict-Transport-Security: max-age=31536000; includeSubDomains")