2009/10/15 Francesco Benincasa <
[hidden email]>:
> 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
_______________________________________________
Plone-IT mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/plone-ithttp://www.nabble.com/Plone---Italy-f21728.html
