[zorp-hu] ssh, https

[Balazs Scheidler]

On Thu, 2005-08-11 at 18:04 +0200, Attila Nagy wrote:
> Balazs Scheidler wrote:
> > ez milyen openssl, milyen gcc-vel forditva? esetleg disztro? nalam
> > nagyjabol negyedennyi jon ki (PIV 3GHz, openssl 0.9.7e, Debian sarge):
> Xeon:
> FreeBSD 5.4
> OpenSSL 0.9.7e 25 Oct 2004
> gcc version 3.4.2 [FreeBSD] 20040728
> 
> Opteron:
> FreeBSD 6.0
> OpenSSL 0.9.7e 25 Oct 2004
> gcc version 3.4.4 [FreeBSD] 20050518
> 
> Mindkét gép AMD64-es üzemmódban megy (azaz a Xeon EM64T, ahogy az Intel 
> szeretné hívni).

aha, ez indokolhatja a kulonbseget.

> > Ekkora kulonbseget nem indokol az orajel kulonbseg, bar a cache meret szamithat.
> 512 kB cache-sel rendelkező 3,06 GHz-es Xeon:
>                    sign    verify    sign/s verify/s
> rsa  512 bits   0.0008s   0.0001s   1268.6  13669.1
> rsa 1024 bits   0.0039s   0.0002s    258.5   4820.7
> rsa 2048 bits   0.0232s   0.0007s     43.1   1476.1
> rsa 4096 bits   0.1563s   0.0024s      6.4    416.5
> 
> A te géped megveri (lehet, hogy FSB, vagy valami chipset mágia, vagy 
> csak a FreeBSD ilyen gagyi? :).

nem tudom :) azt nem is mondtam, hogy notebook-rol van szo, ahhoz kepest
nem is rossz.

> >>Arra ott a második processzor. Ma már "fillérekért" lehet venni egy két 
> >>processzoros dual core opteronos gépet, amely a fenti benchmark szerint 
> >>olyan 4-6000 sign/s-et tudhat, persze csak ha ezzel foglalkozik...
> > Azert altalanos celu op.rendszerekben nehez linearis skalazodast elerni
> > tobb processzorra. Igazad lenne, ha a masodik processzor csak szamolna,
> > ha viszont betolod egy Linux ala, akkor a processzorok kozti context
> > switcheknek egy ido utan eleg nagy az overheadje.
> Persze, a processzek közötti környezetváltás is rengeteg idő, főleg ha 
> másik processzorra migrálja az OS. :)
> 
> A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön 
> thread/processz végezné, nem? Ebben az esetben gyakorlatilag 
> megvalósítható lenne az is, hogy ezeket a processzeket egyes 
> processzorra dedikálja a user, azokból pedig load balance-olt poolt építsen.
> Végeztetek esetleg mérést arra nézve, hogy egy ilyen lehetőség mennyit 
> segítene (a fentiekből azt feltételezem, hogy most a zorp nem külön 
> végzi ezeket a műveleteket, így nem is lehet procit dedikálni alá)?

Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem,
hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik
processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell
figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul
fussanak.

> 
> Ha jelentős lenne a különbség, sokat dobhatna a teljesítményen, főleg a 
> mostani multicore-os CPU-k esetében.
> 
> >>Az nCiphernek ha jól látom vannak Ethernet kártyával egybeépített 
> >>termékei is. Ezekről esetleg van valami tapasztalatotok? Itt megfelelő 
> >>felépítés esetén ez a késleltetés kiiktatható.
> > Nincs sajnos, de ez SSL-hez valoszinuleg nem illesztheto, csak
> > IPSec-hez, ahol mar egy osszerakott csomagot kell titkositani. Az SSL
> Persze, azt hiszem ezt már csak durva firmware hackkel lehetne 
> megoldani. De erre is volt már példa. :)

naja, ha az openssl magan a kartyan futna es lenne ott egy kulon TCP/IP
stack.

> >>Akkor ez az új kérdésem, ha még jó vagyok a válaszra. :)
> >>Cache-elhetők ezek az SSL kapcsolatok?
> > Elvileg igen.
> Az mit jelent? Az apache-ban például van SSL session cache. Van ilyen a 
> zorpban?

1) az openssl-ben van processzen beluli session cache, ezt kulon
implementalni nem kell

2) megneztem kozelebbrol, es sajnos ahogy a Zorp hasznalja az SSL-t, ugy
ez a cache nem mukodik. fel is vettem egy hibajegyet ezzel kapcsolatban.

> 
> Jobbat kérdezek (ha van): van lehetőség arra, hogy mondjuk memcached-del 
> ezt a session store-t több gépen is használhatóvá tegyük?

bar a memcached-t nem ismerem, de az OpenSSL lehetove teszi un.
"external session id cache" letrehozasat, ezt hasznalja az apache is a
fork()-olt processzek kotzi adatmegosztashoz.

> 
> Teszemazt ha valódi load balancingot szeretnénk, nem pedig IP alapú 
> stickys megoldást. (minden új kapcsolat mehet más zorpra, még ugyanarról 
> az IP-ről is)

lehet ilyet, bar nem tudom milyen gyakorlati elonnyel jarna. nyilvan a
kiesett node miatt a kliens atkerulhet egy masik gepre, de ott is max
egy kulcs-cseret kell vegrehajtania, es utana mar ott is cachelt a
kapcsolata.

> Lehet, hogy inkább doksit kellene olvasnom, de ha már így belejöttem, 
> megkérdezem azt is, hogy a többi (ha van) session jellegű infó közös 
> tárolására vizsgáltátok-e már egy ilyen elosztott tudás jellegű megoldás 
> előnyeit?

meg nem :)

> 
> Lehet, hogy teoretikus a kérdés, mert nem kezeltek ilyen infót, hülye 
> vagyok a zorphoz, na. :)

jelenleg session informaciot csak a peldanyon belul lehet megtartani,
ott viszont eleg egyszeru. (azaz azt meg lehet oldani kizarolag
Zorp-bol, hogy a sikeres POP3 authentikacio utan mukodik az SMTP, bar
ugye ezt mar tulhaladta a kor az SMTP auth miatt).

-- 
Bazsi