https na virtualech nad jednou IP

[David Rohleder]

mailinglists at nocomment.sk ("Richard Willmann") writes:

> ehm, no na SSL nie som zrovna expert, ale moje vedomosti su zhruba
> nasledovne:
>
> 1. server posle svoj certifikat obsahujuci nejake udaje ako napr. verejny
> kluc, URL, meno company atd. podpisany CA
> 2. klient si overi digitalny podpis CA na certifikate
> 3. klient posle nejaky nahodny string zakodovany servrovim verejnym klucom
> 4. server posle spat dekodovany string ziskany od klienta


No priblizne to mate predstavu jak to funguje, ale:

nahodna cisla jsou poslana v prvni zprave  (prekvapive nepodepsana) jeste pred
certifikatem. server toto nahodne cislo neposila zpet, ale posle sve
vlastni cislo (opet nepodepsane), pak nasleduje certifikat serveru,
potom vymena klicu, vypocet master_secret z pre_master_secret, vypocet
klicu, IV, MAC sdilenych tajemstvi, a pak uz by to mohlo byt vsechno
(zjednodusena verze bez pouziti klientova certifikatu).


K vymene klicu se rovnez nepouziva vzdy DH, ale libovolny dohodnuty
algoritmus (RSA, Fortezza).

>
> toto staci aby klient zistil ze dostal platny nezfalsovany
> certifikat (overenie certifikatu ako takeho via CA a digitalny podpis) a to
> ze ten kto mu poslal certifikat je naozaj opravnenym vlastnikom certifikatu
> (ked mu posle spat spravny retazec, musi mat prislusny privatny kluc).
>
> vyssie uvedene je bezpecne aj proti utokom man in the middle of course. To
> zabezpecuje najma krok 3 a 4.
>
> k tomu este treba pridat fazu, pri ktore sa bezpecne vymeni kluc, ktory sa
> pouzije pri samotnom sifrovani. SSL pouziva na sifrovanie symetricky sifru z
> dovodu jej nizsich narokov na CPU.
>
> Ako funguje overenie klienta som uz niekde cital, ale priznam sa ze moc si
> to nepamatam.
>
>
> d.
>
> rwi
>
>
>
> ----- Original Message -----
> From: "David Rohleder" <davro at ics.muni.cz>
> To: <net at cs.felk.cvut.cz>
> Sent: Friday, May 18, 2001 5:01 PM
> Subject: Re: https na virtualech nad jednou IP
>
>
> > dan at gw.nic.cz (Dan Lukes) writes:
> >
> > > David Rohleder wrote:
> > >
> > > > Ne tak docela. Navazovani spojeni vcetne predavani certifikatu je
> > > > samozrejme nesifrovane. Ostatne jak jinak by klient ten certifikat
> > > > mohl ziskat, ze.
> > >
> > > No, cirou nahodou mate pravdu - certifikaty se skutecne vymenuji jeste
> > > v ramci nesifrovaneho spojeni - ale neni pravda, ze to tak musi byt, jak
> > > naznacujete v druhe vete.
> > > Certifikaty se nepouzivaji k sifrovani streamu dat, ale k podepisovani
> > > (k sifrovani se pouziva symetricka sifra a klic nam pomahaji vytvorit
> > > panove Diffie a Hellman), takze by klidne nejprve mohlo byt ustaveno
> > > sifrovane spojeni a teprve v ramci nej by probehla vymena certifikatu a
> > > autentizace - a take by to fungovalo.
> >
> >
> > Az na to, ze je to blbost, je to v podstate pravda.
> >
> > Vas postup neumoznuje ochranu proti utokum man in the middle. Nejdrive
> > se musi vymenit certifikaty a pak se nejakym zpusobem vymeni sifrovaci
> > klice, u kterych ovsem musi byt zajistena ochrana proti modifikaci
> > (prave podpisem, ktery overim daty z certifikatu). Teprve po uspesne
> > vymene klicu mohu uvazovat o tom, ze nove nasmlouvane sifrovane
> > spojeni je bezpecne.
> >
> > Takze s vasim postupem bych sice dosahl autentizovaneho spojeni,
> > nikoliv vsak bezpecneho.
>

--
-------------------------------------------------------------------------
David Rohleder						davro at ics.muni.cz
Institute of Computer Science, Masaryk University
Brno, Czech Republic
-------------------------------------------------------------------------