Dilemma: moet Tweakers https inzetten?

Bij Tweakers proberen we goed op de beveiliging van onze code en systemen te letten. We letten er tijdens het programmeren op dat we de standaardfouten niet maken en omdat er altijd wel iets tussendoor kan slippen laten we bovendien af en toe een PEN-test uitvoeren. Ook zijn er vele bezoekers die eventuele fouten die ze tegenkomen bij ons melden en soms zelfs actief op zoek naar dergelijke bugs gaan (waarvoor dank!).

Daar komt ook af en toe de vraag bij naar voren waarom Tweakers niet standaard via https werkt of waarom er dan niet op zijn minst een optie van wordt gemaakt.

We hebben intern die discussie pasgeleden weer gevoerd. De conclusie was dat volgens ons de tijd toch nog niet rijp is. Maar ook werd ons duidelijk dat we het gewicht van de voordelen niet helemaal goed konden inschatten. De context is daarbij natuurlijk wel belangrijk, we zijn tenslotte geen bank of medische instelling. Sterker nog, veel van de informatie die je bij ons plaatst is bedoeld om publiek toegankelijk te zijn

Voordelen

Wij zien een paar voordelen. Puur het feit dat er alleen nog maar versleutelde informatie tussen jou en ons over de lijn gaat geeft al een gevoel van veiligheid en betrouwbaarheid. Bovendien kan er minder eenvoudig met de sessiegegevens aan de haal gegaan worden en kan er niet gezien worden wie je bent of wat je precies doet op Tweakers - maar wel dat je Tweakers bezoekt.

Nadelen

Nadelen zijn er natuurlijk ook, anders hadden we al lang de site omgezet . De twee belangrijkste nadelen zitten 'm in de impact op de clientside performance enerzijds en in de 'mixed content' anderzijds. De https-versie van onze frontpage (alleen de html) is volgens onze externe monitoring zo'n 10-20 milliseconde trager dan de gewone versie. Dat lijkt (en is) weinig. Met je ogen knipperen duurt tenslotte al zo'n 100 tot 400 milliseconden.

Maar een webpagina bevat doorgaans ook nog diverse afbeeldingen en javascript- en cssbestanden. Als je dat meeneemt, komt diezelfde monitoring-omgeving op respectievelijk 0,9 seconde en 1,7 seconde voor respectievelijk de gewone en https-versie. In die tijd kunnen snelle knipperaars vier keer met hun ogen knipperen en dat tijdsverschil vinden wij in ieder geval significant. Hieronder zie je de mediaan van beide frontpage-typen over de cijfers van een week.

Een ander nadeel dat https met zich mee brengt is 'mixed content'. Als een pagina die via https is ingeladen ook elementen bevat die via gewoon http werden ingeladen, dan wordt dat 'mixed content' genoemd. Dat gebeurt bij ons vooral met afbeeldingen, maar ook met video's en advertenties. Afbeeldingen die we zelf hosten kunnen we natuurlijk vrij eenvoudig via https laten lopen en er is ook wel een mouw aan te passen dat de afbeeldingen in bijna alle artikelen (inclusief dit) nog met http in de img-tags staan. Maar van afbeeldingen die gebruikers in het forum of productreviews plaatsen weten we gewoon niet of er een https-versie bestaat. Daar kunnen we dus niet zomaar https van maken en er zal daardoor in ieder geval in user generated content vaak sprake zijn van 'mixed content'.

Hoewel de daadwerkelijke impact daarvan minimaal is, zorgt het er wel voor dat je bij een bezoek aan dergelijke pagina's een minder enthousiast beveiligingsicoontje ziet in je browser. En dat ondermijnt natuurlijk weer het veiligheidsgevoel. Oudere versies van Internet Explorer geven je zelfs een heel aanwezige waarschuwingsbalk en laten die afbeeldingen ook daadwerkelijk niet zien.

Hoe nu verder?

Een risico bij beveiliging is dat ze ook kan omslaan in schijnveiligheid. Bekende problemen zijn de heartbleed-bug en de hacks bij DigiNotar. Beide lagen niet zozeer aan ssl, maar legden wel zwakke plekken in het principe of de onderliggende software bloot.

De gegevens die je op Tweakers achterlaat zijn bovendien zelden (echt) belangrijk, zelfs in de besloten delen van de site. Dus het is maar de vraag hoe belangrijk het is om dat allemaal te versleutelen. Sterker nog, toen we een paar jaar geleden een analyse van wachtwoorden van gebruikers presenteerden waren er diverse bezoekers die exact dat aangaven:

"Dat mensen op tweakers zwakke wachtwoorden hebben heeft denk ik ook te maken met dat het veel mensen helemaal niet uitmaakt of ze gehackt worden op tweakers.net."

"ik gebruik voor de 'minder' boeiende zaken hetzelfde makkelijke wachtwoord en ik gebruik bewust geen complexe wachten voor bijvoorbeeld tweakers"

Maar de vraag blijft staan: hoe nu verder? We zijn hoe dan ook niet van plan https nu of ooit weg te zetten als overbodige gimmick. Maar tegelijkertijd zien we ook (nu) niet voldoende voordeel in https om dat significante performance-offer te willen brengen en de problemen - die 'mixed content' gegarandeerd gaan opleveren - op te willen lossen.

We zijn op de hoogte van de ontwikkelingen van Spdy en http 2.0, maar verwachten dat een definitieve en stabiele implementatie in Apache, Varnish en onze loadbalancers nog wel even zal duren. Toch zien we dat voorlopig als het beste moment om dan opnieuw de keuze te maken en wellicht wel definitief over te gaan op https.

Help ons beslissen

Maar jullie kunnen ons hiermee helpen. Wat vinden jullie? Missen we voordelen of nadelen? Geven we te weinig of te veel waarde aan bepaalde voor- of nadelen? Onderschatten we de privacy-impact van de persoonlijke gegevens die hier achtergelaten worden?

Reacties (462)

[Verwijderd]

Ik zou altijd voor SSL gaan. Het zou geen discussie meer moeten zijn. Maar kennelijk is het dat bij jullie nog wel.
Omdat jullie belangrijkste argument de performance is begin ik daar eerst mee. Jullie doen een test en concluderen dat SSL trager is. Dat zal altijd zo zijn maar ik zou die test pas uitvoeren als je je server ook zo hebt geconfigureerd dat er met SSL performance in gedachten is nagedacht over de configuratie.

Als ik kijk naar jullie SSL configuratie:
https://www.ssllabs.com/s...e.html?d=www.tweakers.net
dan is die zeker niet gebouwd met snelheid in gedachte. Jullie hebben aardig jullie beste gedaan een veilige SSL configuratie neer te zetten maar denk bij snellere SSL aan het volgende:

- Van de Forward secrecy ciphers zijn de ECDHE sneller dan de DHE. Jullie hebben alleen DHE ciphers.
- 256 bit ciphers staan als eerste gesorteerd. 256 bit ciphers zijn sterker maar nog niet nodig. 128 bit AES is nog steeds zeer veilig. De extra veiligheid van 256bit is op dit moment te verwaarlozen maar kost wel rekenkracht en dus snelheid:
https://www.imperialviole.../25/strengthmatching.html
- Er is geen support voor SPDY en OCSP stapling. Zie:
https://www.imperialviole.../25/overclocking-ssl.html

Wat ik niet kan zien maar wat ook handig is om over na te denken is:
- Ensure That Session Resumption Works Correctly
- Use Persistent Connections (HTTP)
- Enable Caching of Public Resources (HTTP)
zie: https://www.ssllabs.com/d...nt_Best_Practices_1.3.pdf

- Zorg dat de certificate chain niet te groot is:
https://www.imperialviole.../25/overclocking-ssl.html
- Present all the intermediate certification authorities in the handshake
http://unhandledexpressio...y-tips-to-accelerate-ssl/

Pas als jullie HTTPS configuratie geoptimaliseerd is zou ik gaan vergelijken en dan pas de afweging maken of de extra veiligheid het waard is ten opzicht van de performance.

Waarom ik altijd voor SSL zou kiezen is dit
- Hier op mijn bureau liggen 2 waardebonnen. Beide als dank gekregen van grote Nederlandse websites die dachten dat ze alle belangrijke onderdelen van hun website versleutelde. Toch ging het in sommige uitzonderingsgevallen niet goed en gingen de gebruikersnamen en wachtwoorden van hun gebruikers zonder versleuteling over de lijn. Dit alle audits en test trajecten ten spijt! Met volledige site SSL zou dit niet zijn voorgekomen.
- In elke onbeveiligde website die een gebruiker opvraagt kan een netwerk hacker (denk NSA maar ook de KPN hacker van 2 jaar geleden) extra code toevoegen die er voor zorgt dat er malware wordt geserveerd aan de gebruiker. Alleen SSL met HSTS kan dit voorkomen. Het VPN argument geld hier niet want ergens gaat het alsnog onversleuteld de wereld in en is te onderscheppen!
- Je weet niet altijd wat er beschermt (had) moet(en) worden. Het is misschien niet perse de standaard Tweakers gebruiker die je moet beschermen maar wel net die ene! Stel je werkt bij Ordina en bekijkt ‘opvallend vaak’:
nieuws: Ordina: medewerkers vertoonden 'ongepast gedrag' bij aanbestedingen. Waarom zou iemand dat dan in zijn jaargesprek moeten uitleggen.
- Het web is groter dan Tweakers.net. Stel ik lees nieuws: Japanner krijgt twee jaar cel voor 3d-printen van functionerende revolvers en ga daarna opzoek naar 3d printers. Moet ik dan aangemeld worden als staatsgevaarlijk of vind je dat het niet mag uitlekken dat ik bezig ben met een winkel die 3d te printen dildo’s (zelf te configureren) aanbied )

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[Coyote76]

Aansluitend op bovenstaande:

Als tussenstap zou je de hele sessie kunnen versleutelen van gebruikers die zijn ingelogd. Het is niet meer van deze tijd om alleen HTTPS te gebruiken op het moment dat het wachtwoord nodig is en/of om je accountgegevens aan te passen.

[MadEgg]

Sterker nog, veel van de informatie die je bij ons plaatst is bedoeld om publiek toegankelijk te zijn

En daar heb je hem. Groot gelijk. Ik zie er bij tweakers ook weinig voordeel in om https te gebruiken en er zijn hele duidelijke redenen tegen. Vooral het mixed content verhaal is een hele sterke, op een site die op user-generated content draait is niet haalbaar. In ieder geval niet op het forum, de plek waar het nog de meeste meerwaarde zou hebben.

Wat mij betreft is de huidige methode waarbij voor het inloggen een https-verbinding gebruikt wordt en verder http een prima compromis.

[Verwijderd]

Eens.

Is het trouwens niet zo dat Google sites met https hoger in de resultaten plaatst?

[Verwijderd]

Correct!
http://googlewebmastercen...ps-as-ranking-signal.html

[redburn]

Nee, zo zwart/wit is het niet.

"[...] affecting fewer than 1% of global queries"

[Peetke]

Een betere vindbaarheid is cruciaal voor het aantal bezoekers van T.net en moet dus meegenomen worden bij de voordelen van https enablen.

Verder denk ik persoonlijk dat er wel degelijk veel persoonsgegevens over mijn account gaan:
-in en verkoop via Vraag en Aanbod: namen, bankrekeningnummers, financiële gegevens, adresgegevens.
-het bladeren door vacatures (erg persoonlijk en kan zijn dat mensen niet willen dat de baas of een familielid dit zou kunnen zien).
-De artikelen die ik in eigendom heb, staan in een privé-lijst afgeschermd op T.net, maar zijn dus wel te achterhalen als iemand je verkeer afluistert. Iemand met veel dure hardware kan dan een inbraak/overval doelwit worden.

[cbravo2]

Wat je eigenlijk zegt is dat https niet nodig is omdat vrije meningsuiting altijd inhoud dat je weet wie wat zegt.

Maar daar gaat het niet alleen om. Het gaat ook om een stuk privacy over wat je bekijkt (en wanneer). Privacy zorgt voor veiligheid.

[Reactie gewijzigd door cbravo2 op 24 juli 2024 18:00]

[Kain_niaK]

SSL beschermt je niet tegen het hacken van de tweakers server en het kopieren van de database.
SSL beschermt je niet tegen exploits op je browser, wanneer je bijvoorbeeld Tweakers over SSL bezoekt en er word een exploit uitgevoert tegen je browser dan bied SSL geen bescherming.
SSL beschermt je niet tegen het doorbreken van je anonimiteit. Wanneer iemand je verbinding tussen tussen de tweakers server en je computer wil kunnen afluisteren dan HEEFT hij je IP adres al en kan hij je dus min of meer al localiseren. Door naar al je andere data te kijken of die nu versteuteld is of niet blijft er van je anonimiteit niks over.

SSL beschermt dus bijna niks tegen anonimiteit, ze weten dat je tweakers bezoekt. Ze kunnen alleen niet zien wat je post, maar ja tweakers is voornamelijk een publiek forum. Dus iedereen kan zowiezo al zien wat je post. Maar die mensen weten je identiteit niet. De hacker heeft jou identeit al lang gevonden veeeeel eerder dan wanneer hij de SSL verbinding tussen je computer en tweakers server kraakt.

[VW-Arjan]

100% eens.

Je kunt niet verwachten dat eenieder die plaatjes post, deze vanaf een https lokatie linkt.
IE wordt toch nog door veel mensen gebruikt en als je dan elke keer dat je tweakers bezoekt een melding krijgt dat er iets met de beveiliging niet in orde is, terwijl dat wel zo is, oogt dat ook vreemd.

Immers werkt de site toch via https? waarom dan toch een veiligheidsprobleem melding?
Je moet het of helemaal doen, of helemaal niet, maar dat is mijn mening.

Er staat toch geen kritische data op tweakers van jezelf die koste wat het kost "veilig" moet zijn?

[Jester-NL]

Een van de voordelen van HTTPS sluit mijns inziens aan bij het publiek ttoegankelijk zijn.
Google heeft onlangs laten weten zoekresultaten met https voorrang/hogere vindbaarheid te willen gaan geven: http://googlewebmastercen...ps-as-ranking-signal.html

[Nyarlathotep]

Ik zie alleen maar meer nadelen. En een gevoel van veiligheid... Daar koop ik niks voor. Nu weet ik dat hier op Tweakers te pas en te onpas met het woord privacy wordt gesmeten (het is echt een stokpaardje geworden) maar dat is hier nauwelijks aan de orde.
Tweakers bevat geen vertrouwelijke informatie dus van mij hoeft het allemaal niet.

Wat is trouwens de impact als je Tweakers bezoekt vanaf een systeem waar het nodige is dichtgetimmerd? Ik bezoek Tweakers vaak vanaf een pc bij mij op kantoor (zoals nu). Ons systeem is behoorlijk zwaar beveiligd, en filmpjes werken bijvoorbeeld niet.
Ik weet zeker dat een hoop mensen overdag op kantoor zitten te Tweakeren.

[Verwijderd]

Helemaal mee eens, wat boeit de veiligheid van tweakers? Iemand kan niets met mijn account, ik zit alleen nieuwsitems te lurken en reageer af en toe. Het zou eerder relevant zijn voor alleen het forum bijv. maarja, daar wordt ook niets boeiends gedeeld.

In jullie situatie is https een hype waar jullie niet aan mee hoeven te doen. Leuk dat iemand zichzelf slim vind op jullie kantoor en het persé wilt, maar zorg maar eerst dat er iets is dat überhaupt bescherming nodig heeft. Leuk dat jullie ons hierbij betrekken hoor, maar ik ken niet eens een nieuwswebsite die https heeft.

Misschien waarom het een overweging waard is; SEO. http://googlewebmastercen...ps-as-ranking-signal.html
Maar zelfs dan.. in Nederland zijn jullie al beetje de grootste..

[Verwijderd]

Het is niet interessant om iets met jou account te doen echter zijn jou reacties natuurlijk zeer interessant. Wanneer ik bijvoorbeeld bij een bedrijf werk en reageer op bepaalde artikelen dan kan dit bedrijf eenvoudig een flag laten opgaan bij bepaalde trefwoorden. Laten we het helemaal maar niet hebben over alle forum reacties en blogs. Tweakers die hypotheek vragen plaatsen en hun loon vragen publiceren.

[Verwijderd]

Ja maar dat bereik je ook als er https is Gewoon crawlertje derop zetten en je heb zo een paar leuke tweakers te pakken. Zou dom zijn om mijn verkeer te proberen onderscheppen als het veel makkelijker kan lol

Oja (had niet goed gelezen), en vanuit je werkgever..? Nope. Waar ik werk is dat totaal irrelevant. Maar dan is het inderdaad iets interessanter.. beetje werkgever doet dat niet en al ben je bang van wel, dan moet je gewoon iets als tor gebruiken.. Want als ze zo ver gaan, zou ik überhaupt niet op tweakers zitten (doe ik namelijk al teveel)

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[Verwijderd]

Als je systeem zodanig is dichtgetimmerd dat je geen https kunt gebruiken, om veiligheidsredenen bovendien, is daar iets heel erg mis.

[Venator]

Ik zie de volgende voor-en nadelen:

• Beveiliging: HTTPS beschermd gebruikersdata tegen man in the middle aanvallen (ook al is die kans niet enorm groot)
• Industrie Standaard: HTTPS is een must voor ieder online bedrijf of entiteit welke werkt met betaalkaarten en zou de Payment Card Industry Data Security Standard (PCIDSS) moeten volgen.
• Vertrouwen: Met een steeds grotere bewustwording van veiligheid en beveiliging zullen gebruikers eerder gaan kiezen voor websites die wel https gebruiken.

En dan heb je nog een stukje Google Ranking. Google geeft een voorkeur aan sites die met HTTPS werken in de pageranking. Voor nu ligt de impact echter op minder dan 1% van de zoekopdrachten, maar dat wordt meer.

Nadelen:

• Extra kosten: Je moet een certificaat aanschaffen en periodiek vernieuwen tegen een bedrag.
• Tragere site: De site kan trager worden door de encryptie/decryptie die plaats moet vinden. Kan vooral problematischer zijn op langzamere devices/slechtere verbindingen.
• Issues met dubbele content: Je zult een HTTPS versie ometen maken voor alle content. Zie ook de opmerkingen over mixed content.
• Crawling & Indexing problemen: Beetje een no-brainer voor T.net denk ik, maar: sta het crawlen naar robots.txt e.d. wel toe, ook als er HTTPS wordt gebruikt en sta search indexing toe door niet de "Noindex" meta tag te blijven gebruiken.
• Sociale impact: Het voeren van HTTPS kan deels ook betekenen dat bepaalde informatie niet zo maar meer gedeeld kan worden, waardoor ook sociale mogelijkheden beperkt worden.

Kleine toevoeging nog:

Over adverteerders gesproken en mixed content: Als je een website met HTTPS voert en je gebruikt bijv. een advertisement delivery network als AdSense van Google, dan zegt Google het volgende: Als je besluit een website in HTTPS te gaan voeren, dan halen wij alle non-SSL compliant advertenties uit de bieding van AdSense, waardoor de veilingdruk verlaagt wordt en er minder inkomsten gegenereerd worden op de pagina's waar advertenties geplaatst worden. Minder concurrentie op de markt voor SSL-compliant advertenties betekent dan lagere prijzen om te adverteren t.o.v. HTTP = minder inkomsten.

Nu weet ik niet hoe het hier precies zit, maar het kan dus per pagina ook gewoon inkomsten schelen voor Tweakers.net op de korte tot middellange termijn.

Daarnaast is er voor mixed content zeker een vraagstuk, maar ook voor bijvoorbeeld surveys en polls, waarin een persoonlijke voorkeur wordt vastgelegd van gebruikers. Deze is nu ook niet beveiligd, terwijl het wel informatie is waarmee een profilering van een gebruiker gedaan kan worden. Zelfde geldt natuurlijk ook voor de reacties en het forum. De vraag is dan denk ik hoe zwaar dat telt op een website waar juist de snelle levering van publieke content (en de opinie/discussie daarover) belangrijk is.

[Reactie gewijzigd door Venator op 24 juli 2024 18:00]

[Verwijderd]

• Sociale impact: Het voeren van HTTPS kan deels ook betekenen dat bepaalde informatie niet zo maar meer gedeeld kan worden, waardoor ook sociale mogelijkheden beperkt worden.

Die begrijp ik niet, hoe werkt dat?

[Venator]

Bepaalde info die je nu deelt is publiek domein. Met het inschakelen van HTTPS wordt dat exclusief tussen jou en Tweakers.net. Dat is informatie die vaak niet zo maar gebruikt kan worden om bijv. sociale impact en dergelijke te meten of te analyseren. Het kan ook betekenen dat content-sharing naar andere netwerken die geen HTTPS gebruiken (bijv. embedden van content, waarmee je eigenlijk weer een type mixed-content in het leven roept) lastiger zal verlopen voor gebruikers en men het links laat liggen. Daarmee verliest je informatie ook sneller zijn sociale waarde.

[CAPSLOCK2000]

Ik ben voor HTTPS.

Mijn redenen zijn:
- als alles HTTPS is hoef je je nooit meer af te vragen of een bepaalde pagina HTTPS moet gebruiken. Je kan je daar dus ook niet in vergissen. Ik vind dat HTTP overal (dus niet alleen op Tweakers) moet worden vervangen door HTTPS.
- er wordt regelmatig enigzins gevoelige of persoonlijke informatie gepost, met name op het forum. Andere Tweakers mogen dat weten, die zien toch niet meer dan een nickname, maar de baas hoeft niet mee te lezen. Dat is geen harde veiligheid, de baas/netwerkbeheerder kan ook Tweakers bezoeken, maar het helpt tegen passief monitoren.
- een veilig gevoel is belangrijk voor hoe mensen de website ervaren en hoe vrij ze zich voelen om hun hart te luchten.
- https-only laat zien dat Tweakers vooruitstrevend is, niet onbelangrijk voor een tech-site.
- tweakers is een bovengemiddeld sappig doelwit voor misbruik en spionage. Zie (Watering Hole attack.. Nu heb ik ook bovengemiddeld veel vertrouwen in de beheerders van Tweakers, maar niemand is perfect en alle beetjes helpen.
- mixed content is inderdaad vervelend maar hoe langer je wacht hoe groter het probleem wordt. Als je ooi https-only wilt gaan draaien (en ik verwacht dat dit vroeg of laat gaat gebeuren) kun je maar beter zo snel mogelijk beginnen, iedere dag die je wacht komt er HTTP-content bij. Een goede eerste stap bij een overgang naar HTTPS-only is afdwingen dat nieuwe content via HTTPS bereikbaar is.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 18:00]

[xelnaha]

FYI, HTTPS helpt helemaal niet voro je puntje 2: zelfs met https wordt het prima leesbaar voor de baas. HTTPS helpt alleen het verkeer tussen server en client te encrypten, niet het onleesbaar maken voor iedereen die niet ingelogd is.

[CAPSLOCK2000]

Dat leg ik uit in de derde zin van dat puntje; blijkbaar niet duidelijk genoeg. Het voordeel van HTTPS is dat je baas/beheerder actief op zoek moet gaan naar je posts en ze niet toevallig langs ziet komen op de gateway/ids/firewall/proxy/whatever.

Ik sprak vanmiddag nog iemand die het heeft meegemaakt dat een systeembeheerder "hey, leuke vakantiefoto's heb je" over de afdeling riep. Die had hij zien langskomen bij het monitoren van de uitgaande verbinding.

[33Fraise33]

Ik vind dat tweakers zeker mag overstappen op https. De voordelen winnen het hier van de nadelen vind ik. Als ik even langer moet wachten om de site te laden heb ik dat er voor over als het verkeer via https verloopt.

En waarschijnlijk komen er nog wel wat updates voor https waardoor deze uiteindelijk toch weer sneller laadt.

[Reactie gewijzigd door 33Fraise33 op 24 juli 2024 18:00]

[Kees]

Versleuteld verkeer zal (tot ndn eens uitgerold word) altijd langzamer blijven dan niet versleuteld verkeer, domweg omdat je meer 'round trips' moet doen voor https.

En vergis je niet; de getallen die we noemen zijn eigenlijk een beetje misleidend; Deze externe monitor zit ergens in een datacentrum in Nederland met een dedicated lijn en hoge snelheid en zal dus in het algemeen veel sneller zijn dan de gemiddelde gebruiker.

Als we naar daadwerkelijke performance gehaald door bezoekers (gemeten met NewRelic) kijken dan zien we de volgende cijfers (uiteraard voor de non-https versie, gekeken over de afgelopen week):
- Mediaan bezoekers: 1,1s
- Gemiddelde bezoeker: 2,0s
- 95-percentiel: 5s

Als we dan kijken naar de performance van de externe monitoring:
Externe monitoring, http->https: 0,88s -> ~1,7s = 1,9x langzamer

Dan zal voor de bezoekers ongeveer dit de performance zijn:
- Median: http: 1,1s -> https: 2,1s
- Gemiddelde bezoeker: http: 2,0s -> https 3,8s
- 95-percentiel: http: 5s -> https: 9,5s

Waarbij wel opgemerkt dient te worden dat dit behoorlijk variabel is en afhangt van heel veel factoren.

Voor meer dan 50% van de gebruikers echter zal de site vertragen van ~2s naar bijna 4s, dat is zeker goed merkbaar.

[Reactie gewijzigd door Kees op 24 juli 2024 18:00]

[bartvb]

Dit is wel een erg kort door de bocht berekening. De tijd die Tweakers nodig heeft om pagina's te genereren verandert niet als je een andere verbinding hebt, je kan de factor 1,9 binnen NewRelic dus niet zomaar extrapoleren in http vs https waarbij het vooral over het aantal roundtrips gaat.

Net even snel een Webpagetest.org test gedaan:

http://www.webpagetest.or...1024_AH_F7H,141024_HH_F78

Het lijkt erop dat webpagetest het wat druk heeft (de timings van de verschillende runs liggen best ver uit elkaar) maar op een gesimuleerde kabelverbinding lijkt het verschil tussen https en http vrij minimaal. De veilige variant lijkt in dit specifieke geval zelfs sneller

Nu is ook daar best het e.e.a. op af te dingen. Het gaat hier om een gesimuleerde kabelverbinding, kijken naar prestaties van een mobiele/high-latency verbinding is interessanter. Verder gaan we hier uit van Chrome en Google doet nogal z'n best om https snel te laten werken. Maar dan nog, de verschillen in snelheid lijken niet zo groot als Kees hier stelt. Wat dat betreft eigenlijk ook wat teleurgesteld in het stuk van Arjan. Ik had daar wat diepgravender benchmarks verwacht dan een simpele vergelijking van NewRelic.

Hier iig een voorstander van https. Belangrijkste argument is dat het positief is als zoveel mogelijk sites overgaan naar https. Wat ik wel/niet doe op Tweakers.net is niet zo heel boeiend, maar als je dat samenpakt met wat ik lees op nu.nl, De Correspondent en Blendle dan krijg je toch best een behoorlijk compleet beeld van mijn interesses. Da's niet perse een ramp, maar wel vervelend/vrijheidbeperkend.

Wat mij betreft komt er een vervolgartikel waar het snelheidsargument wat verder wordt uitgewerkt. Ook interessant voor de andere sitebeheerders op Tweakers.net Ik zit zelf namelijk met hetzelfde dilemma

Overigens is Google DFP/AdSense/AdX tegenwoordig helemaal geschikt voor https en de problemen met UGC zijn op te lossen door dat niet meer toe te staan De avatars zijn om diezelfde reden even terug ook omgezet naar 100% gehost via Tweakers.net. Vreemd dat dat niet is gebeurd met [img] plaatjes.

edit:

Ok, ik kon het niet laten:

http://www.webpagetest.or...1024_G1_G1E,141024_FS_G12

https vs http via een (gesimuleerde) 3G verbinding met 300ms RTT.

Dit overzichtsplaatje laat een wat extremer beeld zien dan de twee onderliggende tests suggereren:
http://www.webpagetest.org/result/141024_G1_G1E/ (http, 9 sec 1e view, 3.5 sec 2e view)
http://www.webpagetest.org/result/141024_FS_G12/ (https, 12 sec 1e view, 4 sec 2e view)

Dus ja, zeker verschil, maar niet zo dramatisch als uit de NewRelic extrapolatie wordt afgeleid.

Overigens wordt via https://tweakers.net/ niet alles via https afgehandeld (b.v. de smileys niet) maar wel veel. Google Analytics, alle advertenties, CSS, JS.

[Reactie gewijzigd door bartvb op 24 juli 2024 18:00]

[ACM]

Zoals je in jouw schermen kan zien, gaat niet al het verkeer via HTTPS in je HTTPS-voorbeeld. Juist de wat grotere afbeeldingen (die van ic.tweakimg.net) gaan daar vrijwel allemaal via HTTP.

Dus hoewel het verschil lastig te voorspellen is (het hangt idd af van latency, browser-stack, server-optimalisaties, e.a.), doet ook vergelijking dat niet helemaal goed

Wat wel voorlopig bij HTTPS zal bijven is de extra serie round-trips alvorens de verbinding opgezet is. En hoe vaker je dat extra moet doen, hoe meer effect het heeft op de totale wachttijd. Die round-trips vervallen niet als je een 'betere' ssl-stack op je server zet.

Voor wat betreft img-plaatjes. We zitten niet te wachten op weer een hele reeks perikelen die ontstaan door dat allemaal te hosten/proxien...

[bartvb]

True, niet alles gaat via HTTPS maar het belangrijkste (eerste pagina, JS, CSS, advertenties). Het ophalen van grote afbeeldingen is, naar mijn mening, juist het minst interessante in deze vergelijking. Het snelheidsverschil zit voornamelijk in het opzetten van de verbinding, de throughput is vrijwel helemaal gelijk. Als de grotere afbeeldingen van dezelfde server komen als de CSS/JS/kleine plaatjes dan zou dat in de vergelijking weinig uit moeten maken.

Maar feit blijft dat het snelheidsverschil niet heel dramatisch is. Of iig niet heel dramatisch lijkt en snelheid is in het artikel en in de reacties van Kees toch wel een van de belangrijkste argumenten.

Maar wat dat betreft ben ik al erg blij met het feit dat tweakers.net bereikbaar is via HTTPS voor de mensen die daar behoefte aan hebben. Op zich ben ik voorstander van alles by default omzetten naar HTTPS maar snap goed de tegenargumenten. De huidige situatie is dus redelijk 'best of both worlds'. Mensen die graag HTTPS gebruiken kunnen dat doen (evt mbv een browser extensie), de bezoekers die de toegevoegde waarde (nog) niet zien krijgen een HTTP site.

En idd. Hopen dat HTTP 2.0 snel van de grond komt (hoewel SPDY/HTTP2 ook zo hun technische en meer filosofische nadelen hebben).

Wist trouwens niet van de problemen met het hosten/proxy-en van [img] content. Ik ga eens zoeken, benieuwd naar die discussie.

[Reactie gewijzigd door bartvb op 24 juli 2024 18:00]

[ACM]

Ik weet niet of daar een recente discussie over is. Maar het geeft sowieso uitdagingen op juridisch gebied (auteursrecht met name).

En dan zit je natuurlijk met het feit dat het uberhaupt gemaakt moet worden (en dus meer werk toevoegt) en extra requirements op het gebied van opslag op onze centrale storage oplevert.

Kortom, nog meer dingen om uit te zoeken/op te lossen

[bartvb]

Kwestie van [img] met externe plaatjes uitschakelen Dan lost dat probleem zichzelf na verloop van tijd vanzelf op zonder copyright problemen.

Of idd proxy-en. Dat is iig wat GitHub al een flinke tijd doet:

https://github.com/blog/7...hase-3-ssl-proxied-assets

Hoe dit in NL precies juridisch zit is een interessante vraag iig. Staat bij mij op de lijst om uit te zoeken. Als ik daar een definitief antwoord op heb laat ik het weten.

[ACM]

Ja, dat is wat tricky. En de topics als de "mooie jonge meiden" in de HK zal ook wel bol staan van auteursrechtentechnisch niet helemaal correcte bronnen, waar we dan met een proxy-dienst zelf ook nog wat verder in verwikkeld raken

[Kain_niaK]

Ik denk dat vele die hier reageren niet echt precies weten waar https je tegen verschermt en waar het niks mee te maken heeft. Wanneer het verkeer tussen jou computer en de tweakers server versleuteld is kunnen mensen die je verkeer onderscheppen nog steeds zien dat je verbinding maakt met de servers van tweakers. En wanneer ze je tweakers gebruikersnaam weten kunnen ze ook al je publieke post lezen. Wanneer de tweakers server gehackt word bied https ook geen enkele bescherming. Of wanneer je computer zelf gehackt is. Of wanneer iemand een MITM attack uitvoert. De enige bescherming is dan een waarschuwing in je browser dat er iets niet scheelt aan het certificaat. Etc etc etc.

Met security moet je altijd kijken, in hoeverre is deze bescherming een hoop nadelen en het opgeven van comfort het waard? Een password van 23 tekens bied en bepaalde context een hogere veiligheid dan een van 5 maar het is wel minder comfort.

Dus https op tweakers. Als het gedaan word elke keer als je wachtwoord of email adres verstuurd word, eventueel wanneer je ee n DM stuurt. Dat is meer dan veilig genoeg. In de meeste andere gevallen hoeft het verkeer echt niet versleuteld te zijn. SSL bied niet echt end to end encryptie in dit geval, zeker niet wannneer 99,9% van alle informatie die op tweakers binnen komt gewoon overversleuteld op de server word opgeslagen want het is voornamelijk een publiek forum. Wie gaat er tijd verspillen aan het afluisteren van individuele gebruikers wanneer hij ook kan proberen te hele server te hacken en de database te bemachtigen?

[incaz]

Maar uitgebreidere stats lijken mij wel interessant - wat gebeurt er nu werkelijk als ic.tweakimg.net via https gaat lopen? Wil je echt een uitspraak kunnen doen over de werkelijke nadelen op de performance, dan is een goede test denk ik minstens zo interessant als een theoretisch redeneren over roundtrips.

Verder, maar zo diep ben ik niet in de materie gedoken, lijkt me dat je de extra roundtrips een keer per host moet doen, en is het aantal hosts dat betrokken is bij een pagina op vrijwel alle onderdelen van tweakers behalve het forum beperkt, toch?

[33Fraise33]

Dit is inderdaad een merkbaar verschil maar is het dan niet mogelijk om tijdens de overstap nog wat specifieke optimalisatie te doen zoals in deze reactie uitgelegd wordt: http://tweakers.net/plan/...eaction=7276643#r_7276643 ?

En wat misschien ook een mogelijkheid is zoals tweakers hier beneden zeggen: enkel inlogpagina, profielpagina, karmastore enz. over https? Dit lijkt me een goed begin en deze pagina's zullen waarschijnlijk voor de meeste tweakers wat trager mogen laden.

EDIT: ik zie dat dit al zo verloopt blijkbaar

[Reactie gewijzigd door 33Fraise33 op 24 juli 2024 18:00]

[Verwijderd]

Ik zie niet in waarom https voordelen zou bieden. Jullie spreken zelf van een 'gevoel' van veiligheid, terwijl de eindgebruikers er niets bij winnen. Wat maakt het uit of
- een publiek beschikbaar artikel versleuteld of niet tot bij mij geraakt?
- je browser zegt dat heel de sessie van A tot Z perfect geëncrypteerd is ?
- het gegarandeerd over tweakers.net gaat en niet iemand anders?
- er man-in-the-middle-gewijs niemand de content gewijzigd heeft?

Zo lang jullie geen webshop openen of content hebben die privacy gevoelig is zie ik geen enkel voordeel en enkel nadelen, zijnde extra werk langs jullie kant en langere load tijden langs onze kant. Encryptie op een nieuwssite lijkt me een oplossing op zoek naar een probleem.

[Rainbow]

Wat ik in deze comment mis, en eigenlijk bijna alle comments "tegen" HTTPS, is de privacy.

Als ik via HTTP naar een site als Tweakers navigeer, kan iedereen die requests aftappen, en dus zo zien welke artikelen ik lees, waar ik op zoek, met wie ik interacteer, etc.

Als dat verkeer echter via HTTPS gaat, dan zijn deze requests versleuteld, en is dit niet af te luisteren.

Daarom vind ik het ook raar dat in het artikel op zich net gedaan wordt alsof er enkel een "gevoel" van veiligheid is, en er met geen woord gerept wordt over de daadwerkelijke voordelen voor de privacy van de bezoeker. Zeker tegenwoordig, waarbij al onze informatie op straat komt te liggen en massaal het internet afgetapt wordt, is het belangrijk dat we dit soort zaken belangrijk gaan vinden.

Persoonlijk bezoek ik Tweakers.net altijd over HTTPS, en heb amper problemen met mixed content, en dat requests af en toe een klein beetje trager zijn, merk ik ook vrij weinig van.

[Verwijderd]

Exact. Velen reageren met "nergens voor nodig, het is toch openbaar". Maar ondanks dat het hier inderdaad geen financiële of medische gegevens betreft, zijn er wel degelijk genoeg situaties denkbaar waarin je niet wil dat anderen (providers, werkgevers, wifi-deelgenoten enz) kunnen zien wat jij leest of schrijft.

Dus ik zou zeggen: minstens opt-in, zodat men in ieder geval de keuze heeft.

[SirLenncelot]

Ik gok dat Tweakers vooral een hobby is voor veel mensen. Er zijn natuurlijk twee soorten hobbys. Bijvoorbeeld:
- Voetbal
- Een wekelijkse vechtpartij in dorpscafe De Bezige Boer.

Uiteraard wil je niet dat jouw werkgever er van op de hoogte is dat je wildvreemde dronken een kopje kleiner maakt (voordeel https). Daarnaast zit je niet op voetbal omdat je niet wilt dat iemand kom kijken hoe je staat te ploeteren rechtsachter tegen die iets te dikke linksbuiten. (voordeel http)

De enige vraag die rest: in welke categorie hobby valt Tweakers?

ps. grote kans dat een aanzienlijk deel van de Tweakers in de tech-sector werkzaam is. http beperkt je in de mogelijkheden om kritisch op je "eigen" product te zijn. (voordeel https)

[marcelvb]

Ook handig dat je baas weet op welke personeelsadvertenties jij klikt.

[Eagle Creek]

Denk nou niet dat HTTPS daartegen beschermt. Je baas kan legio commerciële producten aanschaffen die de SSL-verbinding openmaken en weer netjes voor je werkplek dichtzetten.

Argument in de basis valide maar in de praktijk achterhaald.

[Miepermans]

Dit zal echter alleen maar werken, als er op de werknemer pc's een rootCA geinstalleerd is welke gesigned is door het bedrijf. In theorie mogelijk maar in de praktijk onhaalbaar omdat mensen ( lees, denkende mensen ) wel checken waar een certificaat vandaan komt.

Overigens hebben medewerkers ook rechten, en het inspecteren van datastromen zonder hiervoor expliciet toestemming te verlenen is een leuk vraagstuk. Zelfs als het bedrijf zich indekt door dit in een contract op te nemen is er altijd nog zoiets als bescherming van rechten van werknemers.

[Eagle Creek]

In theorie mogelijk maar in de praktijk onhaalbaar omdat mensen ( lees, denkende mensen ) wel checken waar een certificaat vandaan komt.

Het spijt me maar...

A) De niet-denkende mensen (= gros) valt dit niet op, die zien alleen een slotje.
de wel-denkende mensen (= minderheid) valt het wel op, meldt dit eventueel bij de servicedesk maar krijgt te horen dat dit vanwege bedrijfsbeleid zo is ingericht.

Werkt natuurlijk niet of minder effectief bij een BYOD-concept maar als je enige mogelijkheid is óf de site bezoeken via de interne CA óf niet bezoeken, dan weet je wel waar men voor kiest .

[Verwijderd]

Denk nou niet dat HTTPS daartegen beschermt. Je baas kan legio commerciële producten aanschaffen die de SSL-verbinding openmaken en weer netjes voor je werkplek dichtzetten.

Niet zonder dat er dan een fake certificaat op zit, dus krijg je warnings in je browser.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[Jeroenneman]

Dat niet in werktijd doen, kan ook wel eens helpen.

[fre0n]

dat wordt niet geregistreerd als de rest van de pagina ssl is denk je ?

[Kain_niaK]

Ah je en als die mensen willen zien wat je schrijft gaan ze natuurlijk je verkeer afluisteren ipv ik noem maar iets, je gebruikersnaam opzoeken en je post op een publiek forum lezen

[BenGenaaid]

Helemaal mee eens, maar ik wil er nog even aan toevoegen wat een beetje ondergesneeuwd lijkt te worden in de algemene discussie: Het lijkt mij van algemeen belang dat alle websites overal op internet via HTTPS gaan, puur en alleen om het gegeven dat dit het niet belangrijke verkeer mixed met het belangrijke privacy gevoelige verkeer waardoor de algemene veiligheid in het grote geheel toeneemt omdat er geen onderscheid meer te maken is tussen belangrijke verleutelde data en "niet belanrijke" ..nu ook versleutelde data.
Dus overgaan op HTTPS is zowieso gewenst, of dat nu al moet...ach mijn grootvader zei eens van uitstel komt afstel ... ik weet niet of dat hier opgaat want je zou ook kunnen zeggen, haastige spoed is.... enz.

Mijn persoonlijke mening, doen..

[Verwijderd]

ik begrijp het probleem niet goed. Tweakers is blijkbaar perfect via https te bereiken. als je dat wil kun je toch gewoon naar de https versie gaan?

[Baserk]

Opvallend inderdaad.
Het artikel zelf schetst een onwaarachtig beeld door alleen al het versleutelen van je cookie als 'een gevoel van veiligheid' voor te stellen.
Er is, met het vrijwel totale gebrek aan het benoemen van privacy als argument, aardig bot naar een conclusie toe geredeneerd.
(Echt waar, 'Heartbleed' als argument durven nemen? Foei.)

Die toonzetting is wel in overeenstemming met de vele reacties dus er zal wel steun zijn voor de conclusie.
Privacy? Whatever.

[FragFrog]

What he said.

Ik heb met mijn collega's voor een andere website een soortgelijke discussie gehad. Zei wilden erg graag HTTPS implementeren "want dat is veiliger", ik wilde heel graag een snelle website-ervaring aanbieden. Uiteraard gebruikten we wel HTTPS voor gevoelige pagina's (inloggen, factuuroverzichten etc), maar veel content is gewoon publiek toegankelijk, moet ook juist zo toegankelijk zijn, en wat levert het versleutelen daarvan op?

Sowieso zijn MitM aanvallen relatief zeldzaam vergeleken met andere aanvallen. De kans dat een website ten prooi valt aan SQL-injectie, een XSS-exploit of CSRF aanval is vele malen groter dan dat iemand een dedicated MitM aanval uitvoert. En als iemand al een MitM aanval uitvoert, is dat hoogstwaarschijnlijk lokaal* (een compromised WiFi-access point bijvoorbeeld) en is de impact daarvan minimaal. Iemand moet al specifiek gaan lopen vissen op bezoekers van jou site en daar zijn aanval op afstemmen wil je er last van hebben.

En dan heb ik het nog niet eens gehad over simpelweg onveilige computers: als jij een virus op je PC hebt kun je al je verkeer wel drie keer versleutelen, het maakt geen ene fluit uit: de aanvaller kan nog steeds precies zien wat je doet.

Natuurlijk voegt het een extra laag veiligheid toe, maar het "https is veilig en http niet" fabeltje is zo zwaar overtrokken in de beleving van veel mensen dat ik liever geen HTTPS aanbied als het niet nodig is: schijnveiligheid zorgt waarschijnlijk voor meer problemen dan dat HTTPS op zou lossen. Nog helemaal afgezien van de extra laadtijd.

* Grotere aanvallen middels bijvoorbeeld DNS cache poisoning zijn veel lastiger, en als je dat voor elkaar krijgt richt je niet je pijlen op een nieuws-site, dan ga je achter banken aan..

[Reactie gewijzigd door FragFrog op 24 juli 2024 18:00]

[Darkstriker]

* Grotere aanvallen middels bijvoorbeeld DNS cache poisoning zijn veel lastiger, en als je dat voor elkaar krijgt richt je niet je pijlen op een nieuws-site, dan ga je achter banken aan..

Je zegt het al zelf. Dan richt je op banken, maar die bieden allemaal geen http meer aan. Zeker niet voor gevoelige dingen. Dan is ineens het gebruik maken van informatie op sites als tweakers voor oplichting een reeel probleem.

[Kain_niaK]

Als je die informatie wilt hack je de hele server en ga je niet individuele gebruikers afluisteren. Daarbij is alles in een profiel openbaar behalve email adres en wachtwoord.

[Darkstriker]

Je hebt ook niet gelezen of wel? Er gaat veel meer prive info over tweakers dan wat je in je profiel hebt staan zodra je van V&A gebruik maakt. Dat hoort beveiligd te zijn.

[Kain_niaK]

En dat is ook beveiligd. Een deel van tweakers gaat over https, bijvoorbeeld wanneer je inlogt. Maar niet de hele site omdat het niet zo veel uitmaakt wanneer verkeer dat voor een publiek forum is onversteuteld word verstuurd. Heb je ooit al eens in je leven een email versleuteld verstuurd met bijvoorbeeld PGP?

[Reactie gewijzigd door Kain_niaK op 24 juli 2024 18:00]

[Eagle Creek]

Wij zien een paar voordelen. Puur het feit dat er alleen nog maar versleutelde informatie tussen jou en ons over de lijn gaat geeft al een gevoel van veiligheid en betrouwbaarheid.

Helaas zie ik dat niet als een voordeel. Het overmatig afgrendelen, classificeren, rubriceren of anderzins beveiligen zonder echte onderbouwing en uitsluitend op basis "van het gevoel" is in mijn ogen een slechte aanpak. Je haalt namelijk wel de nadelen in huis (welke dat ook zijn), zonder er voordelen uit te halen anders dan een irrationele graadmeter: het gevoel..

Daarnaast kan het ook een vals gevoel van veiligheid geven aan minder bekende bezoekers. Die kijken vaak al niet verder dan een slotje en/of groene balk alleen.

Bekijk serieus wat of je wilt beschermen, wat of je wilt bereiken en stem daar je beveiliging op af. En niet "zomaar" alles over SSL omdat dit een relatief eenvoudige maar ook vooral voor de buitenwereld zichtbare beveiliging biedt.

[Reactie gewijzigd door Eagle Creek op 24 juli 2024 18:00]

[Rafe]

Sommige groepen gebruikers (crew) kunnen dus wel bij gevoelige informatie. Denk aan notes en crewfora. Is in het verleden al eens misgegaan met session hijacking: ReactID misbruik en de gevolgen

Beste oplossing: maak er een opt-in optie van in de preferences, iedereen gelukkig

[Reactie gewijzigd door Rafe op 24 juli 2024 18:00]

[NMe]

Iedereen gelukkig? Dat weet ik zo net nog niet. Dat kost namelijk evenveel werk om op te lossen als in het artikel omschreven staat, met name om dat mixed content-verhaal op te lossen maar vervolgens gaat waarschijnlijk maar een heel beperkt deel van de users het daadwerkelijk gebruiken. Dat maakt de investering nóg lastiger te verantwoorden.

Overigens zie ik hier in de reacties heel wat mensen die onderschatten hoe veel effect laadtijden op onder andere je bounce rate hebben. Er zijn talloze onderzoeken gedaan naar het effect van laadtijd op bezoekersaantallen en de zeggen volgens mij allemaal dat een verhoogde laadtijd van een paar honderd milliseconden de bounce rate al met een paar procent verhogen. Ik zit nu mobiel dus ik kan even niet lekker bronnen opzoeken maar die zijn vast niet moeilijk te vinden.

[Darkstriker]

Je hoeft het mixed content geval toch helemaal niet volledig op te lossen. Ik denk dat hier wel genoeg begrip voor is in het forum. Maar op de frontpage, de V&A en vooral de priveberichten zou ik wel degelijk volledige https willen zien (vooral in die laastste twee), omdat daar toch geregeld gevoelige informatie zoals rekeningnummers, namen en adressen worden uitgewisseld. Die wil ik graag beveiligd zien.

En ik denk dat het optionele wel degelijk de beste optie is, als je site-performance als de belangrijkste struikelblok noemt.

Persoonlijk gebruik ik bvb https-everywhere. Ik ben wel bereid een seconde langer te wachten op tweakers om het in https te krijgen. Als anderen dat niet willen, dan moeten ze vooral de mogelijk hebben om verder op http te blijven. Ik zou dan wel graag willen zien dat de priveberichten bij iedereen in https afgedwongen worden. Daar ligt wat mij betreft het grootste risico.

[NMe]

Wat zou een optionele uitrol van HTTPS voor jou voor voordelen bieden bovenop HTTPS Everywhere?

[Verwijderd]

Dat je er geen aparte plugin voor nodig hebt, dat het werkt in alle browsers, en dat het ook werkt op Android en iOS.

[NMe]

Die plugin gebruikt iemand die blijkbaar zó om zijn privacy geeft toch wel voor andere sites. En ik ken eigenlijk niemand die actief meer dan één browser gebruikt. Blijft alleen mobiel als argument over, maar juist daar ondervind je ook vooral de nadelen van SSL.

[Darkstriker]

HTTPS Everywhere werkt natuurlijk alleen als de website het ondersteunt (DUH)

Op dit moment kan ik dus geen https hier gebruiken. Maar ik zou dat wel willen. Vooral op die punten die ik eerder noemde.

Als andere mensen niet zoveel om hun privacy geven en liever een zo snel mogelijke website willen hebben, dan is dat dus ook mogelijk.

[Patriot]

Je hoeft het mixed content geval toch helemaal niet volledig op te lossen. Ik denk dat hier wel genoeg begrip voor is in het forum. Maar op de frontpage, de V&A en vooral de priveberichten zou ik wel degelijk volledige https willen zien (vooral in die laastste twee), omdat daar toch geregeld gevoelige informatie zoals rekeningnummers, namen en adressen worden uitgewisseld. Die wil ik graag beveiligd zien.

Dat zou pure schijnveiligheid zijn. Iemand die de verbinding kan afluisteren kan op het moment dat je een HTTP verbinding met Tweakers opzet jouw sessie kapen en dus alles inzien wat jij zelf in kunt zien.

[Darkstriker]

Het mixed content probleem is alleen van toepassing op externe afbeeldingen. Er zou dus idd nooit een onversleutelde verbinding met tweakers gelegd moeten worden. Maar dat is ook gewoon te realiseren.

[Patriot]

Het mixed content probleem is alleen van toepassing op externe afbeeldingen. Er zou dus idd nooit een onversleutelde verbinding met tweakers gelegd moeten worden. Maar dat is ook gewoon te realiseren.

Ik doelde op het voorstel van Darkstriker om bepaalde delen van Tweakers via een beveiligde verbinding te laten verlopen. Op het moment dat iemand een onbeveiligd deel van de website bezoekt is zijn sessie id namelijk wel over de onbeveiligde lijn gegaan.

Of je moet ook nog apart laten inloggen voor verschillende delen en met secure-only cookies gaan werken, maar dat is weer ontzettend onpraktisch.

[ari3]

HTTPS of niet, Tweakers kan haar bounce rate verbeteren door niet meer te pagineren, althans niet pas de content van de volgende pagina in te laden het moment dat de gebruiker klikt.

Als je iedere keer moet wachten als je op volgende klikt dan verhoogt dat inderdaad de bounce rate. Met de beschikbare bandbreedte en scriptmogelijkheden is het niet meer van deze tijd dat content niet anticiperend ingeladen wordt.

[NMe]

Je realiseert je dat heel veel mensen ook een grafhekel hebben aan het automatisch inlezen van nieuwe content als je tot bijna onderaan gescrolld hebt?

[FireDrunk]

Zeer zeker, een pesthekel...

Ik vind een Opt-Out beter... Veilig, en je kan als je zelf er voor kiest om de veiligheid moedwillig te verlagen iets meer performance krijgen.

Default: Veilig
Optioneel: snel...

Wat je ook nog kan doen is:

Default niet ingelogd: Geen HTTPS, er gaat toch weinig persoonlijks over de lijn.
Default ingelogd: HTTPS voor forum en HTTP voor frontpage.

Opt-out voor HTTP only
en
Opt-in voor HTTPS only.

[Thystan]

Daar ben ik het mee eens. Ik vind dat je als snelle bezoeker het beste af bent met een snelle website.

Maar zodra ik ergens een account heb, en dus login gegevens verstuur (al is dat het enige) dan heb ik het liever via https.

Ik zie het liefst een opt-in optie die direct voor mij overal https aanzet. En ik begrijp wel dat mixed content dan niet secure is, maar ik voer ook niet mijn login gegevens in om die content te aanschouwen.

[sjongenelen]

Eens ! En als mensen het écht willen kunnen ze nu al HTTPS gebruiken...

[JDVB]

Hoe zou je het nu moeten gebruiken zonder browser plugins dan?
Als ik naar https://tweakers.net surf, en op een willekeurige interne link klik, zit ik vervolgens weer op de gewone http versie.
En rechtermuis op een link, koppelingslocatie kopiëren, in de adresbalk plakken en er een s bij prakken vind ik niet echt een optie.
Wat T.net op zijn minst zou kunnen (en eigenlijk moeten) doen is ervoor zorgen dat als je op de https variant binnenkomt, hier ook op verder gaat.

[sjongenelen]

Ah dat had ik niet getest.. Waarom is dat eigenlijk? Wat jij zegt klinkt als een default implementatie

[MGutker]

Ik vind persoonlijk dat er te veel waarde gegeven word aan de nadelen. Sinds Tweakers radio reclame maakt en meer een publieke community is geworden zijn er ook regelmatig gebruikers die bijvoorbeeld enkel de pricewatch en de wenslijsten gebruiken. Daarvoor hebben zij een account nodig.

Deze 'normale' niet icters denken waarschijnlijk niet aan het wachtwoord wat ze gebruiken hier, en dat dit het zelfde wachtwoord van bijv de bank of DigiD is.

Sinds er een tijdje geleden de keuze heeft gemaakt om Tweakers een meer 'publieke' community te maken ben ik van mening dat we ook voor de minder ICT bekwame mensen onder ons moeten spreken. En zeggen dat HTTPS wellicht een stap in de goede richtig is op dat gebied.

[sjongenelen]

Ja dat is waar, maar ik mag aannemen dat alle inlog gedeelten etc wél SSL zijn?

[Kain_niaK]

klopt. Het versturen van DM's over SSL laten gaan heeft ook weinig zin. Modjes kunnen DM's lezen. Bijna alles in de database is onversleuteld behalve wachtwoorden ....

Dus waar beschermt SSL je tegen op een publiek forum zoals Tweakers? Tegen helemaal niks. Er zijn een paar 100 makkelijker manieren voor een hacker om achter jou informatie te komen wanneer je naar tweakers surft over een https verbinding dan om te proberen de SSL verbindinging te kraken. Die hacker moet trouwens je verbinding al KUNNEN afluisteren. Dus hij zit op je eigen netwerk, of bij je provider, op bij het netwerk van de tweakers server. In dit geval heeft zo'n hacker al zo veel toeganag dat het retestom zou zijn om te proberen JOU ssl verbinding te onsteutelen.

De overheid gaat dat ook niet doen, die gaan met een dwangbevel het serverpark in een lopen naar buiten met de onversteutelde database. SSL is allemaal niet zo relevant, niet bij een publiek forum als Tweakers. Wel bij je bank of het versteutelen van je credit card nummer.

[Patriot]

Deze 'normale' niet icters denken waarschijnlijk niet aan het wachtwoord wat ze gebruiken hier, en dat dit het zelfde wachtwoord van bijv de bank of DigiD is.

Dat is precies waarom het inloggen al wél over een SSL verbinding gaat. Dat wil dus zeggen dat de sessie weliswaar te kapen is omdat ná het inloggen het sessie id wel over een HTTP verbinding gaat, maar dat het wachtwoord op die manier niet te achterhalen valt.

[BushWhacker]

Da's nu net het probleem. Dat kan niet.
De frontpage kun je met https laden, maar alle links zijn `hard` met http geprefixed.

EDIT: Ik was te laat. Iemand was me al voor met deze reactie.

[Reactie gewijzigd door BushWhacker op 24 juli 2024 18:00]

[3DDude]

Met een MTM attack is SSL ook te strippen..

[Verwijderd]

Bij de IT afdeling van het bedrijf waar je werkt kan meegekeken worden met wat je allemaal post. Dit is een nadeel van het niet gebruiken van HTTPS.

[Verwijderd]

Als je inlogt op tweakers is het toch al jaren de bedoeling dat jouw post die bedoeld is om algemeenheden en ook mistoestanden of iets dergelijks (foutjes en nieuwtjes op computer en ander bijbehorende gebieden aan te kaarten ook en ook de -1 optie) de mogelijkheid biedt door iedereen op het forum gelezen te worden, zodat ook iedereen zijn (eigen) mening en commentaar kan geven, met de hoop op een verbetering en aanpassing, van het menselijk denken (denkpatroon) zodat uiteindelijk de hele maatschappij verbeterd kan worden ? En dat is tegenwoordig wel heel hard nodig met allerlei (regering, tweede kamer, ministers) onware aannames, die voor waarheid moeten doorgaan.

[Verwijderd]

Dit klinkt als "je hebt toch niets te verbergen?"
Dat heeft er natuurlijk niets mee te maken. Jij post bijvoorbeeld ook niet onder je echte naam.

Moet je eens kijken wat een reacties er op tweakers verschenen toen Google een regel invoerde dat je je echte naam moest gaan gebruiken. Dat zegt al genoeg.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[Kain_niaK]

Als hij zijn echte naam nooit intypt op tweakers kan zijn naam ook niet worden gevonden door niet versleuteld verkeer af te luisteren ...

[Verwijderd]

Jouw werkgever weet natuurlijk het IP adres van jouw kantoor PC...

[Kain_niaK]

Jouw werkgever weet natuurlijk je echte naam.

[Gomez12]

Voor de IT-afdeling maakt https / http geen drol uit hoor.

Via een gpo een root-CA uitrollen en een progje ertussen steken die certificaten uitgeeft en iedereen ziet overal slotjes die niet zeggen.

Heb je wat zeurderige gebruikers dan kan je nog eens kijken of er niet gpoi's beschikbaar zijn dat mensen niet meer de info het ca krijgen et voila, weg niet-bestaand probleem.

Wat jij schetst is een niet-bestaand probleem, want of je hebt een goede IT-afdeling en dan kan het technisch wel, maar zal het nooit gebeuren. Of je hebt een slechte IT-afdeling en die introduceert bijv de methode die ik hierboven beschrijft en dan ben je nog geen stap verder.

[Verwijderd]

Maar een tweaker kan natuurlijk wel zien of de juiste certificaten worden gebruikt.

[Xieoxer]

Er zijn inderdaad weinig voordelen, maar het wordt wel enorm belangrijk dat websites https gaan gebruiken. Google heeft laatst aangekondigd dat websites die https gebruiken hoger in de ranglijst komen dan websites zonder https. Voor Tweakers is het enorm belangrijk dat nieuwe bezoekers de website Tweakers kunt vinden. Het zou zonde zijn dat ze veel bezoekers zouden mislopen omdat Tweakers geen https aanbied!

[Gomez12]

Google heeft laatst aangekondigd dat websites die https gebruiken hoger in de ranglijst komen dan websites zonder https.

Dat is populaire onzin, Google heeft iets van 200 factoren waarop bepaald wordt waar een website komt te staan, dit zou hooguit factor 201 worden.

Je enkel en alleen focussen op factor 201 is nutteloos want dan zak je vanzelf wel omdat je 200 andere dingen laat vallen.

Het is een factor die meespeelt, maar die bijv weer grotendeels opgeheven wordt door een andere factor namelijk snelheid

[Xieoxer]

Het is absoluut geen onzin. Ik weet dat Google 200 factoren heeft waarop bepaald wordt hoe hoog de website binnen de zoekresultaat komt, maar https gaat in de toekomst een groot deel van van de zoekresultaat beïnvloeden. Google heeft dat zelf gezegd.

[Verwijderd]

Of iets privacy gevoelig is zal per persoon verschillen. Niet iedereen gebruikt Tweakers vanuit huis via een provider die hij/zij goed vertrouwd.

Als ik via de gratis Wi-Fi op een Amerikaans vliegveld reageer op een Snowden artikel doe ik dat liever via een versleutelde verbinding.

Wat mij betreft wordt SSL aangeboden als opt-in.

[marcelvb]

Zou mooi zijn als het een keuze was. Kan iedereen zelf kiezen of snelheid of privacy de voorkeur heeft. In mijn geval privacy.

[Garma]

eens, van mij hoeft het ook niet. Tweakers doet het prima zo en zoals jullie zeggen de informatie is juist bedoeld om publiek beschikbaar te zijn.

[Kain_niaK]

De mensen die dat denken weten gewoon niet echt wat https inhoudt en wat SSL nu precies is en wat het niet is. Voordat je SSL verkeer kunt ontsleutelen moet je het eerst al afgeluisterd hebben. Als iemand je verkeer afluistert louter en alleen om er achter te komen wat jij op een publiek forum plaatst .... nu ja zo iemand is niet echt een slimme hacker.

Daarom dat ik thuis ook geen kogelvrij glas heb, er word niet genoeg op mijn ramen geschoten om daar de moeite voor te gaan doen.

[GrooV]

In hoeverre is jullie SSL daadwerkelijk geoptimaliseerd? Als je dit goed doet dan merk je niet zo'n groot verschil. Met +2 seconden heb ik het gevoel dat hier niet echt goed naar gekeken is.

Met deze discussie / plan krijg ik weer het zelfde gevoel als met de IPV6 discussie, op een of andere manier rijmt jullie infrastructuur niet met een tech website.

Het hele internet gaat over op IPV6 & SSL maar tweakers heeft weer zijn eigen redenen. Als je een beetje verdiept in deze technieken kom je erachter dat deze tegenwoordig niet meer optioneel zijn.

[Gomez12]

In hoeverre zou jij technieken die je niet zegt actief te ondersteunen (SSL) gaan optimaliseren?

In wezen is het vanuit t.net gewoon een kosten-baten analyse.
En dan is snelheidsverlies een kosten, dat kan je vast wel weer gaan optimaliseren (=extra kosten) maar alsnog zeg je zelf al dat je uitkomt op "niet zo'n groot verschil" oftewel het blijft trager.

En qua infrastructuur van een tech website, het lijkt mij redelijk evident dat die infrastructuur redelijk gelijk is aan wat er aan de buitenkant getoond wordt.
Niemand gaat voor de fun SSL optimalisaties doorvoeren gewoon omdat het kan, daar moet een bepaald nut tegenover staan en zolang directie niet zegt "We gaan SSL ondersteunen" zijn optimalisaties enkel tijdsverspilling.

[Cerebriform]

Dit overtuigt mij liever te zien dat Tweakers niet overstapt naar https. Ik klik vaak tijdens werk even kort door Tweakers heen. Hoe lang het laden duurt maakt daarbij uit, of de gegevens versleuteld zijn juist helemaal niks. Ook als ik met mensen op het forum over een game klets of op zoek ben naar een videokaart in de pricewatch hoeft absoluut niet versleuteld te worden wat mij betreft: liever een snelle site dan dat het onmogelijk wordt voor anderen te zien dat ik over games klets en naar pc onderdelen kijk.

[Richh]

Eens. Ik vind de laadtijd veel belangrijker dan https ondersteuning. Als ik nou betalingen deed ofzoiets is het een ander verhaal. En als ik het me goed herinner heeft jullie aboshop inderdaad wel https!

Voorlopig zou ik het lekker zo laten, en als het toch standaard wordt, maak het ook mogelijk om het zonder te doen aub

[i-chat]

ik denk dat jullie de nadelen van mixed content overschatten, natuurlijk geeft het een 'ander' icoontje, maar ten eerste is dat niet jullie fout en/of probleem maar die van de browserbouwers,
en met het oog op http2 mogen we ze daar misschien wel eens op weizen...

men wil graag dat alles https is, en daar ben ik het wel deels mee eens, MAAR het is onzinnig op plaatjes en javascript files e.d. niet via een cdn te versturen. kortom er wordt een grotere rol toebedicht aan mixed content dan ie werkelijk verdiend.

waar men zich in werkelijkheid wat browsers eens op moet richten is niet, of er mixed content is maar welke.. immers is data terugsturen via een invoerveld dat niet met https werkt een stuk schokkender dan wanneer je het henk logo via http binnen hengelt.

wat mij betreft dus wel https, maar niet voor alle data die nu ook al via een cdn geleverd word,
zo heb je wel de sessie-veiligheid, en weet je zeker dat er niemand namens jou kan trollen (grapje!), maar hoeven de servers niet belast te worden met zaken waarvoor het niet nuttig is dat ze via https worden verstuurd.

want laten we eerlijk zijn, we zijn tweakers, wat geven wij nu om de schijnveiligheid van dat mooie icoontje

[incaz]

CDN's kunnen ook https-content leveren natuurlijk. Kwestie van configureren. De serverbelasting lijkt erg mee te vallen.

Daarnaast is mixed content wel gewoon een probleem - SSL beveiligt niet alleen jouw communicatie naar de website, maar ook de integriteit van de pagina. Toestaan dat daar een gaatje inzit kan genoeg zijn om de hele boel lek te laten zijn.
Zeker javascript is een probleem - een keylogger injecteren is dan op open wifi's niet zo'n probleem. Kun je de rest leuk encrypted hebben, maar dat doet er niet meer toe.

Zie ook http://www.troyhunt.com/2...not-about-encryption.html of http://www.troyhunt.com/2...sts-to-https-but-you.html

Er zijn best afwegingen te maken over htttps vs http, maar mixed content is de oplossing niet.

[Nas T]

Ik denk dat het snelheidsverschil wel substantieel is. Ik weet niet hoe moeilijk het is om de site aan te kunnen in https naast http? Ik zie boven op de frontpage wel eens een soort informatieve banner staan, misschien dat je daar de gebruiker kunt vragen of de site in https geserveerd moet worden, met alle nadelen duidelijk opgenoemd. Dan kan iedereen voor zichzelf afwegen en zijn de "veiligheidsfreaks" ook tevreden.

Enige nadeel is misschien het extra onderhoud aan de site.

[Martinspire]

Kun je dan ook niet net als bij andere sites het optioneel maken? Dat iemand het aan kan zetten als hij wil? Of dat je hem benaderbaar maakt via HTTPS, maar ook via HTTP (en hij die connectie vasthoud)?

Of anders het profiel-gedeelte achter HTTPS hangen en de rest niet? Daar is tenslotte de plek waar je informatie bekijkt en invoert die persoonsgebonden is.

[Vayra]

Mijn twee centen.

Wacht met de overstap op https totdat 4G redelijk tot goed is ingeburgerd onder de bezoekers. Veel mensen bezoeken de site namelijk mobiel, en daar is het verschil in performance wel degelijk een struikelblok voor 'even snel kijken' op Tweakers.

Het zal geen jaren meer duren, 4G is nu actueel, dus wat zal het moment gaan zijn, over een maandje of 6-8?

[Keypunchie]

Wat is de reden om te versleutelen? Het hoofddoel is om te beschermen tegen Man-in-the-Middle aanvallen. Waarom zouden mensen mijn Tweakers.net sessies willen onderscheppen? Dat ze kunnen zien wat ik lees?

Als je er over nadenkt kom je eigenlijk alleen maar uit op wellicht de Chinese/Russische overheid, die de eigen burgers wil controleren op wat ze uitspoken op Tweakers.net. Immers, veel informatie over cryptografie, vpn etc. wat die overheden liever niet hebben. Wat mij betreft mag je best ver gaan om die gebruikers te beschermen.

Wellicht is het een idee om https duidelijker als optie aan te beiden. Wie zich zorgen maakt, kan dan sneller opt-in doen door van https-versie gebruik te maken door het drukken op een knop. Wie snelheid prefereert, maakt gebruik van reguliere site.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 18:00]

[rickboy333]

Versleuteld verkeer zal (tot ndn eens uitgerold word) altijd langzamer blijven dan niet versleuteld verkeer, domweg omdat je meer 'round trips' moet doen voor https.

En vergis je niet; de getallen die we noemen zijn eigenlijk een beetje misleidend; Deze externe monitor zit ergens in een datacentrum in Nederland met een dedicated lijn en hoge snelheid en zal dus in het algemeen veel sneller zijn dan de gemiddelde gebruiker.

Als we naar daadwerkelijke performance gehaald door bezoekers (gemeten met NewRelic) kijken dan zien we de volgende cijfers (uiteraard voor de non-https versie, gekeken over de afgelopen week):
- Mediaan bezoekers: 1,1s
- Gemiddelde bezoeker: 2,0s
- 95-percentiel: 5s

Als we dan kijken naar de performance van de externe monitoring:
Externe monitoring, http->https: 0,88s -> ~1,7s = 1,9x langzamer

Dan zal voor de bezoekers ongeveer dit de performance zijn:
- Median: http: 1,1s -> https: 2,1s
- Gemiddelde bezoeker: http: 2,0s -> https 3,8s
- 95-percentiel: http: 5s -> https: 9,5s

Waarbij wel opgemerkt dient te worden dat dit behoorlijk variabel is en afhangt van heel veel factoren.

Voor meer dan 50% van de gebruikers echter zal de site vertragen van ~2s naar bijna 4s, dat is zeker goed merkbaar.

Ik vraag me af, is het niet mogelijk om de bezoeker te laten kiezen of ze HTTP of HTTPS willen ? Als je in de persoonlijke voorkeuren die optie erin zet zodat bezoekers kunnen aanklikken wat ze willen. Jullie zeggen zelf dat het mixed content wordt tegen die tijd. Dus maak Tweakers een HTTPS site en elk account kan dan bepalen welk element op de site HTTP of HTTPS wordt.

Of het technisch mogelijk is weet ik niet maar het is misschien een optie om naar te kijken.

[Viriya]

Deze rede zorgt ervoor dat het totaal niet op weegt om over te gaan naar https. Ik durf te wedden dat de normale nieuwslezers niet geïnteresseerd zijn om 2x zo lang te moeten wachten op een pagina alleen maar omdat sommige gebruikers zo bang zijn voor hun privacy.

Ik vind naar de Rabobank of een site van de overheid met Digid integratie zo traag en lang duren dat ik probeer deze zo min mogelijk te gebruiken.

[Osiris]

"Voor meer dan 50% van de gebruikers echter zal de site vertragen van ~2s naar bijna 4s, dat is zeker goed merkbaar.", euh, je bedoelt van 1 naar 2 seconden. De mediaan geeft juist de scheiding tussen de twee helften van de populatie weer, niet het gemiddelde

Maar afijn, meer ontopic: wat ik niet uit het artikel kan halen is of bij de snelheidsberekeningen tussen HTTP en HTTPS wel of niet gebruik is gemaakt van keep-alive.
Want dat er een (kleine) tijd nodig is om 't een en ander voor TLS te initialiseren, dat moge duidelijk zijn. Maar als je gebruik maakt van keep-alive én al je content komt niet van tig verschillende hosts af, dan hoef je dat dus ook maar 2x te doen (t.net en je content-host).
Bij de single-page zie je een gemiddelde toename van 0,016 sec. door TLS. Zonder encryptie doet de volledige site er gemiddeld 0,88 seconde over. Verdeeld over twee verbindingen zou dat 0,032 seconden extra aan TLS-handshaking opleveren = 0,912 seconde. Da's bijna de helft van die 1,7 seconde!

Dus ik vraag me ernstig af hoe die metingen precies zijn uitgevoerd..?

[Kain_niaK]

Volgende keer kan Tweakers beter eerst eventjes wat achtergrond info en uitleg geven over wat https nu precies is en hoe het technisch werkt. En waar het tegen beschermt, en waar het niet tegen beschermt. Hoop mensen hier die niet precies weten hoe het allemaal in elkaar steekt.

Zijn er trouwens nog andere momenten naast het inlog moment waar tweakers gebruik maakt van SSL wanneer mogelijk?

[Verwijderd]

De vraag is eigenlijk heel simpel, zijn we allemaal al zo gestresseerd, dat men geen 4 seconden extra tijd over heeft, dan wordt het toch tijd om je eigen leven eens drastisch onder handen te nemen.

[FragFrog]

Klinkt leuk in theorie, in de praktijk heeft oa Google erg veel onderzoek gedaan naar hoe laadtijd het surfgedrag van mensen beinvloed. Als ik me goed herinner zit een optimale surf-ervaring op ongeveer anderhalve seconde: duurt het laden van een pagina langer, dan beginnen mensen al af te haken. Dit is onder andere de reden waarom Google standaard maar tien resultaten laat zien (zodat hun zoekpagina snel kan laden) en waarom ze tegenwoordig site-speed meetellen in ranking.

Ik was ook ooit een kleine FragFrog die geen enkele moeite had met een pagina die dertig seconden nodig had om te laden (of langer, ten tijde van Dial-up). Tegenwoordig verwachten mensen echter dat een pagina er binnen een seconde of twee staat. Daar kun je van vinden wat je wilt, realiteit is dat langere laadtijden leiden tot hogere bounce-rates en een slechtere gebruikerservaring.

[Verwijderd]

Dat bedoel ik dus ook, de wereld heeft nergens meer enig geduld voor, geen wonder dat het barst van de TV programma's met stressende en irriterende mensen. Ik wacht geduldig 30 seconden en ben op deze wereld waarschijnlijk de enige mens die geen doktoren en tv programma's nodig heeft

[Verwijderd]

Ik ben voor het versleutelen van alle communicatie op het internet, dus wat mij betreft mag het default HTTPS worden. Gebruik zelf al de HTTPS everywhere extentie dus ik bezoek tweakers.net sowieso al via HTTPS.

[Verwijderd]

Probleem is alleen dat de huidige https van Tweakers geen vercijfering ondersteund, beetje een nep https dus. Ik zat er gedeeltelijk naast zie reactie @jonkiji. Ik blijf wel van mening dat de https implementatie beter kan.

Tweakers moet gewoon beide opties aanbieden. Normale http voor mensen die privacy onbelangrijk vinden en een (goede) https voor mensen die wel de noodzaak inzien.

Die extensie werkt erg goed inderdaad.

@Kees: Mijn browser meldt geen 'slotje' icoon, zoals bij andere sites, waar ik ook gelijk de gebruikte versleutel methodes te zien krijg. Certificaat ja, maar daaronder wordt vermeld dat de site niet volledig versleuteld is.Certificaat is ook niet geverifieerd, bij andere sites wel..-> Mixed content vind Firefox niet prettig blijkbaar.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[Kees]

Welke vercijfering bedoel je? Op dit moment gebruiken wij de volgende ciphersuite:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

En bij de protocollen zijn sslv2 en sslv3 uitgezet.

Volgens mij staan de ciphers die geen encryptie ondersteunen (de NULL ciphers) gewoon netjes uit en gebruiken wij gewoon versleuteling. We krijgen weliswaar niet de hoogste score bij qualys ssl labs test, maar een A- lijkt mij niet echt 'nep https'

[djc]

Wat is de reden dat jullie niet hoger gaan dan A-? Compatibility met oudere clients?

[Kees]

Oude apache (2.2) versie en compatibility met oudere clients inderdaad. Wat overigens ook prima een gebrek aan mijn SSL-kennis kan zijn dat ik niet de juiste CipherSuite kan bedenken.

[praseodymium]

Apache 2.2 doet helemaal geen ECDHE, terwijl in een andere comment juist werd gesuggereerd dat jullie Apache 2.4 gebruiken.

[Kees]

Ja dat is enigszins verwarrend; we zijn namelijk druk bezig om over te stappen op apache 2.4 en daarom kijken wij ook naar modules voor apache 2.4. Maar op dit moment gebruiken wij apache 2.2 in productie samen met php 5.3 en Ubuntu 12.04.

We zijn druk bezig nieuwe webservers aan het uitzoeken waarbij we overstappen op Ubuntu 14.04 en Apache 2.4. Verder hebben we loadbalancers ervoor hangen die nu nog SSL termination doen, maar ik zit er toch erg over na te denken om de SSL termination naar een nginx server over te hevelen, die dan weer proxied naar een varnish server die op zijn beurt weer proxied naar de apache server)

[Tomsworld]

Kees waarom wil je ssl op cpu's doen normaal zijn die toch trager dan dedicated ssl chips / processors die dat offloaden in loadbalancers / ADC.

Verder ben ik voorstander om zoveel mogelijk in https te doen.

[praseodymium]

ECDHE lijkt niet te werken, dus wordt verbinding gemaakt met DHE. Dat verklaart wel waarom het veel trager is, zie b.v. http://vincent.bernat.im/...recy.html#some-benchmarks

[MikeN]

Als ik nu vanuit Chrome connect wordt de keyuitwisseling gedaan dmv DHE ipv ECDHE. Dit is verreweg de traagste methode, en verklaart voor een aardig deel de traagheid die jullie zien. Daarnaast is een vertraging van een seconde extra gewoon onzin, ik zie een verschil van 0.02s op HTTPS requests bij onze sites, inclusief de gehele handshake. Is die eenmaal gedaan, dan is er geen performance verschil meer (het kan zelfs sneller zijn, als je SPDY gaat gebruiken).

Net als met het hele IPv6 verhaal laat Tweakers hier weer eens zien niet voorop te lopen als tech site. Het hele internet gaat, met goede redenen, over op SSL, maar Tweakers blijft achter (of dat wettelijk te verantwoorden is vraag ik mij overigens af, gezien je je session id's nu gewoon over HTTP gooit...)

[Verwijderd]

Niet volledig versleuteld, dat is de mixed content.
In dit geval worden de plaatjes op de frontpage over http binnengehaald.

De identiteit is wel gewoon geverifieerd. (RapidSSL).

[Reactie gewijzigd door Verwijderd op 24 juli 2024 18:00]

[chaozz]

Bedankt voor de tip. Ik heb die plugin ook maar even geïnstalleerd!

Verder ben ik ook voor een keuze optie http/https. Ik zou het aanzetten, maar kan me om de in het artikel genoemde nadelen ook voorstellen dat anderen er voor kiezen dit niet te doen.

[naaitsab]

Ik prefereer veiligheid boven snelheid. Zeker omdat het een minimaal (lees niet merkbaar) snelheidsverschil is. Hierbij een stem pro HTTPS.

@redactie: Een poll zou wellicht handig zijn

[Dwazer]

Ja, daar dacht ik ook al aan

[Kees]

Het nadeel van een poll is dat je dan teveel stuurt; een discussie is mischien lastiger te analyseren maar levert wel meer op dan een poll met 'ja/nee/mischien'

[Dwazer]

Ja, dat begrijp ik

Het was (in mijn persoonlijke oogoptiek hoor ) wellicht sneller en overzichtelijker te zien wat de intentie van de meeste mensen hier zou kunnen zijn.

Poll voor het overzicht, de reacties voor de onderbouwing en de discussie

Maar ik snap je punt hierin: Alleen maar "Ja/Nee/Misschien" klikken heeft geen fundering

[Kees]

Helemaal in de huidige tijd met snowden, nasa en privacy; ik verwacht dat bij een poll de meeste mensen 'ga over op https' aanclicken zonder er echt even over na te denken; en als je een reactie plaatst zul je toch even moeten nadenken (althans, dat hopen we )

[klakkie.57th]

nu ben jij wel aan het sturen natuurlijk.
Voor mij gaat veiligheid boven alles, waarom zou ik hier dan niet over nagedacht hebben. Dat je dan bv voor het forum in een mixed omgeving terecht komt is toch ook geen probleem.

[Kain_niaK]

Heb jij kogelvrij glas thuis?

[Bunga]

De poll is toch simpel?

"willen jullie snelheid of (fake) privacy?"

Ik zou privacy toch niet te licht opnemen. Het is niet omdat wij er zelf geen evil gebruik inzien dat anderen dat niet doen. Om maar een voorbeeld uit te vinden, stel je voor dat je werkgever je traffic begint te bekijken om jou te kunnen ontslaan. Ik mag wel op tweakers zitten omdat het werkgerelateerd is maar als ik wat artikels zit te bekijken die niet gerelateerd zijn kan hij denken van "hebbes!". OK beetje vergezocht maar het punt is zowieso privacy is nodig ook al is er op dit moment nog geen probleem vastgesteld. Niemand had eraan gedacht dat de belastinginspectie gebruik zou maken van de anrp data.

Jouw tweakers data kan dan ook weer samengevoegd worden met andere info en zo weer andere aannames ondersteunen etc...

[xippie]

Of een poll met ja/nee/optioneel/misschien

[Dunky555]

Wanneer je een poll houd moet je wel dit artikel gelezen hebben lijkt mij. Wanneer mensen niet weten wat de voor- en nadelen zijn en zomaar stemmen voor het nieuwste (want dat is altijd beter), dan krijg je een scheve uitslag denk ik.

Misschien daarom een enquête houden via mail met dit artikel als begeleidend schrijven.

[Reactie gewijzigd door Dunky555 op 24 juli 2024 18:00]

[naaitsab]

Hoeft ook geen poll op de FP te zijn. Kan in een topic of onderaan dit bericht.

[Dunky555]

OK, dat is wel beter dan zomaar op de homepage ff stemmen.

[Oktopus]

Misschien alleen de ' privacy gevoelige' pagina's in https?
Inlogpagina lijkt dan voor de hand liggend.

[Brummetje]

Inlog pagina's zijn natuurlijk al simpel te encrypten zonder https. Bijvoorbeeld met JavaScript kun je wachtwoorden al omzetten naar een sha512 hash voordat het verstuurd wordt over het net.

[Kees]

Ja, maar dan kun je met die hash inloggen

Verder lopen alle inlog en profiel pagina's wel gewoon via https, en als je https-anywhere gebruikt is de site ook al grotendeels https.

[Gommers]

Daar dacht ik inderdaad ook meteen aan. Op dat moment kan er ingelogd worden met de hash waarde, dus veranderd er niets aan de situatie. Of je nu een ge-hashed password verstuurt, een hacker deze onderschept en gebruikt om in te loggen maakt geen verschil:

Als jij kunt inloggen met een hash, kan een hacker dat ook.

Het lijkt me dat hiervoor een public-key encryptie voor nodig is. Op dat moment is de content niet terug te herleiden, dus ook niet de hash of plain wachtwoord.

Je kunt het ge-hashte wachtwoord op de server ook nog een keer hashen met een salt, waardoor het uitlekken van hashes uit de database niet meteen betekend dat daarmee kan worden ingelogd.

[Brummetje]

Dan doe je het toch echt verkeerd

De systemen waar ik het gebruik werkt dat dus niet.. Want als je die hash zou gebruiken wordt die hash ook weer omgezet en komt er natuurlijk iets heel anders uit

Plus dat het natuurlijk erom gaat dat het niet zichtbaar is met wireshark bijvoorbeeld... Ik zeg niet dat de hash in de database het zelfde is natuurlijk

[Reactie gewijzigd door Brummetje op 24 juli 2024 18:00]

[MneoreJ]

De systemen waar ik het gebruik werkt dat dus niet.. Want als je die hash zou gebruiken wordt die hash ook weer omgezet en komt er natuurlijk iets heel anders uit

Als je de request kunt onderscheppen kun je gewoon een replay uitvoeren. Je hoeft niet te weten hoe de hashing werkt. Dat kun je natuurlijk weer ondervangen met challenge/response... maar dan ben je dus gewoon SSL aan het bouwen, en kun je beter gewoon SSL gebruiken.

[tympie]

Je geeft aan dat de hashing plaatsvindt op de client. De client kant is nou juist de onbetrouwbare factor. Een aanvaller hoeft niet perse jouw user interface (html/javascript, ...) te gebruiken om verbinding te maken met je systeem, hij kan het omzetten/hashen omzeilen en moet er alleen voor zorgen dat hij uiteindelijk de juiste data over het lijntje stuurt. Hashing aan de client kant maakt het een aanvaller misschien wel wat lastiger, maar is op zich niet veel veiliger.

[ACM]

Dat laatste werkt niet. Dan zou die sha512 vanaf dan de wachtwoordsleutel worden en is het nog net zo makkelijk om in te loggen bij een man-in-the-middle aanval (je weet dan alleen de plain-text niet).

En als iemand toch in man-in-the-middle situatie zit kan ie eventueel ook de opgestuurde javascript aanpassen om dat wachtwoord voor de hashing nog even ergens anders heen te sturen...

[Martinspire]

Niet iedereen (zeker op Tweakers zal de groep groter zijn) heeft Javascript aan staan. Mij boeit het weinig, maar je hebt mensen die echt alles blokken wat er te blokken valt.

[RGAT]

Javascript als beveiliging is natuurlijk vragen om gehackt te worden

[SeatRider]

Dat was ook mijn eerste reactie. Maar de inlogpagina is al via https (https://secure.tweakers.net/...) dus daar wordt nu al aan voldaan.

Job done, zou ik zeggen.

[tweaker2010]

Misschien alleen de ' privacy gevoelige' pagina's in https?
Inlogpagina lijkt dan voor de hand liggend.

Dat staan ze al, zie het fotoalbum bijvoorbeeld: https://secure.tweakers.net/my.tnet/fotoalbum

Ik zie de meerwaarde van https wel, zeker omdat Tweakers ook qua berichtgeving privacy hoog in het vaandel heeft. Misschien een stukje schijnveiligheid, maar baat het niet, schaad het niet.

[Verwijderd]

Ja, overstappen op https. Zeer goed initiatief. Met alle veiligheids- en privacyproblemen tegenwoordig zou zoveel mogelijk communicatie encrypted moeten verlopen. Https op websites draagt daar zeker aan bij.
Hieraan gerelateerd: wij willen SSL

Ik zeg: goed plan, doen! Jullie zouden een goed voorbeeld zijn voor andere sites!

[Neo_TGP]

Ik vind dit nou echt een goed voorbeeld van wat er mis is met alle privacy huilbabies van tegenwoordig..

"Met alle veiligheids- en privacyproblemen tegenwoordig zou zoveel mogelijk communicatie encrypted moeten verlopen"

Wat precies dat hier op tweakers.net is er nou zo schadelijk als iemand anders zou kunnen zien dat je het gelezen hebt? Als er nou ook goede argumenten bij dit soort comments stonden dan was het nog wat, maar het is altijd maar weer het volg de grote kudde en zeur over privacy zonder dat men zelf eigenlijk nog enig idee heeft van waar ze zich dan precies druk over maken..

Voor wat betreft Tweakers.net zou ik me kunnen voorstellen dat bijvoorbeeld de berichten module en bijvoorbeeld Vraag en Aanbod standaard https zouden gebruiken, maar voor de frontpage zou het voor mij echt geen toegevoegde waarde hebben.

[Verwijderd]

Voorbeeld: bij een topic over de zoveelste ING storing reageert een medewerker van ING. Die misschien wel een reactie wil plaatsen die zijn manager niet zint. Bijvoorbeeld dat ze daar een warboel hebben door slecht management.

Dan is het wel prettig als de manager of systeembeheerder of wie dan ook, niet kan monitoren dat diegene eerlijk zijn mening geeft.

[Neo_TGP]

Ik stel voor dat als je zo iets gaat doen dat je sowieso eerst eens moet nadenken je niet niet beter eerst met je manager kan gaan praten.. En als je als "klokkenluider" aan de gang wil zou ik dat sowieso niet doen vanaf het netwerk van je werkgever.

[Verwijderd]

Ik stel voor dat als je zo iets gaat doen dat je sowieso eerst eens moet nadenken je niet niet beter eerst met je manager kan gaan praten..

Dat sowieso, maar genoeg situaties waarin er niet wordt geluisterd. Zou toch slecht zijn als je dan niet anoniem je mening mag verkondigen.

En als je als "klokkenluider" aan de gang wil zou ik dat sowieso niet doen vanaf het netwerk van je werkgever.

Misschien doe je dat wel in je vrije tijd, thuis vanaf je eigen PC. Maar als je later een keer op je werk tweakers.net leest en je bent ingelogd wordt het alsnog aan jou(w username) gekoppeld.

[Nyarlathotep]

Je bent ook een pannenkoek van formaat als je zo'n reactie onder werktijd plaatst op een werkstation van de werkgever die je zwart gaat maken. Jouw argument kan dus de prullenbak in.

[Verwijderd]

"Zwart maken", ik zei eerlijk een mening geven.

En misschien doe je dat wel in je vrije tijd, thuis vanaf je eigen PC. Maar als je later een keer op je werk tweakers.net leest en je bent ingelogd wordt het alsnog aan jou(w username) gekoppeld.

[Rafe]

Wat dacht je van session hijacking, eentje van bijvoorbeeld een crewlid? Die kan bij persoonlijke informatie van gebruikers en bij vertrouwelijke informatie in crewfora. Het zou niet de eerste keer zijn: ReactID misbruik en de gevolgen

[Neo_TGP]

Ik zeg ook nergens dat het nooit toegevoegde waarde heeft, en dat je als crewlid bijvoorbeeld wel altijd een beveiligde verbinding gebruikt (wat nu ook al kan) is een keuze die je kan maken.. Maar dan is het nog steeds onzin om altijd maar te roepen dat alles altijd encrypted zou moeten zijn.

[Rafe]

Op mobiele devices werken addons niet om https af te dwingen. Persoonlijk ben ik ook voor een opt-in.

[StephanVierkant]

Websites die met https:// beginnen (in plaats van http://) gebruiken SSL, en zijn dus veilig.

Erg kort door de bocht. Het gebruik van SSL is slechts een onderdeel van veiligheid.

[Verwijderd]

Neem aan dat er bedoeld wordt "wat betreft de communicatie tussen website en bezoeker" (daar gaat dat artikel ook over). Uiteraard zijn er nog tig andere aspecten aan veiligheid in het algemeen.

[StephanVierkant]

Dat neem ik ook aan, maar zelfs die uitspraak is erg kort door de bocht. De afgelopen tijd zijn meerdere bugs openbaar geworden, dus alleen het gebruik van SSL (zonder verder details te vermelden, zoals welke versie) is niet per definitie veilig.

Ik val niet over het incomplete van de stelling, maar de stelligheid. Elke beveiligingstechniek maakt het misschien veiliger, maar de stelling "en is dus veilig" is mij echt te kort door de bocht.

[sjongenelen]

Jij kunt toch prima naar de https versie gaan?

Ik wil het liever niet, dus verplichten nee dank je