Jak funguje HTTPS

Ahoj, je to jednoduché, jak jsi správně napsal, protokol https je šifrován pomocí SSL nebo TLS (a to vždy) certifikát zde slouží k ověření identity (zda komunikuješ s tím správným serverem)

Zdravím, soukromé klíče jsou již importovany ve tvém prohlížeči. Certifikační agentury, které vydávají SSL certifikáty pro domény je automaticky dávají i do prohlížečů. Btw to je pro prohlížeče dobrej business. Čím levnější SSL certifikát, od anonymní certifikační agentury, tím větší pravděpodobnost, ze nebude v prohlížečích podporován a při přístupu na takto zabezpečeny web bude prohlížeč hlásit bezpečnostní riziko.Je to stejně, jako když si vygeneruje te vlastní SSL klíč a zabezpečuje si svou doménu. Mate to zdarma, ale prohlížeč hlásí bezpečnostní problém. Mno takto to funguje ;)

Ne, soukrome klice v prohlizeci nejsou. Proto jsou soukrome, aby je nemel kazdy.Pro puvodniho tazatele. Jestli prectes anglicky text, docela podrobne vysvetleni je tady: http://www.moserware.com/2009/06/first-few-millise... Strucna verze (pro bezne pouziti bez klientskeho certifikatu) - pri spojeni posle server svuj certifikat jako odpoved klientovi, ktery s nim navazuje spojeni. Jeho pravost je overitelna, protoze ten certifikat je podepsany certifikacni autoritou a jeji klic je uz ulozen v prohlizeci nebo primo v systemu klienta. Diky tomu muze klient poslat serveru nejaka data sifrovane. A pomoci toho si vzajemne dohodnou nahodny sifrovaci klic, ktery plati pouze pro to jedno spojeni. Je to trochu zjednoduseny popis, ale jako zaklad snad staci.

"Přece potřebuju ještě soukromý klíč podle kterého se komunikace šifruje ne?"Ne. Soukromy klic je pojem z asymetrickeho sifrovani. To je pouzito jen na zacatku spojeni pro vymenu zakladnich informaci, a v beznem pripade staci, aby mel soukromy klic jen server, na ktery se pripojujes.Samotne spojeni je uz potom sifrovano symetrickou sifrou, kde klic/heslo musi znat oba a musi zustat utajene.

S Jirkou plne souhlasim. Pro jednossi pochopeni lze to vysvetlit tak, ze server a klient si potrebuji dohodnout na nejakym spolecnem klici, kterym by odemkli zasifrovana data. Nejdrive tehdy potrebuji tento klic nejakym zpusobem sharovat, aby vedeli JEN oni dva, jaky je spolecny klic. Aby se to mohlo tedy sharovat bezpecne, tak se pouziva asymetricky sifrovani. Jednodusse si prestavte, ze server posila klientovi uzamceny box s mensim otvorem. Klic na tento box ma pouze server. Do tohoto boxu klient hodi spolecny klic a posle box zpet serveru. Server box odemkne vlastnim klicem a zijsti pak, jaky je spolecny klic. Tento spolecny klic si server a klient dale pouzivaji ke odemceni zasifrovanych dat.Tehdy asymetrickym sifrovanim se pouziva pro posilani public key mezi klientem a serverem, dale pak probiha jen symetricky sifrovani, kdyz o spolecnym klici uz vi bezpecne jen server a dany klient.

No, je to tak, že https je šifrováno asymetrickým šifrováním a to poměrně dobře. Při slušné implementaci protokolu je to velmi bezpečné. Tedy odposlech běžící session je běžně neřešitelná věc. Co ale je samozřejmě problém je to, že při startu session si musí obě strany vyměnit veřejné klíče, což by ideálně mělo proběhnout jiným kanálem, ale tak to nebývá. Oficiálně řečeno je problém ověřit autenticitu předávaných klíčů. Proto se protokol https dá nejlépe odposlouchávat tak, že se už ve fázi vytváření spojení mezi klienta a server zařadí "proxy", která naváže https spojení s klientem a druhé https spojení s požadovaným serverem a v proxy jsou k dispozici tím pádem nešifrovaná data a lze je libovolně upravovat. Tohle lze pochopitelně detekovat, ale ne jednoduše a většina uživatelů to nemá šanci zjistit. Další už si domyslíte sám.

"vetsina uzivatelu to nema sanci zjistit" - krome toho, ze jim v kazdem rozumnem prohlizeci vyskoci varovani, ze certifikat serveru neodpovida, a musi podniknout nekolik kroku, aby se v tom spojeni dalo pokracovat...

Přesně. A třeba mně Komerční banka doporučovala jeden software, který to hlídá automaticky:Trusteer Rapporthttps://www.kb.cz/bezpecnost/klient/

Opět se nudíte?! Vše je popsáno na síti Internet, včetně příslušných RFD, třeba: http://tools.ietf.org/html/rfc2818 .Jen byste se nemusel opět nudit a pokud se opravdu zajímáte, pak hledat. Ovšem vás to nezajímá, jen opět prudíte.

Pardon, RFC, Troll mne opravdu prudí.

Certifikát a soukromý klíč tam je jen pro ověření identity serveru. Tedy aby jsi měl jistotu že komunikuješ s tím správným serverem a nikoli s hackerem, co se tam přichomít.Pro samotnou komunikaci se používá klasická proudová šifra na heslo. Heslo pro šifru si klient a server dohodnou na začátku komunikace.