Mag ik mijn klanten verplichten SSL/TLS te gebruiken?

security-beveiliging-ketting-slot-chainEen lezer vroeg me:

Mag ik, als hostingprovider, klanten dwingen om SSL/TLS te gebruiken? Via een aantal scripts is het gehele proces te automatiseren, zodat er tijdens het aanmaken van een account een certificaat wordt aangemaakt (via Let’s Encrypt, dus geen meerkosten) en verbindingen vervolgens over SSL/TLS forceren (mod_rewrite en HSTS header). Ik heb veel kleine ondernemers als klant die hier écht steken laten vallen en ik wil ze tegen zichzelf beschermen.

Ik denk dat dit in principe wel kan. Je kunt in je algemene voorwaarden opnemen dat je verlangt dat klanten hun websites en software goed beveiligen, en dat jij maatregelen mag nemen, zoals SSL/TLS beveiligde verbindingen, om dat af te dwingen.

Dit is wel een tikje ongebruikelijk (helaas) dus je moet de klant daar wel expliciet over informeren. Ik zou zelf dat heel proactief willen zien: stuur ze een mail dat er wat mis is, vraag of ze dat binnen 14 dagen willen herstellen en anders doe jij het. Aangenomen dat dit geen nadelige effecten heeft voor de site, zie ik dan het probleem niet.

Maak je dingen wél stuk, dan komt dat op jouw bordje te liggen. En natuurlijk heb je als hoster in je algemene voorwaarden je aansprakelijkheid beperkt, maar bij dit soort handelen gaat dat niet zomaar op. Voor opzettelijk handelen ben je altijd volledig aansprakelijk, en dit neigt daar toch wel een tikje naar. Een hoster zou er dan ook voor kunnen kiezen om te zeggen, binnen 14 dagen herstellen en anders de site in een sandbox of op zwart. (Ja, de wet vindt het erger dat je iets half doet dan wanneer je iemand op zwart zet.)

Arnoud

37 reacties

  1. Dit is te kort door de bocht. Bij een hoster die zich op deze manier bemoeit met hoe ik zijn diensten gebruik zou ik geen klant worden. Er zijn allerlei toepassingen denkbaar waarbij TLS ongewenst is of zelfs technisch in de weg zit. Met ‘website en software beveiligen’ heeft het ook niet altijd te maken. Als een hoster in zijn recht staat om een dienst die ik op zijn platform aanbiedt zo ingrijpend te wijzigen is er iets mis… Ik kan me dan ook niet voorstellen dat dit correct is.

      1. Het is zeer ongewenst. Wanneer je in een webpagina scripts, plaatjes, embedded zaken afkomstig van andere domeinen laad, krijg je een mengeling van secure content (je eigen via https geleverde deel) en insecure content (afkomstig via de http referenties aan externe zaken). Dit helpt de SSL beveiliging om zeep. Webbrowsers waarschuwen dan ook voor dit soort menging.

        Wanneer deze hosting provider dus plotseling https gaat afdwingen wacht zijn klanten veel werk om hun eigen website op te schonen en externe zaken via https binnen te halen. Maar soms is het niet mogelijk die externe content via https te benaderen en dan rest er niets anders dan je eigen pagina zonder SSL te leveren.

        Daarrnaast zijn sommige oude webbrowsers niet in staat om om te gaan met SSL als verschillende domeinen gebruik maken van hetzelfde IP-adres, wat bij nogal wat hosting providers het geval kan zijn.

        1. Maar soms is het niet mogelijk die externe content via https te benaderen en dan rest er niets anders dan je eigen pagina zonder SSL te leveren.

          Dan ga je dus ofwel de aanbieder van de betreffende content erop aanspreken, ofwel je haalt de content weg. Het is onverantwoordelijk om om een dergelijke reden maar de hele zooi onbeveiligd te laten, en dan de verantwoordelijkheid op een derde partij af te schuiven. Je zoekt maar gewoon een aanbieder die zijn zaakjes wel op orde heeft.

          1. Waarom zou ik ergens moeite voor moeten doen? Als ik een website heb over mijn konijn en elders een leuk plaatje heb van zo’n beest is er voor mij geen reden om die te beveiligen en ik zou not amused zijn als ik ineens extra werk moest doen omdat mijn hoster dat leuk/fancy/veiliger vind.

        2. Je vergeet nog alle pakketten waar je redelijk wat tijd in mag steken om alle interne verwijzingen goed te zetten. Als je dit zo doet krijg je bij bv WordPress een oneindig aantal redirects en werkt de site effectief niet meer tot iemand de database heeft aangepast. Gaat de hoster dat ook voor alle bestaande klanten doen?

            1. WordPress was slechts een voorbeeld. Er zijn meer systemen die het doen (en soms maken ze het, waar mogelijk, nog lastiger). En als hoster kun je niet zo plugins voor klanten gaan installeren of verwijderen lijkt mij.

      2. Daarnaast kunnen er scripts gebruik maken van de service, die mogelijk geen redirects volgen. Deze zullen breken als ze opeens met een 301 Gebruik maar HTTPS returncode worden opgezadeld.

        Ik zou me als hoster niet gaan bemoeien met of mijn klanten nou wel of geen HTTPS gebruiken. Hooguit mailings sturen met “Upgrade nu uw website naar HTTPS, GRATIS!”

      3. Ikzelf host een oude gameserver met een webserver om de maps te serveren. De client heeft geen ondersteuning voor https en dat maakt ook geen klap uit voor maps downloaden, dus als een hoster dit mij op zou leggen zou ik daar direct weg gaan.

        1. De client heeft geen ondersteuning voor https en dat maakt ook geen klap uit voor maps downloaden

          Dat betwijfel ik ten zeerste. Afhankelijk van welk spel het is, kan dit zeker een vector zijn om malware te serveren – danwel via bewuste code execution die in het spel ingebouwd is voor maps, danwel door een veiligheidslek.

          EDIT: Bovendien gaat het niemand een snars aan welke maps je gebruikers spelen, en is het ook niet aan de beheerder om te bepalen of dit wel of geen privacygevoelige data is. Die keus is aan de gebruikers.

          1. Het zelf implementeren van http in een programmeertaal als C of C++ is niet zo moeilijk, het wordt makkelijker als je besluit een aantal features niet in een client te ondersteunen. TLS is een gecompliceerd protocol en redelijkerwijs niet zelf te doen. Ik kan prima begrijpen dat (oudere) spellen geen SSL or TLS ondersteuning hebben. (Of alleen verouderde SSL versies ondersteunen.) Om dat te fixen zou de originele maker van het spel (als die nog bestaat) een nieuwe versie (update) van het spel moeten uitbrengen… commercieel niet interessant.

            1. Daar zijn zat andere oplossingen voor; bijvoorbeeld een socat-achtige aanpak waar je het netwerkverkeer onderschept met een extern tooltje en het in TLS verpakt, ongeacht of je zelfs maar toegang hebt tot de broncode van de originele applicatie. Dit is dus absoluut geen excuus.

                1. Dat geldt voor zoveel maatschappelijk wenselijke zaken. Als je het als winkel allemaal maar onnodig veel werk vindt om je klantgegevens veilig op te slaan, dan heb je ook pech; want die verantwoordelijkheid heb je gewoon – zowel praktisch, als ethisch, als nu ook juridisch. Ik zie niet waarom dat hier ineens anders zou zijn “omdat internet”.

          2. Ik heb bewust geprobeert om ssl te implementeren, maar het spel (call of duty 2, 10 jaar oud) ondersteunt dit nou eenmaal niet. Welke maps gespeeld worden is publieke data welke vanaf de server gelezen kan worden door wie dan ook.

            Code execution is zeker een puntje, maar niet iets wat ik als een groot risico zie.

            1. Ik heb bewust geprobeert om ssl te implementeren, maar het spel (call of duty 2, 10 jaar oud) ondersteunt dit nou eenmaal niet. Welke maps gespeeld worden is publieke data welke vanaf de server gelezen kan worden door wie dan ook.

              Zoals ik hierboven ook al beschreef, kan het dus wel met een socat-achtige aanpak.

              Code execution is zeker een puntje, maar niet iets wat ik als een groot risico zie.

              Dat kun je vinden, maar dat is het dus wel. Juist spellen zijn vaak een erg goede vector voor dit soort aanvallen, omdat ze doorgaans vol zitten met dit soort bugs, ze niet gemakkelijk te vervangen zijn, ze na release niet vaak meer bijgewerkt worden, en er peer pressure bestaat om de software te blijven gebruiken.

      4. Elke browser kan tegenwoordig wel https ( = http + TLS) praten, dus voor gewone websites is het geen enkel probleem. Misschien moet je je site-software op een paar plekken fixen als er ergens expliciet “http://” URLs staan, maar dat is alles.

        Een groter probleem is als je niet met normale browsers communiceert, maar met iets anders; ofwel met client-side software die een http-gebaseerde web API gebruikt, ofwel met een niet-http protocol. Invoegen van https zou dan de compatibiliteit kunnen breken.

        Een voorbeeld van zo’n set-up is een systeem voor multiplayer spellen waarbij spelers elkaar op het internet kunnen vinden. Mensen die een spel starten maken een server aan, en melden die server aan bij een “meta-server”, die is geïmplementeerd als pagina op een website. Anderen kunnen dan op die pagina zien welke servers online zijn, en daar mee doen met spelen. Dit moet allemaal in-game, dus het spel zelf moet communiceren met de webserver. In een eigen voorbeeld kan je zien dat zelf HTTP implementeren niet zo moeilijk is; TLS erbij stoppen vereist het ombouwen van de software, zodat er een TLS library wordt gebruikt (extra dependency!); dat maakt het allemaal veel lastiger. Dit ombouwen vereist expertise en tijd; die zijn niet altijd aanwezig, en als ondersteuning van oude closed source software nodig is, kan het wel eens erg lastig worden.

  2. Blijf met je tengels van de inhoud van mijn VPS af! Niet alleen omdat het míjn omgeving is. Maar als de hoster vanwege deze simpele reden al aanpassingen aan mijn systeem mag maken. Dan is het hek van de dam voor allerlei verzoeken waar ik méér problemen mee heb.

    1. Mijn lezing van het probleem was dat het gaat om websites, niet vps’en.

      Overigens zou ik als ik de vraagsteller was deze policy instellen voor alle nieuw aangemaakte accounts en bestaande sites ongemoeid laten (of een opt-in geven). Er kan best veel stuk aan een site die er nog niet op voorbereid is: als hij bijvoorbeeld binnen zijn site content inlaadt over http, dan breekt dat en/of krijg je mixed-content warnings.

      1. Mijn lezing van het probleem was dat het gaat om hosting providers geen website providers alleen. Mijn VPS wordt ook gehost bij een hosting provider en draait ook een website. Ook eentje zonder SSL/TLS.

  3. Prima dat je je klanten hiertoe wil dwingen, maar dan wel graag met een uniek IP adres per website, zodat het ook met oude computers blijft werken.

    Ik zou trouwens een andere hoster gaan zoeken dan; ik wil mijn klanten niet opzadelen met mogelijke “mixed content” foutmeldingen.

  4. SSL is prima, graag zelfs. HSTS zou ik niet doen zonder expliciete toestemming, dat vermindert de mogelijkheid van je klant om naar een provider zonder SSL over te stappen. Houd even rekening met de gevolgen voor SEO, als je aan google niet aangeeft dat het base url verandert (van http:// naar https://), kan het gezien worden als duplicate content met een langere ranking. En bied de klant de optie een echt ssl certificaat te kopen, want lets encrypt is niet door 100% van de browsers ondersteund.

  5. Het lijkt me beter dit naar de klant toe te brengen als een advies: “Wij raden u ten zeerste aan SSL/TLS te gebruiken en we hebben dit voor u geautomatiseerd, klik hier om dit proces te starten.”. Dit zou het al heel wat vriendelijker en gemakkelijker maken, lijkt me.

  6. Er zijn situaties waarin https-only ongewenst is (zie hierboven); ik denk dus dat de http-mogelijkheid moet blijven bestaan voor klanten die daar in het verleden gebruik van maakten. Dat zou pleiten voor opt-in; het nadeel van opt-in is dat een hele volksmassa van sites waarvoor het allemaal niets uit maakt dan ook op http blijft hangen.

    Zou het niet beter zijn om van elke site-beheerder te eisen om expliciet te kiezen tussen wel of niet https-only? Misschien met een wizard erbij, waarbij site-beheerders kunnen invullen hoe hun site wordt gebruikt, en de wizard daarna advies geeft. Je moet ook de mogelijkheid bieden om van https-only terug te schakelen naar http+https, zodat de keuze minder ingrijpend en definitief voelt voor site-beheerders.

    Als je echt wilt dat mensen op https over stappen, zou je extra geld kunnen vragen voor het in de lucht houden van http.

    1. En de nieuwe klant die goede redenen heeft om http te willen? Stuur je die naar de concurrent? En wat doe je met een nieuwe grote klant met slechte redenen? Kun je als hoster de kwaliteit van de argumenten van je klant inschatten?

  7. Als een Hoster mij zou dwingen om SSL/TSL te gebruiken dan zou ik per direct overstappen naar een andere hoster! Ik weet namelijk prima wat ik doe en beveiliging is lang niet altijd noodzakelijk! Het toevoegen van beveiliging maakt sommige zaken soms erg complex en het zit bovendien in de weg van de server die ik gebruik voor het hosten van meerdere domeinnamen!

    Want wat is het probleem? Ik heb 1 server en daarop heb ik meerdere domeinen en subdomeinen. Bij het gebruik van SSL gaat IIS echter niet meer kijken naar het domein waarnaar wordt verwezen maar naar de eerste site die met SSL is beveiligd. Heb ik er meerdere dan ontstaan er conflicten. Nu heeft IIS8 dit wel opgelost maar echt handig vind ik het niet. Mede ook omdat certificaten kunnen verlopen en je dan weer door de gehele configuratie heen moet.

    En ja, voor gevoelige informatie gebruik ik SSL. Vandaar dat ik Google Apps gebruik voor mijn email en documentatie, omdat Google de boel goed weet te beveiligen. En ik gebruik wordpress.com om mijn eigen blog te hosten omdat zij ook de boel veilig houden en continu updaten. Maar de meeste sites die ik zelf ontwikkel hebben geen gevoelige informatie die beveiligd moet worden. Ja, mijn CV die ergens online staat, misschien. Maar dat is eigenlijk meer een soort statische web pagina’s.

    Ik ben eerder bang dat een hacker op mijn host weet te komen dan dat een hacker mijn site weet te kraken…

  8. Er zijn situaties waarin https-only ongewenst is (zie hierboven);
    […]
    en beveiliging is lang niet altijd noodzakelijk!

    Precies. Mijn site bijvoorbeeld is voor het allergrootste deel alleen server naar browser, van materiaal dat per definitie openbaar is, want het staat immers op een website. Waarom zou dat verkeer vercijferd moeten zijn?

    Het weinige dat andersom gaat, is bijvoorbeeld zoekwoorden van een opzoeking in een online woordenboek. Ik log dat niet. Hoezo is het erg dat in theorie een systeembeheerder ergens onderweg zou kunnen zien wat iemand opzoekt? Ook dan vind ik encryptie overkill.

    1. Waarom zou dat verkeer vercijferd moeten zijn?

      Omdat de bedoeling van TLS helemaal niet is om voor ‘geheime’ data gebruikt te worden. Je haalt hier twee dingen door elkaar: “secrecy” (data die slechts voor een selectief publiek bedoeld is) en “privacy” (het prive houden van je doen en laten).

      “Secrecy” is niet van toepassing op openbare data, maar dat is dan ook niet het doel van TLS. Het doel van TLS is om privacy te creëren. Je versleutelt niet de informatie op de pagina, maar het feit dat iemand er naar kijkt, ongeacht of de informatie waar ze naar kijken in principe vrij toegankelijk is.

      In die zin ben jij als beheerder helemaal niet in een positie om te beslissen of dit wel of niet noodzakelijk is; dit is een keus van de gebruiker, en de enige manier om die keus mogelijk te maken is om TLS standaard aan te bieden. Dat is waarom.

      1. Daar komt bij dat, als je alleen privacy-gevoelige gegevens via TLS uitwisselt, het feit op zich al dat een gebruiker TLS gebruikt een privacy-gevoelig gegeven wordt, net zoals je nu in de ogen van sommige mensen al een halve terrorist bent als je TOR gebruikt.

        Voor geloofwaardige privacy is het noodzakelijk dat niet alleen gevoelige, maar ook ongevoelige data beschermd wordt.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.