https mixed content warning

[crisp]

Omgekeerd: gaat het echt zo vaak nog fout dan?

desnoods doe je dat alleen bij een handjevol bekende hosts, dan heb je al meteen de grote bulk van de plaatjes.

Dat doen we serverside iig al

[Hero of Time]

ACM schreef op donderdag 1 november 2018 @ 22:44:
[...]

Vast niet, maar wellicht deed dat plaatje het wel bij de topicstarter via https... Je weet maar nooit wat men allemaal aan certificaten whitelist

Overigens doet de afbeelding in de reactie waar jij naar verwijst het ook gewoon via https bij mij, zonder browser-warning.

Nu op werk in Firefox doet 'ie het idd, maar gisteravond thuis met Otter dus niet, daar krijg ik deze melding:

Connection is insecure
The owner of assets.amuniversal.com has configured their page improperly. To protect your information from being stolen, connection to this website was aborted.

Als ik dan kijk naar het certificaat, staat er dan ook ssl.cdngc.net bij Common Name. Daar zal Otter over vallen denk ik zo. En het is ook volkomen terecht dat er zo'n melding komt, wat de naam in het certificaat komt niet overeen met de site die ik bezoek. Alsof ik een certificaat voor Google krijg als ik Tweakers bezoek. Valideert allebei, maar niet voor de juiste site.

[crisp]

Hero of Time schreef op vrijdag 2 november 2018 @ 07:57:
[...]

Nu op werk in Firefox doet 'ie het idd, maar gisteravond thuis met Otter dus niet, daar krijg ik deze melding:

[...]

Als ik dan kijk naar het certificaat, staat er dan ook ssl.cdngc.net bij Common Name. Daar zal Otter over vallen denk ik zo. En het is ook volkomen terecht dat er zo'n melding komt, wat de naam in het certificaat komt niet overeen met de site die ik bezoek. Alsof ik een certificaat voor Google krijg als ik Tweakers bezoek. Valideert allebei, maar niet voor de juiste site.

Ik ben geen expert in certificaten, maar ik zie assets.amuniversal.com wel staan bij 'Certificate Subject Alt Name'...

[Hero of Time]

Daar staat idd een hele waslijst met alt names. Die ik overigens niet zie met openssl -connect. Dan moet het daar fout gaan.

[ACM]

crisp schreef op vrijdag 2 november 2018 @ 08:07:
Ik ben geen expert in certificaten, maar ik zie assets.amuniversal.com wel staan bij 'Certificate Subject Alt Name'...

Sterker nog, dat is ook hoe het certificaat voor Tweakers werkt. Het domein gathering.tweakers.net zit ook in het certificaat geintegreerd van die van tweakers.net

[Raven]

ACM schreef op donderdag 1 november 2018 @ 22:24:
Daar zijn wmb de topicreports voor

offtopic:
Dan moeten die wel afgehandeld worden , ik heb er weer eens een paar her en der openstaan die nooit afgehandeld zullen worden omdat de topics inmiddels druk bezig zijn met wegzakken. Waaronder in SB...

[.oisyn]

ACM schreef op donderdag 1 november 2018 @ 22:24:
[...]

Sterker nog, hij ziet een https-url (zoals al eerder in dit topic gemeld) en vertrouwd erop dat dat klopt. Gaan we wmb ook niet fixen.

Het is in beginsel de verantwoordelijkheid van de gebruiker om afbeeldingen te linken die werken, maar doet ie dat met http; dan zetten wij dat om via onze https-proxy, de gebruiker heeft tenslotte niet altijd de keus om er https van te maken.

Het is niet ons doel om automatisch alle afbeeldingen te downloaden en te checken of e.e.a. ook echt werkt met https. Dat is bovendien onbetrouwbaar, want certificaten en protocollen verouderen/verlopen of kunnen in (specifieke) browsers uitgesloten worden. Dat zou dan betekenen dat we eigenlijk elke https-afbeelding steeds opnieuw zouden moeten controleren...

Wat mij betreft stoppen we ook met dit soort foutieve urls als 'bug' te beschouwen, het is uiteindelijk gewoon een onjuist geplaatste afbeelding. Daar zijn wmb de topicreports voor

Wacht even, zeg je nu dat de image checker van een post niet eerst HTTPS probeert als je linkt naar HTTP? Want dat doet ie dus wel. En dat is imho gewoon een bug als het plaatje niet voor iedereen standaard beschikbaar is via HTTPS.

.edit: oh wacht er was nog een pagina

crisp schreef op donderdag 1 november 2018 @ 23:46:
Omgekeerd: gaat het echt zo vaak nog fout dan?


[...]

Dat doen we serverside iig al

Ik zie het zo nu en dan gebeuren. Het probleem is dat de poster het niet opvalt, want bij hem werkt het gewoon, want die accepteert een fout certificaat.

Maar als je dat serverside al doet, waarom dan zo krampachtig volhouden proberen aan de clientkant al HTTPS te proberen?

[ Voor 18% gewijzigd door .oisyn op 27-11-2018 16:06 ]

[ACM]

.oisyn schreef op dinsdag 27 november 2018 @ 16:03:
Wacht even, zeg je nu dat de image checker van een post niet eerst HTTPS probeert als je linkt naar HTTP? Want dat doet ie dus wel. En dat is imho gewoon een bug als het plaatje niet voor iedereen standaard beschikbaar is via HTTPS.

Er zijn twee dingen relevant hierbij:
- Wat de gebruiker post, na eventuele javascript processing
- Wat de gebruiker invoert; dus voor eventuele javascript processing

Van de urls die met de POST-request meekomen gaan we bij https-urls ervanuit dat die werken. We gaan dus niet (steeds) testen meer of de https-urls wel valide zijn, geldige certificaten hebben, logins nodig hebben, etc. Dat is onbegonnen werk en een enorme verspilling van resources; en dan waarschijnlijk alsnog onbetrouwbaar op het moment dat bijvoorbeeld bij een client strengere ssl-validatie aanstaat of de https-versie anders blijkt te zijn dan de http-versie (maar wel beide images).

We testen trouwens ook niet of plaatjes met http-urls het wel doen, die zetten we blind om via onze image proxy.

Net voor submit wordt bij de plaatjes-check functie inderdaad nog voor iedere afbeelding gechecked of ie toevallig met https werkt en zoniet dan de http-versie gebruikt.

Ik zie het zo nu en dan gebeuren. Het probleem is dat de poster het niet opvalt, want bij hem werkt het gewoon, want die accepteert een fout certificaat.

Maar als je dat serverside al doet, waarom dan zo krampachtig volhouden proberen aan de clientkant al HTTPS te proberen?

Krampachtig? Zoals gezegd gaan we wmb geen resources verspillen aan server-side testen of afbeeldingsurls wel werken. En ook als we niet zelf afbeeldingen om zouden zetten naar https via de client side, zouden jouw scenario's ook misgaan als de gebruiker van die sites zelf https-linkjes neerzet. Dat hebben we tenslotte ook gezien met gebruikers die plaatjes plaatsten waar authenticatie voor nodig was...

Uiteindelijk hebben wij invulling gegeven aan de door gebruikers uitdrukkelijk uitgesproken wens om de site via HTTPS uit te serveren. Maar dat betekent wel dat er een paar randvoorwaarden zijn ontstaan; de resources - zoals door gebruikers geplaatste afbeeldingen - moeten via https.

Omdat dat laatste toen in ieder geval niet realistisch afgedwongen kon worden, hebben we twee dingen gedaan: pro-actief toch https proberen en als dat echt niet kan dan via onze eigen https-proxy.


Wellicht moeten we gewoon stoppen met die proxy en iedereen verplichten https-images toe te voegen? Want effectief ondersteunen we nu een gebruiksscenario dat buiten de wens van diezelfde gebruikers viel.
Deze laatste vraag is niet eens bedoeld als rant, maar een serieus vraag

[.oisyn]

ACM schreef op dinsdag 27 november 2018 @ 20:18:
[...]

Er zijn twee dingen relevant hierbij:

Niet echt. Voor jullie relevant, maar vanuit het oogpunt van de gebruiker totaal niet . Er telt maar 1 ding: wat hij in het formulier invoert. Wat er verder mee gebeurt ligt compleet binnen jullie controle. Je kunt de gebruiker niet de verantwoordelijkheid toewijzen voor wat het clientside controleerscript met de invoer doet.

We gaan dus niet (steeds) testen meer of de https-urls wel valide zijn

Waarom staat die "steeds" daar? Hij staat dan wel tussen haakjes, maar ik zie niet hoe het ooit van toepassing is. Er is maar 1 moment: op het moment dat het plaatje wordt toegevoegd aan een post.

Dat is onbegonnen werk en een enorme verspilling van resources;

Jullie doen het ook voor niet-https-plaatjes, wat nog veel meer resources kost (het plaatje moet daadwerkelijk gedownload en opgeslagen worden), dus eerlijk gezegd denk ik het mijne bij deze stelling . Meer resources dan nu idd, dat is zeker waar. En op een andere plek/moment (plaatjesproxy ipv forumpost).

en dan waarschijnlijk alsnog onbetrouwbaar op het moment dat bijvoorbeeld bij een client strengere ssl-validatie aanstaat of de https-versie anders blijkt te zijn dan de http-versie (maar wel beide images).

Valide argument. Misschien gewoon helemaal niet meer omzetten, dan? . Dat is uiteindelijk mijn voorstel: de clientside plaatjeschecker niet de test laten doen maar gewoon respecteren wat de gebruiker heeft ingevoerd.

De serverside check is dan alleen maar een optimalisatie om de proxy te verlichten (waardoor je uiteindelijk mínder resources gebruikt tov gewoon alles proxy'en wat http is)

Krampachtig? Zoals gezegd gaan we wmb geen resources verspillen aan server-side testen of afbeeldingsurls wel werken.

Dat vind ik kortzichtig. Er is meer data nodig natuurlijk, maar je moet de afweging maken hoeveel van de plaatjes uiteindelijk succesvol worden geconverteerd van tevoren. Er is een reden dat de gebruiker een http link pastete - zo is het plaatje hem geserveerd. Sites met goed werkende https hanteren in de regel sowieso al https URL's. En daarnaast hebben jullie naar eigen zeggen een whitelist van de grote plaatjesserveerders.

En ook als we niet zelf afbeeldingen om zouden zetten naar https via de client side, zouden jouw scenario's ook misgaan als de gebruiker van die sites zelf https-linkjes neerzet. Dat hebben we tenslotte ook gezien met gebruikers die plaatjes plaatsten waar authenticatie voor nodig was...

Don't make perfect the enemy of good enough. Ik constateer een probleem dat in principe oplosbaar is. Het kost idd niet álle problemen op, maar wel een groot deel. Of je tijd en resources wil spenderen aan die oplossing is uiteraard aan jullie .

Wellicht moeten we gewoon stoppen met die proxy en iedereen verplichten https-images toe te voegen? Want effectief ondersteunen we nu een gebruiksscenario dat buiten de wens van diezelfde gebruikers viel.
Deze laatste vraag is niet eens bedoeld als rant, maar een serieus vraag

Natuurlijk is dit wel een rant en totaal niet iets dat jullie willen .

[ Voor 3% gewijzigd door .oisyn op 27-11-2018 20:59 ]

[ACM]

.oisyn schreef op dinsdag 27 november 2018 @ 20:54:
Niet echt. Voor jullie relevant, maar vanuit het oogpunt van de gebruiker totaal niet

Het was relevant voor de opmerking die je maakte a.d.h.v. mijn eerdere antwoord.

Waarom staat die "steeds" daar? Hij staat dan wel tussen haakjes, maar ik zie niet hoe het ooit van toepassing is. Er is maar 1 moment: op het moment dat het plaatje wordt toegevoegd aan een post.

Omdat een plaatje dat nu werkt via https over een week een ingetrokken of verlopen certificaat kan hebben.
Bij http kan het natuurlijk ook gebeuren dat plaatjes niet werken, maar bovenop 404's en verdwijnende hosts komen er dus nog wat meer varianten bij waarom een host niet goed is. Ook problemen die je aanhaalt waar we 'nu' op zouden moeten checken.

Jullie doen het ook voor niet-https-plaatjes, wat nog veel meer resources kost (het plaatje moet daadwerkelijk gedownload en opgeslagen worden), dus eerlijk gezegd denk ik het mijne bij deze stelling . Meer resources dan nu idd, dat is zeker waar.

Nee dat doen we niet. Met checken bedoel ik specifiek een plaatje server-side downloaden, controleren wat de response was en als die niet werkte dan nog via http proberen. Dat vraagt om problemen die waarschijnlijk ook de nodige hoeveelheid false positives geeft, juist bij hosts die sowieso hun https niet lekker hebben geconfigureerd (of net als wij clients redelijk streng behandelen).
Bovendien is het dan alsnog 'achteraf', zonder dat de gebruiker daar wat van merkt.

Dat vind ik kortzichtig. Er is meer data nodig natuurlijk, maar je moet de afweging maken hoeveel van de plaatjes uiteindelijk succesvol worden geconverteerd van tevoren. Er is een reden dat de gebruiker een http link paste - zo is het plaatje hem geserveerd. Sites met goed werkende https hanteren in de regel sowieso al https URL's.

Er is nog veel te veel fout geconfigureerde https waarbij plaatjes niet werden gedirect terwijl er ook gewoon een https versie van was. Maar zonder data kunnen we beide eigenlijk alleen op inschattingen reageren

En daarnaast hebben jullie naar eigen zeggen een whitelist van de grote plaatjesserveerders.

Alleen van de grote. Wat dus een aardige lange long-tail van allerlei andere hosts geeft.

Natuurlijk is dit wel een rant en totaal niet iets dat jullie willen .

Het is vooral een verzuchting dat de wens tot https zoveel gedoe blijft opleveren. Bij een poging om gebruikers te helpen bij wat theoretisch gezien ongewenste input is (http-links) lijkt niet goed te doen.

• "Foute" urls, met http, laten staan en niet proxyen levert mixed content op
• De urls blind laten staan zorgt voor een zwaardere belasting van onze proxies (ik heb geen cijfers voor hoeveel). En die proxy is ook niet perfect, waardoor die imperfecties meer zichtbaar worden.
• Zoveel mogelijk alvast omzetten naar https (wat we nu doen) geeft de hier benoemde problemen
• Dat verplaatsten naar server-side geeft waarschijnlijk allerlei andere nieuwe problemen en waarschijnlijk ook daarnaast een deel van dezelfde die we nu hebben

De http-urls als invalid input hanteren is daarom een eenvoudige oplossing voor de meeste problemen, maar geen gebruiksvriendelijke (wat dus weer een nieuw probleem geeft).

Ik heb ook een beetje de angst dat uberhaupt die plaatjes controleren als ze op http staan op den duur niet meer goed gaat werken - dus met name de afmetingcheck niet meer - door mixed content issues. Dat zou dan een extra reden zijn om toch eerst de https-versie even te proberen. Tenzij natuurlijk dat 'controleer mijn plaatjes' uberhaupt ongewenst is?

[.oisyn]

Ik kan me on veel van de punten die je noemt wel vinden, hoor. Wat betreft de laatste vraag, wmb is de afmetingchecker wel gewenst, en je kunt 'm altijd nog uitzetten indien nodig.

[ACM]

We gaan dit voorlopig niet veranderen, maar wellicht wordt het relevant ivm de interpretatie van de AVG door de AP