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?
Elk hedendaags apparaat kent wel HTTPS. Dus ik zou niet eens meer naar devices kijken. Mijn antieke Nokia N95 die hier in de kast ligt als 'museumstuk' gaat al over zijn nek met SNI vermoed ik. Menig website werkt niet eens meer en laadt met een algemene nietszeggende foutmelding.
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.
Als je een gedeelte van je site via HTTPS aanbied wordt security technisch meestal aanbevolen om dan meteen de hele site via HTTPS te serveren. Anders zou een man-in-the-middle aanvaller alsnog de "klik hier om in te loggen" link op een HTTP pagina kunnen kapen, en de (nietsvermoedende) gebruiker naar een kopie pagina door kunnen sturen (de gebruiker let dan toch niet meer op, en voert gewoon z'n wachtwoord in).
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.
[size=xsmall]Toevoeging op 14/04/2018 19:04:21:[/size]
Wat zijn trouwens de grootste "technische implicaties" waar je tegen aan hikt?
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.
Als je voor beide versies (HTTP / HTTPS) dezelfde domeinnaam gebruikt, en het PHP sessie cookie niet als HttpOnly is gemarkeerd, dan gebruik je in beide versies dezelfde sessie, en merk je d'r dus weinig van als je van de ene smaak naar de ander ping/pongt (qua sessie, maar dito dus voor andere cookies).
[size=xsmall]Toevoeging op 14/04/2018 23:17:14:[/size]
Maar zoals gezegd wordt het dus niet aanbevolen om te gaan "ping pongen".
@Rob, volgens mij had httponly weinig van doen met HTTP(S). httponly gaf volgens mij alleen aan dat het cookie niet via een scriptingtaal (zoals JavaScript) ingesteld kan worden, maar enkel toegankelijk is voor het HTTP-protocol (dit omvat ook HTTPS lijkt mij).
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.
Ik hoor wat je zegt @Ozzie, en ben die argumenten zelf ook al tegengekomen. Maar als ik uiteindelijk een oplossing kies wil ik graag zo min mogelijk uitsluiten en zorgen dat mijn maaksel zo compatibel mogelijk is.
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.
Als je je framework wil gaan verkopen dan snap ik je gedachtegang. Ik ging er vanuit dat het alleen voor eigen gebruik was. Dan zou je dus moeten afwegen wanneer je verwacht dat je framework klaar is. Is dat binnen nu en een paar maanden, dan kan ik je beweegredenen volgen. Is het echter over een jaar, dan vermoed ik dat https de standaard zal zijn. De vraag is of het zinvol is om allerlei extra checks in te gaan bouwen, waarvan je nu eigenlijk al weet dat het in de nabije toekomst niet meer relevant zal zijn. Natuurlijk kun je die checks er in de toekomst uit slopen, maar je kunt ook besluiten om ze er niet in te bouwen. Scheelt je 2x tijd ;-) En ik denk dat jij naar klanten goed kunt verklaren waarom je alles naar https forceert.
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.
