site met zowel HTTP alsook HTTPS wenselijk?
- Ariën - op 16/04/2018 17:33:50:
Dat geldt ook voor de nieuwe wildcard-certificaten van Let's Encrypt. Die moeten ook geverifieerd worden. Mogelijk ook later voor normale certificaten.
Verificatie van wildcard-certificaten van Let's Encrypt gaat op dezelfde manier als voor gewone certificaten. Het enige verschil is dat het verifiëren middels een nonce in je webroot niet meer mogelijk is; het *moet* via DNS.
Gewijzigd op 16/04/2018 17:37:20 door Willem vp
Nog even hierop terugkomen: zie https://xn--80aa0cbo65f.com/
Deze website bevat een COMODO-certificaat; blijkbaar controleren ze daar de identiteit van de aanvrager dus ook niet, wat de uitleg van de hostingprovider behoorlijk onderuit schoffelt. ;-) Als je een browser hebt die IDNs niet omzet naar punycode (zoals een out-of-the-box Firefox) dan zul je https://paypal.com in je adresbalk zien staan...
(Voor Firefox-gebruikers kan het dus handig zijn om via about:config de instelling network.IDN_show_punycode op true te zetten, maar dat terzijde.)
Om op de oorspronkelijke vraag terug te komen: ik heb drie argumenten pro-HTTP (althans, de ondersteuning ervan) gezien:
1) Intranetten
2) Hosters
3) Legacy-apparaten/applicaties
Wat het gebruik op intranetten betreft: non-routable adressen lijken me (afhankelijk van de CA) geen probleem. Een CA als Let's Encrypt (is 'ie weer ;-) ) ondersteunt validatie via DNS, dus zodra je intranet een hostname op een publieke DNS-server heeft, kun je een certificaat aanvragen. En anders gebruik je een wildcard-certificaat voor je domein.
Gebruik je hostnames als 'www.bedrijfsnaam.intranet' dan wordt het wat lastiger; dan zul je met self-signed certificaten moeten gaan werken. Plus de handmatige toestemmingen in elke browser, maar als je bedrijf groot genoeg is om een intranet te hebben, dan heb je waarschijnlijk ook een centrale beheeromgeving waarin je dat kunt regelen.
Hosters die niet standaard HTTPS aanbieden, zijn een groter probleem. Ik ben daar redelijk zwart/wit in: als een hoster het niet belangrijk vindt om HTTPS aan te bieden (even afgezien van de eventuele kosten voor een certificaat) dan vind ik het niet belangrijk om daar klant te zijn. Een jaar of 20 geleden was HTTPS nog een aanslag op je CPU-resources, dus ik kan me voorstellen dat destijds niet iedere hoster stond te springen om het te ondersteunen, maar tegenwoordig is het verschil verwaarloosbaar, dus dat mag geen argument meer zijn.
En dan hebben we de legacy-systemen nog. Ik moet toegeven dat ik op mijn werk nog een paar vhosts heb waar wat protocollen op HTTP worden gepiggybackt, en ik heb geen idee wat er instort als ik daar HTTPS onder zet. Aan de client-kant heb ik nog ergens een RedHat 6.2 (18 jaar oud) die al dat nieuwerwetse SSL niet meer begrijpt. Maar zolang de sites die bereikt moeten worden nog HTTP ondersteunen, is er voor mijn baas geen prikkel waardoor hij besluit om de software die op dat systeem draait te herschrijven, en draait het systeem over 18 jaar waarschijnlijk nog steeds.
Anders gezegd: als iedereen HTTP blijft ondersteunen, komen we er nooit vanaf. En dan kom ik bij een uitspraak eerder in dit draadje:
> maar als de informatie zelf niet gevoelig is, en er geen persoonlijke data over de lijn gaat,
> dan boeit het niet of er iemand meeluistert.
Het probleem is, dat het op voorhand moeilijk te bepalen is welke informatie gevoelig/persoonlijk is, en welke niet. Vaak is bepaalde informatie op zich niet gevoelig, maar verandert dat, wanneer het gecombineerd wordt met andere (niet-gevoelige) data. Het gaat bovendien niet alleen om gegevens die worden verstuurd naar een website, maar ook om gegevens die worden ontvangen. Het beste kun je er dus vanuit gaan dat álle over en weer verstuurde gegevens gevoelig zijn.
Zoals gezegd, kun je op een HTTP-verbinding een MITM-attack uitvoeren. Zo'n MITM kan natuurlijk kijken of je toevallig ergens een wachtwoord invoert, maar het is waarschijnlijk veel lucratiever om iets te doen met de pagina's die je opvraagt. Bijvoorbeeld elke hyperlink rewriten naar een link die naar een website van de MITM verwijst. En zo zijn er nog talloze manieren waarop een nietsvermoedende gebruiker om de tuin kan worden geleid.
Met HTTPS (en eigenlijk ook nog alleen in combinatie met HSTS) weet je in ieder geval redelijk zeker dat je terechtkomt op de website die je hebt opgevraagd. Meer dan dat is het niet. Het zegt niets over de eigenaar van die site. Als je op een verkeerde link klikt, of een tikfout maakt, kun je best op een site terechtkomen met een geldig certificaat, maar een malafide eigenaar. Je moet dus altijd op blijven letten. Net als wanneer je op een kruispunt door een groen licht rijdt; er kan altijd aan de andere kant iemand door rood scheuren. Ondanks dat hebben die verkeerslichten toch hun nut.
Zelf zou ik bij nieuwe projecten in ieder geval geen extra moeite meer doen om HTTP te blijven ondersteunen.
Gewijzigd op 18/04/2018 01:35:26 door Willem vp