Rapport: TLS-overhaling kan blive et sikkerhedsproblem

24 kommentarer.  Hop til debatten
Rapport: TLS-overhaling kan blive et sikkerhedsproblem
Illustration: faithiecannoise/Bigstock.
Flere protokoller har i den seneste tid fået sig en overhaling, der skal sikre brugernes sikkerhed. Problemet er, at meget sikkerhedssoftware kan ikke håndtere den nye kryptering.
10. august 2020 kl. 11:30
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

To af de grundlæggende protokoller på internettet, Transport Layer Security (TLS) og DNS, har på det seneste gennemgået store ændringer, sådan at man bedre kan sikre brugerens privatliv.

Det skriver Techrepublic.

Men på kort sigt, kan det vise sig at blive et problem for sikkerheden, og derfor skal der nye værktøjer til i løbet af de næste par år. Det konkluderer en ny rapport fra Forester Research.

Protokoller gør sikkerhedssoftware ’blind’

Fornyelsen af protokollerne er gode, idet de skjuler brugerdata fra nysgerrige øjne, men samtidig skjuler de også metadata for sikkerhedssoftware, der praktisk talt gør dem ’blinde’ for trusler, fordi de ikke længere kan registrere trafikkens indhold og destination.

Artiklen fortsætter efter annoncen

TLS 1.3 er et resultat af Internet Enginering Task Force (IETF), og er lavet for at sikre brugerne mod dataindsamling og aflytning, og DNS er allerede tilgængeligt og understøttet på flere browsere. Man forventer fra Forester Research, at det i løbet af de kommende år vil være en standard. Derfor er sikkerheds-fagfolk også nødt til at iværksætte flere tiltag, herunder en gennemgående proxy-inspektion af indgående data.

24 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
23
11. august 2020 kl. 21:15

få fat i ukrypteret trafik til Facebook og Google

Hvis de virkelig har noget at skjule, så er det næppe i klartekst og veldokumenterede formater til at begynde med.

Og de vil under alle omstændigheder ikke kunne undgå trafikanalyse. De kan allerhøjest håbe på at skjule sig i den kommunikation som iøvrigt går til deres datacentre.

22
11. august 2020 kl. 21:14

apps

En vigtig forskel på netop 1.3 er, at den skifter til AEAD's som forhindrer diverse oracle attacks. 1.3 er med andre ord den eneste som ikke i et eller andet omfang kan brydes.

20
11. august 2020 kl. 15:23

så hvordan ændrer TLS1.3 på den situation ?

Det er ikke specielt TLS1.3, men derimod den ukritiske jublen hvergang der bliver krypteret lidt hårdere og det medfølgende helt ukritiske fripas til hvor meget FaceBook og Google spionerer, mens ethvert tiltag fra vores demokratiske valgte folketing bliver udbasuneret som togafgang til tugthuslejr.

19
11. august 2020 kl. 13:38

@phk Men forskellen på nuværende TLS 1.2 og TLS 1.3 er jo KUN at man så ikke kan se domænenavnet. De siger jo INTET om hvad f.ex. google eller facebook apps sender til moderskibet - så hvordan ændrer TLS1.3 på den situation ?

At det klart er et problem med hvilke data diverse apps kan sende kvit og frit til moderskibet mm. - er jo ikke relevant ifbm. TLS 1.3 vs. TLS 1.2 ?

15
11. august 2020 kl. 07:15

den studsede jeg godt nok også noget over ?

13
10. august 2020 kl. 23:48

Det lyder måske meget ideelt og flot, indtil man overvejer at de to firmaer begge har en forretningsmodel der handler om at vide alt om alle, "come hell or GDPR".

Nu er der andet på internettet end Google og Facebook.

Men selv for disse tjenester med alle deres fejl og mangler: hvad skulle det dog gavne, at NSA eller FE overvåge min kommunikation?

Facebook kan jeg fravælge. FE's ulovlige masseovervågning kan kun bekæmpes med TLS.

12
10. august 2020 kl. 23:42

Hvad ville du så have haft i stedet? Hvad skulle TLS så have kunnet give?

11
10. august 2020 kl. 23:41

Ja, men TLS 1.3 virker som det skal. Hvad ville I hellere have haft?

Alle andre SSL/TLS versioner er usikre by design.

9
10. august 2020 kl. 22:13

Meningen med SSL/TLS har altid været at skabe (integritet)/konfidentialitet mellem 2 enheder, ikke andet. Og det fungerer det godt til.

De to enheder er hhv. Google eller FaceBook servere i deres datacenter og deres App på din enhed.

Målet med TLS1.3 er at sørge for at ingen, nogensinde kan se hvad der sker på den forbindelse.

Det lyder måske meget ideelt og flot, indtil man overvejer at de to firmaer begge har en forretningsmodel der handler om at vide alt om alle, "come hell or GDPR".

8
10. august 2020 kl. 21:11

Artiklen burde nok lige ses efter i sømmene: "DNS er allerede tilgængeligt og understøttet på flere browsere". Nu har DNS været tilgængeligt i mange årtier, så det giver ingen mening. Det den oprindelige artikel i TechRepublic omtaler er DNS-over-HTTPS (DoH) altså krypteret DNS opslag via HTTPS eller TLS protokollen (DNS-over-TLS). Det er næppe et sikkerhedsproblem (i første omgang) for brugerne, men derimod på enterprise niveau.

7
10. august 2020 kl. 20:12

Det må du gerne uddybe. Hvad mener du, at der er galt med TLS 1.3? Ud fra et teoretisk perspektiv er TLS 1.3 lavet som det er, fordi det ellers ikke ville være sikkert.

TLS 1.3 med en valgfri udvidelse (ESNI m.v.) giver mulighed for at kryptere det domænenavn, som overføres i forbindelse med det indledende TLS handshake hvis der bruges SNI (som er nødvendig hvis der er flere domæner, virtuelle servere i Apache-speak, på samme IP-adresse). Cloudflare understøtter dette.

Der er selvfølgelig andre forskelle mellem TLS 1.2 og TLS 1.3.

Udover kryptering af HTTP-trafikken (URL, indhold, etc) giver TLS 1.3 med ESNI mulighed for at skjule domænet over for alle servere (din ISP, dit lands store firewall, din virksomheds DPI firewall, etc) mellem klienten og serveren. Det kan gøre en forskel hvis bestemte domæner er blokeret (DNS-opslaget vil også skulle laves krypteret med DNS over TLS eller HTTPS).

Visse ISP'er i Danmark bruger SNI snooping til at blokere domæner (Hi3G og muligvis andre) i stedet for DNS-blokering.

Udover privacy aspektet kan ESNI måske få nogle stater til at holde igen med blokeringer, fordi der vil være større collateral damage. Det er ikke længere muligt at blokere et domæne ved SNI snooping, kun al trafik til den IP-adresse som den uønskede webside er på, sammen med alle de ikke-uønskede. På samme måde kunne stater og andre før HTTPS lave blokering på URL niveau, i stedet for domæne niveau.

Eller.. de kan gå mere håndhændet til værks, som Kina der blokerer TLS 1.3 med ESNI. Ultimativt vil det koble Kina af internettet som Nordkorea (og så langt vil selv Kina nok ikke gå). Det betyder under alle omstændigheder, at flere borgere rammes ("collateral damage"), hvilket måske kan få flere til at gøre oprør mod den undertrykkende stat.

6
10. august 2020 kl. 19:51

med mindre selvfølgelig at applikationen har et hardcodet klient certifikat eller en kontrol af servercertifikate er det rigtige ud fra en hardcoded liste.

Hvis du mener certificate pinning, kan det også håndteres i forhold til TLS interception, forudsat at du selv "kompromitterer" klienten (Frida script), eller en angriber gør det for dig. Det er fx gjort i denne analyse af TikTok samt den analyse af "exposure notification" apps på Android som Version2 skrev om for nylig.

5
10. august 2020 kl. 15:59

Det må du gerne uddybe. Hvad mener du, at der er galt med TLS 1.3? Ud fra et teoretisk perspektiv er TLS 1.3 lavet som det er, fordi det ellers ikke ville være sikkert.

Meningen med SSL/TLS har altid været at skabe (integritet)/konfidentialitet mellem 2 enheder, ikke andet. Og det fungerer det godt til.

4
10. august 2020 kl. 15:48

det er vel muligt at installere et certifikat på en proxy og forhåndsgodkende det på klienten, så klienten kun ser proxy'ens certifikater og proxyen terminere sessioner

Det er præcis sådan "TLS Intercept" proxy'er fungerer - dens rod-certifikat er præinstalleret på klienterne, og proxy'en laver så et certifikat "on-the-fly" så når klienten går på https://www.version2.dk/ så får den også et certifikat med det rigtige navn i.

Det virker kun fordi TLS 1.2 (og tidligere) ikke krypterer "www.version2.dk" i sit TLS handshake, så proxy'en kan se hvilket website den skal lave et certifikat til. I TLS 1.3 er dette felt krypteret, så proxy'en ikke kan aflæse det i tide. Det er det "Encrypted Server Name Indication (ESNI)" gør.

Om du så helst vil have privatliv eller et beskyttende filter mod ondsindede websites er en subjektiv afgørelse. Personligt mener jeg at det fuldt ud kan forsvares at lave TLS Intercept på en arbejdsplads, mens det er fuldstændig uacceptabelt når jeg er hjemme i privaten.

2
10. august 2020 kl. 15:08

Den er nu primært lavet for at beskytte Google, FaceBook imod forskere der snager i hvor meget de spionerer imod deres brugere.

Ikke at jeg er ekspert, men det er vel muligt at installere et certifikat på en proxy og forhåndsgodkende det på klienten, så klienten kun ser proxy'ens certifikater og proxyen terminere sessioner fra FAANG mfl. på proxy'en vil trafikken kunne læses ukrypteret, med mindre selvfølgelig at applikationen har et hardcodet klient certifikat eller en kontrol af servercertifikate er det rigtige ud fra en hardcoded liste.

1
10. august 2020 kl. 12:19

"TLS 1.3 er et resultat af Internet Enginering Task Force (IETF), og er lavet for at sikre brugerne mod dataindsamling og aflytning,"

Den er nu primært lavet for at beskytte Google, FaceBook imod forskere der snager i hvor meget de spionerer imod deres brugere.

Meget apropos har Kina dog lige blokeret for TLS 1.3 i deres firewall.