Troy Hunt:
https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-security-absolutism/

Kort antwoord: ja.

HTTPS is het HTTP protocol over een TLS verbinding. TLS zorgt voor vertrouwelijkheid (encryptie/versleuteling) van de data en tegelijk zekerheid dat je met de juiste server praat (certificaten/PKI). Die beveiligde verbinding loopt tussen jou en een webserver. Als een bedrijf gebruik maakt van Cloudflare, Akamai of een andere CDN, dan is dat de webserver waar de TLS verbinding stopt. Dat bedrijf krijgt dus inzage in alle pagina's die je opent, gegevens die je zelf upload en ook alle webpagina's die je zelf voorgeschoteld krijgt. Wanneer zij zelf het antwoord niet weten wordt het verzoek pas doorgezet naar de echte servers van dat bedrijf. In sommige gevallen zelfs zonder TLS, waardoor je onterecht denkt dat je verbinding beveiligd is. Voordeel voor de echte eigenaar is dat de voorpagina gecached kan worden en dat scheelt veel bandbreedte. Daarnaast worden ook webaanvallen geblokkeerd en zijn grote CDN's minder vatbaar voor een DDOS omdat ze nu eenmaal een grote internetverbinding hebben.

In het geval dat een bank dus een klantomgeving - niet per se de hoofdwebsite - bij Akaimai/Cloudflare/... host, krijgen deze Amerikaanse bedrijven inzage in al jou financiele transacties. Immers komt die beveiligde HTTPS verbinding uit op hun servers, niet die van je bank.

Het gebruik van Cloudflare is vaak nog wel te herkennen in een certificaat. Maar bedrijven kunnen ook zelf een certificaat aanvragen en deze uploaden zodat hier niets aan te zien is. Zowel Akamai als Cloudflare kan je op dezelfde manier detecteren: door DNS naar de CNAME's en IP adressen te kijken. In het geval van Akamai is dat '*.edgekey.net' en voor Cloudflare 'cloudflare.net'.

Voorbeeldjes (kdig kan vervangen worden door dig, ./rdap door whois)

Akamai heeft een optie waarbij de TLS decryptie onder beheer van de bank blijft, en Akamai dus geen inzicht in de data krijgt.

Het antwoord is dus een onverwacht Nee.

Daarnaast is de DDOS bescherming niet noodzakelijkerwijs ook direct een TLS terminatie. Dus: paniek om niets.

Wat veel mensen niet weten is dat een "webpagina" niet 1 geheel is, maar bestaat uit vele elementen: HTML tekst,
stylesheets, scripts, plaatjes en ga zo maar door. En wat ze al helemaal niet weten is dat deze elementen op 1 pagina
helemaal niet van dezelfde server hoeven te komen! Dat betekent dat een bank best allerlei statische content kan
laten leveren door zo'n Content Delivery Network (CDN) zoals Akamai of Cloudflare, maar dat dat nog helemaal niets
zegt over de financiele gegevens. Zelfs al zie je die op dezelfde webpagina.
Je moet dan eerst precies uitvlooien wat precies van welke server komt. Alleen maar "www.bedrijfsnaam.nl" opzoeken
en dan de conclusie trekken "oh die zitten ook al daar en daar" dat is dus niet goed.

Dat DDOS bescherming geen TLS terminatie vereist klopt. Echter mis je dan alle web application firewall (WAF) en caching voordelen die dit soort diensten bieden. Het lijkt mij een hoogst ongebruikelijke configuratie voor een CDN, maar noodzakelijk is het inderdaad niet.

Dat 'TLS decryptie onder beheer van de bank' is marketing waar je je niet op moet verkijken. Cloudflare bied iets vergelijkbaars aan onder de naam 'keyless TLS' https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/. Als je goed kijkt hoe dit werkt, mag duidelijk zijn dat Cloudflare WEL toegang heeft tot alle data. Alleen NIET tot de prive sleutels van het certificaat, die blijven in een klant omgeving. (Voor deze use case zal in de toekomst waarschijnlijk subcerts gebruikt gaan worden.) Maar het idee dat Cloudflare geen toegang zou hebben tot de data omdat de bank de sleutels heeft, is niet dus juist. Hoe dit bij Akamai zit weet ik niet. Wat ik wel weet is dat je specifieke Akamai HTTP foutmeldingen krijgt bij o.a. Rabobank. Het mag duidelijk zijn dat Akamai daar dus wel degelijk toegang heeft tot bankieren.rabobank.nl , waar in ieder geval de inlogpagina op te vinden is.

Als correctie op mijn reactie hiervoor over bankieren.rabobank.nl ; ik meende gisteren wel degelijk de kenmerkende Akamai access denied te zien maar kan dat nu niet reproduceren. Wellicht dat deze op een andere website te zien was, dat de onversleutelde data via Akamai zou lopen is dus geen gegeven.

Nee, je weet niet of de TLS-verbinding daar stopt.
Het kan maar het hoeft niet.
Als het wel zo is dan zou de bank de privésleutel van het certificaat moeten delen delen met de clouddienst.
Maar voor het verwerken van DDOS aanvallen is dit niet nodig.
Wel leert de cloud misschien welk IP-adres bij welke bank is aangesloten, en hoeveel bankverkeer er met een bepaalde bank is. Maar dat ze het zo hebben opgezet dat clouddiensten mee kunnen lezen met de banktransacties lijkt me sterk,
dus daar zou ik niet te snel vanuit gaan.

Het is wel een zorg als 3 Nederlandse systeembanken gebruik moeten maken van één niet-Europese clouddienst.
Mocht er namelijk een ernstig internationaal conflict ontstaan dan zit je in de problemen als de toegang tot deze dienst wordt geblokkeerd. Echter de banken zeggen dat Akamai niet de enige partij is waar ze gebruik van (kunnen) maken.

En daar hebben de banken gelijk in. Immers ze hebben hun DNS niet daar ondergebracht, dus ze kunnen ieder moment
hun DNS recors omzetten naar andere servers. Misschien gebeurt dat zelfs volautomatisch, er zijn DNS providers die
je DNS records kunnen aanpassen als ze constateren dat de servers waar die heen wijzen niet beschikbaar zijn.
Dus misschien toch maar gewoon geloven wat de banken zeggen?

dit is je probleem, en ja dit kan prima decrypted worden .

mijn.ing.nl

Er wordt daar geen gebruikt gemaakt van DNS CAA.
Squid proxy kan dit decrypten b.v. vrij simpel.
Maar ja, dat is gemeld, maar er zitten pruters bij de bank.

https://www.ssllabs.com/ssltest/analyze.html?d=mijn.ing.nl&s=145.221.181.241&hideResults=on&ignoreMismatch=on
Prima score die A+ echter.

Geen DNS CAA.. dus kan ik deze via onze proxy server decrypten.

Vetgedrukt door mij.

Het klopt inderdaad gedeeltelijk: CDN's bieden ihkv. anti-DDos of Cloud-WAF de mogelijkheid om te decrypten. Dat is een bewuste keus van de klant (bank in dit geval). Daarvoor moeten de certificaten/private keys overgedragen worden aan de CDN.
Dit kan voor alles op de pagina, maar kan ook voor onderdelen (bv. statisch.bank.nl) die op www.bank.nl gepresenteerd worden.
Als de bank geen private keys overhandigd kan zo'n CDN bv. wel volumetrische DOS-en mitigeren (heeeel veel verkeer, al dan niet vanaf heel veel adressen), maar niet applicatieve DOS-en (bv. specifieke requests die resource depletion veroorzaken: immers de cloud-WAF kan niet in de encrypted stream kijken). Als bank moet je in dat geval een eigen WAF on-prem hebben om je betaal omgeving te beschermen.

Naast rechtstreeks overhandigen kan je de keys ook via HSM's beschikbaar stellen aan de decryptielaag: de CDN krijgt dan niet rechtstreeks de keys maar die blijven onder controle van de bank. Ofwel, de CDN kan bv. niet zo maar zelf een kopie van www.bank.nl maken en verkeer omleiden, of de keys aan criminelen verkopen...

Het is dus een keus van de bank.

Overigens is het niet zo dat als de private keys overgedragen zijn, iedereen bij de CDN zomaar ergens in kan kijken: hier zijn zware eisen, gecontroleerde afgeschermde omgevingen, specifieke PAM systemen en veelvuldige audits voor... De bank moet dit soort keuzes nl. ook weer naar de Nederlandse bank verantwoorden.

Q

Ze kunnen nog steeds de DNS omzetten , alleen via SIDN - ze zijn eigenaar van hun domeinen.

Als je DDoS bestendig wilt zijn, zul je ook heel erg robuuste DNS servers moeten gebruiken, want het heeft heel weinig zin als de site wel beschikbaar is maar de DNS eruit geflood wordt.

Gut gut gut. Alleen voor gebruikers die certificaat waarschuwingen negeren - of bij gebruikers bij wie je een eigen root CA geinstalleerd hebt.

Maar waarom beweer je dat je voor die mensen NIET zou kunnen decrypten als de ING DNS CAA zou gebruiken ?

Als je alles voor je gebruikers controleert en je hebt een MITM proxy , en clueless gebruikers dan wel managed clients met alle MITM CA's geinstalleerd kun je met hetzelfde gemak DNS CAA records uit de antwoorden slopen voor de clients, en ben je terug bij af - en natuurlijk blokkeer je rechtstreekse DNS lookups en DoH voor je gebruikers.

Akamai verkoopt meerdere producten.
Alleen het CDN product, waar je de TLS connectie dus op het laatst pas opbouwt naar de klant, zou dat mee kunnen.

Gewoon het anti ddos pakket? No way. Ze hebben geen idee wat de inhoud van de pakketten zijn (maar bv replay attacks kun je dan wel weer zien adhv de meta data).

Maar boeit het? Nee. Want ze hebben verwerkersovereenkomsten. En die zijn aardig dwingend over wat mag en niet op hele hoge boetes.

DNS CAA records worden alleen gecontroleerd bij het uitgeven van een nieuw certificaat. Zodra die uitgegeven is doet het niks meer. Het is geen certificate pinning / HPKP achtig mechanisme, enkel een manier om aan CA's aan te geven wie er certificaten voor een domein mogen uitgeven. Als je een squid proxy gebruikt met prive CA geinstalleerd op clients, dan gaat een CAA record hier niets tegen doen.

Kan iemand een duidelijklijk geven?

als het gaat om certificaten ... en je hebt 3 partijen [trusted certificat owner][company][client user]
if you have 2 pieces you can decript : see google or mutch spy organistion can do it

kijk naar cloudflare/akamai staan bij mij op de zwarte lijst ip ranges blocked nu kan het zijn dat programmeur zo dom zijn dat zij oneindige loops maken bij clienten als zij de spy proberen tegen te houden [script zijn meestal aangeleverd door het spy bedrijf](en meestal lijkt het oh sorry dat er een fout in zat)maar als je niet hoeft te betalen moet je niet klagen . Dan keer je terug naar de domme programmeur die dergelijk rotzooi gebruikt uit luiheid soms omdat het budjet er niet is.

Zie je cdn of share of mail... dan mag je denken hier is een knoeier aan het werk geweest. En dan is het antwoord ga naar een andere bank ... maar is er nog een bank die zo professioneel is (zij helpen oplichters binnen te raken door die gratis onbetrouwbare rotzooi)dit is niet het zelfde als code van een ander gebruiken zoals cms open source can je volledig doorkijken wordt niet veel gedaan maar er zijn mensen die het beoordelen.

en om een duidelijk antwoord te geven ja het kan.

Wat wil je daarmee zeggen? Wat waar ik bankier doen ze dat wel, maar een Squid proxy kan daar nog steeds gewoon tussen worden gezet. Moet je wel op de uiteindelijke clients ook een certificaat installeren, en dan kun je dus nimmer nooit het EV certificaat faken. En laat dat nou net zijn waar de bank op zijn inlogpagina mij elke keer vraagt dat even te controleren.

Conclusie: check gewoon altijd het certificaat, of gebruik de app (die doet dat zelf al). Geen probleem wie er dan tussen zit op de verbinding.

n.b. Het wordt wel tijd dat DNS CAA door de certificaat-uitgevers eens beter wordt gebruikt in de attendering, want op wat eigen domeinen wel eens expres wat verkeerds gedaan, nooit mails van gehad.

v.w.b. ING.nl: volgens https://crt.sh/?q=www.ing.nl heeft nooit iemand een fake certificaat gekregen wat met DNS CAA had voorkomen (altijd Entrust, KPN of Verisign, geen let's encrypt :P). 0 impact dus

Akamai en Cloudflare zijn beide Amerikaanse bedrijven. Dat betekend dat hier sprake is van een data transfer naar een derde land. Laat dat nu net illegaal zijn. Privacyshield is afgeschoten en alle SCC's die geen rekening houden met de surveillance wetgeving daar moeten worden stopgezet. Leuk dus zo'n verwerkersovereenkomst, maar dat wil niet zeggen dat het allemaal zomaar mag.

Ben er geen klant, maar wilde eens zien wat de ABN Amro zelf zou schrijven over deze data transfer. Ze zijn namelijk verplicht om hier melding van de maken in de privacy verklaring en als klant moet je kunnen nagaan of je gegevens wel goed beveiligd zijn. Op de website is het volgende te lezen:
In die laatste zin over een lijst van de EC is een link te vinden. Die wijst door naar de veilige landen volgens de Nederlandse asiel procedure. Geen grap, het is echt heel knullig. Misschien iemand die het niet helemaal snapte en de eerste de beste link naar iets over 'veilige landen' erin heeft gezet? Daarnaast is het totaal niet transparant naar welke landen er persoonsgegevens verstuurd wordt of welke extra waarborgen er genomen zijn. Het is werkelijk waar niet zo moeilijk om de AVG eens te lezen om te zien wat er wel en niet in zo'n privacyverklaring moet staan: https://gdpr-info.eu/art-13-gdpr/.

Je zou beter verwachten van een bank, maar helaas. Als je dit al in een paar minuten kan vinden vraag ik mij af hoe het met de rest zit...

Hier zit de stevige aanname dat er geen zaken wordt gedaan met een Europesche tak.

Als data EU niet verlaat, en daar hoeft helemaal geen sprake van te zijn, heb je weinig met de USA van doen.

Nu ken ik de infra van Akamai niet, maar ik kan mij zo voorstellen dat die best prima EU-only kan worden ingericht.

Maar waarom mail je hun privacy officer niet even en vraag je het (post het daarna ook even zodat we onze mening over het antwoord kunnen geven).

Akamai heeft aparte centers in London en Frankfurt, juist hiervoor

Als dat mogelijk is dan vallen de bezwaren over data transfers inderdaad weg. Ik verwacht zelf dat een Europeesche tak in de achterkant zelf een overeenkomst heeft met het Amerikaanse hoofdkantoor, net zoals Facebook Ierland dat bijvoorbeeld ook heeft.

Ik ben ook geen klant bij ABN Amro en mijn eigen bank maakt geen gebruik van dit soort (buitenlandse) diensten. Als iemand wel klant is bij ABN Amro dan zouden ze het zeker eens moeten navragen, het gaat immers om hun persoonsgegevens.

Bij internationale data transfers gaat om de vestigingslocatie van een bedrijf, niet om de precieze locatie waar een verwerking plaatsvindt. Dat laatste is uiteraard ook van belang, maar niet als de vraag is of er sprake is van doorgifte naar een derde land.

Deze twee kan je als klant van Akamai (de bank in kwestie die Akamai inhuurt voor anti-DDOS, niet de klant van de bank!) expliciet selecteren zodat data vanuit europa nooit europa verlaat. Ofwel een klant in Europa zal alleen via een scrubbing center van Akamai in Europa geleid worden en daarna afgeleverd worden bij de bank in Europa. Speciaal opgezet ivm. europese privacyregels

Weet iemand hoe dat met die zaak over de E-mail server van Microsoft in Ierland is afgelopen waar meen ik de NSA buitengewone interesse in had. Die yanks kunnen onder hun security acts een boel afdwingen hoor bij bedrijven. En ik sluit niet uit dat een "Anders doen wij met u geen zaken meer" soms al voldoende is.

weet iemand hoe je er achter komt of een bank hun private CA tls key hebben geupload bij Cloudflare/Akamai voor tls inspectie ?
klanten hebben toch recht om te weten hoe er met hun gegevens omggegaan wordt.
gewoon vragen aan ABN of Rabobank?

Heel simpel: kijk waar het IP adres waar jij tegen aan praat eindigt.
Bijvoorbeeld met urlscan.io.

Is dat Cloudflare of Akamai: daar is je antwoord.
Is dat de bank: dan doen die andere partijen niet met de versleutelde informatie.

Ja

Ik wil mijn vorige post (hierboven, 12-08-2020, 18:06) even corrigeren. Private keys moet natuurlijk Public keys zijn.


Jodocus 'Q' Oyevaer

Je kunt de vraag stellen, maar daar ga je geen antwoord op krijgen.

Je gaat ook niet te horen krijgen welke patches men gaat installeren op een machine.

Voor https://swa.sns.bank.nl gevonden 25% tracking en verder 31 verzoeken van sentry.io.
Geeft ontwikkelaars de nodige cross-site-zichtbaarheid.
1 tracker geblokkeerd van Adobe Analytics.

Ook dit nog qua code error

luntrus