[Plone-IT] chiamata xmlrpc lenta (con zope + apache + SSL)

[luigi scarso]

2009/10/15 Francesco Benincasa <ciccio2000 a users.sf.net>:
> Ciao a tutti,
> in realta' forse sono un po' OT,
Uh -- sei *tu* OT oppure *questa* tua email ?
>pero' provo a chiedere, magari qualcuno ha
> avuto la stessa esperienza.
>
> Uso delle chiamate xmlrpc a zope, che sta dietro apache. Nelle aree sotto
> HTTPS capita a volte che ci metta piu' di 30 secondi, nelle altre va veloce,
> quindi sono abbastanza certo che sia un problema di negoziazione SSL su
> apache. Anche perche' sia lato client sia il metodo plone sono due righe di
> codice.
>
> Qualcuno ha affrontato un problema simile? Ossia la lentezza delle chiamate
> xmlrpc con zope dietro apache + SSL?
Ho fatto qualcosa di vagamente  assimilabile tempo fa,
forse c'è traccia nella mailing list.
E cmq sono molto interessato alla cosa.

>
> Grazie, ciao.
>
> P.S.: googlando l'unico suggerimento che ho trovato e' stato di non usare
> /dev/random nella direttiva SSLRandomSeed (o qualcosa del genere), cosa che
> gia' accadeva

Questo potrebbe essere comprensibile in termini di velocità ma non di sicurezza:

$>man random

The character special files /dev/random and /dev/urandom (present
since Linux 1.3.30) provide an interface to the kernel’s random
       number generator.  File /dev/random has major device number 1
and minor device number 8.  File /dev/urandom has major device num‐
       ber 1 and minor device number 9.

       The  random number generator gathers environmental noise from
device drivers and other sources into an entropy pool.  The genera‐
       tor also keeps an estimate of the number of bits of noise in
the entropy pool.  From this entropy pool random  numbers  are  cre‐
       ated.

       When read, the /dev/random device will only return random bytes
within the estimated number of bits of noise in the entropy pool.
       /dev/random should be suitable for uses that need very high
quality randomness such as one-time pad or key generation.  When  the
       entropy pool is empty, reads from /dev/random will block until
additional environmental noise is gathered.

       A  read from the /dev/urandom device will not block waiting for
more entropy.  As a result, if there is not sufficient entropy in
       the entropy pool, the returned values are theoretically
vulnerable to a cryptographic  attack  on  the  algorithms  used  by
the
       driver.   Knowledge of how to do this is not available in the
current non-classified literature, but it is theoretically possible
       that such an attack may exist.  If this is a concern in your
application, use /dev/random instead.



-- 
luigi