Názory k článku
SSL už aj pri hľadaní v Google
-
Jack (neregistrovaný)
Mala prosba o radu (resp. vysvetleni)…
Pri hledani v googlu je dotaz videt v URL. Pry se to u ISP neobjevi, protoze je zbytek URL predavan az po uskutecneni zabezpeceneho spojeni (aspon tak sem to pochopil). Ale to je snad jenom kdyz dam https://googe.com a POTOM do policka zadam dotaz.
Ale co kdyz (napr. pri vyhledavani z adresniho radku) zadavam dotaz rovnou a zaroven s adresou. Tj. otevru prohlizec a bez otevreni nejake stranky s polickem zadam rovnou adresu:
https://www.google.com/search?hl=cs&source=hp&q=POKUS
Objevi se POKUS u ISP?
Nebo tam dojde jenom pozadavek na https://www.google.com a zbytek az potom (sifrovane)?
Predem moc dekuju. -
Dokonca tam nedojde ani poziadavka https://www.google.com. Jedine, co dojde k ISP, je DNS poziadavka na www.google.com a potom ISP vidi uz len TCP packety obsahujuce SSL protokol na nejaku IP adresu. Co sa tam prenasa, to by nemal vediet zistit, ak nepodvrhne certifikat alebo sa mu nepodari rozbit sifrovanie.
-
Jack (neregistrovaný)
Whow, dekuju za (velice rychle) info.
Akorat (je mi lito, ale sitovym protokolum fakt moc nerozumim), chapu to teda dobre tak, ze tu cast „/search?hl=cs&source=hp&q=POKUS“ z dotazu „fyzicky“ odfiltruje (resp pocka s ni) uz muj pocitac?
Tedy ze z moji sitovky nejdriv odejde pozadavek k ISP na www.google.com bez toho zbytku, pak se navaze sifrovane spojeni primo s Googlem a az teprv potom z moji strany odejde to „/search?hl=cs&source=hp&q=POKUS“? -
Jiří J. (neregistrovaný)
Podrobněji to funguje asi nějak takhle:
1) tvůj PC pošle DNS A request www.google.com na DNS server
2) v případě CNAME to může opakovat vícekrát, než se dohrabe k IP adrese googlu
3) tvůj PC pošle TCP SYN na IP adresu googlu
4) google odpoví s TCP SYN,ACK
5) tvůj PC mu pošle TCP ACK
následující komunikace probíhá již na layer-5, tedy v TCP payloadu, proto vynechám l4 věci jako TCP ACK
6) tvůj PC pošle googlu SSL Client Hello
7) obdobně google server vrátí Server Hello
8) server pošle certifikát
9) tvůj PC si zjistí věrohodnost certifikátu, tedy DNS query na thawte/verisign/etc, připojení se tam, ..
10) pak si tvůj PC a google server dohodnou detaily (pro více viz SSL/TLS RFC)
11) přenos HTTP dat
Tedy vše od bodu 9 (ověření certifikátu) ISP nemá šanci vidět/logovat, aniž by použil falešný certifikát.
Problém tohoto modelu je v nemožnosti „namapovat“ více domén na jednu IP adresu (třeba pomocí Apache name-based virtual hostů), právě z principu fungování SSL, tedy „vejce versus slepice“. -
Sten (neregistrovaný)
To mapování funguje pomocí techniky Server Name Indication, kdy klient pošle nešifrované jméno webového serveru, se kterým chce komunikovat, spolu se žádostí o certifikát (tedy ISP kromě DNS požadavků uvidí to jméno – a pouze jméno – i v SSL/TLS požadavku). Starší prohlížeče to však nepodporují
