Mag ik mijn klanten verplichten SSL/TLS te gebruiken?

| AE 8734 | Beveiliging | 37 reacties

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

Deel dit artikel

  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.

      • 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.

      • 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!”

        • 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.

      • 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.

    • 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.

  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.

  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.

    • 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.

      • 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.

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS