site met zowel HTTP alsook HTTPS wenselijk?
Nu vraag ik mij het volgende af: op het moment dat je HTTPS gaat gebruiken, is het dan nog wenselijk om uberhaupt HTTP in je site te hebben. Hiermee bedoel ik dus HTTPS voor pagina's waar user data heen en weer geslingerd wordt en de rest (statische content) over HTTP, hiermee doel ik niet op mixed content perikelen, wat ongewenst is.
Een gemixte variant maakt dingen waarschijnlijk complexer, maar ik vraag mij toch af of het zinnig is om HTTP-ondersteuning te houden in een site waar HTTPS gebruikt wordt. Een aantal redenen die ik zou kunnen bedenken:
- sommige externe apparaten die van diensten of wat dan ook gebruik maken hebben mogelijk geen HTTPS-ondersteuning
- het is in sommige gevallen niet nodig om een pagina over HTTPS te serveren omdat er in wezen niets gevoeligs over de lijn gaat (maar zoals gezegd, het is dus de vraag of dit opweegt tegen de technische implicaties voor de ondersteuning van een mengvorm)
Dit is (dus) een vrij grote ontwerpbeslissing: heb ik één schakelaar waarbij ik alles in 1x op HTTPS forceer (of niet) of bouw ik voorzieningen in waarmee je per pagina kunt kiezen hoe dit geserveerd moet worden, met alle technische implicaties van dien.
Nu is het verleidelijk om die schakelaar te bouwen, en het zou alles aanzienlijk simpeler maken. De vraag is dan eigenlijk ook: zijn er (doorslaggevende) argumenten om dit niet te doen, zoals bovengenoemde redenen?
*neemt een slok koffie*
Ik zou het zelf toch gewoon doen, en dan gewoon voor de hele site of niet. Stel je voor dat je certificaat opeens verlopen is, of verkeerd ingesteld wat bij sommige browsers foutmeldingen geeft. Dan heb je liever even een site die bereikbaar is via http dan dat deze niet bereikbaar is via https.
Spreekt zich wel dat je je rewrite-rule even moet deactiveren in je .htaccess of configuratie van je webserver. Maar ook dat kan je automatiseren. Maar de vraag is: Hoe ver wil je gaat voor iets wat zelden tot nooit gebeurd. Een switch zou ik toch zeker aanraden. Veel softwarepakketten hebben deze.
Andersom merk ik dat vanuit veel programmeeromgevingen een HTTPS aanroep naar bijvoorbeeld een API nog vrij "lastig" is (SSL vs gewoon platte tekst over poort 80). Dan is "gewoon HTTP" (met evt. IP white listing en/of HMAC) dus toch nog wel gewenst.
En dan weer andersom: Soms wordt een stuk van jouw site in een iframe getoond, of bijvoorbeeld een plaatje "gelinkt", en als de hoofdsite dan HTTPS is, dan moet jouw site ook in HTTPS kunnen.
Zelf ken ik dus 3 standen:
- Zowel HTTP als HTTPS toestaan (en het aan de gebruiker laten; zie bovenstaande voorbeelden). Meestal voor "niet zo heftige sites" (enkel een beetje informatie; geen inlog).
- Alleen HTML pagina's ("normale gebruikers") naar HTTPS redirecten; overige calls mogen het nog steeds zelf weten (wederom de API).
- Alles naar HTTPS drukken.
Toevoeging op 14/04/2018 19:04:21:
Wat zijn trouwens de grootste "technische implicaties" waar je tegen aan hikt?
Rob Doemaarwat op 14/04/2018 18:33:08:
Wat zijn trouwens de grootste "technische implicaties" waar je tegen aan hikt?
Dat is op dit moment eigenlijk alleen nog een gevoel, maar ik kan mij zo voorstellen dat als je een site hebt waarbij je heen en weer pingpongt tussen HTTP en HTTPS dat er dan wat administratie geregeld moet zijn ten aanzien van authenticatie en cookies enzo. Interne navigatie zit verder wel okay omdat deze via methoden en configuratie worden opgebouwd dus daar heb ik al volledige controle over.
Toevoeging op 14/04/2018 23:17:14:
Maar zoals gezegd wordt het dus niet aanbevolen om te gaan "ping pongen".
3 voordelen:
1. Bezoekers zien dat alles beveiligd is, dat wekt vertrouwen
2. Zoekmachines (Google) waarderen https pagina's beter dan http pagina's
3. Browsers gaan straks waarschuwingen geven bij onbeveiligde http pagina's
Kortom ... alles via https.
Er is wel/ook een secure flag, die aangeeft of het cookie alleen ingesteld/verzonden zou moeten worden indien HTTPS wordt gebruikt. Als ik een gemixte site heb dan kan ik dus niet altijd dit soort secure cookies gebruiken.
Hostingpartijen verplichten hun afnemers ook niet om HTTPS te gebruiken maar bieden dat nog steeds als aparte "dienst" aan.
We zijn dus voorlopig nog niet zover dat alles enkel van HTTPS gebruik maakt wat mij betreft, maar het begint te komen.
Thomas van den Heuvel op 15/04/2018 01:20:14:
Er is wel/ook een secure flag, die aangeeft of het cookie alleen ingesteld/verzonden zou moeten worden indien HTTPS wordt gebruikt. Als ik een gemixte site heb dan kan ik dus niet altijd dit soort secure cookies gebruiken.
Ja, die bedoelde ik (...), en bij mixed kun je die dan dus idd niet gebruiken.
Quote:
Maar als ik uiteindelijk een oplossing kies wil ik graag zo min mogelijk uitsluiten en zorgen dat mijn maaksel zo compatibel mogelijk is.
Dat is een mooi streven, maar er gaat gewoon heel veel veranderen qua privacy.
Wat ik mij afvraag is het wenselijk om een product op de markt te brengen die de "oude" stijl (http) mogelijk maakt. Is het voor jou als developer wenselijk om het probleem of beter gezegd de onwil om geen https te willen gebruiken als klant. Ja, het is nog niet de standaard maar ik ben er van overtuigd dat https wel de standaard gaat worden. Is het dan geen beter idee om je klanten dan al de bewustwording mee te geven dat het zo eigenlijk zou moeten.
Laat ik een voorbeeld geven:
Een vereniging wil zo snel mogelijk een CMS systeem hebben om een mooie website te laten draaien.
Maar ze willen ook de administratie geïmplementeerd hebben. Dat MOET al gewoon via een ssl lijntje lopen.
Nu geef jij de mogelijkheid om daar die vereniging niet aan te laten voldoen, want och, dat kost extra bij zijn provider, is lastig, en dat doen we later wel regelen als het maar werkt. Maar als de privacy gevoelige gegevens op straat komt te liggen willen ze wel jou verantwoordelijk maken omdat jij de software hebt ontwikkeld.
Ik denk dat je dat niet moet willen.
Klinkt mooi een knopje om het aan en uit te zetten, en heel prettig als het allemaal nog in development is, maar live denk ik dat het toch echt geen handige optie is.
- Ariën - op 14/04/2018 17:33:08:
Ik zou het zelf toch gewoon doen, en dan gewoon voor de hele site of niet. Stel je voor dat je certificaat opeens verlopen is, of verkeerd ingesteld wat bij sommige browsers foutmeldingen geeft. Dan heb je liever even een site die bereikbaar is via http dan dat deze niet bereikbaar is via https.
Ach, een beetje zichzelf respecterende website stuurt ook een Strict-Transport-Security header mee, en dan is de fallback naar http niet eens meer mogelijk... ;-)
Dit is overigens een systeem voor persoonlijk gebruik, maar ik probeer nog steeds iets te maken wat breed inzetbaar is.
Misschien heb ik een "tegenvoorbeeld" gevonden: intranetten. Volgens mij is het daar lastig om HTTPS (makkelijk) in te zetten (certificaten werken niet voor "local names", d.w.z. servers met lokale naamgeving en/of gereserveerde (niet gerouterde) IP adressen) maar hier zijn blijkbaar wel opties voor.
Op een intranet zit je al min of meer op een afgeschermd netwerk, dus is het dan nog nodig (of uberhaupt goed mogelijk) om daar HTTPS in te zetten?
En nogmaals, ik geloof niet dat HTTPS een noodzakelijke voorwaarde is voor een "veilige" site, en omgekeerd, HTTPS biedt geen absolute garanties voor de veiligheid van een site.
Het is wel een voorwaarde op het moment dat je gevoelige gebruikersinformatie verstuurt. Met https voorkom je een 'man-in-the-middle attack'. Wordt er geen gebruikersinformatie verstuurd, dan heb je gelijk. Echter blijft dan nog steeds het feit overeind staan dat zoekmachines je lager gaan waarderen en dat browsers een waarschuwingsmelding gaan geven (klik).
Ik ben al over de streep wat betreft het nut en de noodzaak van HTTPS hoor :).
M.b.t. pagerankings, sluit mooi aan bij mijn "tegenvoorbeeld": voor intranetten zijn die niet interessant.
Het tegengaan van MITM-aanvallen is een argument voor het gebruik van HTTPS op het moment dat er persoonlijke data over de lijn gaat (en is tegenwoordig ook verplicht vanwege de wet bescherming persoonsgegevens?), 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 is nogal loos als iemand de omroep dat het water over enkele ogenblikken begint te golven onderschept ;). Of aanpast, for that matter.
Die vraag is volgens mij toch beantwoord ;-)
>> 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.
Blijft nog steeds overeind dat browsers gaan waarschuwen bij een http-pagina. En dat wil je niet. Ik kan me voorstellen dat het bij een intranet anders ligt, maar dan zou de keuze misschien niet moeten zijn http / https, maar internet / intranet. Ik weet niet of een browser ook bij een http intranet gaat mauwen als het geen https is.
Grootste probleem zit hem in de overgang van het http naar https bij een formulier beginnen sommige browsers direct te klagen over onbeveiligde verbinding.
Ander probleem was destijds de https certificering dat niet op een ip adres kon wegens geen ondersteuning.
Heb het destijds opgelost door een virtual apache server aan te maken op een gefingeerd url, poort: 443 & daar het certificaat te stallen, vanuit de http-pagina kun je dan probleemloos een https-pagina aanroepen zonder al te veel aan htaccres te sleutelen.
Met een beweging naar HTTPS op het web heeft dit waarschijnlijk ook tot gevolg dat er op den duur goede ( / betere) en slechte(re) partijen tussen gaan zitten. Dit is dus ook aan inflatie onderhevig.
Initiatieven als Let's Encrypt zijn (lijken?) dan nobel, maar als ik de uitleg van een hostingpartij lees waarom zij deze niet ondersteunen dan stelt mij dit niet echt gerust:
Quote:
We ondersteunen geen Let's Encrypt omdat aanbieders van gratis SSL-certificaten de identiteit van de aanvrager niet controleren. Het certificaat maakt weliswaar een versleutelde verbinding tussen browser en webserver mogelijk maar bevestigt niet dat de organisatie, die eigenaar is van het certificaat, legitiem is.
Is dit de eerste / een volgende kink in de kabel in de "chain of trust"?
En dan de grote partijen (*kuch*Comodo*kuch*), die op den duur dan wel de status "too big to fail" hebben, die laten ook wel eens steken vallen.
Dat komt, omdat Let's Encrypt alleen DV-certificaten (Domain Verified) aanbiedt. Als je bij Comodo -of wat voor certificatenboer dan ook- een DV-certificaat neemt, worden je gegevens ook niet gecontroleerd; daarvoor moet je een OV- of EV-certificaat hebben.
De check bij een DV-certificaat bestaat eruit dat je een bestandje in de root van je website moet zetten, of een bepaalde DNS-entry aan moet maken. Het is dus niet zo dat elke Pipo de Clown een certificaat voor je domein kan aanvragen.