Taky by nebylo spatne konecne zavest SSL pro weby iinfa (root, lupa, mesec...). Podle Adama Langleyho je overhead SSL tak 1-2% (data z nasazeni SSL na googlich sluzbach):
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Jiny dobry napad je preferovat cipher-suites zarucujici perfect forward secrecy (napr. ECDHE-xxx):
http://www.imperialviolet.org/2011/11/22/forwardsecret.html
Mirne zvlastni je, ze Google preferuje RC4 pred AES. Z googlich blogu je zrejme, ze to delaji kvuli rychlosti. RC4 ma jiste teoreticke trhliny a je tezke pouzit spravne, nastesti zrovna v SSL se neprojevuji (na rozdil od fiaska s WEP).
Google, Youtube, Duckduckgo, Abclinuxu jsou taky verejne weby a vsechny pouzivaji HTTPS.
SSL krome tajnosti zarucuje i integritu (podobne jako DNSSEC, kdyz uz ma iinfo podepsane domeny). Sifrovana spojeni navic delaji odposlouchavani nebo automaticky profiling velmi tezky (a cim vetsi procento sifrovanych spojeni, tim tezsi odlisit podstatne a nepodstatne spojeni). Sifrovana spojeni nelze filtrovat (ve smyslu ruznych blacklistu ktere se vynareji).
Peter Eckersley (autor HTTPS Everywhere) urcite nekde uvadi velmi kratky a trefny duvod, jenom si ho uz nepamatuju ;-)
Pak jsou ty login hesla, ktere jiz zminovali jini. Tudiz je spis je otazka: proc ne?
> ale ještě nikdo mi nevysvětlil k čemu by to bylo dobré
V praci mame blokovane URL ktore maju v nazve "free" (zrejme kvoli stahovaniu free aplikacii), takze si napr. neprecitam http://www.root.cz/clanky/linuxove-standardy-od-free-standards-group/, ja konkretne som na to narazil ked som pracovne riesil problem s uvolnovanim pamate a v url bolo nieco ako "using-malloc-and-free". Pri HTTPS sa url filtrovat neda. Samozrejme ze som zavolal IT oddelenie, a za necele dva dni som sa uz na tu stranku dostal, ale je to otrava. Keby vsetky weby pouzivali SSL tak taketo problemy nemusim riesit.