Permalänk
Medlem

Blockera HTTP/3 eller inte

Vet inte varför jag har tänkt på detta innan men...

HTTP/3 är bra för slutanvändaren men dåligt för IPS/IDS/DPI/Brandväggar som jag förstår det. Eller spelar det ingen roll eftersom mycket använder TLS/SSL i alla fall?

För närvarande blockerar jag UDP/80 och UDP/443.

Visa signatur

"Maybe one day you will learn that your way, is not the only way"

Permalänk
Medlem
Skrivet av Orici:

Vet inte varför jag har tänkt på detta innan men...

HTTP/3 är bra för slutanvändaren men dåligt för IPS/IDS/DPI/Brandväggar som jag förstår det. Eller spelar det ingen roll eftersom mycket använder TLS/SSL i alla fall?

För närvarande blockerar jag UDP/80 och UDP/443.

HTTP3 har varit igång hos de stora aktörerna Googel, Microsoft och amazon i över 6 månader (kanske ännu längre) och ska inte påverka brandväggen nämnvärt. Saknas stöd för QUICK så hanteras väl trafiken som tidigare, dvs syn/ack för TCP, TLS och HTTP separat i stället för på en och samma gång. Till skillnad från HTTP 1 och 2 så används UDP ab HTTP 3 så det ska du inte behöva blocka. Och ja, allt är krypterat.

Visa signatur

There are two kinds of people: 1. Those that can extrapolate from incomplete data.
Min tråkiga hemsida om mitt bygge och lite annat smått o gott: www.2x3m4u.net

Permalänk
Medlem
Skrivet av Dr.Mabuse:

HTTP3 har varit igång hos de stora aktörerna Googel, Microsoft och amazon i över 6 månader (kanske ännu längre) och ska inte påverka brandväggen nämnvärt. Saknas stöd för QUICK så hanteras väl trafiken som tidigare, dvs syn/ack för TCP, TLS och HTTP separat i stället för på en och samma gång.

Ja precis, om man blockerar QUIC så går det över HTTP/2 istället. Men HTTP/3 verkar påverka brandväggar mycket,
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-se...
https://www.networkstraining.com/what-is-quic-protocol/

Visa signatur

"Maybe one day you will learn that your way, is not the only way"

Permalänk
Medlem
Skrivet av Orici:

Ja precis, om man blockerar QUIC så går det över HTTP/2 istället. Men HTTP/3 verkar påverka brandväggar mycket,
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-se...
https://www.networkstraining.com/what-is-quic-protocol/

Tänkte mest prestandamässigt och där har jag inte upplevt någon skillnad (dock ej uppmätt). Funderade ärligt talat inte så mycket på hur det kan påverka t.ex. app restrictions. Jag får läsa på helt enkelt o tackar för länkarna.

Visa signatur

There are two kinds of people: 1. Those that can extrapolate from incomplete data.
Min tråkiga hemsida om mitt bygge och lite annat smått o gott: www.2x3m4u.net

Permalänk
Medlem
Skrivet av Orici:

Ja precis, om man blockerar QUIC så går det över HTTP/2 istället. Men HTTP/3 verkar påverka brandväggar mycket,
https://www.fastvue.co/fastvue/blog/googles-quic-protocols-se...
https://www.networkstraining.com/what-is-quic-protocol/

Jag får erkänna att jag inte är superinsatt, det här är mer ett hobbyintresse än något jag måste kunna perfekt för mitt jobb...

Först och främst: QUIC är designat så att man (webbservern) kan spåra användare när de byter nätverk, förutsatt att webbläsaren inte startas om. Perfekt för att kunna mappa din mobiltelefon till ditt hemma-IP-nummer alltså och förstå vilken användare som finns bakom även om du senare byter till en annan enhet på hemmanätverket.

Dessutom: Som jag förstår det är det mycket svårt att blockera QUIC. En webbserver meddelar klienten om var dess QUIC-tjänst (HTTP/3) finns genom Alt-Svc-headern. Denna header innehåller ett portnummer som alltså kommer att användas för UDP-trafiken som QUIC kör över. Eftersom detta portnummer kan vara vilket giltigt portnummer som helst (inte bara 80, 443) så måste man spärra all UDP-trafik för att spärra QUIC. Och att spärra all UDP-trafik kommer att skapa massor av problem.

QUIC går över UDP som går över IP. Ovanpå QUIC kan man köra HTTP/3. Som jag förstår det är HTTP/3 rätt OK, det råkar bara bo ovanpå ett protokoll som har egenskaper som inte är direkt önskvärda.

För att brandväggar ska kunna inspektera innehållet i krypterad trafik (inklusive QUIC) måste de göra en man-in-the-middle-attack på den TLS-krypterade trafiken. Det är inget som skiljer sig principiellt oavsett om man kör HTTP/1.1, HTTP/2 eller HTTP/3 som jag förstår det. Däremot så krävs det förstås lite ny teknik och brandväggsstöd för att göra det över QUIC, det gamla stödet för TCP+TLS duger inte. Därmed är det svårare än någonsin att genomföra sådan inspektion i praktiken. Det har alltid krävt att man kan installera sitt eget rotcertifikat på klienten, så att man i brandväggen i realtid kan utfärda en fejkad version av sajtens certifikat, signerat av ens eget rotcertifikat.

Google för ett aktivt krig mot inspektion och manipulation av trafik mellan deras tjänster och klienterna. Syftet är förstås att det ska bli svårt att upptäcka och hindra spårning och reklamöverföring. Medlet de använder är webbstandarder som de pushar och sin dominans på webbläsarmarknaden. Än så länge är det teoretiskt möjligt att styra trafiken man är ena ändan av, men de flesta orkar/kan förstås inte sätta sig in i detta (jag är en av dem som inte orkar). Och det är redan helt omöjligt på enheter som man inte har administrativ access till, till exempel TV-apparater och många mobiltelefoner. Andra exempel på det kriget är DNS-över-HTTPS och testballongerna man skjutit upp för att ändra i API:erna i Chrome/Chromeium för att hindra att annonsblockerare ska fungera. TLS 1.3 gör det även svårare att genomföra MITM-attacker, men jag minns inte de exakta detaljerna.

Permalänk
Medlem

En nyligen släppt video om just detta : https://www.youtube.com/watch?v=cdb7M37o9sU

Permalänk
Medlem
Skrivet av KAD:

Jag får erkänna att jag inte är superinsatt, det här är mer ett hobbyintresse än något jag måste kunna perfekt för mitt jobb...

Först och främst: QUIC är designat så att man (webbservern) kan spåra användare när de byter nätverk, förutsatt att webbläsaren inte startas om. Perfekt för att kunna mappa din mobiltelefon till ditt hemma-IP-nummer alltså och förstå vilken användare som finns bakom även om du senare byter till en annan enhet på hemmanätverket.

Ja, det är en av dom bra egenskaper med http/3.

Skrivet av KAD:

Dessutom: Som jag förstår det är det mycket svårt att blockera QUIC. En webbserver meddelar klienten om var dess QUIC-tjänst (HTTP/3) finns genom Alt-Svc-headern. Denna header innehåller ett portnummer som alltså kommer att användas för UDP-trafiken som QUIC kör över. Eftersom detta portnummer kan vara vilket giltigt portnummer som helst (inte bara 80, 443) så måste man spärra all UDP-trafik för att spärra QUIC. Och att spärra all UDP-trafik kommer att skapa massor av problem.

QUIC går över UDP som går över IP. Ovanpå QUIC kan man köra HTTP/3. Som jag förstår det är HTTP/3 rätt OK, det råkar bara bo ovanpå ett protokoll som har egenskaper som inte är direkt önskvärda.

För att brandväggar ska kunna inspektera innehållet i krypterad trafik (inklusive QUIC) måste de göra en man-in-the-middle-attack på den TLS-krypterade trafiken. Det är inget som skiljer sig principiellt oavsett om man kör HTTP/1.1, HTTP/2 eller HTTP/3 som jag förstår det. Däremot så krävs det förstås lite ny teknik och brandväggsstöd för att göra det över QUIC, det gamla stödet för TCP+TLS duger inte. Därmed är det svårare än någonsin att genomföra sådan inspektion i praktiken. Det har alltid krävt att man kan installera sitt eget rotcertifikat på klienten, så att man i brandväggen i realtid kan utfärda en fejkad version av sajtens certifikat, signerat av ens eget rotcertifikat.

Okej detta är vad jag ville få ut av denna tråd, tack. Som jag förstår detta är att HTTP/3 ger brandväggar mindre att gå på och därmed kan dom inte klassifera trafiken. Men du säjer alltså att HTTP/2 och HTTP/3 avslöjar lika lite för brandväggar?

Skrivet av KAD:

Google för ett aktivt krig mot inspektion och manipulation av trafik mellan deras tjänster och klienterna. Syftet är förstås att det ska bli svårt att upptäcka och hindra spårning och reklamöverföring. Medlet de använder är webbstandarder som de pushar och sin dominans på webbläsarmarknaden. Än så länge är det teoretiskt möjligt att styra trafiken man är ena ändan av, men de flesta orkar/kan förstås inte sätta sig in i detta (jag är en av dem som inte orkar). Och det är redan helt omöjligt på enheter som man inte har administrativ access till, till exempel TV-apparater och många mobiltelefoner. Andra exempel på det kriget är DNS-över-HTTPS och testballongerna man skjutit upp för att ändra i API:erna i Chrome/Chromeium för att hindra att annonsblockerare ska fungera. TLS 1.3 gör det även svårare att genomföra MITM-attacker, men jag minns inte de exakta detaljerna.

Detta är en sak som i viss mening är lika HTTP/3, där meningen är att ge slutanvändaren bättre säkerhet till kostnad av att brandväggar får det svårare att filtrera trafik. Dock kan just detta nog lösas genom att tvinga användere att bara använda godkända DNS servrar.

Skrivet av iXam:

En nyligen släppt video om just detta : https://www.youtube.com/watch?v=cdb7M37o9sU

Jag skapade denna tråd efter att ha sett denna video, tyckte inte att dom gick igenom hur brandväggar påverkas av HTTP/3.

Visa signatur

"Maybe one day you will learn that your way, is not the only way"

Permalänk
Avstängd
Skrivet av KAD:

Jag får erkänna att jag inte är superinsatt, det här är mer ett hobbyintresse än något jag måste kunna perfekt för mitt jobb...

Först och främst: QUIC är designat så att man (webbservern) kan spåra användare när de byter nätverk, förutsatt att webbläsaren inte startas om. Perfekt för att kunna mappa din mobiltelefon till ditt hemma-IP-nummer alltså och förstå vilken användare som finns bakom även om du senare byter till en annan enhet på hemmanätverket.

Dessutom: Som jag förstår det är det mycket svårt att blockera QUIC. En webbserver meddelar klienten om var dess QUIC-tjänst (HTTP/3) finns genom Alt-Svc-headern. Denna header innehåller ett portnummer som alltså kommer att användas för UDP-trafiken som QUIC kör över. Eftersom detta portnummer kan vara vilket giltigt portnummer som helst (inte bara 80, 443) så måste man spärra all UDP-trafik för att spärra QUIC. Och att spärra all UDP-trafik kommer att skapa massor av problem.

QUIC går över UDP som går över IP. Ovanpå QUIC kan man köra HTTP/3. Som jag förstår det är HTTP/3 rätt OK, det råkar bara bo ovanpå ett protokoll som har egenskaper som inte är direkt önskvärda.

För att brandväggar ska kunna inspektera innehållet i krypterad trafik (inklusive QUIC) måste de göra en man-in-the-middle-attack på den TLS-krypterade trafiken. Det är inget som skiljer sig principiellt oavsett om man kör HTTP/1.1, HTTP/2 eller HTTP/3 som jag förstår det. Däremot så krävs det förstås lite ny teknik och brandväggsstöd för att göra det över QUIC, det gamla stödet för TCP+TLS duger inte. Därmed är det svårare än någonsin att genomföra sådan inspektion i praktiken. Det har alltid krävt att man kan installera sitt eget rotcertifikat på klienten, så att man i brandväggen i realtid kan utfärda en fejkad version av sajtens certifikat, signerat av ens eget rotcertifikat.

Google för ett aktivt krig mot inspektion och manipulation av trafik mellan deras tjänster och klienterna. Syftet är förstås att det ska bli svårt att upptäcka och hindra spårning och reklamöverföring. Medlet de använder är webbstandarder som de pushar och sin dominans på webbläsarmarknaden. Än så länge är det teoretiskt möjligt att styra trafiken man är ena ändan av, men de flesta orkar/kan förstås inte sätta sig in i detta (jag är en av dem som inte orkar). Och det är redan helt omöjligt på enheter som man inte har administrativ access till, till exempel TV-apparater och många mobiltelefoner. Andra exempel på det kriget är DNS-över-HTTPS och testballongerna man skjutit upp för att ändra i API:erna i Chrome/Chromeium för att hindra att annonsblockerare ska fungera. TLS 1.3 gör det även svårare att genomföra MITM-attacker, men jag minns inte de exakta detaljerna.

För mig låter det mer snarare som att de vill införa MER övervakning av användarna, och försvåra blockerandet av denna altmer övervakande samhälle vi lever i.

Gömma deras övervakning i skuggorna som du beskriver det, sedan veta ännu mer om du byter nätverk eller enhet. Motarbeta t.ex. reklamblockerare och andra anti-tracking-addons till t.ex. webbläsare osv.

Permalänk
Medlem
Skrivet av Orici:

Vet inte varför jag har tänkt på detta innan men...

HTTP/3 är bra för slutanvändaren men dåligt för IPS/IDS/DPI/Brandväggar som jag förstår det. Eller spelar det ingen roll eftersom mycket använder TLS/SSL i alla fall?

För närvarande blockerar jag UDP/80 och UDP/443.

Folk har starka åsikter om H3, det hade folk även om ESNI och DoH. Men helt ärligt hade folk starka åsikter när allt började gå mot SSL/TLS och perfect forward secrecy var ett faktum. Det blev svårare att se exakt vad folk gjorde på internet. Om man nu behöver och har legitima skäl att övervaka vad folk gör på internet så kan man lösa det på andra sätt. Kryptering kommer nog inte försvinna.

Om du inte har koll så "läcker" H1/H2 domännamnet okrypterat som man besöker via SNI när man sätter upp TLS. Även DNS läcker vilka domännamn du besöker. Detta är bland annat hur IPS/IDS/DPI funkar idag. Se https://blog.cloudflare.com/encrypted-sni/

Men att H3 byter till UDP har ju lite andra typer av implikationer än bara kryptering. Om det faktiskt blir bättre i alla lägen återstår väl att se, även om google använt det länge. Men en brandvägg bör ju inte ha några tekniska problem med det direkt, faktiskt därför UDP valdes och inte nått mer exotiskt.

Skrivet av stgr:

För mig låter det mer snarare som att de vill införa MER övervakning av användarna, och försvåra blockerandet av denna altmer övervakande samhälle vi lever i.

Gömma deras övervakning i skuggorna som du beskriver det, sedan veta ännu mer om du byter nätverk eller enhet. Motarbeta t.ex. reklamblockerare och andra anti-tracking-addons till t.ex. webbläsare osv.

Allt går väl att använda åt olika saker. Men att kunna vara säker på att en och samma användare går från 4G till wifi är helt klart ett use case som behövs när det kommer till säkerhet. Att spåra vad folk har för IP på sitt internet har gjorts sen internet kom och kommer nog inte försvinna på länge.

Permalänk
Avstängd
Skrivet av varget:

Folk har starka åsikter om H3, det hade folk även om ESNI och DoH. Men helt ärligt hade folk starka åsikter när allt började gå mot SSL/TLS och perfect forward secrecy var ett faktum. Det blev svårare att se exakt vad folk gjorde på internet. Om man nu behöver och har legitima skäl att övervaka vad folk gör på internet så kan man lösa det på andra sätt. Kryptering kommer nog inte försvinna.

Om du inte har koll så "läcker" H1/H2 domännamnet okrypterat som man besöker via SNI när man sätter upp TLS. Även DNS läcker vilka domännamn du besöker. Detta är bland annat hur IPS/IDS/DPI funkar idag. Se https://blog.cloudflare.com/encrypted-sni/

Men att H3 byter till UDP har ju lite andra typer av implikationer än bara kryptering. Om det faktiskt blir bättre i alla lägen återstår väl att se, även om google använt det länge. Men en brandvägg bör ju inte ha några tekniska problem med det direkt, faktiskt därför UDP valdes och inte nått mer exotiskt.

Allt går väl att använda åt olika saker. Men att kunna vara säker på att en och samma användare går från 4G till wifi är helt klart ett use case som behövs när det kommer till säkerhet. Att spåra vad folk har för IP på sitt internet har gjorts sen internet kom och kommer nog inte försvinna på länge.

Har inget med att spåra ip tror jag, utan lättare spåra (ännu) mer vad du gör, då allt ska kunna gås förbi brandväggar, vilket gör det ääääännnnu enklare att spåra användarna.
Sedan att motverka tillägg som reklamblockare och andra spårnings-koder spär på min tanke om att de vill göra det extrems mycket enklare att övervaka folket.

Permalänk
Medlem
Skrivet av KAD:

För att brandväggar ska kunna inspektera innehållet i krypterad trafik (inklusive QUIC) måste de göra en man-in-the-middle-attack på den TLS-krypterade trafiken.

Eller så installerar man mjukvara på klienten som löser detta. Då slipper man ta hand om andra problem så som CAA tex.

Permalänk
Medlem
Skrivet av stgr:

Har inget med att spåra ip tror jag, utan lättare spåra (ännu) mer vad du gör, då allt ska kunna gås förbi brandväggar, vilket gör det ääääännnnu enklare att spåra användarna.
Sedan att motverka tillägg som reklamblockare och andra spårnings-koder spär på min tanke om att de vill göra det extrems mycket enklare att övervaka folket.

Du får gärna utveckla hur du tänker. Redan i dag så blir du spårad oavsett om en brandvägg är där eller din data krypteras. Det är ju servern du väljer att prata med som spårar dig. Inte nått på vägen. Reklamblockare funkar fortfarande med H3, jag kör både pihole och uBlock. Båda dem kör utanför H3.

Permalänk
Hedersmedlem
Skrivet av Orici:

Vet inte varför jag har tänkt på detta innan men...

HTTP/3 är bra för slutanvändaren men dåligt för IPS/IDS/DPI/Brandväggar som jag förstår det. Eller spelar det ingen roll eftersom mycket använder TLS/SSL i alla fall?

För närvarande blockerar jag UDP/80 och UDP/443.

Kör du någon brandvägg på ditt nätverk som har funktioner som fungerar på TCP-trafil med TLS, men inte funkar på QUIC-trafik?

Tips: Om du inte vet är svaret nej.

Och i så fall bör du sluta blockera de portarna, QUIC har en del prestandafördelar som du går miste om genom att blockera det.

Permalänk
Medlem
Skrivet av varget:

Folk har starka åsikter om H3, det hade folk även om ESNI och DoH. Men helt ärligt hade folk starka åsikter när allt började gå mot SSL/TLS och perfect forward secrecy var ett faktum. Det blev svårare att se exakt vad folk gjorde på internet. Om man nu behöver och har legitima skäl att övervaka vad folk gör på internet så kan man lösa det på andra sätt. Kryptering kommer nog inte försvinna.

Om du inte har koll så "läcker" H1/H2 domännamnet okrypterat som man besöker via SNI när man sätter upp TLS. Även DNS läcker vilka domännamn du besöker. Detta är bland annat hur IPS/IDS/DPI funkar idag. Se https://blog.cloudflare.com/encrypted-sni/

Men att H3 byter till UDP har ju lite andra typer av implikationer än bara kryptering. Om det faktiskt blir bättre i alla lägen återstår väl att se, även om google använt det länge. Men en brandvägg bör ju inte ha några tekniska problem med det direkt, faktiskt därför UDP valdes och inte nått mer exotiskt.

Allt går väl att använda åt olika saker. Men att kunna vara säker på att en och samma användare går från 4G till wifi är helt klart ett use case som behövs när det kommer till säkerhet. Att spåra vad folk har för IP på sitt internet har gjorts sen internet kom och kommer nog inte försvinna på länge.

Varför bör inte en brandvägg ha problem med H3, då H3 visar mindre än H2?

Skrivet av pv2b:

Kör du någon brandvägg på ditt nätverk som har funktioner som fungerar på TCP-trafil med TLS, men inte funkar på QUIC-trafik?

Tips: Om du inte vet är svaret nej.

Och i så fall bör du sluta blockera de portarna, QUIC har en del prestandafördelar som du går miste om genom att blockera det.

Nej, en stor del av trafiken är bara kategoriserat som SSL/TLS.

Visa signatur

"Maybe one day you will learn that your way, is not the only way"

Permalänk
Medlem
Skrivet av Orici:

Varför bör inte en brandvägg ha problem med H3, då H3 visar mindre än H2?

Beror så klart på vad man anser att en brandvägg ska göra. Men att släppa igenom quic klarar alla brandväggar, lika så att blocka det. Jag mena inte att de ska klara att inspektera din trafik i quic. Det var redan svårt innan. Har man legitim anledning att inspektera trafiken så är mjukvara på klienten lösningen, där alla nycklar till tls även finns.