https na virtualech nad jednou IP

[Richard Willmann]

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

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.