Certifikat-brøler hos MitID gav usikker forbindelse: »Det må siges at være røde ører«

Så skal der foreligge en risikovurdering med konsekvens analyse, af netop den her del af løsningen. Igen vi snakker en hjørnesten i national IT sikkerhed her.

Databehandling (f.eks. transport) på krypterede data, er også databehandling. Og det kunne være meget relevant at se hvordan man har forholdt sig til GDPR Artikel 25 altså Databeskyttelse gennem design og databeskyttelse gennem standardindstillinger. Og især hvordan man forholder sig til

Taking into account <strong>the state of the art</strong>, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing

Og i den her kontekst er det vigtigt at huske på at vi snakker ikke kun confidentiality her, men også Integrity og Availability (og Accountability and Assurance).

// Jesper

Jeg har lige skruet et simpelt test-setup via cloudflare op: - Cloudflare er det jeg lige har adgang til ;-)

https://direct.cdn-test.alslug.dk

https://cdn-test.alslug.dk

Det er den samme site på begge adresser. Den sidste pipes bare gennem cloudflares CDN.

Kører man en curl -v $HOST giver det to forskellige certifikater.

henning@hp:~$ echo | openssl s_client -servername cdn-test.alslug.dk -connect direct.cdn-test.alslug.dk:443 2>/dev/null | openssl x509 -noout -fingerprint
SHA1 Fingerprint=01:24:DE:29:0B:49:AC:38:B5:03:1F:7F:F0:50:F0:6B:EA:25:83:E4
 
henning@hp:~$ echo | openssl s_client -servername cdn-test.alslug.dk -connect cdn-test.alslug.dk:443 2>/dev/null | openssl x509 -noout -fingerprint
SHA1 Fingerprint=F4:67:E4:15:79:D9:E0:4E:6D:D7:A6:7A:81:91:16:EB:95:92:99:CD

Dvs der ikke er den store tvivl om at cloudflare kan kigge med på forbindelsen. I praksis er det helt officielt muligt, da der kan køres scripts på edge-serveren hos CF.

Hvis CF ( som Akamai ) havde brugt LetsEncrypt, havde det været mere grumset, men man ville kunne se forskel i creation/expire-times på certifikaterne.

Men da vi ikke har adgang til MitIDs backend-servere kan vi ikke checke om der laves ssl-pass-throuh eller om den termineres hos Akamai. ( og som andre har skrive, vil der i princippet kunne skelnes på IP-basis om der skal pipes eller terminres )

/Henning

Akamai har ikke adgang til den private nøgle hos MitID. Hvordan skal de hermed kunne dekryptere data?

Nemt. Akamai forbinder til MitID's backend. Slutbrugeren forbinder til Akamai, Akamai wrapper responsen fra MitID i deres eget ssl, efter de har udpakket responsen fra MitID (da MitID jo forbinder til Akamai). Herimellem er der et mellemrum som ikke er pakket ind, eller det ved vi reelt set ikke noget om, men vi ved heller ikke om det ikke er tilfældet.

Det her bringer i øvrigt minder om dengang NSA opsnappede data fra google, der brugte lidt samme setup. Slutbrugeren forbandt til en reverse proxy med ssl, der servede google's interne backend til slutbrugeren, her var der dog ikke ssl. NSA fik så installeret en intercepter som lyttede med.

https://i0.wp.com/wp-blog-dir.s3.amazonaws.com/uploads/sites/27/2013/10/nsagoogle311013.gif?ssl=1

Akamai har ikke adgang til den private nøgle hos MitID. Hvordan skal de hermed kunne dekryptere data?

Nej, men den normale opsætning af CDN, gør at forbindelsen ikke terminres hos MitID, men derimod hos Akamai med deres egen nøgle, og du kan ikke se om det er MitID's nøgle eller Akamais nøgle der bruges - med mindredu har haft direkte forbindelse med MitIDs server, og har registreret hvilken fingerprint de forskellige nøgler har.

Problemet er at vi ikke ved, og ikke kan umiddelbart kan detektere hvad der sker i en amerikas-kontrolerede mellem-server.

Jeg er i hvert fald ikke tryg ved opsætningen.

/Henning

Når der browses på https, bruges der først PKI i dette tilfælde LC. MitID ligger inde med den private nøgle og browseren kan hente det public keypair. Efter etableret forbindelse mellem browser/server, forhandles en asymetrisk nøgle til sessionen.

Akamai har ikke adgang til den private nøgle hos MitID. Hvordan skal de hermed kunne dekryptere data?

NGINX kan anvende streams og derved lave SSL passthrough.

Herligt. Så blev jeg klogere på den del. Jeg var ikke bekendt med ngx_stream_core_module.

Tilbage står så spørgsmålet angående Akamai som underdatabehandler:

Vi anvender leverandøren Akamai til visse sikkerhedsmæssige driftsleverancer. Hvis sådanne driftsmæssige forhold derfor nødvendiggør det, kan behandling af persondata ske uden for EU

Enten er der SSL passthrough og så betragter man jonglering med IP adresser som behandling af persondata.

Eller også er der SSL terminering, og så kan persondata og transaktionsoversigten tilgås med 100% henførbarhed.

Uanset så har Jacob #60 ret. Når som helst og f.eks. per src IP adresse kan Akamai etablere et certifikat og terminere SSL.

Hvis Akamai får instruks fra en US efterretningstjeneste, så skal de etablere dette og må ikke sladre.

NGINX kan anvende streams og derved lave SSL passthrough.

Så vidt jeg ved, kan HAProxy også bruges til at lave SSL Pass Through, hvor den ved hjælp af SNI kan fordele trafikken, også via en delt IP adresse.

En Pass Through ville betyde at Akamai kun kan beskytte mod angreb, baseret på kilde IP Adresser, og ikke indhold, som der også blev nævn tidligere i tråden.

Men hvad forhindrer Akamai i at udstede et nyt, domain-valideret / HTTP-01 certifikat i morgen, hvorefter de kan terminere SSL lokalt, og dermed opsnappe data? Med lidt mere info, kunne det endda ske baseret på kilde IP Adresse.

Jeg håber også at du omvendt kan se at f.eks. Nginx ud af boksen fungerende som frontend server faktisk terminerer SSL og kører seperate krypterede forbindelser til backend servere. Og dermed har adgang til ukrypteret trafik.

NGINX kan anvende streams og derved lave SSL passthrough.

...ser i øvrigt ikke ud til at være sat for mitid.dk og er derfor heller ikke preloadet. Til gengæld returnerer www.mitid.dk hele 2 HSTS-policies med forskellige parametre. Det burde kunne gøres bedre.

Derfor har Akamai adgang til adresse, CPR, telefonnummer og listen over MitId aktiviteter mindst for alle borgere som logger in med MitId i browseren.

B) hvorledes skal browseren handshake med backend uden Akamai lytter med, medmindre al trafik forwardes og Akamai ikke selv besidder SSL certifikatet for domænet?

Ved cloudflare hedder det Keyless SSL. Det løser problematikken med at give sine private keys til tredjemand, men ikke at terminere SSL hos CDN.

Se også https://www.cloudflare.com/learning/ssl/keyless-ssl/

Jeg håber også at du omvendt kan se at f.eks. Nginx ud af boksen fungerende som frontend server faktisk terminerer SSL og kører seperate krypterede forbindelser til backend servere. Og dermed har adgang til ukrypteret trafik.

Det er ikke ualmindeligt, at firmaer terminerer den sikre forbindelse for at kunne scanne for, hvad de nu synes at de bør scanne for. Noget Hækkerupsk med overvågning giver tryghed ... eller noget.

Pas generelt på at stole for meget på fortroligheden, hvis der er andre, som kan bestemme, hvordan din browser er sat op.

Hvad der foregår på bagsiden af proxien kan du ikke se, og her benyttes bl.a. tunnelering af SSL.

SSL passthrough beskrives her, og jeg formoder at det er det du omtaler som SSL tunnelling:https://avinetworks.com/glossary/ssl-passthrough/

Og i det tilfælde kan Akamai ikke cache noget som helst og selvfølgelig heller ikke se data, eller bot-filtrere på layer 7.

The data passes through fully encrypted, which precludes any layer 7 actions.

Men i det tilfælde adskiller Akamai sig ikke fra andre ISPer eller carriers. Så hvorfor skal Akamai stå som underdatabehandler?

Jeg kan godt se at ved SSL passthrough, så kan man stadig benytte Lets Encrypt til certifikatet, da backendserveren modtager LE validerings requestet og ikke frontendserveren hos Akamai. Og derfor er min tidligere argumentation ang. LE ugyldig hvis passthrough benyttes.

Jeg vil stadig meget gerne vide om MitId benytter SSL passthrough eller om Akamai terminerer SSL.

Jeg håber også at du omvendt kan se at f.eks. Nginx ud af boksen fungerende som frontend server faktisk terminerer SSL og kører seperate krypterede forbindelser til backend servere. Og dermed har adgang til ukrypteret trafik.

Jeg afprøvede lige mine søgemaskine-evner. De kunne finde oplysninger om .....

• ..... hvordan man kan sætte en proxy-server op til også at lade browseren snakke med en https-server. Mao en helt normal proxy på en server et eller andet sted som jeg vil bruge som trinbræt ud i verden. Det er ikke interesant i denne sammenhæng.

• .... opsætning af reverse-proxy. men kun hvor forbindelsen termineres på proxyen, og trafikken sendes videre til backenden. Det er den problematiske løsning hvor proxyen kan kigge med i trafikken. Cloudflares beskrivelse på https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/ siger det hele:

  A reverse proxy is a server that sits in front of one or more web servers, intercepting requests from clients. This is different from a forward proxy, where the proxy sits in front of the clients. With a reverse proxy, when clients send requests to the origin server of a website, those requests are intercepted at the network edge by the reverse proxy server. The reverse proxy server will then send requests to and receive responses from the origin server.

• .... opsætning af reverse-proxy, hvor ssl'en ikke termineres på proxyen kunne jeg ikke finde noget om.

Dermed ikke sagt at det ikke er muligt, men mon ikke der er nogen derud som har lavet det, og skrevet om det, hvis det er muligt?

/Henning

kan vi nu ikke snart få lagt det forpestede www i graven?

For mig ser det ud som et helt normalt (evt caching) proxy-setup der benyttes.

Ja, det er et helt almindeligt setup, hvor IP adresserne er spredt ud over jordkloden. Det gør man ikke kun af load-mæssige årsager, men også for at tilgodese en lettere transport til roamede mobiltelefoner, som breaker ud lokalt, men som bevarer sin danske IP adresse i nettet.

Hvad der foregår på bagsiden af proxien kan du ikke se, og her benyttes bl.a. tunnelering af SSL. Caching af ikke krypteret variabelt indhold, og indhold hvor cachen er udløbet, hentes selvfølgelig også direkte fra back-end serverne. Så ingen grund til bekymring af den grund.

de to ip-adresser 95.100.155.161 og 95.100.155.168 udelukkende kan bruges til mitid.dk

Jeg checkede lige en host www.mitid.dk fra de forskellige steder ude i verden jeg har adgang til servere:

Via Kviknet:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 2.23.172.123
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 2.23.172.187
Via Stofa fiber:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.161
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.168
Via Hetzner i Helsinki og Falkenberg:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 96.16.49.34
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 96.16.49.58
Via Hetzner i Nurnberg:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 104.126.37.43
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 104.126.37.48
Via Yourserver.se:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 23.36.162.68
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 23.36.162.71
Via linode i london:
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.101.143.241
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.101.143.163

For mig ser det ud som et helt normalt (evt caching) proxy-setup der benyttes. Men jeg vil da blive glad for at tage fejl.

/Henning

Det er fordi du ikke forstår - eller vil forstå - hvad SSL tunnellering er og hvordan det bruges.

Alright:) Godt ord igen, Hr. Jeg vil faktisk mægtig gerne forstå, og er interesseret i hvorledes man i praksis sætter den slags op på Akamai.

Lad os håbe de forskellige henvendelser kan give agtindsigt i opsætningen.

Jeg håber også at du omvendt kan se at f.eks. Nginx ud af boksen fungerende som frontend server faktisk terminerer SSL og kører seperate krypterede forbindelser til backend servere. Og dermed har adgang til ukrypteret trafik.

Men jeg kan ikke se hvorledes de ikke nødvendigvis håndterer dekrypteret trafik.

Den eneste mulighed for at de kan lave noget tunneling, er hvis de laver en ren port-forwarding.

Ikke korrekt.

Der er intet - som i absolut intet - belæg for at konkluderer noget i den retning, ud fra hvad der er oplyst.

Hey man, jeg vil ligesom dig gerne vide hvordan det i virkeligheden fungerer. Og hvis jeg tager fejl æder jeg en fastelavnsbolle:)

Men at sige der ikke er belæg for SSL terminering for CDNer er kontrafaktuelt.

Og digst angiver Akamai som databehandler.

Heldigvis sker SSL kryptering end-to-end. Certifikatet bruges alene til at authentikere serveren. Så Akamais håndterer ikke ukrypterede slutbruger data.

Den eneste mulighed for at de kan lave noget tunneling, er hvis de laver en ren port-forwarding.

Dvs at ....

henning@nx7400-6:~$ host <a href="http://www.mitid.dk">www.mitid.dk</a>
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.161
<a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.168

de to ip-adresser 95.100.155.161 og 95.100.155.168 udelukkende kan bruges til mitid.dk

Hvor finder vi en service som kan finde ud af hvlike domins der peger på de to IP'er? Hvis der er andre der peger på dem KAN de ikke køre ren port-forwarding, for de ikke kigger med på forbindelsen.

/Henning

Alle disse spekulationer om diverse tekniske forhold og protokoller og som bruger af disse infrastrukturer, og er vi ikke alle det, får mig til at spørge: Er der nogen, der VED, hvordan det foregår, og om disse MITM servere har adgang til trafikken eller ej? Og ikke flere spekulationer, tak.

Jeg er fuldstændig enig. At postulere at MitID løsningen er usikker på basis af en begynderfejl på fornyelsen af et servercertifikat er forkert. Som jeg skrev ovenfor: Det farligste er at postulere, at man ved noget hvis man ikke gør det.

Jeg har prøvet at give mit bidrag baseret på hvordan proxy servere normalt virker, og ud fra den viden vil jeg være tryg ved at bruge MitID. Påstanden om man-in-the-middle angreb og Akamai som skjult SSL inspector, er for mig at se fuldstændig fri fantasi grebet ud af luften. Der er intet - som i absolut intet - belæg for at konkluderer noget i den retning, ud fra hvad der er oplyst.

Om formålet med en sådan misinformation er at skabe frygt, mistillid til løsningen, eller bare generel samfundsmæssig destabilisering - eller ren og skær stædig uvidenhed - er svært at vide.

Jeg har lige fået at vide, at jeg skal skifte til MitID, ellers bliver jeg udelukket fra netbanken. Så må jeg jo overveje, hvad der er det største onde.

Alle disse spekulationer om diverse tekniske forhold og protokoller og som bruger af disse infrastrukturer, og er vi ikke alle det, får mig til at spørge: Er der nogen, der VED, hvordan det foregår, og om disse MITM servere har adgang til trafikken eller ej? Og ikke flere spekulationer, tak.

Det har jo stor betydning for troværdigheden, om uvedkommende kan lytte med og evt. ændre trafikken, når vi sender 100 kr til moster Oda eller sælger vore hus.

Artiklen viser også hvordan CDN "visitor" siden forwarder SSL handshaket (Client hello / Server hello) direkte igennem til origin.

Det kan meget vel være jeg tager fejl, men jeg ser ingen steder i artiklen at dette er tilfældet.

Jeg læser at klienten forhandler med CDN særskilt. Hvilket også er standard opsætningen i f.eks. Nginx og Googles load balancers:

https://cloud.google.com/load-balancing/docs/ssl

Jeg vælger at tro, at der er tale om rene spekulationer, og at Akamai agerer fornuftigt som SSL tunnelerings proxy.

Jeg håber også at løsningen ikke på nogen måde gør det muligt for Akamai frontend serveren som modtager HTTPS requestet:

1. at dekryptere request fra browseren
2. at dekryptere response fra backenden

Men med nuværende opsætning gætter jeg stadig på at både 1 og 2 er tilfældet, ligesom alle andre opsætninger af frontendservere jeg har set.

Jeg formoder at Akamai kører Nginx med automatiseret Lets Encrypt certificering og almindelig proxy_set_header og proxy_pass mod backend-servere/backend-loadbalancers hos MitId leverandøren via https som så er firewallet passende.

Og i det tilfælde kan Akamai læse alle de nævnte persondata.

Der er desuden to argumenter man skal overveje.

A) hvis Akamai forwarder al trafik fra IP adressen og ikke kan SSL terminere, hvad præcis for en service tilbyder Akamai da så?

B) hvorledes skal browseren handshake med backend uden Akamai lytter med, medmindre al trafik forwardes og Akamai ikke selv besidder SSL certifikatet for domænet? Og det må formodes de besidder LE certifikatet da LE leverer certifikater der valideres mod IP adressen registreret for domænets A records. Og IP adressen er Akamais.

Den eneste årsag til at HTTP/S CDNer og Loadbalancers ikke betragtes som MITM angreb er fordi en underdatabehandler aktivt har valgt at benytte dem. Men jeg kan ikke se hvorledes de ikke nødvendigvis håndterer dekrypteret trafik.

Årsagen til at diverse routers og switches på vejen fra og til klient hhv. backend ikke skal angives som underdatabehandlere er fordi de typisk ikke SSL terminerer.

With all due respect, men når det er noget digitaliseringsforstyrrelsen er rodet ind i, så vil jeg mene at det er mere end farligt at forlade sig på tro.

Ja, måske - men så må forstyrrelsen søge hjælp. Det farligste er nok at postulere, at man ved noget hvis man ikke gør det.

Jeg vælger at tro,

Således dekrypterer CDN trafikken fra backend for at kryptere den igen i retning mod klienten (browseren der requester)

CDN serveren kører SSL tunneling imod origin. CDN har intet behov for at intercepte SSL trafikken. Krypteringen mellem CDN og origin sikrer, at ikke-krypteret trafik mellem parterne ikke kan kompromitteres.

Artiklen viser også hvordan CDN "visitor" siden forwarder SSL handshaket (Client hello / Server hello) direkte igennem til origin.

Hvis det kan dokumenteres, at Akamai er sat up så tjenesten agerer SSL inspection proxy, er der tale om et ekstremt alvorligt sikkerhedsbrud, og løsningen bør stoppes omgående. Jeg vælger at tro, at der er tale om rene spekulationer, og at Akamai agerer fornuftigt som SSL tunnelerings proxy.

Udgangspunktet er, at proxien hele tiden har en live session med origin serveren

Artiklen viser så vidt jeg læser, at det er forskellige certifikater mellem klient-CDN hhv. CDN-backend.

Således dekrypterer CDN trafikken fra backend for at kryptere den igen i retning mod klienten (browseren der requester)

Den live session henviser til at der ikke skal genforhandles TLS for hvert request fra samme frontend server til samme backend server.

Benyttes Akamai med dette setup er alle nævnte persondata læsbare for Akamai.

Kan du ikke henvise til hvorledes Akamai tager imod et HTTPS request og formidler det til backendserveren uden at kunne dekryptere requestet (og som bonus sikrer at browseren ved at den kommer fra en backendserver man kan stole på) ?

Der er en udmærket forklaring her: https://www.imperva.com/learn/performance/cdn-and-ssl-tls/

Udgangspunktet er, at proxien hele tiden har en live session med origin serveren, men kun nøgler udveksles. Først når sessionen committes, opdaterer proxien sin origin.

!

SSL er et public key system, som benytter to forskellige nøgler i hver retning.

Yes. Der er en public + private nøgle_A_browser og en public+private nøgle_A_server. Så der er faktisk mindst 4 nøgler, og de udskiftes on the fly. Men det er et nøglesæt etableret mellem browser og webserver (Akamai) som sikrer at enhver pakke er krypteret i transit og kan valideres kommer fra den korrekte modpart.

Kan du ikke henvise til hvorledes Akamai tager imod et HTTPS request og formidler det til backendserveren uden at kunne dekryptere requestet (og som bonus sikrer at browseren ved at den kommer fra en backendserver man kan stole på) ?

Browser forbinder til CDN med et request med nøgle A
CDN dekrypterer request med nøgle A

SSL er et public key system, som benytter to forskellige nøgler i hver retning. Et sæt til afsendelse og et sæt til modtagelse. SSL sørger for, at begge parter kan udveksle nøgler så de kan kommunikere fortroligt med hinanden i begge retninger.

Browsere bruger altid SSL. Og browseren kontrollerer altid serverens authentitet ved at checke serverens certifikat. Det checkes typisk op imod udstederen. Hvis certifikatet er revoked får man rød hængelås og en adsvarsel som den der illustrere artiklen.

Nøgler til SSL er 99% sikkert genereret hos Akamai og ikke hos Statens IT eller hvor selve origin serverne står.

SSL nøgler genereres i browser og server og der genereres et nyt set ved hver ny session.

Nej. Serveren står hos MitID udbyderen, eller i driftscentre udpeget af ham. Akamais sørger for forbindelsen fra offentlighedn til disse servere.

En simpel opsætning af CDN forløber således:

Browser forbinder til CDN med et request med nøgle A

CDN dekrypterer request med nøgle A og forbinder til backend med request og nøgle B

Backend svarer med request krypteret med nøgle B

CDN dekrypterer med nøgle B

CDN krypterer og svarer browser med nøgle A

Det er selvfølgelig 100% afgørende om dette er tilfældet eller ej. Og jeg er meget meget nysgerrig på om opsætningen er anderledes således at der er krypteret fra backend til browser.

Såfremt der er krypteret fra backend til browser, så kan CDN ikke benytte hverken URL eller andre headere til vurdering af spamvektorer.

Er der nogen som kan pege til en dokumentation, som viser hvorledes Akamai kan konfigureres som frontend server og servere data fra backend uden at Akamai kan dekryptere data?

Nej. Serveren står hos MitID udbyderen, eller i driftscentre udpeget af ham. Akamais sørger for forbindelsen fra offentlighedn til disse servere.</p>
<p>Krypteringsnøglerne til selve SSL sessionen genereres i hhv. server og browser pr. session, og har ikke noget at gøre med serverens authentikerings certifikat.

Uanset om du har ret eller ej, (og det har du nok) så har dataansvarlige siden juli 2020 haft bevisbyrden.

Enig. Og det er mere omfattende end det. MitID er en del af en kritisk infrastruktur og skal dermed følge NIS-direktivet (direktiv 2016/1148/EU). Det betyder anmeldelsespligt til CFCS.

Og som følge af bekendtgørelse nr. 258 af 22. februar 2021 om oplysnings- og underretningspligter vedrørende net- og informationssikkerheds §§ 3 og 4, skal aftaleforhandlinger om kritiske netkomponenter (som en datatransportør som Akamai er) også (formodentlig) anmeldes til CFCS. Jeg er ikke jurist, så jeg kan tage fejl, men jeg håber da, at CFCS er opmærksom på MitID som nationalkritisk infrastruktur.

Umiddelbart ser det ud til at alle der benytter Nets eID (https://broker.signaturgruppen.dk/) broker benytter Akamai. F.eks. peger disse bank host names:

hvidbjergbank.mitid.dk lpb.mitid.dk danskeandelskassersbank.mitid.dk

på

hvidbjergbank.mitid.dk. 592 IN CNAME mitid.netseidbroker.dk. mitid.netseidbroker.dk. 34 IN CNAME netseidbroker.mitid.dk.edgekey.net. netseidbroker.mitid.dk.edgekey.net. 1830 IN CNAME e106975.b.akamaiedge.net. e106975.b.akamaiedge.net. 20 IN A 95.100.155.240 e106975.b.akamaiedge.net. 20 IN A 95.100.155.194

BEC fremgår ikke selv på listen over brokers (se https://digst.dk/it-loesninger/mitid/nyheder-om-mitid/nyheder-fra-2021/ti-brokere-i-mitid/), så det kunne tænkes at alle banker der benytter BEC's systemer bruger Nets eID broker dvs. Akamai...

Hyggeligt når man skal logge på sin netbank hos LPB :-(

Uanset om du har ret eller ej, (og det har du nok) så har dataansvarlige siden juli 2020 haft bevisbyrden. Det er altså op til Digitaliseringstyrelsen at dokumentere at Akamai ikke kan læse data.

Og det er Akamais server.

Nej. Serveren står hos MitID udbyderen, eller i driftscentre udpeget af ham. Akamais sørger for forbindelsen fra offentlighedn til disse servere.

Krypteringsnøglerne til selve SSL sessionen genereres i hhv. server og browser pr. session, og har ikke noget at gøre med serverens authentikerings certifikat.

Jeg bad i december digitaliseringstyrelsen om at forklare deres brug af Akamai og midt i januar bad de om yderligere 14 dage til at undersøge sagen.

De er nu udløbet så jeg laver anmeldelse til Datatilsynet i denne uge.

Så Akamais håndterer ikke ukrypterede slutbruger data.

SSL kryptering end-to-end forløber fra browseren til serveren som holder certifikatet.

Og det er Akamais server.

For at Akamai kan sende mig data som jeg kan dekryptere, så skal de være i besiddelse af denne data ukrypteret.

Den eneste måde Akamai ikke har adgang til ukrypteret persondata, er hvis browseren javascripttid handshaker med backend via Akamai og derefter kommunikerer assymmetrisk krypteret, så Akamai blot videresender krypterede objekter via en krypteret kanal.

Men det gør de ikke.

Inspect requests i din browser, og du kan se at data er krypteret i transit, men modtages ukrypteret.

Derfor har Akamai adgang til adresse, CPR, telefonnummer og listen over MitId aktiviteter mindst for alle borgere som logger in med MitId i browseren.

Det er ubegribeligt!

Dvs. Akamai modtager data fra MitId backend, formodentlig krypteret i transit, men ukrypteret på Akamais servere inden data sendes krypteret til klientens browser.

Heldigvis sker SSL kryptering end-to-end. Certifikatet bruges alene til at authentikere serveren. Så Akamais håndterer ikke ukrypterede slutbruger data.

For mere end 10 år siden overvågede jeg SSL-certifikaterne på et større offentligt site jeg var ansvarlig for med værktøjet Xymon.

Da der kom advarsel om udløb af certifikaterne en måned før udløb adviserede jeg de ansvarlige om at certifikaterne skulle forlænges. Da der kun var en uge til udløb rykkede jeg med en kraftigere formulering og et par dage før 'katastrofen' ringede jeg til kontorchefen og gjorde klart hvad der ville ske. Det virkede, mindre end 24 timer efter var certifikatet forlænget. Utroligt at ingen har overvåget MitId certifikaterne for man skal naturligvis overvåge alle sine certifikater, Xymon er gratis.

I MitID_Privatlivspolitik_v1_2.pdf som kan downloades fra MitId.dk skrives:

Vi anvender leverandøren Akamai til visse sikkerhedsmæssige driftsleverancer. Hvis sådanne driftsmæssige
forhold derfor nødvendiggør det, kan behandling af persondata ske uden for EU, hvorfor der er sikret
overførselsgrundlag for denne eventuelle kortvarige behandling.

Al trafik går via www.mitid.dk til Akamais frontend servere og krypteres af LE certifikat, som er udstedt til Akamai.

Dvs. Akamai modtager data fra MitId backend, formodentlig krypteret i transit, men ukrypteret på Akamais servere inden data sendes krypteret til klientens browser.

Al diskussion om LE certifikaters (u)fortræffeligheder eller Helsingørs brug af Google Sheets for 3.klasserne er fuldstændigt ubetydelig iforhold til at det mest centrale authentikeringstrin for alle væsentlige digitale borgertransaktioner ligger læsbart for Akamai.

Jeg vil virkelig gerne vide hvilke databehandleraftaler og overvejelser MitId har på plads for at understøtte denne konstruktion!

Why Let’s Encrypt is a really, really, really bad idea…

På www.mitid.dk benyttes der rigtigt nok et Lets Encrypt certifikat, men det var ikke udløbet i går. Kun på det sekundære domæne mitid.dk der viderestiller til www.mitid.dk.

Burde hedde "Why monocultures/monopolies are bad". Problemet er ikke Let's Encrypt.

Det er jeg fuldstændig enig i, og det er også noget af budskabet i artiklen. Men i forholdet til debatten her, er det jo så MitID som får problemet. Og dermed får alle brugere af MitID potentielt problemet - også selv om det ikke er LE's skyld.

Why Let’s Encrypt is a really, really, really bad idea…

Burde hedde "Why monocultures/monopolies are bad". Problemet er ikke Let's Encrypt.

Why Let’s Encrypt is a really, really, really bad idea…

Hmm, det burde nok snarere ligge i systemet, at der inden der er gået tre år, skal udsendes en advarsel om at certifikatet skal skiftes. Og denne advarsel skal gensendes indtil det er bekræftet, at løbetiden igen er tilpas lang, hvorefter advarslen skal nulstilles indtil næste gang det er tæt på at udløbe.

Så vidt jeg husker så satte vi cron jobs op i min gamle virksomhed, som i god tid sendte mails om at domæne X snart skulle have fornyet sit SSL-certifikat. Altså efter det var gået galt 1-2 gange.

Vores lokale ISP plejer at opdage at deres mailserver-certifikat skulle have været opdateret hver 3. måned, når kunderne ringer og klager.

Her til aften ville jeg færdiggøre installationen af mitid og da jeg skulle bekræfte min aktivering fortalte appen at jeg ikke har internet forbindelse. Hvilket jeg har. Kan se andre har haft dette problem tidligere på dagen, så det har nok stået på siden middag. Nogle gange kan appen slet ikke få fat i noget og så står timeglasset bare snure rundt. Det er godt nok ikke betykkende det her.

Det er <a href="http://www.mitid.dk">www.mitid.dk</a&gt; som går igemmen Akamais CDN.

Dvs din browsers krypterede forbindelse går til Akamai server, som kigger på den og sneder requesten videre til MitIDs servere.

• mitid.dk peger på en server ved Statens IT.
• www.mitid.dk peger på Akamai.
• mitid.dk (Statens IT) redirecter til www.mitid.dk (Akamai) vha. en 301.

Udover DDoS er det til gengæld ikke tydeligt hvorfor Akamai skal ind over. Men det er vel også en ret fornuftigt antagelse. Jeg ville så ønske at de havde noget andet end LE. Der må være nogen et-eller-andet sted indenfor staten, som forholdsvist billigt kan udstede et "rigtigt" certifikat.

Jeg gætter på, at Akamai benyttes til DDoS-beskyttelse og evt. webapplikationsfirewall.

Det gør den helt sikkert, men ændrer ikke noget ved at de er nød til at lykke med på forbindelsen for at kunne gøre det store.

Og dermed kan de principielt lytte med på forbindelsen.

/Henning

Dvs din browsers krypterede forbindelse går til Akamai server, som kigger på den og sneder requesten videre til MitIDs servere.

Jeg gætter på, at Akamai benyttes til DDoS-beskyttelse og evt. webapplikationsfirewall.

Har MitID et "tempcert" lige nu, eller hvad?

Tja. Hvad blev brugt tidligere?

Kan se at www.mitid.dk ikke er alene om at køre med LetsEncrypt, og til dels CDN.

Både jyskebank.mitid.dk od sydbank.mitid.dk (begge på bankdata) bruger også LetsEncrypt

danskebank.mitid.dk bruger GlobalSign

danskeandelskassersbank.mitid.dk kører også via Akamai dvs LetsEncrypt

/Henning

MitID er lidt vigtigere, så det burde stå i nogens "jobplan" at huske at opdatere certifikaterne!

Hvis man overlader noget så vigtigt til en enkelt medarbejders jobbeskrivelse, så brænder lokummet så snart den pågældende forsvinder. Hvilket, bortset fra sygdom og den berømte bus, også må forventes at kunne ske med så lange mellemrum mellem hændelser.

Det er ikke direkte betryggende, men måske Akamai bare er billigst til at lave en 301? Hvis Digitaliseringsstyrelsen alligevel aldrig vil benytte andet end <a href="http://www.mitid.dk">www.mitid.dk</a&gt;, så kommer der vel aldrig andet end et ikke-brugbart token gennem mitid.dk.

Nej.

Det er www.mitid.dk som går igemmen Akamais CDN.

Dvs din browsers krypterede forbindelse går til Akamai server, som kigger på den og sneder requesten videre til MitIDs servere.

Din forbindelsen er IKKE krypteret hele vejen til MitIDs servere, så rent principielt har Akamai mulighed for at kigge med i din kommunikation.

Det er også derfor at der er et LetsEncrypt certificat på forbindelsen i stedet for et fra Statens IT

/Henning

Igen noget skrald med quotes :-(

Det må du nok sige!

Det er lissom med brandalarmer på køkkentrapper, der hyler, hvis batteriet ikke er skiftet i tide (eller bare er surt). Alle alarmer i opgangen hyler - i det lange løb tager folk dem ikke alvorligt. Heldigvis blev nmogen så nervøse, at de fik Brandvæsenet til, at tjekke om noget brændte - det gjorde det ikke, men ...

MitID er lidt vigtigere, så det burde stå i nogens "jobplan" at huske at opdatere certifikaterne!

Har MitID et "tempcert" lige nu, eller hvad?

men hvorfor fa**** skal den forbi et CDN som kan kigge med?

Men det er vel i virkeligheden også en god forklaring på, hvad der er fejlet. Statens IT har skiftet et certifikat som var ved at udløbe, men de ansvarlige ved Digitaliseringsstyrelsen/DanID har glemt at Akamai står for "halvdelen" af domænet.