Privacy
- Wat niemand over je mag weten
Halve Https & Cloudflare?
31-01-2016, 23:45 door Anoniem, 23 reacties
Al enige tijd geleden las ik over de wijze waarop Cloudflare (naar ik begrijp) een MitM pleegt op https verbindingen van vele websites van haar klanten.
Op de site crimeflare.com is een pagina te vinden waar ruim 57 duizend websites die gebruikmaken van Cloudflare diensten tegen het licht worden gehouden.
http://www.crimeflare.com/cfssl.html
(Over de aard van de site en inhoud zelf kan je diverse soorten discussies voeren maar hier lijkt wel een overtuigende inhoudelijke vaststelling te zijn gedaan.)
Vlak na 1 januari dit jaar heb ik de gelegenheid genomen deze enorme webdomeinen lijst eens door te nemen op Nederlandse websites, nou ja degenen die eindigden op een .nl extensie dan.
In deze Nl lijst van enige tientallen Nederlandse websites zaten een paar hele grote met een 'speciale vermelding'.
Een speciale vermelding (code blauw volgens crimeflare.com) die ik niet geheel thuis kan brengen omdat ik technisch niet genoeg ben onderlegd om het exact te duiden.
Vandaar mijn vraag hier aan de experts die er wel verstand van hebben.
Op de pagina http://www.crimeflare.com/cfssl.html wordt uitgelegd dat in nogal wat gevallen (bij een verkeerde configuratie?) de gebruiker bij bezoek van een website (via Cloudflare) een https-slotje te zien krijgt terwijl er eigenlijk helemaal geen sprake is van een volledige https verbinding met die website.
Wat er gebeurt is (als ik het goed begrijp) dat jij het certificaat van Cloudflare te zien krijgt dat alleen de verbinding versleutelt tot aan de servers van Cloudflare die als veiligheidsservice tussen jou en de uiteindelijke website staan.
Helaas schijnt voor nogal wat websites te gelden dat de verbinding vanaf Cloudflare naar betreffende website niet beveiligd is maar een gewone http verbinding betreft.
Jij als gebruiker/bezoeker van die website kan dat niet zien of beoordelen omdat je toch een slotje (van Cloudflare) ziet.
Je hebt op dat moment te maken met een niet volledig versleutelde verbinding met een website terwijl je de indruk hebt dat dat wel het geval is!
Wat heb je nou aan de helft wel en de helft niet versleuteld?
Dat lijkt mij een vorm van schijnveiligheid,.
Is dat erg?
Ik denk van wel, zeker als er sprake is van websites die gevoelige informatie bevatten en met wie je als gebruiker liever veilig wil communiceren.
In de eerste week van januari waren er drie grote portals die me daarbij opvielen.
Portals die wel een https verbinding legden maar waarvan ik niet kon beoordelen of die https verbindingen werkelijk helemaal van begin tot eind versleuteld waren.
Die zeer grote domeinen, domeinen met vermoed hoge bezoekersaantallen en wat mij betreft kritische informatie, betroffen:
• https://www.amsterdam.nl Gemeente amsterdam
• https://www.huisarts.nl
• https://www.dokter.nl
Inmiddels, een kleine drie weken later, zijn de twee laatste medische sites teruggevallen op een http verbinding.
Over de sites valt een aparte forumpost te vullen (wat ik misschien nog ga doen maar nu even buiten dit verhaal laat).
Eén groot wat mij betreft kritisch domein dat overblijft ter beoordeling is dan van de Gemeente Amsterdam die vermoedelijk toch wel ettelijke honderdduizenden unieke klanten moet hebben.
• https://www.amsterdam.nl
In een poging om te beoordelen of je als bezoeker van deze site te maken hebt met slechts een halve https verbinding heb ik de site bezocht en naar het certificaat gekeken, dat van Cloudflare via Comodo is.
Verder dan dat kom ik niet want ik ben geen techneut.
De grote vraag :
Hebben de hondderduizenden bezoekers van de Amsterdamse website https://www.amsterdam.nl een volledig versleutelde verbinding?
Of is die verbinding alleen versleuteld tot aan de MitM server van Cloudflare en gaan de gebruikers gegevens daarna doodleuk open en bloot over een onbeveiligde http verbinding naar het domein amsterdam.nl ?
Ik kan me bijna niet voorstellen dat dat het geval is, alhoewel er wel meer niet zou moeten kunnen, wie weet of kan (onderbouwd) bevestigen danwel ontkrachten of de verbinding met een grote kritische website als www.amsterdam.nl dan half of geheel versleuteld is?
Best belangrijk om te weten of een overheidsportal wel zo veilig is als het suggereert te zijn, vandaar deze forumvraag.
Wie heeft het onderbouwde verlossende antwoord?
Op de site crimeflare.com is een pagina te vinden waar ruim 57 duizend websites die gebruikmaken van Cloudflare diensten tegen het licht worden gehouden.
http://www.crimeflare.com/cfssl.html
(Over de aard van de site en inhoud zelf kan je diverse soorten discussies voeren maar hier lijkt wel een overtuigende inhoudelijke vaststelling te zijn gedaan.)
Vlak na 1 januari dit jaar heb ik de gelegenheid genomen deze enorme webdomeinen lijst eens door te nemen op Nederlandse websites, nou ja degenen die eindigden op een .nl extensie dan.
In deze Nl lijst van enige tientallen Nederlandse websites zaten een paar hele grote met een 'speciale vermelding'.
Een speciale vermelding (code blauw volgens crimeflare.com) die ik niet geheel thuis kan brengen omdat ik technisch niet genoeg ben onderlegd om het exact te duiden.
Vandaar mijn vraag hier aan de experts die er wel verstand van hebben.
Op de pagina http://www.crimeflare.com/cfssl.html wordt uitgelegd dat in nogal wat gevallen (bij een verkeerde configuratie?) de gebruiker bij bezoek van een website (via Cloudflare) een https-slotje te zien krijgt terwijl er eigenlijk helemaal geen sprake is van een volledige https verbinding met die website.
Wat er gebeurt is (als ik het goed begrijp) dat jij het certificaat van Cloudflare te zien krijgt dat alleen de verbinding versleutelt tot aan de servers van Cloudflare die als veiligheidsservice tussen jou en de uiteindelijke website staan.
Helaas schijnt voor nogal wat websites te gelden dat de verbinding vanaf Cloudflare naar betreffende website niet beveiligd is maar een gewone http verbinding betreft.
Jij als gebruiker/bezoeker van die website kan dat niet zien of beoordelen omdat je toch een slotje (van Cloudflare) ziet.
Je hebt op dat moment te maken met een niet volledig versleutelde verbinding met een website terwijl je de indruk hebt dat dat wel het geval is!
Wat heb je nou aan de helft wel en de helft niet versleuteld?
Dat lijkt mij een vorm van schijnveiligheid,.
Is dat erg?
Ik denk van wel, zeker als er sprake is van websites die gevoelige informatie bevatten en met wie je als gebruiker liever veilig wil communiceren.
In de eerste week van januari waren er drie grote portals die me daarbij opvielen.
Portals die wel een https verbinding legden maar waarvan ik niet kon beoordelen of die https verbindingen werkelijk helemaal van begin tot eind versleuteld waren.
Die zeer grote domeinen, domeinen met vermoed hoge bezoekersaantallen en wat mij betreft kritische informatie, betroffen:
• https://www.amsterdam.nl Gemeente amsterdam
• https://www.huisarts.nl
• https://www.dokter.nl
Inmiddels, een kleine drie weken later, zijn de twee laatste medische sites teruggevallen op een http verbinding.
Over de sites valt een aparte forumpost te vullen (wat ik misschien nog ga doen maar nu even buiten dit verhaal laat).
Eén groot wat mij betreft kritisch domein dat overblijft ter beoordeling is dan van de Gemeente Amsterdam die vermoedelijk toch wel ettelijke honderdduizenden unieke klanten moet hebben.
• https://www.amsterdam.nl
In een poging om te beoordelen of je als bezoeker van deze site te maken hebt met slechts een halve https verbinding heb ik de site bezocht en naar het certificaat gekeken, dat van Cloudflare via Comodo is.
Certificaat : ssl278906.cloudflaressl.com
Verder dan dat kom ik niet want ik ben geen techneut.
De grote vraag :
Hebben de hondderduizenden bezoekers van de Amsterdamse website https://www.amsterdam.nl een volledig versleutelde verbinding?
Of is die verbinding alleen versleuteld tot aan de MitM server van Cloudflare en gaan de gebruikers gegevens daarna doodleuk open en bloot over een onbeveiligde http verbinding naar het domein amsterdam.nl ?
Ik kan me bijna niet voorstellen dat dat het geval is, alhoewel er wel meer niet zou moeten kunnen, wie weet of kan (onderbouwd) bevestigen danwel ontkrachten of de verbinding met een grote kritische website als www.amsterdam.nl dan half of geheel versleuteld is?
Best belangrijk om te weten of een overheidsportal wel zo veilig is als het suggereert te zijn, vandaar deze forumvraag.
Wie heeft het onderbouwde verlossende antwoord?
Reacties (23)
Vandaag gecheckt en de eerder beschreven situatie is hetzelfde.
Ook hetzelfde is dat er geen enkele reactie op de forum vraag is gekomen.
Hoe kan/komt dat?
a [ ] Niemand die het weet of er verstand van heeft?
b [ ] Niemand die wel/niet volledige https verbindingen interesseert?
c [ ] Niemand die over een Cloudflare issue online wil discussiëren?
d [ ] Overig?
De eerste twee opties kan ik me niet voorstellen.
De tweede misschien, Nederland staat wereldwijd op plaats 4 van Cloudflare gebruikers
( http://www.crimeflare.com/cfusers.html , 5.130 NETHERLANDS) dus wellicht maakt de meerderheid van de specialisten hier gebruik van Cloudflare diensten en discussieert liever niet over de diensten die zij bieden?
Kan ik me toch ook slecht voorstellen.
Nogmaals een oproepje dan aan degene die er zicht op zouden kunnen hebben en mijn misschien wel verkeerde constatering met juiste informatie kunnen rechtzetten.
De vraag : Als je het eerder genoemde domein https://www.amsterdam.nl bezoekt, heb je dan een werkelijk geheel versleutelde verbinding of voor slechts een deel van de route naar die website?
Wie?
Groet topic starter
Ook hetzelfde is dat er geen enkele reactie op de forum vraag is gekomen.
Hoe kan/komt dat?
a [ ] Niemand die het weet of er verstand van heeft?
b [ ] Niemand die wel/niet volledige https verbindingen interesseert?
c [ ] Niemand die over een Cloudflare issue online wil discussiëren?
d [ ] Overig?
De eerste twee opties kan ik me niet voorstellen.
De tweede misschien, Nederland staat wereldwijd op plaats 4 van Cloudflare gebruikers
( http://www.crimeflare.com/cfusers.html , 5.130 NETHERLANDS) dus wellicht maakt de meerderheid van de specialisten hier gebruik van Cloudflare diensten en discussieert liever niet over de diensten die zij bieden?
Kan ik me toch ook slecht voorstellen.
Nogmaals een oproepje dan aan degene die er zicht op zouden kunnen hebben en mijn misschien wel verkeerde constatering met juiste informatie kunnen rechtzetten.
De vraag : Als je het eerder genoemde domein https://www.amsterdam.nl bezoekt, heb je dan een werkelijk geheel versleutelde verbinding of voor slechts een deel van de route naar die website?
Wie?
Groet topic starter
04-02-2016, 14:17 door Anoniem: De vraag : Als je het eerder genoemde domein https://www.amsterdam.nl bezoekt, heb je dan een werkelijk geheel versleutelde verbinding of voor slechts een deel van de route naar die website?
Je hebt in elk geval een IP verbinding met een server van Cloudflare, de IPv4 adressen van www.amsterdam.nl zijn momenteel 104.25.245.10 en 104.25.244.10 (d.w.z. als ik dit aan de Google nameserver met IP-adres 8.8.8.8 vraag).In theorie zou dat IP-adres kunnen "NATten" voor de "echte webserver", d.w.z. dat de versleutelde verbinding daadwerkelijk end-to-end is naar een server die "eigendom is" van de gemeente Amsterdam. Maar als dat zo zou zijn, jou je geen foutmelding kunnen krijgen zoals getoond in o.a. https://support.cloudflare.com/hc/en-us/articles/200171906-Error-522-Connection-timed-out (zo'n soort foutmelding heb ik ook wel eens gezien bij het bezoeken van https://www.security.nl/ - die "zit ook achter Cloudflare").
Zo'n foutmelding kan alleen getoond worden als Cloudflare beschikt over de private key behorende bij het getoonde certificaat (anders zou je, als Cloudflare je een foutmelding zou willen laten zien, eerst een certificaatfoutmelding weg moeten klikken).
Als Cloudflare over de private key beschikt, betekent dit dat ze, in elk geval als ze dit willen, de TLS verbinding kunnen termineren waar hen belieft. Het ligt niet zo voor de hand dat ze deze verbidning alleen bij Cloudflare termineren als de "echte webserver" niet bereikbaar is.
Ik vermoed (maar dat is een gok) dat de TLS verbinding op servers met genoemde IP-adressen getermineerd wordt (of ergens "vlak" daarachter, na een load balancer o.i.d., in elk geval op een Cloudflare server). Of en hoe gegevens vanaf dat punt, d.w.z. bij Cloudflare zelf en op de verbinding tussen Cloudflare en de "echte" server(s) van Amsterdam worden versleuteld (en zo ja wie de sleutel allemaal hebben), weet je niet. Dat heet "cloud".
In elk geval heeft de gemeente Amsterdam aan Cloudflare toestemming moeten geven om DNS-entries te maken voor *.amsterdam.nl (of heeft dat zelf voor Cloudflare gedaan). Alleen al daardoor kan Cloudflare een DV (Domain Validated) certificaat aanvragen voor o.a. www.amsterdam.nl (m.i. is dit schandalig, DV certificaten zijn waardeloos en daardoor misleidend).
Opvallend is wel dat formulieren.amsterdam.nl niet bij Cloudflare is gehost (IP adres 62.112.234.14 is geregistreerd bij ASP4All). Van https://formulieren.amsterdam.nl/ (zie [1] voor een voorbeeld dat niet meteen een redirect doet) krijg je dan ook een PKI-Overheid certificaat, waar veel strengere controles voor gelden dan voor DV certificaten.
[1]: https://formulieren.amsterdam.nl/TriplEforms/LoketAmsterdam/Default.aspx?EnvironmentId=evDBI&scenarioId=scVerhuizen
Cloudflare is een Amerikaans bedrijf. Met het ongeldig verklaren van de Safe Harbor overeenkomst met de USA, en het nog niet geratificeerd zijn van de nieuwe "Privacy Shield" overeenkomst, is Amsterdam feitelijk in overtreding als zij jou vraagt persoonsgegevens te verstrekken via een bij Cloudflare gehoste site, want Cloudflare kan die gegevens inzien.
Erger, in principe kan een kwaadwillende Cloudflare medewerker de domainname in de URL in de pagina https://www.amsterdam.nl/veelgevraagd/?productid={47F48177-0BF3-4364-A525-1B3E61412D64}, "Online" openklappen, onder "Direct Regelen" -> "Verhuisformulier", dat is [1] hierboven, wijzigen in www.amsterdam.nl en de rest van de URL aanpassen naar iets dat nu niet bestaat. Dan kan de aanvaller, een paar schermen verder, de DigiD login faken (lastig), of het door de werkelijke DigiD site geretourneerde token (simpel) misbruiken voor andere doeleinden dan jij wenst.
Maar ja, een kwaadwillende medewerker van ASP4All kan dat natuurlijk ook (op de huidige formulieren.amsterdam.nl) want ook die server staat niet in de kelder van het stadhuis van Amsterdam. En als hij daar zou staan, zou je ook de lokale beheerders moeten vertouwen. Aan de andere kant: die lokale beheerder legt direct verantwoording af aan de gemeente en kan ook gesanctioneerd worden door die gemeente. Hoe dat "in de cloud" gaat, moet je maar afwachten, evenals de betrokkenheid die medewerkers van cloud-providers hebben met de organisaties waar zij indirect voor werken.
Nb. doordat de meeste PKI-overheid certificaten nog geen EV-status hebben, ziet de gebruiker geen verschil in de slotjes van https://www.amsterdam.nl/ en https://formulieren.amsterdam.nl/ - triest maar waar.
04-02-2016, 20:06 door
Sheins
@Erik
Wat ik op https://www.cloudflare.com/keyless-ssl/ lees:
En ze hebben ook een service 'Keyless SSL':
Hoe dan ook, het blijk dus dat Clownflare in beide gevallen toegang heeft tot de gegevens.
Wat misschien ook interessant kan zijn: de verschillende instellingen voor SSL verbindingen die Clownflare biedt. https://support.cloudflare.com/hc/en-us/articles/200170416-What-do-the-SSL-options-Off-Flexible-SSL-Full-SSL-Full-SSL-Strict-SSL-Only-mean-
- Off: user <-unencrypted-> Clownflare <-unencrypted-> server
- Flexible: user <--encrypted--> Clownflare <-unencrypted-> server
- Full SSL: user <--encrypted--> Clownflare <--encrypted--> server (mag met self-signed certificaat)
- Full SSL (Strict): user <-encrypted-> Clownflare <-encrypted-> server (moet officieel certificaat hebben)
En voor de Clownflare Enterprise klanten:
- SSL-Only Origin Pulls: user <-(un)encrypted-> Clownflare <--encrypted--> server (geen certificaat eisen?)
Overigens valt in de discussie op https://security.stackexchange.com/questions/97920/cloudflares-free-ssl-options-require-trusting-them-what-could-they-do-to-chang te lezen dat Clowflare de SSL verbinding wel moet decoderen voor application layer traffic analysis
Meer informatie:
- http://www.unrest.ca/cloudflare-keyless-ssl-and-the-selling-of-secure
- https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
- https://scotthelme.co.uk/cloudflares-great-new-features-and-why-i-wont-use-them/
- https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/
- https://www.reddit.com/r/programming/comments/2grd1d/cloudflare_annouces_keyless_ssl/
- http://arstechnica.com/information-technology/2014/09/in-depth-how-cloudflares-new-web-service-promises-security-without-the-key/
Wat ik op https://www.cloudflare.com/keyless-ssl/ lees:
The standard CloudFlare SSL service requires a customer to share their site’s SSL key with CloudFlare.
Gevolgd door een belofte:CloudFlare takes extensive technical measures to safeguard customer key information.
En ze hebben ook een service 'Keyless SSL':
With Keyless SSL, for the first time ever, an organization can use a solution such as CloudFlare, that is infinitely scalable and infinitely elastic, without sharing their SSL key.
Maar:Keyless SSL requires that CloudFlare decrypt, inspect and re-encrypt traffic for transmission back to a customer’s origin.
Hoe dan ook, het blijk dus dat Clownflare in beide gevallen toegang heeft tot de gegevens.
Wat misschien ook interessant kan zijn: de verschillende instellingen voor SSL verbindingen die Clownflare biedt. https://support.cloudflare.com/hc/en-us/articles/200170416-What-do-the-SSL-options-Off-Flexible-SSL-Full-SSL-Full-SSL-Strict-SSL-Only-mean-
- Off: user <-unencrypted-> Clownflare <-unencrypted-> server
- Flexible: user <--encrypted--> Clownflare <-unencrypted-> server
- Full SSL: user <--encrypted--> Clownflare <--encrypted--> server (mag met self-signed certificaat)
- Full SSL (Strict): user <-encrypted-> Clownflare <-encrypted-> server (moet officieel certificaat hebben)
En voor de Clownflare Enterprise klanten:
- SSL-Only Origin Pulls: user <-(un)encrypted-> Clownflare <--encrypted--> server (geen certificaat eisen?)
Overigens valt in de discussie op https://security.stackexchange.com/questions/97920/cloudflares-free-ssl-options-require-trusting-them-what-could-they-do-to-chang te lezen dat Clowflare de SSL verbinding wel moet decoderen voor application layer traffic analysis
Meer informatie:
- http://www.unrest.ca/cloudflare-keyless-ssl-and-the-selling-of-secure
- https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
- https://scotthelme.co.uk/cloudflares-great-new-features-and-why-i-wont-use-them/
- https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/
- https://www.reddit.com/r/programming/comments/2grd1d/cloudflare_annouces_keyless_ssl/
- http://arstechnica.com/information-technology/2014/09/in-depth-how-cloudflares-new-web-service-promises-security-without-the-key/
05-02-2016, 08:37 door
Erik van Straten
@Sheins: dank voor jouw bijdrage, heel overzichtelijk zo!
Wat ik in mijn vorige bijdrage niet genoemd heb: ook als de verbinding tussen Cloudflare en de werkelijke webserver niet versleuteld is, profiteren mensen die van public WiFi gebruik maken in elk geval van een geauthenticeerde en versleutelde verbinding - mits ze zich realiseren dat er iets grondig mis is als hun browser geen https + slotje toont (helaas gebruikt https://www.amsterdam.nl/ geen HSTS, en een MitM aanval lukt alleen als de gebruiker begint met http://www.amsterdam.nl/).
Wat ik in mijn vorige bijdrage niet genoemd heb: ook als de verbinding tussen Cloudflare en de werkelijke webserver niet versleuteld is, profiteren mensen die van public WiFi gebruik maken in elk geval van een geauthenticeerde en versleutelde verbinding - mits ze zich realiseren dat er iets grondig mis is als hun browser geen https + slotje toont (helaas gebruikt https://www.amsterdam.nl/ geen HSTS, en een MitM aanval lukt alleen als de gebruiker begint met http://www.amsterdam.nl/).
Erik en Sheins, hartelijk dank voor de inhoudelijke bijdrage en het kijken ernaar!
Tja, wat kan ik (t.s.) als niet-expert erover zeggen anders dan de punten die jullie zelf hebben geconstateerd en aangedragen
Toch een reactie.
HSTS en redirect HTTP
Wat mij in ieder geval haalbaar lijkt is als zij voor die website HSTS zouden implementeren en een nette redirect naar de HTTPS versie van de website zouden aanleggen.
Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl .
Best iets om over na te denken want juist ouderen schijnen, blijkt uit de statistiek, vaker nog netjes www. in te toetsen voor een domeinnaam en juist bij ouderen is het security bewustzijn en de computerslimheid (nog wel eens) lager dan bij anderen.
Dat geeft o zich niet (minder computerslimheid) maar met kwetsbare groepen hoor je als gemeente wel rekening te houden.
UnSafe Harbor
Wat betreft het gebruikmaken van een dienst van een Amerikaans bedrijf dat zichzelf het recht toe-eigent op de verbinding mee te lezen in combinatie met de Amerikaanse wetgeving die de mogelijkheid geeft onder het mom van .. zich naar eigen inzicht het recht toe te eigenen alle data die men wenst op te eisen, opgeteld daarbij het vacuüm rondom Safe Harbor, ja dat is een interessant wettelijk vacuüm dat voor heel veel meer bedrijven geldt en met de mantel der tijd zal worden bedekt.
Van een dergelijke afwachtende houding, daar hebben we al eerder voorbeelden van gezien.
Bijvoorbeeld met Opstelten die een illegale wet in leven wilde houden vanwege de toekomst optie dat er wel een nieuwe wet zou komen.
Dan moet er veel water door de zee om dat te veranderen en gaat vast niet in dit geval gebeuren.
Dus, alle data(communicatie) in en via een Amerikaanse cloud?
Het blijft een rare situatie als je bedenkt dat men zo'n enorme macht neerlegt bij een Amerikaans bedrijf dat helemaal niet onder onze wetgeving valt.
Namelijk de macht van inzage in gevoelige data.
Data zijn immers het nieuwe goud, ook als Cloudflare er niet in handelt. Mogelijkheid tot inzage door anderen is genoeg.
Ongelijke kappen,..
Let wel, Adobe en Google analytics zouden bij een dergelijke tussenpositie positie hun vingers bij aflikken.
Over 'foreign overheid analytics' hoor je dan weer minder en er zijn ook geen browser-extensies tegen.
Wel/geen waarschuwing
Als je bij dat contrast stilstaat klopt het ook eigenlijk van geen kanten, je wordt immers wettelijk verplicht gewaarschuwd voor trackers en analytics door verplichte cookiemeldingen, maar voor een bedrijf dat onzichtbaar inbreekt op de 'intimiteit van een vertrouwde verbinding', daarvoor wordt je dan weer niet gewaarschuwd:
'Deze site maakt naast gebruik van cookies gebruik van Cloudflare MitM' een leest online met uw verrichtingen mee.
En dat is nogal vreemd, immers, een HTTPS verbinding geeft op zijn minst de suggestie dat je vertrouwelijk communiceert met 1 partij en wekt de suggestie dat zij het meelezen door derden (Als Cloudflare e.a.) nou juist voorkomt en uitsluit.
Neutrale techniek!
Dan kan men zich nog weer verschuilen achter techniek, malware scanners en spamfilters zijn ook heel ongevaarlijk, a-politiek en neutraal, maar toch.
Mogelijk toch een reden dat de 'formulieren' url naar een andere lokale server gaat zonder tussenkomst van Cloudflare?
Inflatie
Ik ben inmiddels bekend met je standpunt rondom al dan niet gratis certificaat gebruik en verkeerde suggesties rondom veiligheid daarvan waar ik het niet in alle gevallen mee eens ben.
In dit geval echter, met een werkwijze zoals die door Cloudflare gehanteerd wordt ben ik het met je eens dat de waarde van HTTPS en de suggestie rondom veiligheid en vooral het vertrouwen dat je veilig communiceert behoorlijk aan inflatie onderhevig is en in dit specifieke geval dan ook nog eens niet consequent is geïmplementeerd door geen HSTS en een consequente redirect naar de HTTPS versie te implementeren van de bestaande HTTP website.
Het model van Cloudflare is eigenlijk en doodsteek voor het vertrouwen in certificaten en verbindingen omdat niemand meer begrijpt en kan zien wat er aan de hand is en dus ook een gesuggereerde garantie (slotje) niet meer kan controleren.
Geen enkel idee / halve garantie
De bezoeker heeft, zoals wel vaker overigens, dus geen enkel inzicht en notie van hoe veilig de verbinding na de Cloudflare MitM is naar de servers van de website en loopt op de koop toe, ondanks de aangeboden HTTPS versie, bij gebruik van de HTTP://www. versie en een lokaal wifi acces point, nog steeds op ongelukken en misbruik.
Foutje bedankt .. wie?
Hobbeltjes
Ergens las ik dat Amsterdam en ICT hier en daar wel wat hobbels kent.
Dan zijn sommige genoemde punten, buiten het UnSafe Harbor, hier maar een heel klein hobbeltje om te nemen.
Men leest vast mee op security.nl
We zullen zien.
Een lange niet-tech reactie. Discussieer vooral in de tussentijd technisch door over de links van Sheins en constateringen van Erik.
Ze geven er namelijk alle aanleiding toe en niet alleen voor aangehaalde website(s).
'Hou ik weer ff mijn mond.'
Groet T.s.
En Cloudflare?
' "Sterk spul" , "het zou verboden moeten worden".
Je zou dus op zijn minst voor deze 'Veilige MitM Haven' gewaarschuwd kunnen worden.
Torbrowser gebruikers worden dat overigens op die site, standaard 3 tot 5 maal verschillende soorten captchas invoeren. Een echte specialiteit van Cloudflare (met hulp van verkeerswijzerspecialist Google), het ultieme middel om veiligheid te vergroten en daarom standaard vol in de blokkade gezet voor wie van privacy houdt.
Dat je het weet (en dat zul je).
Proest, of proost, het is weer weekeinde tenslotte.
Tja, wat kan ik (t.s.) als niet-expert erover zeggen anders dan de punten die jullie zelf hebben geconstateerd en aangedragen
Toch een reactie.
HSTS en redirect HTTP
Wat mij in ieder geval haalbaar lijkt is als zij voor die website HSTS zouden implementeren en een nette redirect naar de HTTPS versie van de website zouden aanleggen.
Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl .
Best iets om over na te denken want juist ouderen schijnen, blijkt uit de statistiek, vaker nog netjes www. in te toetsen voor een domeinnaam en juist bij ouderen is het security bewustzijn en de computerslimheid (nog wel eens) lager dan bij anderen.
Dat geeft o zich niet (minder computerslimheid) maar met kwetsbare groepen hoor je als gemeente wel rekening te houden.
UnSafe Harbor
Wat betreft het gebruikmaken van een dienst van een Amerikaans bedrijf dat zichzelf het recht toe-eigent op de verbinding mee te lezen in combinatie met de Amerikaanse wetgeving die de mogelijkheid geeft onder het mom van .. zich naar eigen inzicht het recht toe te eigenen alle data die men wenst op te eisen, opgeteld daarbij het vacuüm rondom Safe Harbor, ja dat is een interessant wettelijk vacuüm dat voor heel veel meer bedrijven geldt en met de mantel der tijd zal worden bedekt.
Van een dergelijke afwachtende houding, daar hebben we al eerder voorbeelden van gezien.
Bijvoorbeeld met Opstelten die een illegale wet in leven wilde houden vanwege de toekomst optie dat er wel een nieuwe wet zou komen.
Dan moet er veel water door de zee om dat te veranderen en gaat vast niet in dit geval gebeuren.
Dus, alle data(communicatie) in en via een Amerikaanse cloud?
Het blijft een rare situatie als je bedenkt dat men zo'n enorme macht neerlegt bij een Amerikaans bedrijf dat helemaal niet onder onze wetgeving valt.
Namelijk de macht van inzage in gevoelige data.
Data zijn immers het nieuwe goud, ook als Cloudflare er niet in handelt. Mogelijkheid tot inzage door anderen is genoeg.
Ongelijke kappen,..
Let wel, Adobe en Google analytics zouden bij een dergelijke tussenpositie positie hun vingers bij aflikken.
Over 'foreign overheid analytics' hoor je dan weer minder en er zijn ook geen browser-extensies tegen.
Wel/geen waarschuwing
Als je bij dat contrast stilstaat klopt het ook eigenlijk van geen kanten, je wordt immers wettelijk verplicht gewaarschuwd voor trackers en analytics door verplichte cookiemeldingen, maar voor een bedrijf dat onzichtbaar inbreekt op de 'intimiteit van een vertrouwde verbinding', daarvoor wordt je dan weer niet gewaarschuwd:
'Deze site maakt naast gebruik van cookies gebruik van Cloudflare MitM' een leest online met uw verrichtingen mee.
En dat is nogal vreemd, immers, een HTTPS verbinding geeft op zijn minst de suggestie dat je vertrouwelijk communiceert met 1 partij en wekt de suggestie dat zij het meelezen door derden (Als Cloudflare e.a.) nou juist voorkomt en uitsluit.
Neutrale techniek!
Dan kan men zich nog weer verschuilen achter techniek, malware scanners en spamfilters zijn ook heel ongevaarlijk, a-politiek en neutraal, maar toch.
Mogelijk toch een reden dat de 'formulieren' url naar een andere lokale server gaat zonder tussenkomst van Cloudflare?
Inflatie
Ik ben inmiddels bekend met je standpunt rondom al dan niet gratis certificaat gebruik en verkeerde suggesties rondom veiligheid daarvan waar ik het niet in alle gevallen mee eens ben.
In dit geval echter, met een werkwijze zoals die door Cloudflare gehanteerd wordt ben ik het met je eens dat de waarde van HTTPS en de suggestie rondom veiligheid en vooral het vertrouwen dat je veilig communiceert behoorlijk aan inflatie onderhevig is en in dit specifieke geval dan ook nog eens niet consequent is geïmplementeerd door geen HSTS en een consequente redirect naar de HTTPS versie te implementeren van de bestaande HTTP website.
Het model van Cloudflare is eigenlijk en doodsteek voor het vertrouwen in certificaten en verbindingen omdat niemand meer begrijpt en kan zien wat er aan de hand is en dus ook een gesuggereerde garantie (slotje) niet meer kan controleren.
Geen enkel idee / halve garantie
De bezoeker heeft, zoals wel vaker overigens, dus geen enkel inzicht en notie van hoe veilig de verbinding na de Cloudflare MitM is naar de servers van de website en loopt op de koop toe, ondanks de aangeboden HTTPS versie, bij gebruik van de HTTP://www. versie en een lokaal wifi acces point, nog steeds op ongelukken en misbruik.
Foutje bedankt .. wie?
Hobbeltjes
Ergens las ik dat Amsterdam en ICT hier en daar wel wat hobbels kent.
Dan zijn sommige genoemde punten, buiten het UnSafe Harbor, hier maar een heel klein hobbeltje om te nemen.
Men leest vast mee op security.nl
We zullen zien.
Een lange niet-tech reactie. Discussieer vooral in de tussentijd technisch door over de links van Sheins en constateringen van Erik.
Ze geven er namelijk alle aanleiding toe en niet alleen voor aangehaalde website(s).
'Hou ik weer ff mijn mond.'
Groet T.s.
En Cloudflare?
' "Sterk spul" , "het zou verboden moeten worden".
Je zou dus op zijn minst voor deze 'Veilige MitM Haven' gewaarschuwd kunnen worden.
Torbrowser gebruikers worden dat overigens op die site, standaard 3 tot 5 maal verschillende soorten captchas invoeren. Een echte specialiteit van Cloudflare (met hulp van verkeerswijzerspecialist Google), het ultieme middel om veiligheid te vergroten en daarom standaard vol in de blokkade gezet voor wie van privacy houdt.
Dat je het weet (en dat zul je).
Proest, of proost, het is weer weekeinde tenslotte.
05-02-2016, 15:32 door
Erik van Straten
05-02-2016, 13:55 door Anoniem: HSTS en redirect HTTP
Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl
Als ik (met Firefox) naar zowel http://www.amsterdam.nl/ als http://amsterdam.nl/ ga, krijg ik een 301 code terug: "Moved permanently", en Location: "https://www.amsterdam.nl".Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl
05-02-2016, 13:55 door Anoniem: Ongelijke kappen,..
Let wel, Adobe en Google analytics zouden bij een dergelijke tussenpositie positie hun vingers bij aflikken.
Over 'foreign overheid analytics' hoor je dan weer minder en er zijn ook geen browser-extensies tegen.
Nou, mijn NoScript kan anders prima Javascript tegenhouden vanaf ajax.googleapis.com, jquery.com en fonts.net. Iemand die dat niet blokkeert (> 99% van de bezoekers schat ik) informeert genoemde partijen ook inhoudelijk over welke pagina's er precies bezocht worden, en wie weet wat nog meer.Let wel, Adobe en Google analytics zouden bij een dergelijke tussenpositie positie hun vingers bij aflikken.
Over 'foreign overheid analytics' hoor je dan weer minder en er zijn ook geen browser-extensies tegen.
05-02-2016, 13:55 door Anoniem: Wel/geen waarschuwing
En dat is nogal vreemd, immers, een HTTPS verbinding geeft op zijn minst de suggestie dat je vertrouwelijk communiceert met 1 partij en wekt de suggestie dat zij het meelezen door derden (Als Cloudflare e.a.) nou juist voorkomt en uitsluit.
Helaas is het niet zo dat een https verbinding met certificaat en getoond slotje betekent dat jouw browser, op dat moment, slechts verbinding heeft met maar 1 website (wat je wel weet is dat de meeste verbindingen -in elk geval die de meest risicovolle content kunnen verplaatsen- met andere sites versleuteld plaatsvinden), noch weet je precies welke informatie er allemaal wordt uitgewisseld, en noch weet je welke personen er allemaal toegang hebben tot de uitgewisselde informatie (met al die sites).En dat is nogal vreemd, immers, een HTTPS verbinding geeft op zijn minst de suggestie dat je vertrouwelijk communiceert met 1 partij en wekt de suggestie dat zij het meelezen door derden (Als Cloudflare e.a.) nou juist voorkomt en uitsluit.
Kan iemand anders even een pcapje plaatsen waaruit blijkt dat de host niet in de headers al doorgegeven word? Aangezien jullie dapper claimen dat de pagina dan niet weergegeven kan worden?
Menige claim hierboven is weinig beargmenteerd.
Menige claim hierboven is weinig beargmenteerd.
De vraag : Als je het eerder genoemde domein https://www.amsterdam.nl bezoekt, heb je dan een werkelijk geheel versleutelde verbinding of voor slechts een deel van de route naar die website?
Wie?
Wie?
Ik ga een poging doen:
In feite kun je nooit nagaan of de verbinding volledig versleuteld is. Het gedeelte tussen je browser en Cloudflare is versleuteld, dat geeft je browser aan met het slotje. Cloudflare zal de data ontsleutelen (en dus in kunnen zien, en aan kunnen passen), en de vraag daarna herhalen naar de 'echte' webserver. Of hier encryptie toegepast wordt weet je simpelweg niet 100% zeker. Je kunt wel een poging wagen.
Voor het geval http(s?)://www.amsterdam.nl heb ik dit uitgezocht:
- www.amsterdam.nl resolved naar 104.25.244.10 (is een Cloudflare adres)
- amsterdam.nl resolved naar 62.112.234.12 (geen Cloudflare: https://apps.db.ripe.net/search/query.html?searchtext=62.112.234.12#resultsAnchor)
- formulieren.amsterdam.nl resolved naar 62.112.234.14 (zit in diezelfde buurt qua nummering)
Wanneer www.amsterdam.nl wordt aangevraagd via het eigenlijjke adres (104.25.244.10) dan krijg je een certificaat van Cloudflare terug. Door in je hosts file www.amsterdam.nl aan te passen naar 62.112.234.12 zal de aanvraag voor www.amsterdam.nl ook naar server gaan die amsterdam.nl afhandeld. Het effect: http:// wordt geredirect naar https, en je krijgt nu wel netjes een certificaat te zien van de gemeente Amsterdam:
Common Name (CN) www.amsterdam.nl
Organization (O) Gemeente Amsterdam, Dienst ICT
Conclusie:
Cloudflare maakt waarschijnlijk op de achtergrond een versleutelde verbinding met 62.112.234.12 die netjes een geldig certificaat heeft. Ik zeg waarschijnlijk, omdat je dit niet 100% zeker kan weten. Misschien verbinden ze wel met een heel ander IP adres naar die machine, en maken ze alsnog geen gebruik van https. Dat is onmogelijk te zien aan de buitenkant.
Wat je dus moet achterhalen is het 'bron-adres'. In dit geval kon dat omdat amsterdam.nl niet via Cloudflare gerouteerd wordt. Als ze dat wel hadden gedaan is deze truuk lastiger (tot niet) uit te voeren. Wat je dan kunt doen is kijken of er iets bestaat als www-origin.domeinnaam.nl oid.
Beantwoord dit je vraag een beetje?
Door Sheins: @Erik
Wat ik op https://www.cloudflare.com/keyless-ssl/ lees:
En ze hebben ook een service 'Keyless SSL':
Hoe dan ook, het blijk dus dat Clownflare in beide gevallen toegang heeft tot de gegevens.
Begrijp ik dit goed?Wat ik op https://www.cloudflare.com/keyless-ssl/ lees:
The standard CloudFlare SSL service requires a customer to share their site’s SSL key with CloudFlare.
Gevolgd door een belofte:CloudFlare takes extensive technical measures to safeguard customer key information.
En ze hebben ook een service 'Keyless SSL':
With Keyless SSL, for the first time ever, an organization can use a solution such as CloudFlare, that is infinitely scalable and infinitely elastic, without sharing their SSL key.
Maar:Keyless SSL requires that CloudFlare decrypt, inspect and re-encrypt traffic for transmission back to a customer’s origin.
Hoe dan ook, het blijk dus dat Clownflare in beide gevallen toegang heeft tot de gegevens.
Als de private key van een aangesloten website met Cloudflare is gedeeld, dan is het toch technisch mogelijk dat Cloudflare het certificaat van die website ongemerkt tot in de kleinste details kan spoofen als ze dat zouden willen???
Door Erik van Straten:
05-02-2016, 13:55 door Anoniem: HSTS en redirect HTTP
Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl
Als ik (met Firefox) naar zowel http://www.amsterdam.nl/ als http://amsterdam.nl/ ga, krijg ik een 301 code terug: "Moved permanently", en Location: "https://www.amsterdam.nl".Want inderdaad, de redirect naar HTTPS is er wel bij het intoetsen van amsterdam.nl maar niet voor www.amsterdam.nl
Door Anoniem: Kan iemand anders even een pcapje plaatsen waaruit blijkt dat de host niet in de headers al doorgegeven word? Aangezien jullie dapper claimen dat de pagina dan niet weergegeven kan worden?
Menige claim hierboven is weinig beargmenteerd.
Menige claim hierboven is weinig beargmenteerd.
Als Torbrowser bezoeker van amsterdam.nl krijg je een waarschuwingspagina naar https://www.amsterdam.nl/
Amsterdam.nl
Toegang geblokkeerd
De toegang tot de pagina die u probeert te bezoeken is tijdelijk geblokkeerd om overbelasting van de website te voorkomen. Wij vragen u vriendelijk onderstaande vraag te beantwoorden om verder te gaan met uw bezoek.
Krijgt u deze melding vaker te zien? Probeert u het dan op een later tijdstip nogmaals. Onze excuses voor het ongemak.
Wat is er gebeurd?
Amsterdam.nl maakt gebruik van een automatische controle om overbelasting van de website te voorkomen. Volgens deze controle wijkt uw bezoek af van het bezoek van een gemiddelde gebruiker. Mogelijk hebt u in korte tijd zeer veel pagina's opgevraagd of zeer veel formulieren verstuurd. Daarom is uw toegang tijdelijk geblokkeerd. Wanneer u bovenstaande vraag beantwoordt, wordt uw toegang hersteld.
Waarom krijg ik deze melding?
Het is mogelijk dat uw computer een virus of andere schadelijke programma's bevat die invloed hebben op uw surfgedrag. Wij raden u aan uw computer met een anti-virusprogramma te controleren of contact op te nemen met uw systeembeheerder als u gebruik maakt van een bedrijfscomputer.
Het kan voorkomen dat de automatische controle uw bezoek ten onrechte heeft opgemerkt en geblokkeerd. In dat geval bieden wij u onze excuses aan voor het ongemak. Blijft het probleem zich voordoen? Neemt u dan contact op met Antwoord op telefoonnummer 14 020.
Gemeente Amsterdam
Toegang geblokkeerd
De toegang tot de pagina die u probeert te bezoeken is tijdelijk geblokkeerd om overbelasting van de website te voorkomen. Wij vragen u vriendelijk onderstaande vraag te beantwoorden om verder te gaan met uw bezoek.
Krijgt u deze melding vaker te zien? Probeert u het dan op een later tijdstip nogmaals. Onze excuses voor het ongemak.
Wat is er gebeurd?
Amsterdam.nl maakt gebruik van een automatische controle om overbelasting van de website te voorkomen. Volgens deze controle wijkt uw bezoek af van het bezoek van een gemiddelde gebruiker. Mogelijk hebt u in korte tijd zeer veel pagina's opgevraagd of zeer veel formulieren verstuurd. Daarom is uw toegang tijdelijk geblokkeerd. Wanneer u bovenstaande vraag beantwoordt, wordt uw toegang hersteld.
Waarom krijg ik deze melding?
Het is mogelijk dat uw computer een virus of andere schadelijke programma's bevat die invloed hebben op uw surfgedrag. Wij raden u aan uw computer met een anti-virusprogramma te controleren of contact op te nemen met uw systeembeheerder als u gebruik maakt van een bedrijfscomputer.
Het kan voorkomen dat de automatische controle uw bezoek ten onrechte heeft opgemerkt en geblokkeerd. In dat geval bieden wij u onze excuses aan voor het ongemak. Blijft het probleem zich voordoen? Neemt u dan contact op met Antwoord op telefoonnummer 14 020.
Gemeente Amsterdam
Nou nee, niks overbelast, Torbrowser bezoeker en ik ben geen kwaaie piet (euh sint euh, wat is tegenwoordig politiek correct in die stad?) netzoals velen met mij die de browser gewoon gebruiken voor normale browsing doeleinden.
Maar dat terzijde.
Vul je alle captcha's net zolang in totdat je door de digitale douane heen bent als onverdacht persoon, dan wordt je doorgeleid naar de pagina met hoofdcontent op https://www.amsterdam.nl/.
Echter, toets je www.amsterdam.nl in dan kom je op een soortgelijke pagina terecht zij het dan op http://www.amsterdam.nl/, dus de niet secure pagina.
Vul je alle captcha's net zolang in totdat je door de digitale douane heen bent als onverdacht persoon, dan wordt je nu doorgeleid naar de pagina met hoofdcontent op https://www.amsterdam.nl/.
Bij mijn weten, door constatering, was dat eerder niet zo en kwam je op een http pagina van die website uit.
Ik heb er helaas geen screenshot van genomen dus terug in de tijd kan ik niet meer om het te controleren of te 'bewijzen'.
Maar, wat mij betreft is het wel een indicatie dat het zo was omdat, immers, er twee versies zijn van de waarschuwingspagina de https versie en de http versie en dat de http versie pas na authenticatie doorleidt naar de https versie in plaats van direct.
Het lijkt dus daarom (best) aannemelijk dat inmiddels de http waarschuwingspagina alsnog is 'doorgelust' (na invullen van de captcha's) naar de https versie waar dat eerder een doorverwijzing naar de http versie was (dacht ik toch echt eerder geconstateerd te hebben).
Want waarom zou ik bij het nu intoetsen van www.amsterdam.nl niet meteen doorgeleid worden naar de waarschuwingspagina onder https om vanaf daar verder naar de hoofdpagina te gaan op https?
That does not make sense, twee aparte waarschuwingspagina's (http en https) maar wel binnen de aanname dat beide website versies online geheel naast elkaar hebben bestaan.
Vermoed dus een snelle fix vandaag, die op zich, al dat zo is, al een compliment waard is.
Een en ander betreft een te bediscussiëren logica achteraf weliswaar, maar ik kan niet meer bewijzen dan het naar mijn indruk eerder anders was.
Daarbij wil ik best nog wel aantekenen dat vergissen mogelijk was (er is maar 1 Erik van Straaten en dat ben ik niet) omdat je toch nogal afgeleid wordt van wat je wilde doen met al die captcha's en het geven van allerhande toestemmingen onder Noscript vanwege iFrames, javascripts en 'clickjacking attempt' waarschuwingen.
Wat betreft de 'overig weinig beargumenteerde' (concreet onderbouwde? Het is niet verboden de pagina van Amsterdam zelf te bezoeken, hooguit wordt je wat tegengewerkt) zaken.
Dit zijn de response headers van de https waarschuwings-landing-page op de https versie,
mocht je er wat aan hebben.
Ik zie geen HSTS, jij wel?
Server: cloudflare-nginx
Date: Fri, 05 Feb 2016 18:13:09 GMT
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=3600
Expires: Fri, 05 Feb 2016 19:13:09 GMT
Last-Modified: Fri, 05 Feb 2016 10:23:00 GMT
Vary: Accept-Encoding
P3P: CP="NOI DSP MON CUR ADM DEV TAI OUR NOR STA"
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
CF-Cache-Status: EXPIRED
CF-RAY: 2700965f31fb192c-HKG
Content-Encoding: gzip
200 OK
Na de digitale douane goedkeuring
Server: cloudflare-nginx
Date: Fri, 05 Feb 2016 18:13:09 GMT
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=3600
Expires: Fri, 05 Feb 2016 19:13:09 GMT
Last-Modified: Fri, 05 Feb 2016 10:23:00 GMT
Vary: Accept-Encoding
P3P: CP="NOI DSP MON CUR ADM DEV TAI OUR NOR STA"
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
CF-Cache-Status: EXPIRED
CF-RAY: 2700965f31fb192c-HKG
Content-Encoding: gzip
200 OK
Date: Fri, 05 Feb 2016 18:13:09 GMT
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=3600
Expires: Fri, 05 Feb 2016 19:13:09 GMT
Last-Modified: Fri, 05 Feb 2016 10:23:00 GMT
Vary: Accept-Encoding
P3P: CP="NOI DSP MON CUR ADM DEV TAI OUR NOR STA"
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge,chrome=1
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
CF-Cache-Status: EXPIRED
CF-RAY: 2700965f31fb192c-HKG
Content-Encoding: gzip
200 OK
HSTS hoe zie (zag) je dat?
Voorbeeld Security.nl
https://www.security.nl/posting/459360/Halve+Https+%26+Cloudflare%3F
Server: cloudflare-nginx
Date: Fri, 05 Feb 2016 18:20:27 GMT
Content-Type: text/html
Content-Length: 14748
Connection: keep-alive
Set-Cookie: __cfduid=de3b6b409f8fa1396d218002dd74fb9451454696425; expires=Sat, 04-Feb-17 18:20:25 GMT; path=/; domain=.security.nl; HttpOnly sessionid=3~eo57aoi3l0g9hplqjlcnqakvg3; path=/; domain=www.security.nl; secure; HttpOnly sessionid=3~pet2cb04lel25ajepm02c9nsd5; path=/; domain=www.security.nl; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000
X-Frame-Options: DENY
Vary: Accept-Encoding
Content-Encoding: gzip
CF-RAY: 2700a113d425191a-HKG
200 OK
Server: cloudflare-nginx
Date: Fri, 05 Feb 2016 18:20:27 GMT
Content-Type: text/html
Content-Length: 14748
Connection: keep-alive
Set-Cookie: __cfduid=de3b6b409f8fa1396d218002dd74fb9451454696425; expires=Sat, 04-Feb-17 18:20:25 GMT; path=/; domain=.security.nl; HttpOnly sessionid=3~eo57aoi3l0g9hplqjlcnqakvg3; path=/; domain=www.security.nl; secure; HttpOnly sessionid=3~pet2cb04lel25ajepm02c9nsd5; path=/; domain=www.security.nl; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000
X-Frame-Options: DENY
Vary: Accept-Encoding
Content-Encoding: gzip
CF-RAY: 2700a113d425191a-HKG
200 OK
Maar goed, nu meng ik me toch verder in een (diepere) technische discussie die anderen veel beter kunnen voeren (wat niet betekent dat ik hem niet probeer te blijven volgen, ik begon tenslotte erover).
Groet T.s.
P.s. iemand ooit van een Proclaimer gehoord?
Wellicht, maar een standaard bezoeker die onderaan naar de pagina zoekt naar een Privacy verklaring zal de link waarschijnlijk niet leggen. Digitaal verstoppertjes spelen, daarna wordt er wel gewoon over "Privacyverklaring en proclaimer" gesproken.
Daarnaast krijg ik geen cookie meldingen maar die kun je via deze omweg en dan nog een link in de proclaimer tekst verder finetunen. Wat waarschijnlijk niemand doet omdat ..
Dit verbaasde me toch ook wel wat, zo je privacy beleid communiceren kan beter wat mij betreft. Te beginnen met het woord Privacy te gebruiken op de hoofdpagina en een cookie melding te tonen met een keuze veld.
Ik zie nu meer reacties verschijnen en lees die later.
Door Anoniem:
Ik ga een poging doen:
...
Beantwoord dit je vraag een beetje?
De vraag : Als je het eerder genoemde domein https://www.amsterdam.nl bezoekt, heb je dan een werkelijk geheel versleutelde verbinding of voor slechts een deel van de route naar die website?
Wie?
Wie?
Ik ga een poging doen:
...
Beantwoord dit je vraag een beetje?
Hartelijk dank voor je moeite een inzichtelijke antwoord te geven.
Laat ik me bescheiden opstellen en zeggen dat het lijkt of ik het snap (als niet techneut die het niet gaat nadoen want aanpassen van het hostfile in combinatie met Torbrowser wordt me wat ingewikkeld, vermoeiend hoor privacy).
Als ik je antwoord terugkoppel naar mijn starttekst met vraag die niet te vergeten werd gewekt naar aanleiding van de aanleidende suggestie die werd gewekt door de informatie op de site van crimeflare.com en niet te vergeten diverse bijdragen hier dan blijft overeind dat :
- Tussenkomst van Cloudflare het zicht vertroebelt op de suggestie of je een veilige verbinding hebt
- Het voor een standaard gebruiker niet te doen is om de waarde van dat slotje te beoordelen
- Ik, jij, we, eigenlijk geen (100%) idee hebben wat de suggestie van een veilige connectie met de site amsterdam.nl nou eigenlijk behelst en het uiteindelijk dus maar aankomt op vertrouwen in de aanbieder in zijn algemeenheid.
Maar, ja, als het dan toch om vertrouwen in de aanbieder in zijn algemeenheid gaat, (retorisch) heb je daar dan nog wel dat slotje voor nodig?
Immers, als we toch steeds minder een idee hebben van waar dat slotje nou eigenlijk voor staat en ook niet meer kunnen controleren wat de verbinding behelst; wat is dan (nogmaals) de waarde van dat slotje nog?
Het enige signaal dat dan nog van dat slotje uitgaat is dat het een signaal afgeeft dat de aanbieder zich bewust is van security en zich heeft bezig gehouden daar een oplossing voor te zoeken en probeert de bezoeker gerust te stellen.
Dan advocaat van de d. spelende, wat weer terugkomt op de pagina's van crimeflare en ook zelfs terug kwam in een nieuwsbericht van vandaag ( https://www.security.nl/posting/460023/Advertenties+op+TMZ_com+verspreiden+malware ), de tegenpartij maakt ook gebruik van Cloudflare diensten.
Maar dan om zich te verstoppen achter een Cloudflare verbinding om de schijn van legitimiteit en veiligheid te wekken, zonder dat je weet wat er na de MitM van Cloudflare op de lijn gebeurt omdat Cloudflare dat afschermt. (Las geloof ik op Tweakers dat ze misbruik dan wel doorgeven aan speurders).
Maar hoe zit het dan met security.nl?
Security.nl geeft geen certificaat van Cloudflare weer (en ik weet dat ze het gebruiken want ik krijg continue die Cloudflare captcha's voor mijn kiezen, ze staan trouwens ook op die crimeflare lijst van 57000 adressen) maar geeft een ander (geen Cloudflare) certificaat.
Doet security.nl het dan beter?
Kan de gemeente Amsterdam daar dan van leren of maakt dat niet uit?
Bottomline was dus eigenlijk hier een vraag te stellen en c.q. een discussie te starten naar aanleiding van de MitM services van Cloudflare (zoals ik vernam op crimeflare en beter is aangevuld door de bijdrage van Sheins met alle links) en in hoeverre dat dan voor de eindgebruiker zinvol is bij de poging te beoordelen wat voor soort verbinding men nou eigenlijk legt : geheel secure of half secure?
Het voorbeeld van de website van amsterdam.nl is daarin een handig handvat om die discussie te voeren (hele of halve veiligheid?) en ik ben er dan ook content mee dat het alsnog de reactie-deelname-aandacht krijgt die het mijns inziens verdient.
Ook al snap ik er wellicht maar deels de ballen van (sorry) ;).
Tja, weer een lange reactie (sorry voor het breken van de belofte ;), in de hoop dat het wat toevoegt aan de discussie rondom het beoordelen van en vertrouwen in zogenaamde slotjes.
Dank voor je uitzoekerij nogmaals en de technische tip.
Nogmaals, reageer naar hartelust op elkaars technische reacties (blijf ik meelezen, en mezelf waar ik kan overtuigend dat ik het inhoudelijk nog volg).
Groet T.s.
Dit zijn de nadelen voor het gebruik van een zo'n bulk-hoster als Cloudflare, Inc., die nu niet meteen bekend staat om zijn pro-actieve security beleid.
Controleren we eens wat gegevens voor -https://www.amsterdam.nl/
Voor de security header situatie kun je een scan doen hier: http://cyh.herokuapp.com/cyh
Niet eens zo verschrikkelijk slecht, vier correct geconfigureerde security headers, vier met waarschuwingen en vier die ontbreken.
De DNS draait in ieder geval in Nederland bij servicedeskATmotiv.nl
en behalve een SOA hick-up daar, is alles hier dik in orde, zie: http://www.dnsinspect.com/amsterdam.nl/1454709202
Maar het volgende moet ons de meeste zorgen baren, een scan met de Tracker SSL extensie.
92% of the trackers on this site could be helping protect you from NSA snooping.
But, even though amsterdam.nl uses HTTPS, there's at least one third party that's been communicating insecurely.
Tell amsterdam.nl to fix it.
Unique IDs about your web browsing habits have been insecurely sent to third parties.
-Google nid
-www.amsterdam.nl __cfduid
-code.jquery.com __cfduid
-d5fb79cb404xxxxxx1d42d9651ae2ac1a1445965753 -
local.adguard.com __cfduid (mijn adblocker software en extensie)
At least 14 third parties know you are on this webpage.
-Google
-Google
-Google
-Google
-www.amsterdam.nl
-fast.fonts.net
-Google
-code.jquery.com
-local.adguard.com (extensie in Google Chrome)
-Google
-ssl.siteimprove.com
-ssl.google-analytics.com Google
-New Relic
-www.mustbebuilt.co.uk (extensie in Google Chrome)
Tracker could be tracking safely if this site was secure!
Al met al geen opwekkend beeld, en dit is alles wat we slecht via indirecte 3rd party public scanning hebben
opgehaald. Doe persoonlijk ook eens een Dazzlepod IP scan, maar die gegevens kunnen we hier niet delen.
Controleren we eens wat gegevens voor -https://www.amsterdam.nl/
Voor de security header situatie kun je een scan doen hier: http://cyh.herokuapp.com/cyh
Niet eens zo verschrikkelijk slecht, vier correct geconfigureerde security headers, vier met waarschuwingen en vier die ontbreken.
De DNS draait in ieder geval in Nederland bij servicedeskATmotiv.nl
en behalve een SOA hick-up daar, is alles hier dik in orde, zie: http://www.dnsinspect.com/amsterdam.nl/1454709202
Maar het volgende moet ons de meeste zorgen baren, een scan met de Tracker SSL extensie.
92% of the trackers on this site could be helping protect you from NSA snooping.
But, even though amsterdam.nl uses HTTPS, there's at least one third party that's been communicating insecurely.
Tell amsterdam.nl to fix it.
Unique IDs about your web browsing habits have been insecurely sent to third parties.
-Google nid
-www.amsterdam.nl __cfduid
-code.jquery.com __cfduid
-d5fb79cb404xxxxxx1d42d9651ae2ac1a1445965753 -
local.adguard.com __cfduid (mijn adblocker software en extensie)
At least 14 third parties know you are on this webpage.
-www.amsterdam.nl
-fast.fonts.net
-code.jquery.com
-local.adguard.com (extensie in Google Chrome)
-ssl.siteimprove.com
-ssl.google-analytics.com Google
-New Relic
-www.mustbebuilt.co.uk (extensie in Google Chrome)
Tracker could be tracking safely if this site was secure!
Al met al geen opwekkend beeld, en dit is alles wat we slecht via indirecte 3rd party public scanning hebben
opgehaald. Doe persoonlijk ook eens een Dazzlepod IP scan, maar die gegevens kunnen we hier niet delen.
Oh en dan dit nog terwijl het off-topic is, wilde ik het toch nog vermelden. Web-admin doe er je voordeel mee.
Ik scan een onveilige jQuery library:
-https://www.amsterdam.nl
Gedetecteerde libraries:
jquery-migrate - 1.2.1 : -https://code.jquery.com/jquery-migrate-1.2.1.min.js
Info: Ernst: medium
http://bugs.jquery.com/ticket/11290
http://research.insecurelabs.org/jquery/test/
jquery - 1.11.1 : (actief1) -https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js
jquery-ui-autocomplete - 1.10.3 : (actief1) https://www.amsterdam.nl
1 kwetsbare library gedetecteerd.
Zippen en bewaren voor latere referentie. We zien nog te veel van dit soort onveiligheid.
Ook in combinatie met andere code kan dit extra kwetsbaarheid opleveren.
Ik scan een onveilige jQuery library:
-https://www.amsterdam.nl
Gedetecteerde libraries:
jquery-migrate - 1.2.1 : -https://code.jquery.com/jquery-migrate-1.2.1.min.js
Info: Ernst: medium
http://bugs.jquery.com/ticket/11290
http://research.insecurelabs.org/jquery/test/
jquery - 1.11.1 : (actief1) -https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js
jquery-ui-autocomplete - 1.10.3 : (actief1) https://www.amsterdam.nl
1 kwetsbare library gedetecteerd.
Zippen en bewaren voor latere referentie. We zien nog te veel van dit soort onveiligheid.
Ook in combinatie met andere code kan dit extra kwetsbaarheid opleveren.
"halve https" is nog tot daar aan toe, maar technisch lijkt het mij ook mogelijk dat in de cloud de verbinding altijd http kan zijn. Zelfs ook als zowel webserver als client allebei https op hun lijn zien!
Bestudeer maar eens goed het "Current Efforts -Google"-plaatje van http://www.crimeflare.com/cfssl.html.
"GFE" in het plaatje wordt in dit geval "CFE" ("C" van Cloudflare).
Alle clients komen in dit geval binnen op die "klanten-CFE".
Bedenk er vervolgens aan de andere kant van de cloud een tweede CFE bij, waar websites mee worden verbonden.
Dan kan in de cloud, dus tussen "klanten-CFE" en "websites-CFE" de stream theoretisch altijd http zijn.
Dus: "all traffic in clear text in the Cloudflare cloud".
En daar kan ondertussen van alles mee worden gedaan: monitoring, opslag of script injectie. Het kan allemaal.
En niemand merkt er iets van of kan er iets aan doen.
Je hoeft geen genie te zijn om dit te kunnen bedenken. Zo logisch als 1+1=2
Ik twijfel er zelfs aan of je aan het certificaat dan nog zou kunnen zien of je nu een https verbinding hebt mét cloudflare
of alleen maar een (écht veilige) ononderbroken directe verbinding met de gewenste server via cloudflare.
(tenminste... in die gevallen waar een website in vertrouwen zijn private key aan cloudflare heeft afgestaan...)
De enige zekerheid die je dan nog overhoudt, is een papieren zekerheid, namelijk:
"dat cloudflare vertrouwelijk met de private key om zal gaan".
Maar ik denk dat iemand als Erik van Straten dit het beste kan beoordelen?
Bestudeer maar eens goed het "Current Efforts -Google"-plaatje van http://www.crimeflare.com/cfssl.html.
"GFE" in het plaatje wordt in dit geval "CFE" ("C" van Cloudflare).
Alle clients komen in dit geval binnen op die "klanten-CFE".
Bedenk er vervolgens aan de andere kant van de cloud een tweede CFE bij, waar websites mee worden verbonden.
Dan kan in de cloud, dus tussen "klanten-CFE" en "websites-CFE" de stream theoretisch altijd http zijn.
Dus: "all traffic in clear text in the Cloudflare cloud".
En daar kan ondertussen van alles mee worden gedaan: monitoring, opslag of script injectie. Het kan allemaal.
En niemand merkt er iets van of kan er iets aan doen.
Je hoeft geen genie te zijn om dit te kunnen bedenken. Zo logisch als 1+1=2
Ik twijfel er zelfs aan of je aan het certificaat dan nog zou kunnen zien of je nu een https verbinding hebt mét cloudflare
of alleen maar een (écht veilige) ononderbroken directe verbinding met de gewenste server via cloudflare.
(tenminste... in die gevallen waar een website in vertrouwen zijn private key aan cloudflare heeft afgestaan...)
De enige zekerheid die je dan nog overhoudt, is een papieren zekerheid, namelijk:
"dat cloudflare vertrouwelijk met de private key om zal gaan".
Maar ik denk dat iemand als Erik van Straten dit het beste kan beoordelen?
Waarom nog zo'n betoog, alhoewel bijster interessant, als de Tracker SSL extensie in mijn voorbeeld al aangeeft dat 92% van de unieke tracking IDs onveilig over de draad gaat. Daar is al genoeg mee te doen en dat zal zeker zorgen dat je als bezoeker ook stevig "vermarkt" zal worden, ook als in Amsterdam je privacy je aan je hart gaat. Wij met z'n allen zijn tenslotte niets anders dan het product voor diensten als Cloudflare enz..
Het is nog een wonder met de beveiliging die ze niet bieden, dat ze zo hoog in de markt staan.
Behalve dan de "doordenker", die eerder in deze draad een interessant en plausibel betoog opzette. Iets waar we echter nooit het fijne van te weten zullen komen, al zou zo'n doem-scenario echt bestaan. Dan nog maken de meeste gebruikers zich totaal geen zorgen over Cloudflare Inc. en consorten en leven zij verder zonder zorgen in de zekerheid van hun "zalige onwetendheid".
Het is nog een wonder met de beveiliging die ze niet bieden, dat ze zo hoog in de markt staan.
Behalve dan de "doordenker", die eerder in deze draad een interessant en plausibel betoog opzette. Iets waar we echter nooit het fijne van te weten zullen komen, al zou zo'n doem-scenario echt bestaan. Dan nog maken de meeste gebruikers zich totaal geen zorgen over Cloudflare Inc. en consorten en leven zij verder zonder zorgen in de zekerheid van hun "zalige onwetendheid".
Dan testen we het toch even hier: https://www.fairssl.se/en/ssltest
Het certificaat is SHA-1 ondertekend en nog tot voorbij 1 juli 2016 geldig en dient zo spoedig mogelijk door een SHA-2 ondertekend certificaat. Google Chrome 40 en latere versies zullen het volgende tonen aan gebruikers die deze site bezoeken. geen slotje en https://voorbeeld.com
Het server adres dat u gaf komt overeen met de server naam vermeld op het SSL certificaat.
Verder 67 testjes verricht hier, zie het resultaat ervan hier: https://www.wormly.com/test_ssl/h/cloudflaressl.com/i/104.20.71.54/p/443
De verbinding loopt via 443/tcp open ssl/http Cloudflare nginx - ssl-cert: Subject: commonName=ssl324049.cloudflaressl.com
http-title - _ssl-date: TLS randomness does not represent time - tls-nextprotoneg; spdy/3.1 en http/1.1
spy/3.1 oftewel speedy is ontwikkeld door Google voor Chrome en wordt ook in firefox ondersteund.
Comodo heeft ook heel wat issues en ook weer in dit het geval, waar "de slager het eigen worstmerk keurt".
Vertrouw dus ten volle alleen datgene dat u zelf hebt getest en dat geldt voor alles in dit verband.
SSL Status
OK!
Debian Bug: OK (it's good!)
Heartbleed Bug: OK (Confirmed Safe)
Test performed on: 104.20.71.54:443
cloudflaressl.com gives valid IP 104.20.71.54
Server name matches the SAN name.
The certificate expires in 328 days
Testing without sending Server Name Indication (recommended).
Certificate is domain validated.
Received 2 certificates from the server.
Issuer Certificate: COMODO Domain Validation Secure Server CA 2
Issuer Company: COMODO CA Limited
Certificate Key: 2048 Bit - Normal security.
Signature Algorithm: SHA1+RSA *
* SHA1 zou al uitgefaseerd moeten zijn eigenlijk (opm. van mij).OK!
Debian Bug: OK (it's good!)
Heartbleed Bug: OK (Confirmed Safe)
Test performed on: 104.20.71.54:443
cloudflaressl.com gives valid IP 104.20.71.54
Server name matches the SAN name.
The certificate expires in 328 days
Testing without sending Server Name Indication (recommended).
Certificate is domain validated.
Received 2 certificates from the server.
Issuer Certificate: COMODO Domain Validation Secure Server CA 2
Issuer Company: COMODO CA Limited
Certificate Key: 2048 Bit - Normal security.
Signature Algorithm: SHA1+RSA *
SSL Certificates Received
Common Name: ssl324047.cloudflaressl.com
SANs: ssl324047.cloudflaressl.com, *.cloudflaressl.com, cloudflaressl.com
Department: Domain Control Validated
PositiveSSL Multi-Domain
SSL+CRL Check: Ok http://crl.comodoca4.com/COMODODomainValidationSecureServerCA2.crl
Validity: From 31/12-2015 to 01/01-2017
Serial Number: 117043581334930769994610009494384462181
Serial Number (hex): 580DC6185ADC26A466854DB3B94EC965
SHA1 Fingerprint: 3FF136DCE80B278CAD71061FFACBD2D3EA9E8F98
Signature Algorithm: SHA1+RSA
Certificate Algorithm: RSA
Certificate Hash: 3947c95b
Author: COMODO Domain Validation Secure Server CA 2 (COMODO CA Limited)
Features: Web Server, Web Client, Digital Signature, Key Encipherment
[Click here to download the public part of this certificate]
Common Name: COMODO Domain Validation Secure Server CA 2
Company: COMODO CA Limited
Location: Salford,Greater Manchester,GB
SSL+CRL Check: Ok http://crl.usertrust.com/AddTrustExternalCARoot.crl * N.B. een http:// adres!!!
Validity: From 25/09-2014 to 25/09-2029
Serial Number: 49894624593792675272746652240853897126
Serial Number (hex): 25895AEB9044C8E617604A152CF88FA6
SHA1 Fingerprint: 314D3912A83D1D9613CAFB4DBBDC23F0CEE7B409
Signature Algorithm: SHA1+RSA
Certificate Algorithm: RSA
Certificate Hash: 9502d166
Author: AddTrust External CA Root (AddTrust AB)
Features: Web Server, Web Client, Certificate Signing, CRL Signing, Digital Signature
SHA-1 Certificate Valid Past 7/1/2016 Common Name: ssl324047.cloudflaressl.com
SANs: ssl324047.cloudflaressl.com, *.cloudflaressl.com, cloudflaressl.com
Department: Domain Control Validated
PositiveSSL Multi-Domain
SSL+CRL Check: Ok http://crl.comodoca4.com/COMODODomainValidationSecureServerCA2.crl
Validity: From 31/12-2015 to 01/01-2017
Serial Number: 117043581334930769994610009494384462181
Serial Number (hex): 580DC6185ADC26A466854DB3B94EC965
SHA1 Fingerprint: 3FF136DCE80B278CAD71061FFACBD2D3EA9E8F98
Signature Algorithm: SHA1+RSA
Certificate Algorithm: RSA
Certificate Hash: 3947c95b
Author: COMODO Domain Validation Secure Server CA 2 (COMODO CA Limited)
Features: Web Server, Web Client, Digital Signature, Key Encipherment
[Click here to download the public part of this certificate]
Common Name: COMODO Domain Validation Secure Server CA 2
Company: COMODO CA Limited
Location: Salford,Greater Manchester,GB
SSL+CRL Check: Ok http://crl.usertrust.com/AddTrustExternalCARoot.crl * N.B. een http:// adres!!!
Validity: From 25/09-2014 to 25/09-2029
Serial Number: 49894624593792675272746652240853897126
Serial Number (hex): 25895AEB9044C8E617604A152CF88FA6
SHA1 Fingerprint: 314D3912A83D1D9613CAFB4DBBDC23F0CEE7B409
Signature Algorithm: SHA1+RSA
Certificate Algorithm: RSA
Certificate Hash: 9502d166
Author: AddTrust External CA Root (AddTrust AB)
Features: Web Server, Web Client, Certificate Signing, CRL Signing, Digital Signature
Het certificaat is SHA-1 ondertekend en nog tot voorbij 1 juli 2016 geldig en dient zo spoedig mogelijk door een SHA-2 ondertekend certificaat. Google Chrome 40 en latere versies zullen het volgende tonen aan gebruikers die deze site bezoeken. geen slotje en https://voorbeeld.com
Het server adres dat u gaf komt overeen met de server naam vermeld op het SSL certificaat.
Verder 67 testjes verricht hier, zie het resultaat ervan hier: https://www.wormly.com/test_ssl/h/cloudflaressl.com/i/104.20.71.54/p/443
De verbinding loopt via 443/tcp open ssl/http Cloudflare nginx - ssl-cert: Subject: commonName=ssl324049.cloudflaressl.com
http-title - _ssl-date: TLS randomness does not represent time - tls-nextprotoneg; spdy/3.1 en http/1.1
spy/3.1 oftewel speedy is ontwikkeld door Google voor Chrome en wordt ook in firefox ondersteund.
Comodo heeft ook heel wat issues en ook weer in dit het geval, waar "de slager het eigen worstmerk keurt".
Vertrouw dus ten volle alleen datgene dat u zelf hebt getest en dat geldt voor alles in dit verband.
Over de veiligheid van Keyless SSL van CloudFlare, leest u het best deze draad een rustig door: https://news.ycombinator.com/item?id=8334933
Daarin wordt ook beweerd dat het verkeer tussen Cloudflare en de client niet via een "encrypted tunnel" gebeurt, iets wat iemand hier al opperde. Dat hoeft dan ook helemaal niet, omdat alles betreffende de sleutel plaats heeft via een te bevragen "oracle", welke die dan ook checkt voor de eind-bestemming, de genoemde voorbeeldsites hier of een ander instituut, je bank bijvoorbeeld.
Dan is de vraag verder hoe ze daarbij omgaan met de risico mitigatie. Voordeel is dat het sleutelmateriaal buiten het TLS afhandelingsproces wordt gehouden. De privé sleutel blijft dus onder alle omstandigheden veilig (en versleuteld). Alleen als je sleutel-server down is, om wat voor reden dan ook, heb je een probleem, dan kan Cloudflare je verkeer niet verder faciliteren. Maar daar is omheen te laveren via de cache.
Het grote voordeel van het hele schema schijnt te zijn dat je minder afhankelijk van hardware bent. Maar lees de hele discussie via de link eens na om zelf een oordeel te kunnen vormen. Ik hoop dat dit een en ander weer wat duidelijker heeft gekregen.
Daarin wordt ook beweerd dat het verkeer tussen Cloudflare en de client niet via een "encrypted tunnel" gebeurt, iets wat iemand hier al opperde. Dat hoeft dan ook helemaal niet, omdat alles betreffende de sleutel plaats heeft via een te bevragen "oracle", welke die dan ook checkt voor de eind-bestemming, de genoemde voorbeeldsites hier of een ander instituut, je bank bijvoorbeeld.
Dan is de vraag verder hoe ze daarbij omgaan met de risico mitigatie. Voordeel is dat het sleutelmateriaal buiten het TLS afhandelingsproces wordt gehouden. De privé sleutel blijft dus onder alle omstandigheden veilig (en versleuteld). Alleen als je sleutel-server down is, om wat voor reden dan ook, heb je een probleem, dan kan Cloudflare je verkeer niet verder faciliteren. Maar daar is omheen te laveren via de cache.
Het grote voordeel van het hele schema schijnt te zijn dat je minder afhankelijk van hardware bent. Maar lees de hele discussie via de link eens na om zelf een oordeel te kunnen vormen. Ik hoop dat dit een en ander weer wat duidelijker heeft gekregen.
Het volgende ben ik 200% eens met Scott H.:
Je kan het niet maken dat je je bezoekers een perfect certificaat voorschotelt, hetgeen bovendien door SSL-testwebsites
wordt bevestigd, terwijl in werkelijkheid een buitenlandse partij als Cloudflare ertussen zit.
Ik weet niet hoe het anderen gaat, maar ik voel me dan niet echt vrij meer, en ook wat belazerd.
Zo'n website zal door mij nooit meer met het volste vertrouwen worden bezocht. (en dus juist eerder worden gemeden)
Hosts need to be responsible and ensure that if they are using encryption, that at any point our data is on a public network, it is encrypted.
The temptation is there for too many to act in an irresponsible way and CloudFlare seem to be supporting that behaviour.
Jammer dat zelfs ook websites waar je het het laatst van verwacht, deze verleiding niet konden weerstaan. :((The temptation is there for too many to act in an irresponsible way and CloudFlare seem to be supporting that behaviour.
Je kan het niet maken dat je je bezoekers een perfect certificaat voorschotelt, hetgeen bovendien door SSL-testwebsites
wordt bevestigd, terwijl in werkelijkheid een buitenlandse partij als Cloudflare ertussen zit.
Ik weet niet hoe het anderen gaat, maar ik voel me dan niet echt vrij meer, en ook wat belazerd.
Zo'n website zal door mij nooit meer met het volste vertrouwen worden bezocht. (en dus juist eerder worden gemeden)
08-02-2016, 12:20 door
Erik van Straten
07-02-2016, 18:36 door Anoniem: Voordeel is dat het sleutelmateriaal buiten het TLS afhandelingsproces wordt gehouden
Dat is onjuist, zie mijn volgende bijdrage.07-02-2016, 18:36 door Anoniem: De privé sleutel blijft dus onder alle omstandigheden veilig (en versleuteld).
Voor de veiligheid van de private key ben je welliswaar niet afhankelijk van Cloudflare, maar natuurlijk wel van de server waar die private key daadwerkelijk op staat. En meestal is dat niet in een HSM (Hardware Security Module), en als deze private key al versleuteld is (ongebruikelijk), moet de sleutel daarvan ernaast liggen. Nb. een HSM helpt om diefstal van een private key te voorkomen, maar niet om die private key live te kunnen gebruiken bij cryptografische operaties.07-02-2016, 18:36 door Anoniem: Alleen als je sleutel-server down is, om wat voor reden dan ook, heb je een probleem, dan kan Cloudflare je verkeer niet verder faciliteren. Maar daar is omheen te laveren via de cache.
Helaas, dat laatste kan niet. Als de TLS verbinding niet tot stand komt, kan er ook geen informatie uit een cache naar de webbrowser worden gestuurd.
08-02-2016, 12:20 door
Erik van Straten
In het algemeen: het woord "Keyless" slaat sowieso helemaal nergens op. Bij elke SSL/TLS verbinding-met-slotje is er sprake van tenminste 3 sleutels (keys) of sleutelparen (key pairs):
(1) Altijd: een asymmetrisch sleutelpaar, in elk geval gebruikt ter authenticatie van de webserver en, als (2) niet gebruikt wordt, om sleutel (3) versleuteld uit te kunnen wisselen via een onveilige verbinding;
(2) Optioneel: een asymmetrisch Diffie-Hellman sleutelpaar, gebruikt om sleutel (3) versleuteld "uit te kunnen wisselen" (overeenstemming bereiken over is een betere beschrijving) via een onveilige verbinding, zonder hierbij de private key (1) voor te gebruiken (Forward Secrecy - mits het asymmetrische sleutelpaar eenmalig wordt gebruikt);
(3) Altijd: een symmetrische sleutel om de verbinding te versleutelen.
De truc die Cloudflare uithaalt bij "Keyless SSL" is een soort "RHSM" oftewel Remote Hardware Security Module. Daarbij wordt de private key (1) niet bij Cloudflare, maar ergens op een server "van" de Cloudflare klant opgeslagen. Alle cryptografische bewerkingen waar die private key voor nodig is, worden uitsluitend uitgevoerd op die server. Daardoor hoeft de private key die server niet te verlaten.
Wat heb je hier aan? Vanuit cryptografisch oogpunt helemaal niets - althans zolang de klant Cloudflare toestaat om van deze RHSM gebruik te maken (immers, bezien vanuit jouw browser is een server bij Cloudflare het eindpunt van de versleutelde verbinding; op die server, en wie weet daarachter, is de informatie niet versleuteld). Het enige (piepkleine) voordeel is dat, zodra de klant Cloudflare de rug toekeert, die voormalige klant die private key (en bijbehorend certificaat) kan blijven gebruiken.
Anderzijds nemen risico's ook toe: als servers van Cloudflare jouw private key mogen gebruiken om zich voor te doen als jouw server, kunnen wellicht andere (minder frisse) partijen dat ook. Hoe goed is dat dichtgetimmerd - vraag ik mij dan af.
Bij https://amsterdam.nl/ en https://www.amsterdam.nl/ is echter helemaal geen sprake van "Keyless SSL" (voor wat dat waard is).
Bij het bezoeken van genoemde sites krijg ik namelijk een certificaat dat gebruikt kan worden voor de websites genoemd onderaan deze bijdrage, waarvan alle, op 1 na, niets met amsterdam.nl te maken hebben. En dat kan alleen als Cloudflare daar de private key van in bezit heeft. Zoals ik al eerder schreef, als DNS wijst naar een server waar jij (ook als je aanvaller bent) toegang tot hebt, kun je doodeenvoudig een DV certificaat aanvragen - en dat is precies wat Cloudflare doet in dit soort situaties.
Het certificaat is geldig voor de volgende sites (met [*.] bedoel ik dat het geldig is voor sites geheel zonder dat voorvoegsel en of voor *.naam.tld, wat betekent dat er 1 willekeurig voorvoegsel voor mag: www.naam.tld mag dus wel, www.sub.naam.tld mag niet):
ssl278906.cloudflaressl.com
[*.]amadorasbonitas.com
[*.]amsterdam.nl
[*.]barebackrt.com
[*.]bbrts.com
[*.]cardboardcutoutstandees.com
[*.]cbcec.be
[*.]civano.com
[*.]cyberthreatintel.io
[*.]dairytrain.com
[*.]dojomagic.net
[*.]erinmillington.com
[*.]fablabbcn.org
[*.]filmfreeway.com
[*.]flagsandpoles.com
[*.]guerrillamail.com
[*.]guiavpn.com
[*.]hotchkissconsulting.com
[*.]iaac.net
[*.]jineko.net
[*.]marketsharp.com
[*.]norwoodhousepress.com
[*.]oper.ru
[*.]rajivpant.com
[*.]sexocomgravidas.com
[*.]smartcitizen.me
[*.]strategicsec.com
[*.]sunformalphabet.com
[*.]taaonline.net
Aangezien de nslookups van amsterdam.nl en sexocomgravidas.com dezelfde IP-adressen opleveren, lijkt hier sprake van shared hosting (content van genoemde sites staat op 1 fysieke server) - een gemeente als Amsterdam onwaardig lijkt mij. Als één van die sites, vanwege minder frisse (of kwaadaardige content) op IP-blacklists belandt, heb je kans dat velen de andere websites ook niet meer kunnen bezoeken.
(1) Altijd: een asymmetrisch sleutelpaar, in elk geval gebruikt ter authenticatie van de webserver en, als (2) niet gebruikt wordt, om sleutel (3) versleuteld uit te kunnen wisselen via een onveilige verbinding;
(2) Optioneel: een asymmetrisch Diffie-Hellman sleutelpaar, gebruikt om sleutel (3) versleuteld "uit te kunnen wisselen" (overeenstemming bereiken over is een betere beschrijving) via een onveilige verbinding, zonder hierbij de private key (1) voor te gebruiken (Forward Secrecy - mits het asymmetrische sleutelpaar eenmalig wordt gebruikt);
(3) Altijd: een symmetrische sleutel om de verbinding te versleutelen.
De truc die Cloudflare uithaalt bij "Keyless SSL" is een soort "RHSM" oftewel Remote Hardware Security Module. Daarbij wordt de private key (1) niet bij Cloudflare, maar ergens op een server "van" de Cloudflare klant opgeslagen. Alle cryptografische bewerkingen waar die private key voor nodig is, worden uitsluitend uitgevoerd op die server. Daardoor hoeft de private key die server niet te verlaten.
Wat heb je hier aan? Vanuit cryptografisch oogpunt helemaal niets - althans zolang de klant Cloudflare toestaat om van deze RHSM gebruik te maken (immers, bezien vanuit jouw browser is een server bij Cloudflare het eindpunt van de versleutelde verbinding; op die server, en wie weet daarachter, is de informatie niet versleuteld). Het enige (piepkleine) voordeel is dat, zodra de klant Cloudflare de rug toekeert, die voormalige klant die private key (en bijbehorend certificaat) kan blijven gebruiken.
Anderzijds nemen risico's ook toe: als servers van Cloudflare jouw private key mogen gebruiken om zich voor te doen als jouw server, kunnen wellicht andere (minder frisse) partijen dat ook. Hoe goed is dat dichtgetimmerd - vraag ik mij dan af.
Bij https://amsterdam.nl/ en https://www.amsterdam.nl/ is echter helemaal geen sprake van "Keyless SSL" (voor wat dat waard is).
Bij het bezoeken van genoemde sites krijg ik namelijk een certificaat dat gebruikt kan worden voor de websites genoemd onderaan deze bijdrage, waarvan alle, op 1 na, niets met amsterdam.nl te maken hebben. En dat kan alleen als Cloudflare daar de private key van in bezit heeft. Zoals ik al eerder schreef, als DNS wijst naar een server waar jij (ook als je aanvaller bent) toegang tot hebt, kun je doodeenvoudig een DV certificaat aanvragen - en dat is precies wat Cloudflare doet in dit soort situaties.
Het certificaat is geldig voor de volgende sites (met [*.] bedoel ik dat het geldig is voor sites geheel zonder dat voorvoegsel en of voor *.naam.tld, wat betekent dat er 1 willekeurig voorvoegsel voor mag: www.naam.tld mag dus wel, www.sub.naam.tld mag niet):
ssl278906.cloudflaressl.com
[*.]amadorasbonitas.com
[*.]amsterdam.nl
[*.]barebackrt.com
[*.]bbrts.com
[*.]cardboardcutoutstandees.com
[*.]cbcec.be
[*.]civano.com
[*.]cyberthreatintel.io
[*.]dairytrain.com
[*.]dojomagic.net
[*.]erinmillington.com
[*.]fablabbcn.org
[*.]filmfreeway.com
[*.]flagsandpoles.com
[*.]guerrillamail.com
[*.]guiavpn.com
[*.]hotchkissconsulting.com
[*.]iaac.net
[*.]jineko.net
[*.]marketsharp.com
[*.]norwoodhousepress.com
[*.]oper.ru
[*.]rajivpant.com
[*.]sexocomgravidas.com
[*.]smartcitizen.me
[*.]strategicsec.com
[*.]sunformalphabet.com
[*.]taaonline.net
Aangezien de nslookups van amsterdam.nl en sexocomgravidas.com dezelfde IP-adressen opleveren, lijkt hier sprake van shared hosting (content van genoemde sites staat op 1 fysieke server) - een gemeente als Amsterdam onwaardig lijkt mij. Als één van die sites, vanwege minder frisse (of kwaadaardige content) op IP-blacklists belandt, heb je kans dat velen de andere websites ook niet meer kunnen bezoeken.
Een DROWN ssl2 check op foundeo.com leert dat amsterdam.nl dit heeft uitgeschakeld.
https://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm?test_domain=amsterdam.nl
- Protocol Status Recommendation
SSLv2 SSLv2 is Disabled SSLv2 is weak and should be disabled.
SSLv3 SSLv3 is Disabled Consider disabling SSLv3 to mitigate the POODLE attack. Should be disabled for PCI DSS 3.1 Compliance
Een check op ssl labs laat wel zien dat niet alle onveilige protocollen zijn uitgeschakeld en het geeft meer waarschuwingingen af. Ligt dat aan cloudflare of aan amsterdam en is dat problematisch?
https://www.ssllabs.com/ssltest/analyze.html?d=amsterdam.nl
- Server Key and Certificate #1
Common names www.amsterdam.nl MISMATCH
Trusted No NOT TRUSTED (Why?) https://www.ssllabs.com/ssltest/analyze.html?d=amsterdam.nl#whyNotTrusted
- Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
- Protocol Details
RC4 Yes INSECURE (more info)
Forward Secrecy With some browsers (more info) https://blog.qualys.com/ssllabs/2013/06/25/ssl-labs-deploying-forward-secrecy
- Handshake Simulation
Android 2.3.7 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Android 4.0.4 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.1.1 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.2.2 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.3 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Baidu Jan 2015 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
IE 6 / XP No FS 1 No SNI 2 Server closed connection
IE 7 / Vista RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
IE 8 / XP No FS 1 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA RC4
IE 8-10 / Win 7 R RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
IE 10 / Win Phone 8.0 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Java 6u45 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Java 7u25 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
OpenSSL 0.9.8y RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Safari 5.1.9 / OS X 10.6.8 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Safari 6.0.4 / OS X 10.8.4 R RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
- Miscellaneous
Test date Fri, 11 Mar 2016
Test duration 138.592 seconds
HTTP status code 301
HTTP forwarding https://www.amsterdam.nl
HTTP server signature nginx
Server hostname hvs1nwlb003-hosting-lb-hvs1.internal.asp4all.nl
https://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm?test_domain=amsterdam.nl
- Protocol Status Recommendation
SSLv2 SSLv2 is Disabled SSLv2 is weak and should be disabled.
SSLv3 SSLv3 is Disabled Consider disabling SSLv3 to mitigate the POODLE attack. Should be disabled for PCI DSS 3.1 Compliance
Een check op ssl labs laat wel zien dat niet alle onveilige protocollen zijn uitgeschakeld en het geeft meer waarschuwingingen af. Ligt dat aan cloudflare of aan amsterdam en is dat problematisch?
https://www.ssllabs.com/ssltest/analyze.html?d=amsterdam.nl
- Server Key and Certificate #1
Common names www.amsterdam.nl MISMATCH
Trusted No NOT TRUSTED (Why?) https://www.ssllabs.com/ssltest/analyze.html?d=amsterdam.nl#whyNotTrusted
- Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
- Protocol Details
RC4 Yes INSECURE (more info)
Forward Secrecy With some browsers (more info) https://blog.qualys.com/ssllabs/2013/06/25/ssl-labs-deploying-forward-secrecy
- Handshake Simulation
Android 2.3.7 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Android 4.0.4 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.1.1 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.2.2 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Android 4.3 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Baidu Jan 2015 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
IE 6 / XP No FS 1 No SNI 2 Server closed connection
IE 7 / Vista RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
IE 8 / XP No FS 1 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA RC4
IE 8-10 / Win 7 R RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
IE 10 / Win Phone 8.0 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Java 6u45 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Java 7u25 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
OpenSSL 0.9.8y RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_RC4_128_SHA No FS RC4
Safari 5.1.9 / OS X 10.6.8 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
Safari 6.0.4 / OS X 10.8.4 R RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA ECDH secp256r1 FS RC4
- Miscellaneous
Test date Fri, 11 Mar 2016
Test duration 138.592 seconds
HTTP status code 301
HTTP forwarding https://www.amsterdam.nl
HTTP server signature nginx
Server hostname hvs1nwlb003-hosting-lb-hvs1.internal.asp4all.nl
Stand van zaken ?
Vraag: is er nu 7 maanden iets ten positieve veranderd of zijn geconstateerde zaken nog steeds aan de hand?
Hoe staat het met bijvoorbeeld de shared hosting?
Klopt het dat dit domein met 101 andere websites wordt gedeeld?
Ik krijg even geen goed beeld o.a. (paywall resultaten).
Vraag: is er nu 7 maanden iets ten positieve veranderd of zijn geconstateerde zaken nog steeds aan de hand?
Hoe staat het met bijvoorbeeld de shared hosting?
Klopt het dat dit domein met 101 andere websites wordt gedeeld?
Ik krijg even geen goed beeld o.a. (paywall resultaten).
L.S. Update:
En nu moet men hier weer eens aan de gang volgens de bekende "same origin" policy: https://sritest.io/#report/16ea9e3a-c44c-4577-af57-d0609f5c4322 3 script issues
Hiermee het certificaat gaat het beter, zie het rapport volgens https://cryptoreport.websecurity.symantec.com/checker/
maar het is nog steeds een multi-domein!?!
En wat eens aan jQuery code is verworven. moet ook eens worden "verdorven" e.q. "retired":
https://www.amsterdam.nl/
Detected libraries:
jquery-migrate - 1.2.1 : https://code.jquery.com/jquery-migrate-1.2.1.min.js
Info: Severity: medium
http://bugs.jquery.com/ticket/11290
http://research.insecurelabs.org/jquery/test/
jquery - 1.11.1 : (active1) https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js
Info: Severity: medium
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
jquery-ui-autocomplete - 1.10.3 : (active1) https://www.amsterdam.nl/
(active) - the library was also found to be active by running code
2 vulnerable libraries detected
Nog steeds wat werk aan de Amsterdamse web-winkel dus.
En nu moet men hier weer eens aan de gang volgens de bekende "same origin" policy: https://sritest.io/#report/16ea9e3a-c44c-4577-af57-d0609f5c4322 3 script issues
Hiermee het certificaat gaat het beter, zie het rapport volgens https://cryptoreport.websecurity.symantec.com/checker/
maar het is nog steeds een multi-domein!?!
En wat eens aan jQuery code is verworven. moet ook eens worden "verdorven" e.q. "retired":
https://www.amsterdam.nl/
Detected libraries:
jquery-migrate - 1.2.1 : https://code.jquery.com/jquery-migrate-1.2.1.min.js
Info: Severity: medium
http://bugs.jquery.com/ticket/11290
http://research.insecurelabs.org/jquery/test/
jquery - 1.11.1 : (active1) https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js
Info: Severity: medium
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
jquery-ui-autocomplete - 1.10.3 : (active1) https://www.amsterdam.nl/
(active) - the library was also found to be active by running code
2 vulnerable libraries detected
Nog steeds wat werk aan de Amsterdamse web-winkel dus.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.