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

31. januar kl. 14:2166
Certifikat-brøler hos MitID gav usikker forbindelse: »Det må siges at være røde ører«
Illustration: Screenshot.
MitID-brugere blev mandag morgen mødt med en advarsel om usikker forbindelse, når man forsøgte at tilgå hjemmesiden. Grunden var, at man ikke havde forlænget SSL-certifikatet.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Artiklen er opdateret kl 15:57 med et skriftligt svar fra Digitaliseringsstyrelsen.

Da it-sikkerhedsekspert Peter Kruse ville logge ind på MitID i morges, blev han mødt af en advarsel om, at forbindelsen til hjemmesiden var usikker. Han tjekkede, om SSL-certifikatet mon var udløbet, og rigtigt nok udløb det natten til søndag, nærmere bestemt lørdag d. 29. januar 2022 kl 23:59:59.

Det fik ham til at sende et tweet ud, hvor han referer Homer Simpsons’ ikoniske ”doh” lyd.

»Det må siges at være røde ører,« siger Peter Kruse, der er medstifter af it-sikkerhedsvirksomheden CSIS Security Group.

Artiklen fortsætter efter annoncen

»Det er særlig uheldigt, når det er et projekt med et budget på så mange millioner, der skal levere kritisk infrastruktur til det offentlige såvel som det private.«

SSL-certifikatet verificerer en hjemmesides identitet og aktiverer en krypteret forbindelse, så kriminelle bliver forhindret i at få fat i data.

En forlængelse tager ikke mere end én time for en person, der ved, hvad vedkommende laver, fortæller Peter Kruse.

Han mener, at certifikatet højst sandsynligt er blevet udstedt til www.mitID.dk (som virker), og så har man glemt at opdatere mitID.dk (som er ramt).

»Det skader MitIDs troværdighed for forbrugeren og kan skabe forvirring for folk, om de har gjort noget forkert, hvis de bliver mødt med en advarsel. Samtidig kan man heller ikke være sikker på, at det indhold man ser, bliver leveret af den leverandør, man gerne vil have,« siger Peter Kruse.

»De to ting skaber utryghed.«

Peter Kruse var ikke den eneste, der lagde det manglende certifikat ud på sociale medier.

Digitaliseringsstyrelsen skriver følgende i et skriftligt svar til Version2:

»Fejlen viser sig ved, at man får en fejlmeddelelse, når man vil tilgå MitID’s website, hvis man benytter webadresserne MitID.dk eller https://MitID.dk. De to webadresser omdirigerer normalt brugerne til sitet https://www.MitID.dk, men eftersom certifikatet er udløbet, omdirigeres man i øjeblikket ikke men får i stedet vist en advarselstekst.

Hvis man besøger hjemmesiden ved at skrive www.MitID.dk – det vil sige at man skal skrive www foran i adressefeltet – så vises siden på almindelig vis. Siden kan således stadig tilgås ved at skrive den fulde adresse. Der er bestilt et nyt certifikat, og der bliver arbejdet på højtryk for, at det igen vil være muligt at tilgå siden via adresserne MitID.dk eller https://MitID.dk. I mellemtiden opfordrer vi til, at man i stedet benytter adressen www.MitID.dk.«

Opdatering: 16:05. I en ny mail oplyser Digitaliseringsstyrelsen, at certifikatet er blevet opdateret. En pressemeddelelse er også blevet sendt ud.

66 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
66
7. februar kl. 14:46

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

Jeg har brugt den Engelske version og highlightet state of the art.

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

65
3. februar kl. 21:55

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.

  1. 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
  2. SHA1 Fingerprint=01:24:DE:29:0B:49:AC:38:B5:03:1F:7F:F0:50:F0:6B:EA:25:83:E4
  3.  
  4. henning@hp:~$ echo | openssl s_client -servername cdn-test.alslug.dk -connect cdn-test.alslug.dk:443 2>/dev/null | openssl x509 -noout -fingerprint
  5. 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

64
3. februar kl. 20:50

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

63
3. februar kl. 20:24

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

62
3. februar kl. 20:00

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?

61
2. februar kl. 10:07

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.

60
2. februar kl. 05:46

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.

58
1. februar kl. 21:32

...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.

57
1. februar kl. 20:35

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

MitID er dog bygget til at minimere persondata, så man kan f.eks. ikke få personnumre gennem MitID. Har man brug for et personnummer som offentlig myndighed skal man gå gennem NemLog-in (nemlog-in.mitid.dk, Sectigo CA, hostet af NNIT). Private virksomheder kan alene kontrollere om et givent UUID har et givent personnummer. Adresse og telefonnummer er heller ikke noget som udveksles via MitID.

55
1. februar kl. 19:23

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.

54
1. februar kl. 18:53

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.

53
1. februar kl. 18:33

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

52
1. februar kl. 18:25

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

51
1. februar kl. 17:31

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.

50
1. februar kl. 17:17

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:

  1. Via Kviknet:
  2. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 2.23.172.123
  3. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 2.23.172.187
  4. Via Stofa fiber:
  5. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.161
  6. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.168
  7. Via Hetzner i Helsinki og Falkenberg:
  8. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 96.16.49.34
  9. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 96.16.49.58
  10. Via Hetzner i Nurnberg:
  11. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 104.126.37.43
  12. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 104.126.37.48
  13. Via Yourserver.se:
  14. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 23.36.162.68
  15. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 23.36.162.71
  16. Via linode i london:
  17. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.101.143.241
  18. <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

49
1. februar kl. 17:14

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.

46
1. februar kl. 17:07

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 ....

  1. henning@nx7400-6:~$ host <a href="http://www.mitid.dk">www.mitid.dk</a>
  2. <a href="http://www.mitid.dk">www.mitid.dk</a> has address 95.100.155.161
  3. <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

45
1. februar kl. 17:03

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.

44
1. februar kl. 16:51

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.

43
1. februar kl. 16:46

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.

42
1. februar kl. 16:27

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.

40
1. februar kl. 16:12

Jeg vælger at tro,

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.

39
1. februar kl. 15:49

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

Nej, det er ikke det der sker.

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.

38
1. februar kl. 14:07

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.

37
1. februar kl. 13:53

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.

36
1. februar kl. 13:44

!

35
1. februar kl. 13:42

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å) ?

34
1. februar kl. 13:35

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.

32
1. februar kl. 13:09

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?

31
1. februar kl. 12:57

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.

Nøgler til SSL er 99% sikkert genereret hos Akamai og ikke hos Statens IT eller hvor selve origin serverne står. Kender ikke til Akamai i detaljer, men deres største konkurrent Cloudflare tilbyder at trafik mellem Edge og Origin kan være ukrypteret http traffik. Det er selvfølgelig en dårlig ide og sikkert ikke nogle der gør... host host.. Men alt andet end lige er Akamai eller Cloudflare nød til at terminere HTTPS trafikken inden den sendes videre til origin serverne hvis de skal kunne cache den på edge og optimere på content (f.eks. optimere billeder, minify JavaScript eller hvad de ellers tilbyder af content optimering).

30
1. februar kl. 12:47

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.

29
1. februar kl. 12:46

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

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 :-(

28
1. februar kl. 12:40

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.

27
1. februar kl. 12:33

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.

26
1. februar kl. 12:29

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.

25
1. februar kl. 11:59

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!

23
1. februar kl. 11:30

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.

22
1. februar kl. 11:19

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.

21
1. februar kl. 11:16

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!

20
1. februar kl. 10:21

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

Nå, men på mitid.dk (ikke www.mitid.dk) hvor der var problemer det meste af dagen i går, var det et udløbet cerfifikat fra Sectigo og ikke Lets Encrypt. Det er også fornyet til et Sectigo certifikat Just saying....

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.

16
1. februar kl. 00:12

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.

15
31. januar kl. 23:28

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.

14
31. januar kl. 22:30

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

Det var også det jeg skrev først. Jeg skrev det så ikke anden gang - jeg beklager.

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

Hm. Jeg syntes først jeg så netværket omvendt, men nu er det tydeligt at:

  • 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.

11
31. januar kl. 21:50

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

10
31. januar kl. 21:49

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

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.

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.

9
31. januar kl. 21:36

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

8
31. januar kl. 21:08

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?

7
31. januar kl. 20:47

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

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 www.mitid.dk, så kommer der vel aldrig andet end et ikke-brugbart token gennem mitid.dk.

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.

6
31. januar kl. 19:18

Igen noget skrald med quotes :-(

Håber det giver mening alligevel

/Henning

5
31. januar kl. 19:15

Ikke desto mindre er det netop det de har gjort nu :-) 31-01-2022 18:58:</p>
<p>CN = R3 O = Let's Encrypt C = US</p>
<p>Eller er det mig der har misforstået noget?

Noget kunne se ud til at det var et midlertidigt fix:

{qoute]

  • Server certificate:
  • subject: CN=mitid.dk
  • start date: Jan 31 00:00:00 2022 GMT
  • expire date: Jan 31 23:59:59 2023 GMT
  • subjectAltName: host "mitid.dk" matched cert's "mitid.dk"
  • issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
  • SSL certificate verify ok. [/quote]

henholdsvis

{qoute]

  • Server certificate:
  • subject: CN=www.mitid.dk
  • start date: Nov 29 02:32:18 2021 GMT
  • expire date: Feb 27 02:32:17 2022 GMT
  • subjectAltName: host "www.mitid.dk" matched cert's "www.mitid.dk"
  • issuer: C=US; O=Let's Encrypt; CN=R3
  • SSL certificate verify ok. [/quote]

Men der er noget andet der er problematisk:

henning@hp:~$ host mitid.dk ; host <a href="http://www.mitid.dk">www.mitid.dk</a&gt;
mitid.dk has address 188.64.157.250
<a href="http://www.mitid.dk">www.mitid.dk</a&gt; has address 95.100.155.152
<a href="http://www.mitid.dk">www.mitid.dk</a&gt; has address 95.100.155.161

Hvoreter en whois på ip'erne giver:

inetnum: 188.64.156.0 - 188.64.159.255
netname: SIT-05-SHS-L2
address: Statens IT

og

inetnum: 95.100.144.0 - 95.100.159.255
netname: AKAMAI-PA
descr: Akamai Technologies

Det er åbenbart Akamai som putter LetsEncrypt certifikat på forbindelser via deres CDN, men hvorfor fa**** skal den forbi et CDN som kan kigge med?

/Henning

3
31. januar kl. 17:33

Jaeh, joeh - Let's encrypt er fint til 80 % af brugen på internettet. Til kritisk infrastruktur kan det være et problem ...

Det var skam også skrevet ret meget i sjov. ? Jeg bruger Let's Encrypt på min private server, men tænker ikke det er "god latin" til MitID eller anden samfundskritisk infrastruktur - selvom det rent teknisk jo virker upåklageligt.

Også lidt bøvlet at skulle opdatere hver 3. måned (selvom man snildt kan klare det med et script) - det er jo tilsyneladende udfordrende nok at opdatere hvert 3. år!

... så tænker jeg at de lige nøjagtigt har lavet et stjernecertifikat ...

Nope - du kan jo selv gå ind og se på certifikatet - og se at der under DNS Name står www.mitid.dk. Havde det været et stjerne-certifikat, ja så ville der stå *.mitid.dk

2
31. januar kl. 17:06

Heldigvis er det dejlig nemt at lave et Let's Encrypt certifikat, så kan man lige købe 3 måneder mere.

Jaeh, joeh - Let's encrypt er fint til 80 % af brugen på internettet. Til kritisk infrastruktur kan det være et problem, da nogle organisationer ikke stoler på LE da det er gratis og der ikke er nogen "stake" i det for domæneindehaver.

Desværre har de ikke magtet at lave et wildcard certifikat

Hvis du med wildcard mener det klasseiske stjernecertifikat (*.mitid.dk), så tænker jeg at de lige nøjagtigt har lavet et stjernecertifikat, og glemt, at certifikatet også skal gælde for root (mitid.dk). Ansvaret faldt vel ned mellem to stole pga. dårlig koomunikation - en bestilte et stjernecertifikat, en anden fik lavet selve bestillingen, en tredje udførte bestillingen, og ingen kiggede lige det hele igennem.

1
31. januar kl. 15:21

Heldigvis er det dejlig nemt at lave et Let's Encrypt certifikat, så kan man lige købe 3 måneder mere.

Desværre har de ikke magtet at lave et wildcard certifikat, men det kræver jo også ekstra DNS verifikation...