Ik ben van plan om eigen geschreven hobbycode (een soort van framework/CMS) uit te bouwen, specifiek, om ondersteuning voor HTTPS te introduceren.
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?
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.
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... ;-)
Zelfs met gebruikmaking van HTTPS is het nog steeds mogelijk dat gegevens op straat komen te liggen. Wat dat betreft is ook HTTPS geen wondermiddel. HTTPS beveiligt alleen het transport, het beschermt je niet tegen brakke code :).
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.
>> 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).
Mijn vraag is (nogmaals) niet "waarom zou ik niet (definitief) overstappen naar HTTPS", maar meer "zijn er (voor nu) beweegredenen om HTTP-ondersteuning aan te houden" of ook "waarom zou ik niet enkel van HTTPS gebruik maken?".
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.
>> ... of ook "waarom zou ik niet enkel van HTTPS gebruik maken?"
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.
Leuke vraag en overigens groot probleem.
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:
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.
> omdat aanbieders van gratis SSL-certificaten de identiteit van de aanvrager niet controleren
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.
Dat geldt ook voor de nieuwe wildcard-certificaten van Let's Encrypt. Die moeten ook geverifieerd worden. Mogelijk ook later voor normale certificaten.
