[WEB] Security - HTTP links op een HTTPS pagina

[imp4ct]

Hoi

Ik zit met de volgende vraag. Als webontwikkelaar is het soms nodig bezoekers naar een "https" pagina te sturen, bv. voor in te loggen of om gegevens van je profiel te bekijken, een order af te werken, etc...

Nu is mijn vraag, is het OK om op een pagina die in "https" getoond wordt, links (gewone hyperlinks naar andere pagina's van hetzelfde domein, geen links naar content zoals bv. een afbeelding of css) te maken die starten met "http" ?

De reden dat ik deze vraag stel is de volgende. Naar site performance toe, is in het algemeen geweten dat een pagina over "https" laden een stukje trager is dan over "http", dus daarom leek het mij niet slecht om ervoor te zorgen dat alle pagina's die niet in "https" moeten getoond worden ook nooit een link krijgen die met "https" begint.

Maar.. is dit wel OK, op vlak van security en algemene "web-dev-regels"?

[Sebazzz]

Op niet-HTTPS kan je wellicht geen inloggegevens stelen als je inlogpagina HTTPS is, maar wel de cookie natuurlijk

[ Voor 13% gewijzigd door Sebazzz op 28-04-2014 09:59 ]

[imp4ct]

Sebazzz schreef op maandag 28 april 2014 @ 09:59:
Op niet-HTTPS kan je wellicht geen inloggegevens stelen als je inlogpagina HTTPS is, maar wel de cookie natuurlijk

De inlogpagina zou nooit in "http" getoond worden. 't Zijn gewoon links naar andere pagina's in de site, bv. link naar de contact pagina die bv. in de footer van de site staat, kan je die dan niet gewoon met "http" laten starten op een "https" pagina?

Trouwens.. logindata opslaan in een cookie is niet echt slim

[thof]

Ik meen mij te herinneren dat IE een waarschuwing gaf als je HTTPS gebied verlaat en verder gaat op HTTP. Helaas kan ik hier zo snel niets over vinden, dus wellicht zit ik er naast. Je mag sowieso geen HTTP content in een HTTPS pagina laten zien (mixed content).

[imp4ct]

thof schreef op maandag 28 april 2014 @ 10:06:
Ik meen mij te herinneren dat IE een waarschuwing gaf als je HTTPS gebied verlaat en verder gaat op HTTP. Helaas kan ik hier zo snel niets over vinden, dus wellicht zit ik er naast. Je mag sowieso geen HTTP content in een HTTPS pagina laten zien (mixed content).

Wat de mixed content betreft, daarvan ben ik op de hoogte.

Maar bv. als ik bij Amazon.co.uk mijzelf aanmeld en in m'n account aan't kijken ben (welke natuurlijk een "https" pagina is) en ik zie de links naar producten of andere categoriën dan zijn dat dus "http" links naar die pagina's.

[Voutloos]

imp4ct schreef op maandag 28 april 2014 @ 09:54:
Naar site performance toe, is in het algemeen geweten dat een pagina over "https" laden een stukje trager is dan over "http"

Die wijsheid is misschien ook een beetje achterhaald. Meet eens zelf of 't echt significant trager aka een echte bottleneck is? Zo nee, lekker alles https.

imp4ct schreef op maandag 28 april 2014 @ 10:06:
De inlogpagina zou nooit in "http" getoond worden.

Je probeert te beschermen tegen onder andere man-in-the-middle toch? Welnu, als iemand dat eenmaal kan doen, is het hoogstens een paar minuten meer werk om alle https links NAAR de inlogpagina te veranderen in http (danwel eigen proxysite welke wel https doet).

En kijk bijvoorbeeld ook eens naar HSTS.

[ValHallASW]

imp4ct schreef op maandag 28 april 2014 @ 10:06:
Trouwens.. logindata opslaan in een cookie is niet echt slim

Het punt is dat je cookie een token is waarmee de browser bewijst dat 'ie een gebruiker is -- het is effectief daarmee 'logindata' geworden. Als iemand dat token heeft dan kan 'ie zich op je site als die gebruiker voordoen.

Ik snap het probleem van https niet zo goed -- met persistent connections is het praktisch niet trager. De links hoef je niet handmatig van http naar https om te zetten: gebruik protocol-relative ('//en.wikipedia.org') urls. Vanaf een http-pagina worden die met http bezocht, vanaf een https-pagina met https.

[Waster]

Voutloos schreef op maandag 28 april 2014 @ 10:25:
[...]
Die wijsheid is misschien ook een beetje achterhaald. Meet eens zelf of 't echt significant trager aka een echte bottleneck is? Zo nee, lekker alles https.


[...]
Je probeert te beschermen tegen onder andere man-in-the-middle toch? Welnu, als iemand dat eenmaal kan doen, is het hoogstens een paar minuten meer werk om alle https links NAAR de inlogpagina te veranderen in http (danwel eigen proxysite welke wel https doet).

En kijk bijvoorbeeld ook eens naar HSTS.

Je impliceert dat HTTPS geen voordeel heeft ten opzichte van HTTP, omdat je de man-in-the-middle attack een stap eerder kan doen?

HTTPS beschermt natuurlijk ook tegen passieve aanvallen als sniffers om je logindata gewoon uit het dataverkeer uit te lezen.

[Voutloos]

Nee, dat staat er echt niet. Ik waarschuw alleen dat enkel login via https laten lopen wellicht niet zo waterdicht is als ts lijkt te denken.

Nogmaals, meten is weten. Ik zou zelf anno nu dus geen site meer opleveren met gedeeltelijk https, tenzij echt bewezen dat er een onoverkomelijke bottleneck is.

[drm]

imp4ct:
is dit wel OK, op vlak van security en algemene "web-dev-regels"?

Kort antwoord: Ja, opzich niks mis mee.

Iets langer antwoord: Meestal wil je session cookies en een aantal pagina's (zoals inloggen / registreren, dat soort spul) over https laten gaan. Meestal is het daarom handiger om links niet expliciet naar een protocol te laten verwijzen, maar de applicatie zelf de baas te laten zijn over of iemand naar https zou moeten switchen of niet. Op het moment dat iemand eenmaal een session cookie heeft en die wil je over https laten gaan, dan zul je toch ook al die andere pagina's over https moeten laten lopen, en niet ineens de gebruiker weer http laten gebruiken (want dan gaat toch weer ineens het cookie onversleuteld over de lijn)

Simpele vuistregels:
* Link alleen expliciet naar https en niet naar http
* Als je wel terug wilt forceren naar http, regel dat dan met een redirect en niet met een link
* Link alle assets vanaf andere domeinen met "//" (absolute url zonder http: of https: ervoor)
* Alle pagina's met forms over https
* Indien session cookies aanwezig: ook naar https

Ik heb overigens wel gemerkt dat het toevoegen van https een behoorlijke performance impact kan hebben, maar dat komt dan voornamelijk als je veel assets linkt op je site. Stel er moet elke keer voor 20 javascripts en 25 achtergrondafbeeldingen een "If-Modified-Since" request worden gedaan, moet elk van die requests afzonderlijk een complete SSL handshake doen. Dat merk je echt wel. Maar als je dat allemaal netjes in sprites en minified bestandjes hebt staan, en je zorgt dat de caching headers ok zijn, scheelt dat een hele hoop. Iets wat je sowieso al zou moeten doen, natuurlijk, maar het valt wel nog meer op over SSL.

[imp4ct]

drm schreef op maandag 28 april 2014 @ 22:22:
[...]
Kort antwoord: Ja, opzich niks mis mee.

Iets langer antwoord: Meestal wil je session cookies en een aantal pagina's (zoals inloggen / registreren, dat soort spul) over https laten gaan. Meestal is het daarom handiger om links niet expliciet naar een protocol te laten verwijzen, maar de applicatie zelf de baas te laten zijn over of iemand naar https zou moeten switchen of niet. Op het moment dat iemand eenmaal een session cookie heeft en die wil je over https laten gaan, dan zul je toch ook al die andere pagina's over https moeten laten lopen, en niet ineens de gebruiker weer http laten gebruiken (want dan gaat toch weer ineens het cookie onversleuteld over de lijn)

Simpele vuistregels:
* Link alleen expliciet naar https en niet naar http
* Als je wel terug wilt forceren naar http, regel dat dan met een redirect en niet met een link
* Link alle assets vanaf andere domeinen met "//" (absolute url zonder http: of https: ervoor)
* Alle pagina's met forms over https
* Indien session cookies aanwezig: ook naar https

Ik heb overigens wel gemerkt dat het toevoegen van https een behoorlijke performance impact kan hebben, maar dat komt dan voornamelijk als je veel assets linkt op je site. Stel er moet elke keer voor 20 javascripts en 25 achtergrondafbeeldingen een "If-Modified-Since" request worden gedaan, moet elk van die requests afzonderlijk een complete SSL handshake doen. Dat merk je echt wel. Maar als je dat allemaal netjes in sprites en minified bestandjes hebt staan, en je zorgt dat de caching headers ok zijn, scheelt dat een hele hoop. Iets wat je sowieso al zou moeten doen, natuurlijk, maar het valt wel nog meer op over SSL.

Bedankt voor het duidelijke antwoord!

Nu, ik heb qua "performance" wel m'n voorzorgen genomen, ik werk voor statische bestanden sowieso met een CDN (MaxCDN) .. en natuurlijk hier en daar ook de gekende hosted libraries van Google net JSCDN, wat op zich er al voor zorgt dat ook over https de site wel vlot genoeg draait.

Het vreemde is wel, websites zoals een Coolblue, Amazon en Bol (toch geen kleine spelers) die forceren dus ook hun gebruikers terug naar "http" (Bol en CB doen het met een 302 redirect) ook al ben je ingelogged, dus als ik jouw reactie goed begrijp dan worden die sessie-cookie's gewoon over "http" verstuurd eens ik gewoon in de winkel ben aan't rondsurfen na het inloggen?

Ik volg je standpunt wel, dat eens je ingelogged bent je "best" over https kan blijven gaan en in de toekomst zullen we er waarschijnlijk naar toe groeien dat al het verkeer over "https" zal verlopen (zie FB en Google) maar toch.. bij e-commerce gaat het ook vooral om performance en gebruikersgemak en als je site dan telkens 2 tot 4 miliseconden trager laad .. 't kan misschien toch invoeld hebben.

[OnTracK]

drm schreef op maandag 28 april 2014 @ 22:22:
Stel er moet elke keer voor 20 javascripts en 25 achtergrondafbeeldingen een "If-Modified-Since" request worden gedaan, moet elk van die requests afzonderlijk een complete SSL handshake doen.

Volgens mij klopt dit niet hoor. Er wordt één handshake gedaan en alle requests worden daarna hierover heen gedaan.

Als je spdy aanzet wordt er ook nog eens behoorlijk geoptimaliseerd hierin waardoor bij high-latency verbindingen (mobieltjes) https waarschijnlijk sneller is dan http. Als je spdy gebruikt wil je juist zo min mogelijk verschillende domeinen (CDN) gebruiken, omdat je per domein alsnog een keer een handshake moet doen.

Performance-achteruitgang zit hem eigenlijk alleen bij de server. Maar moderne hardware is zo snel dat dit eigenlijk niet noemenswaardig is. Sterker nog, je kunt met een kwartiertje je eigen code optimaliseren waarschijnlijk al àl het performance-verlies van https oplossen.

Mijn advies is: zodra er ook maar ergens ingelogd wordt, doe gewoon alles over https.

[ Voor 7% gewijzigd door OnTracK op 28-04-2014 22:50 ]

[ACM]

OnTracK schreef op maandag 28 april 2014 @ 22:47:
Er wordt één handshake gedaan en alle requests worden daarna hierover heen gedaan.

Er zal een handshake per verbinding gedaan worden. Doordat browsers proberen een aantal verbindingen op te zetten en die vervolgens hergebruiken zou je inderdaad een stuk minder handshakes (en nieuwe tcp-connecties) nodig moeten hebben dan de hoeveelheid requests die er gedaan moet worden.
Maar dat hangt natuurlijk wel weer af van allerlei zaken, zoals een fatsoenlijke instelling voor de maximale "keep-alive"-tijd in je webserver.

Als je spdy aanzet wordt er ook nog eens behoorlijk geoptimaliseerd hierin waardoor bij high-latency verbindingen (mobieltjes) https waarschijnlijk sneller is dan http. Als je spdy gebruikt wil je juist zo min mogelijk verschillende domeinen (CDN) gebruiken, omdat je per domein alsnog een keer een handshake moet doen.

Ik zou er voorlopig maar van uit gaan dat spdy een nice-to-have is, maar dat men dat nog niet daadwerkelijk gebruikt (buiten Google enzo).

Performance-achteruitgang zit hem eigenlijk alleen bij de server. Maar moderne hardware is zo snel dat dit eigenlijk niet noemenswaardig is. Sterker nog, je kunt met een kwartiertje je eigen code optimaliseren waarschijnlijk al àl het performance-verlies van https oplossen.

Vziw worden ook allerlei caches (ook forward- en backwardcaches) een stuk strenger zodra je met HTTPS browsed, dus ook clientside kan je daar wel degelijk effecten van ondervinden. Verder kan ik me voorstellen dat browsers een lager aantal parallelle verbindingen opzetten bij HTTPS dan bij HTTP, en als dat het geval is zal je ook op dat vlak wat aan de clientside inleveren. (maar ik zie er zo snel geen informatie over, dus wellicht maakt dat niet uit)

Afgezien daarvan moet je ook oppassen met het gemak waar je zo'n opmerking mee plaatst. Voor diverse sites zal het kloppen, misschien ook wel voor de topicstarter.

Maar ik denk dat we bij Tweakers geen significante winst meer kunnen boeken met een kwartiertje code optimaliseren en gezien de hoeveelheid pageviews die wij per seconde uitleveren zouden we wel degelijk wat extra belasting op de webservers zien... Overigens wordt een groot deel van ons https-verkeer via de ssl-hardware van onze loadbalancer geregeld, dus in de praktijk zal het ook bij ons meevallen

Mijn advies is: zodra er ook maar ergens ingelogd wordt, doe gewoon alles over https.

Maar je moet opletten dat al je inhoud dan ook via https moet kunnen werken zodat je gebruiker niet lastig wordt gevallen met allerlei waarschuwingen.

Zodra je advertenties of reacties van gebruikers (met embedded afbeeldingen e.d.) op je site aanbiedt kan je het al bijna vergeten

[OnTracK]

@ACM: Ik had het dan wel over het scenario van de TS, een webshop (die meestal niet het meest efficiënt zijn). En niet tweakers.net (laten we die discussie inderdaad laten, al blijft mijn mening op zich hetzelfde, maar performance-impact inderdaad niet)

Verder heb je HTTPS-sessions, die werken langer dan één request. Waardoor je niet voor ieder request een volledige handshake hoeft te doen. Dat scheelt vooral aan de serverkant processorkracht. Ook met parallele requests. Dat moet je als server natuurlijk wel ondersteunen, anders schiet je jezelf hard in de voet. Caches zijn eigenlijk precies hetzelfde, als je als server aangeeft wat mag gecached worden, dan gebeurt dat gewoon. Dus dan heb je alleen perfomance-verlies als je blind overstapt. Maar het hoeft verder niet. Als je goed oplet en instelt is het echt niet meer hetzelfde als 5 jaar geleden, en kun je ècht overstappen op https zonder teveel server-performance-verlies.

Verder draai ik bijvoorbeeld de lokale studentensportvereniging (geforceerd) over https (+spdy). Advertentieboer is de eis aan gesteld en die kon daar gewoon in mee. Reacties met embedded afbeeldingen is inderdaad lastig, maar dat mogen gebruikers bij ons niet.

[ Voor 51% gewijzigd door OnTracK op 29-04-2014 20:08 . Reden: linkje toegevoegd ]