Il 10 novembre 2009 14.48, Roberto Resoli <roberto.resoli@xxxxxxxxx> ha scritto: > 2009/11/10 Roberto Resoli <roberto.resoli@xxxxxxxxx>: >> Il 10 novembre 2009 12.34, Byte Surfer <bsurfer@xxxxxxxxxx> ha scritto: >>> >>> On 10/nov/09, at 06:54, Roberto Resoli wrote: >>> >>>> Dalla notizia su punto informatico. >>>> ---- >>>> Come spiegato dai due esperti di sicurezza in questo articolo, >>>> >>>> http://www.phonefactor.com/sslgap/ >>> >>> <CUT> >>> >>> interessante, >>> >>> OpenSSL ha disponibile un work-around >> >> A new version of OpenSSL (OpenSSL 0.9.8l) has been released, which >> removes SSL/TLS renegotiation. While this is not a fix for the for the >> SSL/TLS protocol vulnerability, it does mitigate against the resulting >> authentication gap. >> >> eliminare la rinegoziazione è una cosa ben pesante .... >> prevedo problemi. > > nel frattempo è stata proposta anche una modifica al protocollo: > https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/ > (ammesso che vi fidiate ancora di ssl ;-) ) Informazioni complete (incluso un PDF con la descrizione dettagliata del problema) si può trovare qui: http://extendedsubset.com/ da una prima occhiata, il workaround di openssl impedirà la funzionalità che richiede autenticazione client dipendente sull'url richiesto: Se ad esempio apache è configurato per servire https://pippo con certificazione solo server (la cosa più comune), ma richiede autenticazione client su https://pippo/pluto ,quindi con configurazione tipo: <Location /pluto > Options Indexes FollowSymLinks order deny,allow deny from all allow from all SSLVerifyClient require SSLVerifyDepth 5 SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire +OptRenegotiate SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_O} eq "Disney" </Location> Credo che la cosa non funzioni più, perchè il richiamo di https://pippo e poi di https://pippo/pluto innescherebbe una rinegoziazione. ciao, rob -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx