Vlákno názorů k článku Test akcelerátorů Internetu: proč je dial-up pomalý? od Michal Kára - Internet Explorer dela to, ze posle request uz...

Internet Explorer dela to, ze posle request uz v prvnim SYN packetu. A IIS umi takovyto packet zpracovat. Cimz ten jeden roundtrip usetri, ovsem za cenu porusovani RFC.

Zvláštní, že zrovna tohle mě u Mrkvo$oftu nepřekvapuje, oni byli odjakživa zastánci teorie "ukrást a pozměnit", takže nic nového pod sluncem :o)

A zajimave je, ze jenom u IE ma spojeni snahu cas od casu zmrznout. Proste IE ukazuje ubihajici progress bar ale dle snifferu nic neproudi.

To je naprostá pravda. Co si ale bude myslet BFU, až to uvidí? IE aspoň něco dělá, když nabíhá progressbar. Mozilla nedělá nic, když progressbar stojí. Je to takový podvod na BFU.

Zrovna tady na Lupe mi v takovym stavu pravidelne tuhne Opera :-)

pozoroval jste to v praxi? Ja jsem slysel ze to je ve skutecnosti jen chyba v jakesi stare verzi Windows NT.

Matne si vzpominam na to, ze kdosi spekuloval na tema, ze je to chyba prvniho TCP/IP protokoloveho zasobniku, ktery si psal MS sam (pred tim ho mel, stejne jako vetsina ostanich OS, prevzaty z nejake verze BSD).

Myslim ze je to dobra vec. Pamatuju ze kdyz jsem kdysi poprve debugoval TCP handshake, prisel mi prazdny SYN (a prazdny SYN+ACK) packet jako nesmysl.. Neexistuje zadny rozumny duvod (mimo hloupa RFC), proc by nemohly rovnou obsahovat data. MS nevymysli spatne veci VZDY, ale pouze SKORO vzdy.

Pozoroval jsem to kolem poloviny roku 2000, myslím, že to byly první Windows 2000. Pokud si ale dobře vzpomínám, fungovalo to trochu jinak. Nešlo o to, že by se posílala data v SYN paketu, ale o to, že při novém požadavku (novém spojení, neplést s keepalive) se spojení neotevíralo, ale MSIE se choval, jako kdyby bylo spojení stále otevřené. Pokud byl na druhé straně IIS a akceptoval to, ušetřil se tím jeden roundtrip, pokud tam bylo něco normálního, tak se holt po miniaturní prodlevě navázalo skutečné TCP spojení. Podle všeho z toho ale Microsoft posléze sám vycouval, protože tento inovativní přístup k TCP sice zrychloval následné dotazy na MSIE, ale zpomaloval následné dotazy na cokoli jiného. A IIS, na rozdíl od MSIE, naštěstí nikdy neměl mezi servery většinu, takže statisticky na tom MSIE spíš prodělával.

Není to dobrá věc. To, že data aplikační vrstvy musejí být až ve třetím paketu, značně komplikuje podvržení IP adresy. Abyste totiž (při korektní TCP komunikaci) mohl komukoli poslat aplikační data, musíte být buď někde na trase mezi cílem a tím, za koho se vydáváte, nebo uhodnout počáteční sequence number. Pokud je systém negeneruje příliš snadno uhodnutelným způsobem (zdravíme Windows 95/98), je to docela fuška. Pokud byste mohl posílat aplikační data už v prvním paketu, nemusíte nic hádat, ať jste kdekoli.

Ale jak jsem psal před chvílí, ta šílenost od Microsoftu fungovala AFAIK trochu jinak.

Tak mi to nedalo a chvili jsem si hral s Etherealem a IE / Win XP Pro. Musim rici, ze jsem zadne nestandardni chovani nepozoroval. Request to opravdu posila az s prvnim datovym packetem. A i kdyz jsem vznesl stejny dotaz za cca 3 minuty znovu (az spadlo keepalive), tak to to spojeni korektne navazalo.

Takze dalsi povera je vyvracena ;-)

Nemyslíte tohle?

That's it. Jenom jsem se nezmínil o tom napůl ukončeném spojení, nepamatoval jsem si totiž, který z těch dvou výtečníků neposílal FIN.

Copak nekdo pouziva autentizaci pomoci IP adresy? Sekvencni cisla jsou transportni zalezitost, nikoliv bezpecnostni- na to jsou prilis omezena a implementacne zavisla.

Ale mate pravdu, taky se mi nezda ze "ta silenost od MS funguje takhle".. je to na ne prilis jednoduche a uzitecne.

Samozřejmě se nepoužívá autentizace jen podle IP adresy. Ale je přinejmenším dobré vědět, kdo vás otravuje. Využít by to šlo i pro nějaký DoS útok, jehož cílem je vyčerpat maximální počet spojení.

Kdyby měla sequence numbers význam pouze pro určení, jakým způsobem skládat aplikační části paketů za sebe, proč se potom nezačíná prostě od nuly (nebo od jedničky) a hrajeme si s nějakým náhodně zvoleným počátečním bodem? Proč by pak nmap testoval, jak náhodně systém ISN volí?

Od nuly se nezacina hlavne proto, protoze klient casto recykluje lokalni cisla portu, a je treba rozlisit stare a nove TCP sessions.

Nmap tu "nahodnost" testuje hlavne kvuli OS fingerprintingu. Kdysi lide pouzivali rsh a .rhosts, tak se spoofnutim adresy dalo nekam vlamat, ale to uz je myslim davno pryc.

Nedavno na LKML bezela debata, ze zcela nahodna sekvencni cisla NEJSOU vhodna, prave kvuli pozadavku na zabraneni "aliasingu" s nedavno ukoncenymi TCP sessions.