https mixed content warning

[Raven]

Waar kan ik deze connector kopen?

12:28:56.615 Laden van gemengde (onveilige) vensterinhoud ‘http://i1007.photobucket.com/albums/af191/Richard-0/20160914_142444_zpsj1gjhfn3.jpg’ op een beveiligde pagina11719657

12:28:56.691 Content Security Policy: De instellingen van de pagina hebben het laden van een bron op
http://i1007.photobucket....14_142444_zpsj1gjhfn3.jpg (‘default-src https: data: 'unsafe-inline' 'unsafe-eval'’) waargenomen. Er wordt een CSP-rapport verzonden.1(onbekend)

[crisp]

https://s1007.photobucket...14_142444_zpsj1gjhfn3.jpg redirect daar naar http://i1007.photobucket....14_142444_zpsj1gjhfn3.jpg

Helaas is dat lastig te voorkomen. In feite heeft de topicstarter gewoon de verkeerde link gebruikt, en photobucket is stom om dan naar een http-variant te redirecten terwijl ze gewoon https ondersteunen

Ik heb het nu handmatig maar gefixed...

[ Voor 5% gewijzigd door crisp op 15-09-2016 13:14 ]

[Raven]

Hier nog 1: https://gathering.tweakers.net/forum/view_message/48319971

Content Security Policy: De instellingen van de pagina hebben het laden van een bron op http://www.doyouremember....aw-1338634358-595x417.jpg (‘default-src https: data: 'unsafe-inline' 'unsafe-eval'’) waargenomen. Er wordt een CSP-rapport verzonden.

Laden van gemengde (onveilige) vensterinhoud ‘http://www.doyouremember.co.uk/uploads/raw-1338634358-595x417.jpg’ op een beveiligde pagina

[crisp]

Raven schreef op zaterdag 17 september 2016 @ 19:51:
Hier nog 1: https://gathering.tweakers.net/forum/view_message/48319971

[...]

Weer een host die https naar http redirect. Ik zal hem op onze blacklist zetten. Ondertussen de post aangepast

[Raven]

Thanks

Zijn de hosts van https://gathering.tweakers.net/forum/view_message/47987405 en https://gathering.tweakers.net/forum/view_message/47998353 ook al geblacklist? Die had ik in het algemene en inmiddels gesloten https-topic genoemd.

[ Voor 16% gewijzigd door Raven op 17-09-2016 20:21 ]

[crisp]

Raven schreef op zaterdag 17 september 2016 @ 20:19:
Thanks

Zijn de hosts van https://gathering.tweakers.net/forum/view_message/47987405 en https://gathering.tweakers.net/forum/view_message/47998353 ook al geblacklist? Die had ik in het algemene en inmiddels gesloten https-topic genoemd.

Die had ik dan gemist Zal ze er ook op zetten; ondertussen iig alvast aangepast

[PE4000]

Ik weet niet zo of dit ook relevant is: https://gathering.tweakers.net/forum/view_message/48544991

[Raven]

Ehm, ik zie daar nu wel een afbeelding

[Raven]

Weer een: tazzman in "Heb je iets nieuws en MOET je het gewoon showen deel 121"
In GKMT laatst ook, alleen vergeten te melden en gezien de snelheid van die topicreeks is terugvinden onmogelijk

[ Voor 35% gewijzigd door Raven op 27-10-2016 14:09 ]

[crisp]

Raven schreef op donderdag 27 oktober 2016 @ 14:08:
Weer een: tazzman in "Heb je iets nieuws en MOET je het gewoon showen deel 121"
In GKMT laatst ook, alleen vergeten te melden en gezien de snelheid van die topicreeks is terugvinden onmogelijk

Hmm, postimg.org staat op onze 'safe' list van image hosts die https ondersteunen. Blijkbaar zijn ze daar vanaf gestapt

[Raven]

https://gathering.tweakers.net/forum/view_message/49165167 ....

[crisp]

Raven schreef op donderdag 17 november 2016 @ 19:03:
https://gathering.tweakers.net/forum/view_message/49165167 ....

Thanks, even met de hand aangepast

[Raven]

https://gathering.tweakers.net/forum/view_message/49522865

http://cabforward.com/wp-...P-Crewmans-Smoke-Hood.png

[crisp]

Raven schreef op zaterdag 17 december 2016 @ 12:40:
https://gathering.tweakers.net/forum/view_message/49522865

http://cabforward.com/wp-...P-Crewmans-Smoke-Hood.png

Fixed

[Raven]

Thanks

[Hero of Time]

FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016" heeft ook een plaatje dat SSL errors geeft. Krijg helaas niet precies te zien wat er mis is, het certificaat of de chain.

[crisp]

Hero of Time schreef op maandag 19 december 2016 @ 21:20:
FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016" heeft ook een plaatje dat SSL errors geeft. Krijg helaas niet precies te zien wat er mis is, het certificaat of de chain.

Ook maar even via de proxy laten gaan

[Hero of Time]

Opnieuw: FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016"
Plaatje: https://content2.skoften....3/picdump_930_37__800.jpg
Ik dacht dat je skoften.net via de proxy laat lopen? Of is deze niet via de parser naar https omgezet maar door de poster zelf direct als https ingevuld?

[crisp]

Hero of Time schreef op woensdag 28 december 2016 @ 13:31:
Opnieuw: FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016"
Plaatje: https://content2.skoften....3/picdump_930_37__800.jpg
Ik dacht dat je skoften.net via de proxy laat lopen? Of is deze niet via de parser naar https omgezet maar door de poster zelf direct als https ingevuld?

Dat plaatje lijkt het hier gewoon goed te doen?

[Hero of Time]

Ik krijg er toch echt SSL meldingen op. Helaas is Otter erg beperkt hiermee. Opera 12 geeft echter geen melding. Vreemd.

[Raven]

https://gathering.tweakers.net/forum/view_message/49687869 + https://gathering.tweakers.net/forum/view_message/49687829 , gaat om dezelfde host: dslreports.com

[ Voor 4% gewijzigd door Raven op 01-01-2017 15:34 ]

[Osiris]

Wat een zakken hooi bij DSLreports: CloudFront ondersteunt namelijk gewoon TLS, dus ze zouden hun redirects wel eens mogen ver-TLS-en

[crisp]

Osiris schreef op zondag 1 januari 2017 @ 15:44:
Wat een zakken hooi bij DSLreports: CloudFront ondersteunt namelijk gewoon TLS, dus ze zouden hun redirects wel eens mogen ver-TLS-en

Ze staan nu iig op onze https 'shitlist'

[Raven]

McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

[ Voor 8% gewijzigd door Raven op 05-02-2017 11:43 ]

[Hero of Time]

Reddit? Het plaatje linkt naar imgur. De embedding is alleen wat fout gedaan door hem omdat het door reddit gaat naar imgur (hij heeft de link van het plaatje van reddit ipv de directe link).

[_David_]

Raven schreef op zondag 5 februari 2017 @ 11:42:
McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

Imgur*

De outbound tracking link van Reddit (out.reddit.com) is wel HTTPS, maar de imgur URL waar die naar doorstuurt is dat weer niet HTTPS...

Is het niet een idee om die out.reddit.com links te verbouwen zodat alleen de 'echte' URL (URL parameter) er uitgehaald wordt?

Edit: ik zie dat crisp al aan het editten is

[ Voor 5% gewijzigd door _David_ op 05-02-2017 12:35 ]

[crisp]

Raven schreef op zondag 5 februari 2017 @ 11:42:
McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

Dat plaatje is gewoon stuk..

[Raven]

Hero of Time schreef op zondag 5 februari 2017 @ 12:23:
Reddit? Het plaatje linkt naar imgur. De embedding is alleen wat fout gedaan door hem omdat het door reddit gaat naar imgur (hij heeft de link van het plaatje van reddit ipv de directe link).

Woops, zo ver had ik niet gekeken

crisp schreef op zondag 5 februari 2017 @ 12:27:
[...]

Dat plaatje is gewoon stuk..

Nu wel ja , laad niet meer.

[_David_]

crisp schreef op zondag 5 februari 2017 @ 12:27:
[...]

Dat plaatje is gewoon stuk..

De eerste keer dat ik de link opende (voordat hij geedit werd ) deed hij het nog, en als je de link uit de URL parameter haalt, dat doet ie het ook:

[Hero of Time]

Link in img tags hoort eigenlijk https://i.imgur.com/cNqQlY7.jpg te zijn, zoals _David_ demonstreert.

[crisp]

Bij deze aangepast

[Raven]

Weer eens een mixed content warning: Touchdomex in "Het grote kleinemededelingentopic - Deel 360"

[crisp]

Raven schreef op zaterdag 11 maart 2017 @ 10:00:
Weer eens een mixed content warning: Touchdomex in "Het grote kleinemededelingentopic - Deel 360"

Aangepast

[_David_]

De smiley in de quickreply alert van dit topic: [alg] Slechtste programmeervoorbeelden deel 5 is niet gereparsed naar https.

HTML:

<div class="bar warning topicwarning">
<strong>Let op:</strong>
<br>Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. 
<img src="http://tweakimg.net/g/s/smile.gif" alt=":)" />
</div>

[crisp]

_David_ schreef op zondag 19 maart 2017 @ 18:27:
De smiley in de quickreply alert van dit topic: [alg] Slechtste programmeervoorbeelden deel 5 is niet gereparsed naar https.

HTML:

<div class="bar warning topicwarning">
<strong>Let op:</strong>
<br>Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. 
<img src="http://tweakimg.net/g/s/smile.gif" alt=":)" />
</div>

Aangepast

[Raven]

Weer een: Saffie_time in "Het grote kleineSmålandtopic - Deel 361"
host: www.112groningen.nl

[ Voor 74% gewijzigd door Raven op 27-03-2017 10:28 ]

[crisp]

Raven schreef op maandag 27 maart 2017 @ 10:25:
Weer een: Saffie_time in "Het grote kleineSmålandtopic - Deel 361"
host: www.112groningen.nl

Fixed

[Raven]

https://gathering.tweakers.net/forum/view_message/51081671
http://www.autoblog.nl dit keer.

[crisp]

Raven schreef op maandag 1 mei 2017 @ 19:08:
https://gathering.tweakers.net/forum/view_message/51081671
http://www.autoblog.nl dit keer.

Fixed

[Raven]

Weer een tegengekomen: https://gathering.tweakers.net/forum/view_message/51285219
www.112groningen.nl

[crisp]

Raven schreef op zaterdag 20 mei 2017 @ 10:52:
Weer een tegengekomen: https://gathering.tweakers.net/forum/view_message/51285219
www.112groningen.nl

Fix0red

[Raven]

Crim in "Betatest nieuwe redactionele layout"
https://imageshack.com/a/img924/2629/u0TACm.png

[crisp]

Raven schreef op woensdag 14 juni 2017 @ 16:52:
Crim in "Betatest nieuwe redactionele layout"
https://imageshack.com/a/img924/2629/u0TACm.png

meh, die redirect naar http://imagizer.imageshack.us/a/img924/2629/u0TACm.png terwijl https://imagizer.imageshack.us/a/img924/2629/u0TACm.png ook gewoon werkt

Anyway, fixed voor deze, maar aangezien imageshack vaak gebruikt wordt zullen we hier ben ik bang wel even verder maatregelen voor treffen...

[Raven]

Vaak? Ik kan mij niet eens herinneren wanneer die voor het laatst gebruikt werd hier Tegenwoordig is het meer imgur dan wat anders en daar kun je geëmbedde plaatjes niet zomaar van saven (Zelfde als https://www.reddit.com/r/..._photos_from_photobucket/ )

Thanks

[Raven]

CaptJackSparrow in "[Ervaringen] Oplaadbare Batterijen"
https://www.aldi.nl/image...batterijen_big_115610.jpg

[ Voor 23% gewijzigd door Raven op 25-06-2017 13:46 ]

[Osiris]

Raven schreef op zondag 25 juni 2017 @ 13:39:
CaptJackSparrow in "[Ervaringen] Oplaadbare Batterijen"
https://www.aldi.nl/image...batterijen_big_115610.jpg

Da's ook wel een beetje gepruts van Aldi's kant:

[b][green]osiris@desktop [/][blue]~ $ [/][/]curl -vIL https://www.aldi.nl/images/oplaadbare_batterijen_big_115610.jpg
*   Trying 54.230.14.125...
* Connected to www.aldi.nl (54.230.14.125) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=DE; ST=Nordrhein-Westfalen; L=Essen; O=Aldi Einkauf GmbH & Co. oHG; CN=www.aldi.nl
*  start date: Apr 26 00:00:00 2017 GMT
*  expire date: Nov 14 23:59:59 2017 GMT
*  subjectAltName: host "www.aldi.nl" matched cert's "www.aldi.nl"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SHA256 SSL CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1bb01c0)
> HEAD /images/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302 
HTTP/2.0 302 
< content-type: text/html; charset=iso-8859-1
content-type: text/html; charset=iso-8859-1
< content-length: 253
content-length: 253
< location: http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
location: http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
< server: nginx
server: nginx
< date: Sun, 25 Jun 2017 12:28:13 GMT
date: Sun, 25 Jun 2017 12:28:13 GMT
< x-frame-options: *
x-frame-options: *
< expires: Sun, 25 Jun 2017 14:28:13 GMT
expires: Sun, 25 Jun 2017 14:28:13 GMT
< cache-control: max-age=7200
cache-control: max-age=7200
< x-cache-status: HIT
x-cache-status: HIT
< age: 24
age: 24
< x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
< via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
< x-amz-cf-id: EK43sa07LGt6nG8pMXzBJWtEN2zB_YTUp8MWo5B9OvJddGnDOSjQbQ==
x-amz-cf-id: EK43sa07LGt6nG8pMXzBJWtEN2zB_YTUp8MWo5B9OvJddGnDOSjQbQ==

< 
* Connection #0 to host www.aldi.nl left intact
* Issue another request to this URL: 'http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg'
*   Trying 54.230.128.156...
* Connected to www.aldi.nl (54.230.128.156) port 80 (#1)
> HEAD /images_archiv/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: CloudFront
Server: CloudFront
< Date: Sun, 25 Jun 2017 12:28:38 GMT
Date: Sun, 25 Jun 2017 12:28:38 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 183
Content-Length: 183
< Connection: keep-alive
Connection: keep-alive
< Location: https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
Location: https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
< X-Cache: Redirect from cloudfront
X-Cache: Redirect from cloudfront
< Via: 1.1 b2053f9f1abb60895bf31f80837ba9b6.cloudfront.net (CloudFront)
Via: 1.1 b2053f9f1abb60895bf31f80837ba9b6.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: XEd8axI7ZYAqWk45hEgu6TIcEbhLNtQcgH9ceb0Y0kTI8qT4OV2s1g==
X-Amz-Cf-Id: XEd8axI7ZYAqWk45hEgu6TIcEbhLNtQcgH9ceb0Y0kTI8qT4OV2s1g==

< 
* Connection #1 to host www.aldi.nl left intact
* Issue another request to this URL: 'https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg'
* Found bundle for host www.aldi.nl: 0x1bc65f0 [can multiplex]
* Re-using existing connection! (#0) with host www.aldi.nl
* Connected to www.aldi.nl (54.230.14.125) port 443 (#0)
* Using Stream ID: 3 (easy handle 0x1bb01c0)
> HEAD /images_archiv/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
< HTTP/2.0 200 
HTTP/2.0 200 
< content-type: image/jpeg
content-type: image/jpeg
< content-length: 130909
content-length: 130909
< server: nginx
server: nginx
< date: Sun, 25 Jun 2017 12:28:38 GMT
date: Sun, 25 Jun 2017 12:28:38 GMT
< x-frame-options: *
x-frame-options: *
< last-modified: Fri, 23 Jun 2017 13:19:41 GMT
last-modified: Fri, 23 Jun 2017 13:19:41 GMT
< expires: Sun, 25 Jun 2017 14:28:38 GMT
expires: Sun, 25 Jun 2017 14:28:38 GMT
< cache-control: max-age=7200
cache-control: max-age=7200
< x-cache-status: HIT
x-cache-status: HIT
< accept-ranges: bytes
accept-ranges: bytes
< x-cache: Miss from cloudfront
x-cache: Miss from cloudfront
< via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
< x-amz-cf-id: ZufVknDqNyqOuI7UrjItKqWkuls1g5lBJ9m4n15aZQ5TLEqjbI8hFw==
x-amz-cf-id: ZufVknDqNyqOuI7UrjItKqWkuls1g5lBJ9m4n15aZQ5TLEqjbI8hFw==

< 
* Connection #0 to host www.aldi.nl left intact
[b][green]osiris@desktop [/][blue]~ $ [/][/]

De URL wordt geredirect naar een ander path, via een non-HTTPS-URL. Komt uiteindelijk wel weer uit bij een HTTPS-URL, dus een nutteloze tussenstap, maar da's Aldi's fout.

Idealiter zou de caching server de redirects volgen totdat 'ie bij de daadwerkelijke content uitkomt en die laatste URL gebruiken indien er een HTTP redirect in voorkomt.

[crisp]

Dan maar via onze eigen proxy

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 14:36:
Dan maar via onze eigen proxy

Misschien wel interessant om een eventuele patch voor "follow redirects with non-HTTPS-checking" ook via GitHub aan te bieden?

Of blijft 't bij handmatig fixen van dit soort issues?

[crisp]

Osiris schreef op zondag 25 juni 2017 @ 14:58:
[...]

Misschien wel interessant om een eventuele patch voor "follow redirects with non-HTTPS-checking" ook via GitHub aan te bieden?

Of blijft 't bij handmatig fixen van dit soort issues?

Onze proxy volgt gewoon redirects? Het probleem was dat de link in 1e instantie niet geproxied werd omdat de https-versie an sich gewoon werkte. Het blijft handwerk om imagehosts die https redirecten naar/via http via onze proxy te forceren. Dat, of echt alles gaan proxieën ook als https wel goed werkt...

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 15:14:
[...]

Onze proxy volgt gewoon redirects? Het probleem was dat de link in 1e instantie niet geproxied werd omdat de https-versie an sich gewoon werkte. Het blijft handwerk om imagehosts die https redirecten naar/via http via onze proxy te forceren.

Je kunt natuurlijk ook gedurende het redirecten checken of er een non-HTTPS URL tussen zit en indien dat het geval is geen genoegen nemen met die chain of redirects en het geheel proxien. Iets wat klaarblijkelijk nu niet gebeurt? Dat lijkt me niet per se handwerk te hoeven zijn.

crisp schreef op zondag 25 juni 2017 @ 15:14:
(…) of echt alles gaan proxieën ook als https wel goed werkt...

Dat is het nou net: het werkt niet goed zodra er bij al die redirects er een HTTP-URL tussen zit. Dan accepteert (in ieder geval) Chromium het plaatje niet zonder het groene slotje weg te halen.

[ Voor 26% gewijzigd door Osiris op 25-06-2017 15:20 ]

[crisp]

@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 17:15:
@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

En er komt klaarblijkelijk geen error-event op een mixed-content-warning? Is er geen warning te vinden somehow in dat proces? Want de browser spuugt zo'n warning wel over de console heen, de vraag is alleen of je dat bij je client-side check t.b.v. de caching proxy kunt gebruiken

[ Voor 15% gewijzigd door Osiris op 25-06-2017 17:26 ]

[crisp]

Osiris schreef op zondag 25 juni 2017 @ 17:25:
[...]

En er komt klaarblijkelijk geen error-event op een mixed-content-warning? Is er geen warning te vinden somehow in dat proces? Want de browser spuugt zo'n warning wel over de console heen, de vraag is alleen of je dat bij je client-side check t.b.v. de caching proxy kunt gebruiken

Nope, het plaatje laadt immers wel...

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 20:11:
[...]

Nope, het plaatje laadt immers wel...

Is 't niet mogelijk algemene waarschuwingen af te vangen (lees: mixed content warnings) en te checken of het 't desbetreffende plaatje betreft?

Sowieso natuurlijk goed om global mixed content warnings proberen af te vangen, aangezien dat 't doel is van de proxy Moet 't alleen wél mogelijk zijn

[Raven]

Ze germans are coming?
@crisp Geen specifieke post dit keer, het gaat op elke pagina mis

http://www.smartdodo.com/GOT/heilpompom.gif

[crisp]

Raven schreef op maandag 3 juli 2017 @ 14:46:
Ze germans are coming?
@crisp Geen specifieke post dit keer, het gaat op elke pagina mis

http://www.smartdodo.com/GOT/heilpompom.gif

Maar even in mijn eigen fotoalbum gezet; die is wel https

[Raven]

Dat is ook een oplossing

Overigens, die domeinnaam, @SmartDoDo ?

[Hero of Time]

gambieter in "Het grote grappige plaatjes topic Editie Q3-2017" bevat een Fokke en Sukke plaatje gehost op http://www.cs.vu.nl//~fra...kke-sukke-consultancy.jpg. Het plaatje staat er met https in, maar redirect direct naar http. Met als gevolg dat in mijn geval het plaatje niet geladen wordt.

[crisp]

Hero of Time schreef op donderdag 6 juli 2017 @ 12:05:
gambieter in "Het grote grappige plaatjes topic Editie Q3-2017" bevat een Fokke en Sukke plaatje gehost op http://www.cs.vu.nl//~fra...kke-sukke-consultancy.jpg. Het plaatje staat er met https in, maar redirect direct naar http. Met als gevolg dat in mijn geval het plaatje niet geladen wordt.

Fix0red

[Hero of Time]

crisp schreef op donderdag 6 juli 2017 @ 12:07:
[...]

Fix0red

Wauw. Snelheidsrecord?

[Raven]

https://gathering.tweakers.net/forum/view_message/51792425

Mixed content warning via IPv4, via IPv6 laad de hele afbeelding niet:

Uw verbinding is niet beveiligd

De eigenaar van www.hopefarms.nl heeft zijn of haar website niet juist geconfigureerd. Om uw gegevens tegen diefstal te beschermen, heeft Firefox geen verbinding met deze website gemaakt.

[ Voor 46% gewijzigd door Raven op 12-07-2017 11:37 ]

[crisp]

Raven schreef op woensdag 12 juli 2017 @ 11:36:
https://gathering.tweakers.net/forum/view_message/51792425

Mixed content warning via IPv4, via IPv6 laad de hele afbeelding niet:

[...]

En ook via de proxy geforceerd

[Raven]

Zojuist weer eens een warning tegengekomen, alleen was ik verantwoordelijk
http://wp.tipsenweetjes.n.../uploads/2017/04/Toet.jpg
Het bericht is al aangepast door het plaatje via mijn eigen domeinnaam/hostingpakket weer te geven.

Kan de betreffende hoster (tipsenweetjes.nl) via de proxy geforceerd worden?

[Raven]

Weer een: keverjeroen in "Het Grote Lego Topic - Deel 5"
gamer.vjmedia.com

[crisp]

Raven schreef op woensdag 23 augustus 2017 @ 10:28:
Weer een: keverjeroen in "Het Grote Lego Topic - Deel 5"
gamer.vjmedia.com

Fixed

Raven schreef op zaterdag 12 augustus 2017 @ 15:25:
Zojuist weer eens een warning tegengekomen, alleen was ik verantwoordelijk
http://wp.tipsenweetjes.n.../uploads/2017/04/Toet.jpg
Het bericht is al aangepast door het plaatje via mijn eigen domeinnaam/hostingpakket weer te geven.

Kan de betreffende hoster (tipsenweetjes.nl) via de proxy geforceerd worden?

Ik zet niet elk domein op onze proxylijst; alleen als een domein vaker gebruikt wordt voor embedded plaatjes. Anders wordt het een nodeloos lange lijst...

[.oisyn]

crisp schreef op zondag 25 juni 2017 @ 17:15:
@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:14:
[...]


Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

Omdat het het inladen van het plaatje niet blokkeert. Het is non-active content, dus geeft enkel een warning. Of het met de fetch API dus wel een error oplevert is nog maar de vraag...

[.oisyn]

@crisp Het gaat niet zozeer om de error zelf, met de fetch API kun je redirects detecteren.

[Raven]

crisp schreef op woensdag 23 augustus 2017 @ 11:03:
[...]

Fixed

crisp schreef op woensdag 23 augustus 2017 @ 11:03:
[...]

Ik zet niet elk domein op onze proxylijst; alleen als een domein vaker gebruikt wordt voor embedded plaatjes. Anders wordt het een nodeloos lange lijst...

Ok

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:44:
@crisp Het gaat niet zozeer om de error zelf, met de fetch API kun je redirects detecteren.

Ah ja, dat zou sowieso handig zijn. Ik zal er eens naar kijken

[Raven]

Jan Treur in "Elektrische auto's - Deel 2"

https://www.few.vu.nl/~tr...ngeindication20170806.jpg

[crisp]

Raven schreef op zondag 10 september 2017 @ 15:10:
Jan Treur in "Elektrische auto's - Deel 2"

https://www.few.vu.nl/~tr...ngeindication20170806.jpg

Fix0red

[Raven]

crisp schreef op zondag 10 september 2017 @ 15:14:
[...]

Fix0red

[Hero of Time]

Saffie_time in "19-9 Talk like a Pirate-day" heeft een plaatje https://stupidstuff.org/source/pirate05.jpg welke niet volledig HTTPS is. De site draait erop, maar bied geen certificaat aan. In mijn geval zie ik geen plaatje. Open ik de afbeelding direct in Firefox, dan krijg ik geen waarschuwing maar wel het plaatje (site zelf net zo), omdat het teruggaat naar http. Kan die via de proxy gaan?

[ Voor 3% gewijzigd door Hero of Time op 19-09-2017 08:14 ]

[crisp]

Hero of Time schreef op dinsdag 19 september 2017 @ 08:12:
Saffie_time in "19-9 Talk like a Pirate-day" heeft een plaatje https://stupidstuff.org/source/pirate05.jpg welke niet volledig HTTPS is. De site draait erop, maar bied geen certificaat aan. In mijn geval zie ik geen plaatje. Open ik de afbeelding direct in Firefox, dan krijg ik geen waarschuwing maar wel het plaatje (site zelf net zo), omdat het teruggaat naar http. Kan die via de proxy gaan?

Er gingen wel meer plaatjes fout in dat topic. Bij deze gefixed

[Hero of Time]

Ja, die in de TW bijvoorbeeld, maar dat kon een GC mod ook fixen. Rest van de reacties niet gecontroleerd.

[Raven]

Goldia in "Cities: Skylines - Deel 2"
https://goo.gl/EeYLfc -> http://members.ziggo.nl/w...images/Screenshot%206.png

[crisp]

Raven schreef op maandag 25 september 2017 @ 11:30:
Goldia in "Cities: Skylines - Deel 2"
https://goo.gl/EeYLfc -> http://members.ziggo.nl/w...images/Screenshot%206.png

Fixed. Shorteners gebruiken voor plaatjes is sowieso maar raar...

[Raven]

crisp schreef op maandag 25 september 2017 @ 12:15:
[...]

Fixed.

crisp schreef op maandag 25 september 2017 @ 12:15:
Shorteners gebruiken voor plaatjes is sowieso maar raar...

Dat vond ik ook raar , wist niet eens dat de img-parser daar mee overweg kon

[crisp]

Raven schreef op maandag 25 september 2017 @ 12:34:
[...]



[...]


Dat vond ik ook raar , wist niet eens dat de img-parser daar mee overweg kon

De parser kijkt alleen of het een valide url is

[Raven]

crisp schreef op maandag 25 september 2017 @ 13:15:
[...]

De parser kijkt alleen of het een valide url is

Ok

[Raven]

Verwijderd in "HELP-wat voor aansluiting heb ik en hoe krijg ik internet?"
https://extreme.pcgamesha...n-img_20130828_173847.jpg

[crisp]

Raven schreef op dinsdag 3 oktober 2017 @ 22:56:
Verwijderd in "HELP-wat voor aansluiting heb ik en hoe krijg ik internet?"
https://extreme.pcgamesha...n-img_20130828_173847.jpg

Slotje is weer mooi groen

[Raven]

crisp schreef op dinsdag 3 oktober 2017 @ 23:03:
[...]

Slotje is weer mooi groen

, thanks

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:14:
[...]


Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

We hebben gekeken naar de fetch API, maar we lopen daarmee (uiteraard) tegen de cross-domain policy aan. Met no-cors kan je nagenoeg geen properties uitlezen van het Response object wat het helaas onbruikbaar maakt...

[Raven]

Boegie in "Het Grote Kleine Mededelingentopic - Deel 369"
https://memeshappen.com/media/created/2017/02/BUT-WHY-.jpg

[crisp]

Raven schreef op zaterdag 7 oktober 2017 @ 12:37:
Boegie in "Het Grote Kleine Mededelingentopic - Deel 369"
https://memeshappen.com/media/created/2017/02/BUT-WHY-.jpg

Fixed

[Raven]

Dat was snel

[Raven]

Coffeemonster in "Het Grote Kleinemededelingentopic - Deel 370"
https://www.toxel.com/wp-...2011/06/privacydesk01.jpg

[ Voor 19% gewijzigd door Raven op 25-10-2017 13:47 ]

[crisp]

Raven schreef op woensdag 25 oktober 2017 @ 13:46:
Coffeemonster in "Het Grote Kleinemededelingentopic - Deel 370"
https://www.toxel.com/wp-...2011/06/privacydesk01.jpg

Fixed

[Raven]

crisp schreef op woensdag 25 oktober 2017 @ 14:13:
[...]

Fixed

Thanks

[Raven]

Daar gaan we weer

Ramzzz in "Het Grote Gitaartopic - deel 8"
profile.ultimate-guitar.com

[crisp]

Raven schreef op zondag 10 december 2017 @ 17:44:
Daar gaan we weer

Ramzzz in "Het Grote Gitaartopic - deel 8"
profile.ultimate-guitar.com

Fixed

[Raven]

crisp schreef op zondag 10 december 2017 @ 17:57:
[...]

Fixed

[.oisyn]

Enigszins gerelateerd. Zojuist postte iemand in het plaatjestopic het volgende plaatje: http://www.dewals.nl/plaatjes/gammel.jpg

Deze werd door de plaatjeschecker geconverteerd naar de HTTPS variant: https://www.dewals.nl/plaatjes/gammel.jpg. En het plaatje is idd ook via die URL beschikbaar, alleen is het certificaat niet geldig. Maar ja, de plaatjeschecker runt lokaal in de browser van de poster, dus als de poster van het plaatje dat certificaat vertrouwt of de error genegeerd heeft, dan wordt er dus doodleuk HTTPS van gemaakt en zitten we met een niet werkend plaatje.

Hier is natuurlijk niet heel veel aan te doen, behalve het request via t.net te laten lopen ipv lokaal. Een andere optie is eventueel om niet https te checken voor onbekende domeinen, zodat het sowieso al gewoon via de proxy loopt.

[ Voor 11% gewijzigd door .oisyn op 04-10-2018 12:15 ]

[Hero of Time]

Weer eentje in het plaatjes topic: Sjonny in "Het grote grappige plaatjes topic Editie 2018"
Wijst naar https://assets.amuniversa...0b84b013660cb005056a9545d, wat een incorrect SSL certificaat heeft en bij mij iig niet geladen wordt. Als ik echter http://assets.amuniversal...0b84b013660cb005056a9545d open, werkt het wel gewoon. Lijkt er dus ook op dat de image checker incorrect denkt dat https gewoon werkt omdat de server erop reageert.

[ACM]

Hero of Time schreef op donderdag 1 november 2018 @ 22:14:
Lijkt er dus ook op dat de image checker incorrect denkt dat https gewoon werkt omdat de server erop reageert.

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

[Hero of Time]

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.

Maar dat gaat dus regelmatig fout, zoals in dit geval waarschijnlijk ook gebeurt is. Zoals hier ook is genoemd, doet de image checker een controle om te zien of de locatie ook via https bereikbaar is en past de URL aan. De gebruiker heeft hier 0 invloed op, tenzij je het afbreken van de controle invloed wilt noemen. Het wordt dus helemaal niet via de proxy gestuurd. Dat gebeurt pas als het plaatje niet via https te serveren is, oftewel, als de webserver waar het plaatje staat niet op 443 luistert.

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

Prima, als we maar invloed hebben of het plaatje wel of niet achter een werkende https server hangt.

Voor het idee zet ik het plaatje hier in img tags, zonder https en druk alleen op 'Verstuur'. Eens zien wat er gebeurt.


Edit:
Verrek, het doet niet idioot https ervan maken. Is dat in de tussentijd verandert?

[ACM]

Hero of Time schreef op donderdag 1 november 2018 @ 22:39:
Edit:
Verrek, het doet niet idioot https ervan maken. Is dat in de tussentijd verandert?

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.

[ Voor 15% gewijzigd door ACM op 01-11-2018 22:46 ]

[.oisyn]

Maar is het echt zo'n impact om gewoon te respecteren wat de gebruiker heeft aangegeven, ipv op goed geluk https te proberen bij de client? Zoals ik al eerder zei, desnoods doe je dat alleen bij een handjevol bekende hosts, dan heb je al meteen de grote bulk van de plaatjes.

[ Voor 32% gewijzigd door .oisyn op 01-11-2018 23:10 ]