> Alltså, du gör det...
Jaha, du menar så. Jag tänkte den lösning som (t.ex) hotellet själv använder
(och som tydligen ibland blockar vissa portar). Ja OK, det är ju lite
annorlunda om man själv ska fixa till en special lösning...
Portforward eller annan routing
Re: Portforward eller annan routing
Håller inte riktigt med Nerre här.
För att detta skall fungera förutsätts att proxyn består i ett enkelt portfilter som enbart kontrollerar att trafiken går på port 80.
Inte många "riktiga" brandväggar beter sig på det sättet. De flesta har trafik analys (dvs. ÄR det HTTP anrop/svar) och flertalet har content vectoring som vilket tilloch med kan innebära packet assembly på brandväggsnivå för att kontrollera innehållet i det du faktiskt drar ner.
När man skickar krypterad trafik igenom en sådan här brandvägg blir den förbannad, för den kan inte tolka innehållet.
Detta är den eviga förbannelsen vilket drabbar oss som jobbar med precis det motsatta som denna tråd handlar om (dvs. vi som vill kontrollera trafiken
)
Man kan INTE kryptera end to end OCH kontrollera att trafiken är rätt enligt protokollstandard.
Men som sagt det funkar om det bara är ett enkelt port filter.
Edit:fel citat
För att detta skall fungera förutsätts att proxyn består i ett enkelt portfilter som enbart kontrollerar att trafiken går på port 80.
Inte många "riktiga" brandväggar beter sig på det sättet. De flesta har trafik analys (dvs. ÄR det HTTP anrop/svar) och flertalet har content vectoring som vilket tilloch med kan innebära packet assembly på brandväggsnivå för att kontrollera innehållet i det du faktiskt drar ner.
När man skickar krypterad trafik igenom en sådan här brandvägg blir den förbannad, för den kan inte tolka innehållet.
Detta är den eviga förbannelsen vilket drabbar oss som jobbar med precis det motsatta som denna tråd handlar om (dvs. vi som vill kontrollera trafiken
)Man kan INTE kryptera end to end OCH kontrollera att trafiken är rätt enligt protokollstandard.
Men som sagt det funkar om det bara är ett enkelt port filter.
Edit:fel citat
Re: Portforward eller annan routing
Det förutsätts nog inte alls att proxyn bara är ett portfilter, se till exempel http://dag.wieers.com/howto/ssh-http-tunneling/
Poängen är att man kodar trafiken som http, dvs det går över port 80 och ser ut som http request/responses. Om det behövs skulle man kunna koda allting som text så att det ser ut som något ofarligt. Brandväggen kommer inte stoppa en request av foo.txt och som sedan laddar ner ett gäng kB av ascii data, hur ska den kunna skilja det från en riktig nerladdning? Att foo.txt sedan kan dekrypteras till att bli en del av en youtube film som du ville blockera...
Se också http://proxytunnel.sourceforge.net/paper.php
Har inte testat den själv så implementationen kan mycket väl ha begränsningar som gör att den inte tar sig igenom just din brandväggskonfiguration, men principen borde fungera så länge någon sorts nerladdning fungerar från en server jag väljer.
Fast om du jobbar med att sätta upp/säkra brandväggar så kanske det är bäst för alla att du fortsätter tro att man inte kan tunnla ut...
Poängen är att man kodar trafiken som http, dvs det går över port 80 och ser ut som http request/responses. Om det behövs skulle man kunna koda allting som text så att det ser ut som något ofarligt. Brandväggen kommer inte stoppa en request av foo.txt och som sedan laddar ner ett gäng kB av ascii data, hur ska den kunna skilja det från en riktig nerladdning? Att foo.txt sedan kan dekrypteras till att bli en del av en youtube film som du ville blockera...
Se också http://proxytunnel.sourceforge.net/paper.php
Har inte testat den själv så implementationen kan mycket väl ha begränsningar som gör att den inte tar sig igenom just din brandväggskonfiguration, men principen borde fungera så länge någon sorts nerladdning fungerar från en server jag väljer.
Fast om du jobbar med att sätta upp/säkra brandväggar så kanske det är bäst för alla att du fortsätter tro att man inte kan tunnla ut...
Re: Portforward eller annan routing
Jag orkade inte läsa allt 
Så egentligen borde jag ge mig i denna tråd.
Men om man formaterar en fråga som HTTP och formaterar svaret som HTTP så kan man självklart överföra godtycklig information.
Då är det ju HTTP per definition och skall få gå igenom.
Om lösningen bygger på detta blir emellertid vissa protokoll lite trista att överföra då HTTP är stateless (dvs. du ansluter, får svare och kopplar ner för varje anrop till servern.)
Att jämföra med att man skapar anslutning överför det man behöver genom dialog sändare/mottagare.
Om den bygger på HTTPS så har man ju redan bestämt att man bara bryr sig om headern i IP-paketen, men det var inte HTTPS jag pratade om i mitt inlägg.
Vi är väl överens om att en pryl som kontrollerar att svar kommer formaterade som HTML inte kan vara krypterad.
Att den sedan inte bryr sig om huruvida det är Aftonbladets logotyp eller en bit av din E-post som överförs är självklart.
Det som beskrivs i länkarna kan mycket väl lösa TS problem.
Jag skrev för övrigt inlägget lite för att peka på att folk har en märklig tendens att blanda ihop portar och protokoll.
Så egentligen borde jag ge mig i denna tråd.
Men om man formaterar en fråga som HTTP och formaterar svaret som HTTP så kan man självklart överföra godtycklig information.
Då är det ju HTTP per definition och skall få gå igenom.
Om lösningen bygger på detta blir emellertid vissa protokoll lite trista att överföra då HTTP är stateless (dvs. du ansluter, får svare och kopplar ner för varje anrop till servern.)
Att jämföra med att man skapar anslutning överför det man behöver genom dialog sändare/mottagare.
Om den bygger på HTTPS så har man ju redan bestämt att man bara bryr sig om headern i IP-paketen, men det var inte HTTPS jag pratade om i mitt inlägg.
Vi är väl överens om att en pryl som kontrollerar att svar kommer formaterade som HTML inte kan vara krypterad.
Att den sedan inte bryr sig om huruvida det är Aftonbladets logotyp eller en bit av din E-post som överförs är självklart.
Det som beskrivs i länkarna kan mycket väl lösa TS problem.
Jag skrev för övrigt inlägget lite för att peka på att folk har en märklig tendens att blanda ihop portar och protokoll.
Re: Portforward eller annan routing
Allt som kommer via http är inte HTML. Jag har inte hört talas om nån proxy som bara släpper igenom HTML. Då skulle ju inte bilder eller ljudfiler fungera??
Om jag streamar en ljudfil via http, hur i h-e- ska proxyn kunna veta att ljudet (som låter som brus) egentligen är en krypterad VPN-tunnel??
Om jag streamar en ljudfil via http, hur i h-e- ska proxyn kunna veta att ljudet (som låter som brus) egentligen är en krypterad VPN-tunnel??
Re: Portforward eller annan routing
Nu grusar vi tråden rejält.
Så jag drar mig tillbaka med detta svar.
Det jag inte höll med om var:
En proxy kan:
Nivå 1 (Minst avancerad): Kolla att rätt port används.
Nivå 2 (Mer avancerad): Kolla att rätt port används, kolla att godlända (de man valt) HTTP request types (9 st bara) nyttjas och proxifiera avsändaradress, chacha.
Nivå 3 (Mest avancerad) Kolla att respektive HTTP request type är rätt strukturerad och i extrema fall även tolka och göra symantiska/syntaktiska kontroller på innehållet.
Den sistnämnda ställer ofta till det då allt på nätet inte funkar (beroende på hur man skruvat) givetvis.
Jag skulle nog tro att hotell ligger i Nivå 2 kategorin.
HTML använde jag i exemplet bara.
För att strömma krävs väl att man just hanterar innehållet på ett sätt som kan transporteras via HTTP både i server och klient.
Det är väl därför vi mosar in plugins i läsarna (Flashplayer för youtube etc.).
Tror det ligger en proposal på "MPEG over HTTP" för att slippa sådant.
Du har rätt i din senare post Nerre, det var den tidigare som jag inte ansåg stämde.
Så jag drar mig tillbaka med detta svar.
Det jag inte höll med om var:
Det andra håller jag med om (det är ju en annan lösning).Jag var med i ABC-klubben förut och de hade en maskin som t.ex. körde ssh på port 80 har jag för mig, de körde även SMTP-servern på andra portar än 25 just för att klara sig förbi portspärrar.
En proxy kan:
Nivå 1 (Minst avancerad): Kolla att rätt port används.
Nivå 2 (Mer avancerad): Kolla att rätt port används, kolla att godlända (de man valt) HTTP request types (9 st bara) nyttjas och proxifiera avsändaradress, chacha.
Nivå 3 (Mest avancerad) Kolla att respektive HTTP request type är rätt strukturerad och i extrema fall även tolka och göra symantiska/syntaktiska kontroller på innehållet.
Den sistnämnda ställer ofta till det då allt på nätet inte funkar (beroende på hur man skruvat) givetvis.
Jag skulle nog tro att hotell ligger i Nivå 2 kategorin.
HTML använde jag i exemplet bara.
För att strömma krävs väl att man just hanterar innehållet på ett sätt som kan transporteras via HTTP både i server och klient.
Det är väl därför vi mosar in plugins i läsarna (Flashplayer för youtube etc.).
Tror det ligger en proposal på "MPEG over HTTP" för att slippa sådant.
Du har rätt i din senare post Nerre, det var den tidigare som jag inte ansåg stämde.
Re: Portforward eller annan routing
ABC-klubbens maskiner var ju till för att ta sig igenom internetleverantörernas portspärrar. Många spärrar ju t.ex. port 25 utåt för att inte trojaner ska kunna vräka iväg spam från smittade datorer. Men det ställer ju till det om man vill skicka via en extern SMTP-server.
