Dotaz: Některé weby hlásí HTTP Error 403

[Michal Hybner]

Dobrý den, asi v posledních 4 dnech mi začaly nějaké stránky vyhazovat stále chybu 403. Prohlížečem to není, dělá to Opera i Konqueror - po asi 20 vteřinách načítání vždy ukáže tu samou stránku.

Přesné znění chyby:

HTTP Error 403: The service you requested is restricted

The service you requested is restricted and not available to your browser

The restriction can be based on your IP-address, hostname, browser software, time-of-day or other variables. Most likely you requested a service that was made available to a restricted subnet.

Příklad takové stránky je třeba blog.cz. Zkoušel jsem i traceroute a zdá se, že požadavek k serveru normálně dojde, pokud to správně chápu.

$ traceroute www.blog.cz
traceroute to blog.cz (217.31.54.174), 30 hops max, 40 byte packets
 1  10.10.133.78 (10.10.133.78)  223.789 ms  249.924 ms  206.639 ms
 2  10.10.133.66 (10.10.133.66)  626.631 ms  319.937 ms  199.988 ms
 3  10.10.133.141 (10.10.133.141)  199.967 ms  249.935 ms  199.973 ms
 4  10.10.133.1 (10.10.133.1)  206.635 ms  249.940 ms  749.965 ms
 5  vl914.rcnR04i.oskarmobil.cz (217.77.160.26)  299.971 ms  199.924 ms  256.635 ms
 6  po1-0.sitR00i.oskarmobil.cz (217.77.160.62)  199.969 ms  249.929 ms  416.637 ms
 7  ge0-3.gtsR00i.oskarmobil.cz (217.77.160.18)  326.636 ms  226.600 ms  233.306 ms
 8  nix-m.backbone.ignum.cz (194.50.100.8)  903.301 ms  343.262 ms  209.969 ms
 9  chikuma.jyxo.com (217.31.54.174)  226.631 ms  223.266 ms  476.643 ms

Připojení je přes Vodafone Připojení na stálo do telefonu a přes bluetooth k počítači. Takhle to fungovalo několik měsíců. Vím, že mít připojený počítač přes mobilní internet je na nic, ale momentálně není jiná možnost.

Nevíte, prosím, v čem by mohl být problém? Případně rád poskytnu další informace. Díky

Odpovědi

[Jendа]

?

[Michal Hybner]

Nevím, dost pochybuji, že by blokoval stránky jako

• http://www.cocker.cz/waging_tail/
• http://www.sacher.com/sacher/SacherTorte/index_en.jsp
• http://www.thebelgianchocolates.be/
• http://www.potterweb.cz/
• nebo již zmíněný http://www.blog.cz/

To jsou příklady stránek co prostě nejdou otevřít. Párkrát nešlo jít ani na Wikipedii nebo Gmail. Zato vyhledávač Google nebo abclinuxu šlo zatím vždy.

[vencour]

Tak zkuste telnet na port 80 na daném serveru a uvidí se ... jak to maj vychytaný

[Michal Hybner]

Tak to vypadá, že telnet s tím něco dělá. Zkoušel jsem např. stránku www.etree.org, která i na asi desátý pokus obnovení stále vracela chybu 403 a po připojení telnetem se stránka rozběhla.

$ telnet www.etree.org 80
Trying 152.46.7.81...
Connected to etree.org.
Escape character is '^]'.

Vypadá to, že to takhle funguje u všech stránek co jsem zatím zkoušel, všechny i ty co jsem tu předtím vypisloval se po připojení rozběhly. Telnet to asi nějak prošťouchne. Ještě uvidím na jak dlouho. Napadá vás, co by šlo případně přes telnet zjistit? Nevím co do telnetu psát. Díky

[cronin]

No, ten vypis iba hovori, ze sa telnetu podarilo pripojit. Este si mal napisat:

GET / HTTP/1.0

a stlacit 2x Enter; mal by si dostat nejaku odpoved zo servera.

[Filip Jirsák]

Lepší by bylo

GET / HTTP/1.0
Host: www.etree.org

a 2× <Enter>, HTTP servery většinou používají virtual host a pokud nezadáte jméno, dostanete nějakou defaultní stránku (a proxy po cestě rozhodně nezjistí, kam se vlastně připojujete, takže nemůže nic filtrovat).

[cronin]

Tak potom

GET / HTTP/1.1
Host: www.etree.org
Connection: close

nakolko header field Host je definovany az protokolom HTTP 1.1.

[Filip Jirsák]

Ale používal se i v HTTP 1.0 a snad všechny servery používající HTTP 1.0 mu rozumí (a když mu nerozumí, budou ho ignorovat). HTTP 1.1 bych pro ruční testování nepoužíval, protože už je poněkud náročnější na ruční simulaci.

[Michal Kubeček]

Tohle je bohužel velice rozšířený omyl. V příslušném RFC je naprosto jasně řečeno, že jakmile použijete cokoli, co není v HTTP/1.0 (a to Host není), musí být u requestu uvedena verze HTTP/1.1. Deklarací HTTP/1.1 totiž netvrdíte, že podporujete nebo používáte všechny jeho vymoženosti.

[Filip Jirsák]

V RFC 1945 (HTTP 1.0) je uvedeno toto:

Request-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as Entity-Header fields.

Deklarací HTTP/1.1 klient tvrdí, že je alespoň na minimální úrovni kompatibilní s HTTP 1.1 (což na klientské straně znamená např. povinnou hlavičku Host). Jinak HTTP 1.1 vzniklo z velké části standardizací právě těch nových a experimentálních hlaviček HTTP 1.0, jako Host nebo Connection, takže se zákonitě musely používat hlavičky nedefinované v HTTP 1.0 před standardizací HTTP 1.1.

Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ale byla by to pouze teoretická práce (nikdo to nepoužívá, ale určitě by v protokolu chtěly tohle).

[Michal Kubeček]

Tak si přečtěte ještě RFC 2145, sekci 2.3:

An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. An HTTP client MUST NOT send a version for which it is not at least conditionally compliant.

An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy.

[Filip Jirsák]

To ale není v rozporu. Pokud já jako klient podporuji nejvýše verzi 1.0, nemůžu posílat verzi 1.1, ale právě tu 1.0.

[Michal Kubeček]

V tom případě ovšem nepodporujete hlavičku Host, takže tam nemá co dělat.

[Filip Jirsák]

Podporuju – jako novou nebo experimentální.

[Michal Kubeček]

Nová a experimentální? Devět let po RFC 2616 a jedenáct a půl roku po RFC 2068? To opravdu ani trochu nevypadá jako účelová konstrukce vymyšlená k obhájení neobhajitelného…

Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).

[cronin]

Mimochodem, docela by mne zajímalo, kolik z těch, kdo dnes lpí na HTTP/1.0, si je vědomo, jaký je časový odstup mezi RFC 1945 (specifikace HTTP/1.0) a RFC 2068 (první verze specifikace HTTP/1.1).

Hlasim sa medzi tych, co by si priali, aby aspon fungovalo to http/1.0.

Casovy rozdiel som nikdy neskumal. However, je vyrazne jednoduchsie implementovat prijatie http message tak, ze prijmem cely msg a az potom zacnem parsovat, zatial co persistent connections musim on-the-fly parsovat hlavicku, aby som zistil Content-Length. Uznavam, vo vseobecnosti nie je dobry pristup tahat cely msg do pamate (hehe, co ak je odpovedou DVD ISO image?), ale v specialnej aplikacii, ktoru som robil, toto nebolo issue. Zaroven nie je potrebne riesit 1xx status codes, a pod.

Dost mi vsak liezlo na nervy, ked som jednemu velmi rozsirenemu open source browseru z pozicie http servera povedal, ze ovladam HTTP/1.0 a prajem si vypnute keep-alive a prosim ho o uzatvaranie spojenia po kazdom msg, a on mi napriek tomu cpal HTTP/1.1 requesty, pouzival http keep-alive, a spojenia zasadne neuzatvaral.

Takze nelipnem striktne na http/1.0, ale ked je klient ci server on poziadany, mal by fungovat.

[Filip Jirsák]

Nelpím na HTTP 1.0 pro běžnou komunikaci mezi prohlížečem a serverem. Ale pro základní otestování HTTP komunikace je protokol verze 1.0 mnohem jednodušší. Když pošlu serveru dotaz v HTTP 1.1 a on mi odpoví kódem 1xx nebo začne posílat odpověď po částech (chunked encoding), budu z něj mít opravdu radost… Pokud server alespoň vzdáleně odpovídá standardu HTTP 1.0, nemůže ho hlavička Host rozhodit a maximálně ji bude ignorovat. Pokud by ji ignoroval, s HTTP 1.1 bych u něj asi neuspěl o nic lépe.

[Ash]

Naprosto souhlasím, nechápu jak někdo může někomu doporučovat pro "ruční" komunikaci HTTP/1.1 (???) jen proto, aby mohl "hyperkorektně" použít hlavičku Host.

Pokud někdo uvede HTTP/1.1 tak tím tvrdí, že tento protokol ovládá, ale to při ruční komunikaci zpravidla není pravda, takže správné je použít HTTP/1.0 a uvést hlavičku Host tam, protože vzhledem ke stáří HTTP/1.0 kterým se tu někdo oháněl je jasné, že sever to pochopí.

[Michal Kubeček]

aby mohl "hyperkorektně" použít hlavičku Host

To hyper- je tam zcela nadbytečné, proč nenapíšete prostě jen korektně?

Pokud někdo uvede HTTP/1.1 tak tím tvrdí, že tento protokol ovládá, ale to při ruční komunikaci zpravidla není pravda

Smím se zeptat proč?

použít HTTP/1.0 a uvést hlavičku Host tam, protože vzhledem ke stáří HTTP/1.0 kterým se tu někdo oháněl je jasné, že sever to pochopí

Jasné to zdaleka není. A nejde tu ani tak o stáří HTTP/1.0, ale o to, že (1) první verze specifikace HTTP/1.1 vyšla před jedenácti a půl lety, takže to není nějaká horká novinka, které bychom se měli bát, a (2) mezi specifikací HTTP/1.0 a první verzí specifikace HTTP/1.1 uběhlo pouhých sedm měsíců a v samotném RFC 1945 je zmínka, že se očekává brzké nahrazení.

[cronin]

Ostatně protokol, který by nebyl dopředně kompatibilní a nepovoloval rozšíření, by byl celkem k ničemu – nebylo by možné jej prakticky rozvíjet a nové verze protokolu by nevycházely z praxe (co se používá), ...

No, HTTP protokol je sice krasne otvoreny, dopredne kompatibilny a uzastne flexibilny, ale aj velmi nepresny, neuveritelne vagny a na niektorych miestach dokonca specifikacia odporuje sama sebe. Ak webdizajneri vedia, ze vebove prehliadace predstavuju "vitaztvo pocitaca nad clovekom", developeri webovych servero, proxy serverov a http klientov nie su na tom o nic lepsie. A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP. Vsetky tri uvedene role som si mal tu moznost do sytosti vyskusat.

[Filip Jirsák]

A vsetci, co sa zaoberaju bezpecnostou webovych aplikacii vedia, ze 95% bezpecnostnych problemov webovych applikacii suvisi prave s tym, ze ako prenosovy protokol je pouzite prave HTTP.

To bych tedy těch 95 % chtěl vidět. Bezpečnostní problémy webových aplikací zpravidla znamenají ovlivnění serverové aplikace nebezpečným vstupem (např. SQL injection, PHP include apod.), další jsou pak problémy důvěryhodnosti dat v prohlížeči (XSS a různé další způsoby komunikace a kradení údajů mezi doménami). Nic z toho s HTTP nesouvisí. Další druh problému může být buffer overflow, ale to zase s HTTP nijak nesouvisí. Z hlediska bezpečnosti je nešťastný třeba pohrobek HTTP 1.0, kdy ukončení spojení ze strany serveru může být regulérní konec přenosu (místo aby bylo nutné vždy určovat délku entity).

[Michal Hybner]

Napadlo mě zkusit anonymizer a přes něj všechny stránky fungují. Myslím, že to asi bude problém Vodafonu v souvislosti s nově zavedenou cenzurou možná něco pokazili. Napsal jsem jim, prý mě budou kontaktovat do 3 dnů. Ale je zajímavé, že všechny ty stránky fungují ze standartního prohlížeče v mobilu (Nokia) i v Opera Mini. Netuší někdo jak to teda opravdu je? Případně nějaké rady jak to "debugovat", nějak zjistit co se s těmy požadavky cestou k serveru a zpět děje?

[Andrej Herceg]

Pokiaľ viem, tak Opera Mini komunikuje cez server firmy Opera. Ten tú stránku načíta a "optimalizuje" ju. (takže Vodafon vidí len tú komunikáciu so serverom firmy Opera)

Je možné, že rovnako funguje aj ten prehliadač od Nokie.

[Luboš Doležel (Doli)]

Hmm, já bych jim napsal tak možná konec smlouvy - tohle je nepřijatelné chování. Než bych vyřídil přechod, tak bych použil tunel na nějaký server atd.

[powalec]

Tak koukám s tím nic od té doby neudělali, mě se neotevírá půlka korektních webů! Co odpověděli, pokud vůbec?

[cronin]

Bolo by dobre vidiet celu http hlavicku (live headers plugin do ff, napr.).

Moj drahy provider v snahe zabranit pouzivaniu routerov v bytoch, forcuje pouzivanie DHCP; takze ak sa z ich pohladu koncove zariadenie nekonfiguruje pomocou DHCP, akykolvek http traffic presmeruju pomocou

HTTP/1.0 307 OK
Location: http://a.redirect.info/blabla/

(na stranku informujucu o povinnosti nastavit si DHCP; je tam formular, predvyplneny na nieco v zmysle "ano, rozumel som, nastavim si dhcp"; po jeho odoslani sa pripojenie obnovi.

Nemohlo by to byt nieco podobne v Tvojom pripade?

[Michal Hybner]

Celá hlavička je zde.

http://www.blog.cz/

GET / HTTP/1.1
Host: www.blog.cz
User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs; rv:1.9) Gecko/2008052912 Firefox/3.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: cs,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 403 not authorized
Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455)
Date: Mon, 30 Jun 2008 18:06:03 GMT
Accept-Ranges: bytes
Content-Type: text/html
Content-Length: 1258
----------------------------------------------------------

Ale moc jsem z toho nevyčetl. Žádné přesměrování jako v tvém případě se nekoná. Prostě 403 a konec.

[petr_p]

Vizte hlavičku Server a pak Vodafone UK Deploys 724 Solutions' X-treme Mobility Gateway; Production Deployment of a Linux Blade Gateway a Multi-Service Platform (XMP) od 724 Solutions.

[Luboš Doležel (Doli)]

Server: XMS (724Solutions HTA XMP_40_M1_B035 20080226.125455)

Jenže na blog.cz ve skutečnosti běží Apache. Právně znalí lidé, není tohle klasifikovatelné jako porušování listovního tajemství nebo tak něco?

[Tomáš]

Moj drahy provider v snahe zabranit pouzivaniu routerov v bytoch, forcuje pouzivanie DHCP; takze ak sa z ich pohladu koncove zariadenie nekonfiguruje pomocou DHCP, akykolvek http traffic presmeruju ...

Jak se jim to daří? Vždyť i takový router umí DHCP (na jednom rozhraní klient, na druhém server). Dokud nerozbalí packet, tak nemůžou nic vědět (oni nemůžou nic vědět ani tak, protože virtualizační nástroje můžou taky dělat NAT).

[petr_p]

Podívjte se na hodnotu TTL v paketech, které vám přijdou z HTTP komunikace na tento server. Pokud tam je proxy, tak budete mít asi jiný počet hopů.

Zkuste také traceroute přes TCP/80 (traceroute --tcp --port=80 www.blog.cz), implicitní je přes UDP, na což se HTTP filtry samozřejmě nechytají.

[Štefan]

Příloha:

• restricted11.gif (54740 bytů)

Mně se to stává taky, a to i na mobilu (Nokia E51 browser). Přes Operu Mini samozřejmě běhá všechno. A také je tento problém jen u Vodafonu Na stálo. Pomáhá jen odpojit se a znovu připojit, to změní IP adresu a skrytou stránku zpřístupní