UK, tutti a scuola di IT

Il Segretario di Stato Lord Mandelson oltre ad accarezzare le disconnessioni chiede alle università britanniche di far fiorire tra gli studenti capacità ad alto profilo tecnologico. Ne beneficeranno l'economia, il mercato, l'innovazione

Roma – Dovrebbe esserci una maggiore competizione tra le università del Regno Unito, soprattutto se legata a programmi specificamente orientati verso le scienze, la tecnologia, l’ingegneria. Si tratta soltanto della prima di una serie di misure chiave invocate dal Segretario di Stato britannico Lord Mandelson, durante un recente discorso tenutosi alla House of Lords . Una strategia di ampio respiro, annunciata da Mandelson perché il governo di Londra si assicuri che le università forniscano agli studenti quelle competenze di alto profilo richieste da aziende, datori di lavoro e settori avanzati della ricerca.

Stando alla visione illustrata da Lord Mandelson, le stesse aziende dovrebbero contribuire alla causa sbandierata, investendo di più nella programmazione didattica universitaria oltre che nella sponsorizzazione degli studenti più brillanti e dotati. L’università dovrebbe, cioè, fare meglio da ponte tra lo studente ancora virgulto e la piattaforma degli sbocchi professionali. “Il governo – ha spiegato Mandelson – vuole che le università contribuiscano di più al processo di guarigione della nostra economia, per alimentare una crescita futura”.

Perché ciò avvenga nel migliore dei modi, il Segretario di Stato britannico ha illustrato uno scenario in cui venga data una maggiore priorità al bisogno di figure di alto livello tecnologico, nel campo della scienza, della tecnologia, dell’ingegneria e della matematica . Un’altra delle misure invocate da Mandelson rappresenta il tentativo di creazione di un sistema universitario part-time, che dia allo studente la possibilità di portarla a termine anche con un’esperienza lavorativa parallela.

Questa certo ambiziosa strategia è stata accolta con particolare entusiasmo da alcuni che vi hanno visto un potenziale beneficio per il business e l’innovazione legata all’information technology. Mandelson sembra aver dunque indossato la toga da rettore per dettare precise indicazioni al sistema-università, dopo aver lanciato in patria la patata bollente delle disconnessioni dei file sharer con il sistema detto dei tre colpi . Qualcuno ha consigliato a Mandelson di approfittare in prima persona delle future lezioni universitarie: per capire meglio come funzionano realmente un indirizzo IP o un tracker torrent.

Mauro Vecchio

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Gabibbo scrive:
    Belin che robba!!
    Nu so voiatri, ma pen po' riturnu au vegiu moddu de scangiase a roba cumme favan i nostri vegi sensa fa cammina' i dine'.
  • evilripper scrive:
    Di cosa dovremmo temere?
    Allora dall'articolo si desume che tale vulnerabilita' permette di iniettare dei comandi all'interno del flusso dati della transazione. Ora non possono decriptare i dati non possono quindi modificare i dati che ho inviato... Il pericolo maggiore quindi e' per il server che potrebbe eseguire operazioni non volute? Oltretutto come fanno a rintracciare quello che ha iniettato il codice maligno? La cosa preoccupante e' che hanno insabbiato senz patchare robe da matti! Sono da arrestare!
    • Spock scrive:
      Re: Di cosa dovremmo temere?
      No, aspetta. Leggendo l'articolo sembra che il "rogue MITM" usi un suo certificato per parlare con il client e il certificato del client per parlare con il "victim MS SSL server". Ciò non dovrebbe consentire di avere la possibilità di decifrare i messaggi provenienti da entrambe le direzioni?
      • ullala scrive:
        Re: Di cosa dovremmo temere?
        - Scritto da: Spock
        No, aspetta. Leggendo l'articolo sembra che il
        "rogue MITM" usi un suo certificato per parlare
        con il client e il certificato del client per
        parlare con il "victim MS SSL server". Ciò non
        dovrebbe consentire di avere la possibilità di
        decifrare i messaggi provenienti da entrambe le
        direzioni?No non decifra i dati che sono andatti al sever "vero" .. queli rimangono cifrati con una chiave (simmetrica) che il MTIM non è in grado di decifrare... a meno che il MTIM non abbia lo stesso certificato e la stessa chiave privata (cioè la stessa coppia di chiavi asimmetriche)!Il che è poco plausibile ovviamente.Può solo immettere dati nella connessione...Il che è un problema o meglio può essere un problema... ma è un problema che nulla ha a che vedere con la capacità del MITM di leggere i dati.
        • Spock scrive:
          Re: Di cosa dovremmo temere?
          Ma le chiavi simmetriche non vengono scambiate proprio in fase di handshake (e poi rigenerate riscambiate ad intervalli)?
          • Klut scrive:
            Re: Di cosa dovremmo temere?
            Riassunto, da quello che ho capito, in parole povere:- Il client richiede una negoziazione TLS- Il MITM intercetta la richiesta iniziale del client, e la mette da parte.- Il MITM avvia una propria sessione cifrata col server- Il MITM esegue qualche richiesta maligna- Il MITM forza una rinegoziazione, ad esempio chiedendo una risorsa per cui il server chiederà una rinegoziazione del certificato client, o una rinegoziazione degli algoritmi di cifratura, o più semplicemente avviando una rinegoziazione del certificato client su sua iniziativa.- La rinegoziazione avviene cifrata con la chiave che il MITM e il server hanno deciso. Il MITM può fare da traduttore tra client e server, facendo credere al client che la nuova negoziazione che sta avvenendo sia frutto della sua prima richiesta.- Client e server avviano una nuova sessione, con una nuova chiave. Il MITM ora non farà altro che inoltrare tutto quello che gli arriva. Il client sarà convinto di stare parlando direttamente col server, il server sarà convinto di non aver mai cambiato interlocutore.Il problema sta nel fatto che nella nuova sessione, a livello di TLS, non è evidenziato in nessun modo che questa è frutto di una rinegoziazione di una sessione precedente, quindi il client non può rendersi conto che qualcuno "ci ha già messo le mani".Se il protocollo di livello più alto non prevede a sua volta un meccanismo di sessione (oppure gestisce la sua sessione in chiaro, come fa spesso HTTPS con i cookie), neanche il server potrà rendersi conto di star parlando con un client diverso.
  • Quarzo Cristallo scrive:
    Advisory si dice ADVISORY
    come da titolo
  • tsdogs scrive:
    vulnerabilità controllo certificati
    per chi ha un po' di tempo:https://media.blackhat.com/bh-usa-09/video/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-VIDEO.movnon credo sia la stessa vulnerabilità ...
  • ullala scrive:
    Ma documentarsi no?
    In primis non si tratta di una vulnerabilità dell'SSL ne tantomeno di una vulnerablità del protocollo correlato all'uso di certificati da parte di un GENERICO CLIENT ssl/tls in se.Si tratta invece di una vulnerabilità correlata al protocollo HTTPS e in particolare legata al comando HTTP TRACE (http 1.1).Come spiega qui.http://www.kb.cert.org/vuls/id/867593Riassumendo la vulnerabilità è sfruttabile in certe condizioni con certe vulnerabilità lato browser e server e comunque sempre legata a HTTPS (non a SSL/TLS in se.
    • dfsfs scrive:
      Re: Ma documentarsi no?
      rimane il fatto che in 1 anno non ne sono venuti a capo...Ed ora è di dominio pubblico..
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: dfsfs
        rimane il fatto che in 1 anno non ne sono venuti
        a
        capo...
        Ed ora è di dominio pubblico..Ne sono venuti a capo...http://cvs.openssl.org/chngview?cn=18790
        • markoer scrive:
          Re: Ma documentarsi no?
          - Scritto da: ullala
          - Scritto da: dfsfs

          rimane il fatto che in 1 anno non ne sono venuti

          a

          capo...

          Ed ora è di dominio pubblico..
          Ne sono venuti a capo...

          http://cvs.openssl.org/chngview?cn=18790LOL, questo è un workaround, non un fix. La renegoziazione serve ed è parte della security del protocollo stesso. Se non effettui una renegoziazione periodica, aumentano le probabilità che un attacker raccolga campioni della sessione e riesca alla fine a decifrarla.La vulnerabilità è molto più complessa di come la credi, ed implica un cambiamento nel protocollo. Per questo sono mesi che tutti i maggiori vendor ne stanno discutendo - il cambiamento necessario è abbastanza semplice ma implica un aggiornamento radicale di tutti i client ed i server.Cordiali saluti
          • devil64 scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala

            - Scritto da: dfsfs


            rimane il fatto che in 1 anno non ne sono
            venuti


            a


            capo...


            Ed ora è di dominio pubblico..

            Ne sono venuti a capo...



            http://cvs.openssl.org/chngview?cn=18790

            LOL, questo è un workaround, non un fix. La
            renegoziazione serve ed è parte della security
            del protocollo stesso. Se non effettui una
            renegoziazione periodica, aumentano le
            probabilità che un attacker raccolga campioni
            della sessione e riesca alla fine a
            decifrarla.

            La vulnerabilità è molto più complessa di come la
            credi, ed implica un cambiamento nel protocollo.
            Per questo sono mesi che tutti i maggiori vendor
            ne stanno discutendo - il cambiamento necessario
            è abbastanza semplice ma implica un aggiornamento
            radicale di tutti i client ed i
            server.
            Secondo me se ne usciranno con la versione v4 e tutto il tempo che si stanno prendendo non è per una semplice patch, ma proprio per riscirvere il protocollo.Poi ci sarà l'aggiornamento dei servers e dei client con il nuovo protocollo. Sai le banche come saranno contente di avere i telefoni intesati delle massaie che non si collegano più ai loro conto correnti....

            Cordiali saluti
    • unaltro scrive:
      Re: Ma documentarsi no?
      Da cosa deduci che l' advisory che citi abbia qualcosa a che fare con quello di cui si parla?
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: unaltro
        Da cosa deduci che l' advisory che citi abbia
        qualcosa a che fare con quello di cui si
        parla?In sostanza nulla...Ho semplicemente sbagliato a cliccare sull'elenco dei link degli advisory.. può succedere..Il che non toglie che la sostanza della questione resti...Ovvero il buco è legato al supporto di un tipo di negoziazione presente in HTTPS e che in generale le implementazioni che non implementano questa rinegoziazione o non la supportano NON abbiano questa vulnerabiltà!
    • Illo Illi scrive:
      Re: Ma documentarsi no?
      Ma cosa stai scrivendo? Voglio pensare che volevi commentare un altro articolo.Leggiti i pdf qui: http://extendedsubset.com/?p=8E poi pentiti!
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: Illo Illi
        Ma cosa stai scrivendo? Voglio pensare che volevi
        commentare un altro
        articolo.
        Leggiti i pdf qui: http://extendedsubset.com/?p=8
        E poi pentiti!Quale è la parte di HTTPS che ti è sfuggita?
        • markoer scrive:
          Re: Ma documentarsi no?
          - Scritto da: ullala
          - Scritto da: Illo Illi

          Ma cosa stai scrivendo? Voglio pensare che

          volevi

          commentare un altro

          articolo.

          Leggiti i pdf qui:

          http://extendedsubset.com/?p=8

          E poi pentiti!
          Quale è la parte di HTTPS che ti è sfuggita?C'è scritto chiaramente che la vulnerabilità è in TLS e HTTP è solo una delle applicazioni di TLS. Quindi segui il consiglio e leggi :-)Cordiali saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala

            - Scritto da: Illo Illi


            Ma cosa stai scrivendo? Voglio pensare che


            volevi


            commentare un altro


            articolo.


            Leggiti i pdf qui:


            http://extendedsubset.com/?p=8


            E poi pentiti!

            Quale è la parte di HTTPS che ti è sfuggita?

            C'è scritto chiaramente che la vulnerabilità è in
            TLS e HTTP è solo una delle applicazioni di TLS.
            Quindi segui il consiglio e leggi
            :-)


            Cordiali saluti1) Segui anche tu please e trova una applicazione (non https based) vulnerabile thanks!2) evita (per favore) nel futuro di fare come hai fatto più sotto di dire corbellerie come:"Sì. Non se usa IPSec, ma se usa un tunnel su HTTPS lo è."Anche perchè openvpn non è in grado di usare ipsec (lavora solo in TLS/SSL) e un tunnel TLS/SSL NO è (purtroppo per te e per fortuna nostra e anche tua) "un tunnel su HTTPS"...Che ti sia chiaro o meno HTTPS e TLS/SSL sono due (ripeto due) cose diverse....Per questo motivo praticamente nessuna applicazione TLS/SSL (escluse quelle HTTPS) che io conosca implementa la rinegoziazione con le modalità che consentono di sfruttare la vulnerabilità.
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: Illo Illi
        Ma cosa stai scrivendo? Voglio pensare che volevi
        commentare un altro
        articolo.
        Leggiti i pdf qui: http://extendedsubset.com/?p=8
        E poi pentiti!Quale è la parte di HTTPS che ti è sfuggita?
    • NomeECognom e scrive:
      Re: Ma documentarsi no?
      - Scritto da: ullala
      In primis non si tratta di una vulnerabilità
      dell'SSL ne tantomeno di una vulnerablità del
      protocollo correlato all'uso di certificati da
      parte di un GENERICO CLIENT ssl/tls in
      se.

      Si tratta invece di una vulnerabilità correlata
      al protocollo HTTPS e in particolare legata al
      comando HTTP TRACE (http
      1.1).

      Come spiega qui.
      http://www.kb.cert.org/vuls/id/867593

      Riassumendo la vulnerabilità è sfruttabile in
      certe condizioni con certe vulnerabilità lato
      browser e server e comunque sempre legata a HTTPS
      (non a SSL/TLS in
      se.mi sa che prima di documentarsi,bisogna anche sapere *di cosa si parla*.L'advisory che hai riportato non è relativo al bug in questione.se ti interessa *documentarti*, puoi iniziare a leggere qui:http://secunia.com/advisories/37291/http://extendedsubset.com/?p=8http://www.ietf.org/mail-archive/web/tls/current/msg03928.htmlPS: per la cronaca, OpenSSL ha già rilasciato un workaround:http://cvs.openssl.org/chngview?cn=18790
      • ullala scrive:
        Re: Ma documentarsi no?
        victim MS IIS"Come sopra!

        PS: per la cronaca, OpenSSL ha già rilasciato un
        workaround:
        http://cvs.openssl.org/chngview?cn=18790Questo invece è esatto!... ma ..."OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION"Riguarda un tipo di sessione "LEGACY" usato in HTTPS!!!!Morale...Per documentarsi bisogna sapere leggere!Altrimenti riportare link a caso non aiuta!Saluti
        • Illo Illi scrive:
          Re: Ma documentarsi no?
          - Scritto da: ullala
          Morale...

          Per documentarsi bisogna sapere leggere!
          Altrimenti riportare link a caso non aiuta!E bisogna sapere anche di cosa si sta parlando. Tu evidentemente non ne hai idea.
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: Illo Illi
            - Scritto da: ullala

            Morale...



            Per documentarsi bisogna sapere leggere!

            Altrimenti riportare link a caso non aiuta!

            E bisogna sapere anche di cosa si sta parlando.
            Tu evidentemente non ne hai
            idea.Cioè ?vuoi dire che ad esempio Openvpn che usa SSL è vulnerabile? :)Oppure vuoi dire che qualunque server che non implementi (come invece viene fatto su quasi tutti... ma non tutti... i server http) la rinegoziazione è vulnerabile?O forse volevi dire che sei tu a non avere idea di ciò che stai dicendo?
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala[...]
            Cioè ?
            vuoi dire che ad esempio Openvpn che usa SSL è
            vulnerabile?
            :)Sì. Non se usa IPSec, ma se usa un tunnel su HTTPS lo è.
            Oppure vuoi dire che qualunque server che non
            implementi (come invece viene fatto su quasi
            tutti... ma non tutti... i server http) la
            rinegoziazione è vulnerabile?Sì, nel corso del tempo, un attaccante che collezioni campioni di sessione potrebbe decifrare la chiave usata per la criptazione del tunnel (che ti ricordo, in TLS/SSL è simmetrica, subito dopo l'handshake delle chiavi effettuato con criptazione asimmetrica) ed essere in grado di decifrare il contenuto del tunnel.La periodica rinegoziazione dei certificati permette di variare la chiave del tunnel, rendendo meno semplice un attacco MTM.Per evitarti confusione, questo non ha nulla a che fare con la vulnerabilità in questione nell'articolo, che implica la possibilità di un attaccante di iniettare del testo nella connessione, ma non di leggere il contenuto della connessione corrente. In questo senso, al momento puoi scegliere cosa è più importante: che un attaccante riesca ad iniettare del proprio testo nella connessione, o che riesca ad intercettare quella attuale? in molti casi probabilmente - specialmente quando il protocollo non è semplice web browsing over HTTP ma magari SOAP o REST, eccetera, o comunque qualsiasi cosa implichi un checksum fatto dal server sulla richiesta - tanto vale NON usare il workaround ed aspettare che venga aggiornato il protocollo.
            O forse volevi dire che sei tu a non avere idea
            di ciò che stai dicendo?LOL.Cordiali saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala
            [...]

            Cioè ?

            vuoi dire che ad esempio Openvpn che usa SSL è

            vulnerabile?

            :)

            Sì. Non se usa IPSec, ma se usa un tunnel su
            HTTPS lo
            è.
            openvpn non usa "tunnel https" usa ssl e basta!Https e ssl sono cose diverse!Una connessione openvpn NON è un tunnel https!Almeno questo speravo lo sapessi!è un tunnel TLS (o SSL) che è cosa diversa!


            Oppure vuoi dire che qualunque server che non

            implementi (come invece viene fatto su quasi

            tutti... ma non tutti... i server http) la

            rinegoziazione è vulnerabile?

            Sì, nel corso del tempo, un attaccante che
            collezioni campioni di sessione potrebbe
            decifrare la chiave usata per la criptazione del
            tunnel (che ti ricordo, in TLS/SSL è simmetrica,
            subito dopo l'handshake delle chiavi effettuato
            con criptazione asimmetrica) ed essere in grado
            di decifrare il contenuto del
            tunnel.oNiente affatto la chiave di sessione (se non ha sue debolezze intrinseche) ed è comunque cifrata con la chiave asimmetrica o la crakki (perdonami la buttura del termine) perchè è "debole" o la crakki (cioè meglio non hai bisogno di farlo) perchè la conosci AKA ... sei uno degli endpoints!In altri casi sei senza alcuna speranza!

            La periodica rinegoziazione dei certificati
            permette di variare la chiave del tunnel,
            rendendo meno semplice un attacco
            MTM.La rinegoziazione dei certificati è una cosa che è diversa da quella citata nel bug in cui c'è una rinegoziazione della sessione che è un pochino cosa differente!Di per se la rinegoziazione dei certificati non è un problema!Ne tantomeno ti da modo di fare il man in the middle!In opnvpn non c'è affatto questo problema una sossione non parte in "TLS forse" e poi rinegozia una sessione "in SSL3 forse" e poi fa il fallback a una sessione "sslv2" e via elencando!E quello è il problema del bug in questione.Per il resto dovresti (scusa se sono ignorantello) mostrarmi con una sessione non rinegoziata in termini di protocollo (i certificati rinegoziali pure fin che vuoi) come riesci a fare il "man in the middle" dato che fino ad ora (se l'implementazione è corretta) nessuno c'è mai riuscito.

            Per evitarti confusione, questo non ha nulla a
            che fare con la vulnerabilità in questione
            nell'articolo, che implica la possibilità di un
            attaccante di iniettare del testo nella
            connessione, ma non di leggere il contenuto della
            connessione corrente. In questo senso, al momento
            puoi scegliere cosa è più importante: che un
            attaccante riesca ad iniettare del proprio testo
            nella connessione, o che riesca ad intercettare
            quella attuale? in molti casi probabilmente -
            specialmente quando il protocollo non è semplice
            web browsing over HTTP ma magari SOAP o REST,
            eccetera, o comunque qualsiasi cosa implichi un
            checksum fatto dal server sulla richiesta - tanto
            vale NON usare il workaround ed aspettare che
            venga aggiornato il
            protocollo.Ti ripeto che iniettare testo (come tu lo chiami) in una connessione TLS/SSL senza che il server implementi un fallback di rinegoziazione di sessione è del tutto fantastico!Fino a prova contraria!E se il server non ha bisogno di supportare un tale modo applicativo non lo fa!Punto e basta!A titolo di informazione sappi che SOAP è basato su HTTPS (e non su SSL) ancora una volta mi pare che la differenza non ti sia affatto chiara!


            O forse volevi dire che sei tu a non avere idea

            di ciò che stai dicendo?

            LOL.

            Cordiali salutiRicordialissimi
          • Klut scrive:
            Re: Ma documentarsi no?

            La rinegoziazione dei certificati è una cosa che
            è diversa da quella citata nel bug
            [...]
            In opnvpn non c'è affatto questo problema una
            sossione non parte in "TLS forse" e poi rinegozia
            una sessione "in SSL3 forse" e poi fa il fallback
            a una sessione "sslv2" e via
            elencando!
            E quello è il problema del bug in questione.
            [...]
            Per il resto dovresti (scusa se sono
            ignorantello) mostrarmi con una sessione non
            rinegoziata in termini di protocollo (i
            certificati rinegoziali pure fin che vuoi) come
            riesci a fare il "man in the middle" dato che
            fino ad ora (se l'implementazione è corretta)
            nessuno c'è mai
            riuscito.Ora capisco perché a me hai risposto citandomi il fallback a SSL 2...No, hai capito proprio male, la vulnerabilità sta proprio nella rinegoziazione dei certificati.Leggiti i PDF se vuoi capire nel dettaglio come funziona (o leggiti il mio commento all'ultimo thread, che però non credo possa essere altrettanto chiaro).
          • mattomattom atto scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala
            [...]

            Cioè ?

            vuoi dire che ad esempio Openvpn che usa SSL è

            vulnerabile?

            :)

            Sì. Non se usa IPSec, ma se usa un tunnel su
            HTTPS lo
            è.rotfl :D openvpn non puo' usare ipsec e neanche https (ssl/tls!=https)
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: mattomattom atto
            - Scritto da: markoer

            - Scritto da: ullala

            [...]


            Cioè ?


            vuoi dire che ad esempio Openvpn che usa SSL è


            vulnerabile?


            :)



            Sì. Non se usa IPSec, ma se usa un tunnel su

            HTTPS lo

            è.

            rotfl :D openvpn non puo' usare ipsec e neanche
            https (ssl/tls!=https)Non conosco openvpn (infatti ho detto "se") visto che non usiamo né tunnel SSL né soluzioni open source. Se usa TLS o SSL, è comunque vulnerabile. È vulnerabile se usa openssl, se vuoi metterla così...Cordiali saluti
        • NomeECognom e scrive:
          Re: Ma documentarsi no?
          victim MS
          IIS

          "
          Come sopra!




          PS: per la cronaca, OpenSSL ha già rilasciato un

          workaround:

          http://cvs.openssl.org/chngview?cn=18790
          Questo invece è esatto!
          ... ma ...
          "OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION
          Riguarda un tipo di sessione "LEGACY" usato in
          HTTPS!!!!

          Morale...

          Per documentarsi bisogna sapere leggere!
          Altrimenti riportare link a caso non aiuta!

          SalutiDa http://extendedsubset.com/?p=8 (la pagina dove Steve Dispensa,il ricercatore che da tempo ha individuato il problema,spiega il bug):"****Transport Layer Security (TLS, RFC 5246 and previous, including SSL v3 and previous)***** is subject to a number of serious man-in-the-middle (MITM) attacks related to renegotiation""Although this research has focused on the implications specifically for HTTP as the application protocol, the research is ongoing and many of ******** these attacks are expected to generalize well to other protocols layered on TLS. *******"Leggere no,eh?Qualsiasi,e dico proprio qualsiasi,portale di sicurezza parla di bug del protocollo SSL:Secunia: http://secunia.com/advisories/37291Securityfocus: http://www.securityfocus.com/bid/36935etc.l'unico che sostiene che è un bug relativo *esclusivamente* al protocollo https (riportando tral'altro come link un advisory di *tutt'altro* bug...tral'altro noto da svariati anni..vedi un pò te il date reference...)sei te...non ti viene in mente che ,forse, sei tu ad aver mal intepretato lo studio dei link riportati?Saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            victim MS

            IIS



            "

            Come sopra!







            PS: per la cronaca, OpenSSL ha già rilasciato
            un


            workaround:


            http://cvs.openssl.org/chngview?cn=18790

            Questo invece è esatto!

            ... ma ...


            "OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION

            Riguarda un tipo di sessione "LEGACY" usato in

            HTTPS!!!!



            Morale...



            Per documentarsi bisogna sapere leggere!

            Altrimenti riportare link a caso non aiuta!



            Saluti

            Da http://extendedsubset.com/?p=8 (la pagina dove
            Steve Dispensa,il ricercatore che da tempo ha
            individuato il problema,spiega il
            bug):

            "****Transport Layer Security (TLS, RFC 5246 and
            previous, including SSL v3 and previous)***** is
            subject to a number of serious man-in-the-middle
            (MITM) attacks related to
            renegotiation"

            "Although this research has focused on the
            implications specifically for HTTP as the
            application protocol, the research is ongoing and
            many of ******** these attacks are expected to
            generalize well to other protocols layered on
            TLS.
            *******"

            Leggere no,eh?

            Qualsiasi,e dico proprio qualsiasi,portale di
            sicurezza parla di bug del protocollo
            SSL:

            Secunia: http://secunia.com/advisories/37291
            Securityfocus:
            http://www.securityfocus.com/bid/36935

            etc.

            l'unico che sostiene che è un bug relativo
            *esclusivamente* al protocollo https (riportando
            tral'altro come link un advisory di *tutt'altro*
            bug...tral'altro noto da svariati anni..vedi un
            pò te il date reference...)sei te...non ti viene
            in mente che ,forse, sei tu ad aver mal
            intepretato lo studio dei link
            riportati?

            SalutiOk allora!Trova una implementazione non HTTPS in cui la vulnerabilità sia sfruttabile (nessuno ne ha trovate)...Ti ripeto la domandina...OPENVPN è vulnerabile?
          • NomeECognom e scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala
            Ok allora!
            Trova una implementazione non HTTPS in cui la
            vulnerabilità sia sfruttabile (nessuno ne ha
            trovate)...

            Ti ripeto la domandina...
            OPENVPN è vulnerabile?guarda, rinuncio a continuare.hai ragione: Il problema è relativo esclusivamente all'https.se vuoi informa (e consiglia di documentarsi) tu tutti gli altri (compreso chi ha scoperto il bug,securityfocus e tutti i vari portali di information security).Buon weekend
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: NomeECognom e[...]
            guarda, rinuncio a continuare.[...]
            Buon weekendLOL, gli ho detto la stessa identica cosa qualche post più sotto ;-)Cordiali saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: NomeECognom e
            [...]

            guarda, rinuncio a continuare.
            [...]

            Buon weekend

            LOL, gli ho detto la stessa identica cosa qualche
            post più sotto
            ;-)

            Cordiali salutiVa vene voi continuate ad attendere la pach per openvpn ... vi consiglierei (prudenzialmente) di non trattenere il respiro nell'attesa!
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala
            - Scritto da: markoer

            - Scritto da: NomeECognom e

            [...]


            guarda, rinuncio a continuare.

            [...]


            Buon weekend



            LOL, gli ho detto la stessa identica cosa
            qualche

            post più sotto

            ;-)



            Cordiali saluti

            Va vene voi continuate ad attendere la pach per
            openvpn ... vi consiglierei (prudenzialmente) di
            non trattenere il respiro
            nell'attesa!Come detto, non c'è "una patch" da attendere. (a parte che esiste un workaround per openssl, basta installare quello...). È il protocollo che necessita di modifiche, quindi la cosa è un po' più complicata.Cordiali saluti
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: NomeECognom e
        - Scritto da: ullala

        In primis non si tratta di una vulnerabilità

        dell'SSL ne tantomeno di una vulnerablità del

        protocollo correlato all'uso di certificati da

        parte di un GENERICO CLIENT ssl/tls in

        se.



        Si tratta invece di una vulnerabilità correlata

        al protocollo HTTPS e in particolare legata al

        comando HTTP TRACE (http

        1.1).



        Come spiega qui.

        http://www.kb.cert.org/vuls/id/867593



        Riassumendo la vulnerabilità è sfruttabile in

        certe condizioni con certe vulnerabilità lato

        browser e server e comunque sempre legata a
        HTTPS

        (non a SSL/TLS in

        se.

        mi sa che prima di documentarsi,bisogna anche
        sapere *di cosa si parla*.L'advisory che hai
        riportato non è relativo al bug in
        questione.

        se ti interessa *documentarti*, puoi iniziare a
        leggere
        qui:
        http://secunia.com/advisories/37291/
        http://extendedsubset.com/?p=8
        http://www.ietf.org/mail-archive/web/tls/current/m

        PS: per la cronaca, OpenSSL ha già rilasciato un
        workaround:
        http://cvs.openssl.org/chngview?cn=18790ah già mi scordavo di dirti, openvpn usa ssl ma.... non implementa (ne ha bisogno di farlo non essendo HTTP) la rinegoziazione in questione... ergo non è vulnerabile!E come questo ci sono decine di altri casi...Più in generale è in HTT che generalmente si utilizza questo tipo di negoziazione (e non è detto che lo si faccia... dipende dal server, apache, ad esempio lo fa e quindi è vulnerabile)... Riassunto:Parlare di vulnerabilità senza identificare la classe di applicazioni che può essere soggetta è semplice FUD e non aiuta chi gestisce un sistema a capire se corre dei rischi e quali rischi corre.Identificare i casi e le possibili applicazioni invece aiuta e questo dovrebbe essere il tipo di approccio da usare quando si scrivono le notizie.Buona giornata
    • Gurzo2007 scrive:
      Re: Ma documentarsi no?
      quindi i due ricercatori sono dei cialtroni? tutte le aziende citate sono andate a presso a dei cialtroni? comprese tutte le testate giornalistiche? leggendo in giro mi è parso di capire che l'https sia solo il mezzo per sfruttare la vulnerabilità di tali protocolli...http://arstechnica.com/security/news/2009/11/https-ssl-attack-vector-discovered-fix-is-on-the-way.arsanke questo giornalista ha preso un abbaglio?
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: Gurzo2007
        quindi i due ricercatori sono dei cialtroni?
        tutte le aziende citate sono andate a presso a
        dei cialtroni? comprese tutte le testate
        giornalistiche? leggendo in giro mi è parso di
        capire che l'https sia solo il mezzo per
        sfruttare la vulnerabilità di tali
        protocolli...

        http://arstechnica.com/security/news/2009/11/https

        anke questo giornalista ha preso un abbaglio?Non si tratta di cialtroneria ma più banalmente di dare le notizie in modo TROPPO approssimativo come è pessima abitudine dei giornalisti.In realtà è vero che si tratta di un bug "di protocollo" me è altrettanto vero che è legato ad un tipo di proXXXXX "legacy" di rinegoziazione e che tale tipo di proXXXXX si usa GENERALMENTE solo in HTTPS (il che non significa che qualche applicazione non http non possa averlo usato... significa solo che è piuttosto improbabile).D'altra parte è vero anche che neppure qualunque server HTTP è soggetto (potrebbe non supportare questo tipo di negoziazione).Traduzione:Molti (quasi tutti) i server HTTPS sono vulnerabili.Molte (quasi tutte) le applicazioni non correlate al protocollo HTTPS non sono vulnerabili (ad esempio non lo è openvpn) in quanto non hanno in sè alcuna necessità di implementare questo tipo di negoziazione.Conlusione:È poco utile affrontare il problema dando del cialtrone a tizio o caioè altrettanto poco utile dare a chi solleva obiezioni e chiede di essere precisi del "niubbo".Oltretutto può essere azzardato quando non si sa con chi si parla!Tutto ciò potrà anche titillare il proprio ego ma non serve.Ciò che serve (lo ripeto) è fare capire alla gente quale sia il reale pericolo e quali applicazioni sono potenzialmente coinvolte!buona giornata
        • AhLaSentili ta... scrive:
          Re: Ma documentarsi no?
          Quindi ammetti di avere scritto delle boiate.E' un bug di protocollo SSL e ne soffrono le implementazioni che usano la client certificate authentication.Che poi sia quasi solo HTTPS ad implementare questa autenticazione non significa che si tratti di un bug di HTTPS.Se i mattoni sono usati quasi solo per costruire edifici, il bug di un mattone rimane il bug di un mattone, ha effetto sull'edificio ma non è un bug dell'edificio.Un po' di logica prima di iniziare flame inutili ti avrebbe suggerito di startene zitto, perchè l'articolo è stato molto più preciso dei tue deliranti interventi.
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: AhLaSentili ta...
            Quindi ammetti di avere scritto delle boiate.
            E' un bug di protocollo SSL e ne soffrono le
            implementazioni che usano la client certificate
            authentication.
            Che poi sia quasi solo HTTPS ad implementare
            questa autenticazione non significa che si tratti
            di un bug di
            HTTPS.
            Se i mattoni sono usati quasi solo per costruire
            edifici, il bug di un mattone rimane il bug di un
            mattone, ha effetto sull'edificio ma non è un bug
            dell'edificio.
            Un po' di logica prima di iniziare flame inutili
            ti avrebbe suggerito di startene zitto, perchè
            l'articolo è stato molto più preciso dei tue
            deliranti
            interventi.Certo il mattone la piastrella...Il problema è che il "mattone" è fatto apposta per l'edificio HTTPS e il "bug" è dovuto ad un problema di retrocompatibilità (coi browser che erano all'epoca praticamente l'unica implementazione).In sintesi il buco è non in un mattone ma in una piastrella che si usa nel 90% dei casi per retrocompatibilità con i sanitari per bagno richard ginori....Certo le piastrelle non si usano solo in bagno.... però sono diverse da un mattone che usi ovunque!Con tutte le chiacchere però nessuno ha ancora postato (ne riuscirà a farlo) un link a una applicazione non HTTPS con quel problema!Sarà un caso?
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: AhLaSentili ta...
            Quindi ammetti di avere scritto delle boiate.
            E' un bug di protocollo SSL e ne soffrono le
            implementazioni che usano la client certificate
            authentication.È un bug del TLS/SSLv3 e non è limitato al client certificate autentication.Ti sono stai mandati dei link che ne dici di leggerli? ;-)
            Che poi sia quasi solo HTTPS ad implementare
            questa autenticazione non significa che si tratti
            di un bug di
            HTTPS.
            Se i mattoni sono usati quasi solo per costruire
            edifici, il bug di un mattone rimane il bug di un
            mattone, ha effetto sull'edificio ma non è un bug
            dell'edificio.
            Un po' di logica prima di iniziare flame inutili
            ti avrebbe suggerito di startene zitto, perchè
            l'articolo è stato molto più preciso dei tue
            deliranti
            interventi.
      • markoer scrive:
        Re: Ma documentarsi no?
        - Scritto da: Gurzo2007
        quindi i due ricercatori sono dei cialtroni?
        tutte le aziende citate sono andate a presso a
        dei cialtroni? comprese tutte le testate
        giornalistiche? leggendo in giro mi è parso di
        capire che l'https sia solo il mezzo per
        sfruttare la vulnerabilità di tali
        protocolli...

        http://arstechnica.com/security/news/2009/11/https

        anke questo giornalista ha preso un abbaglio?No, è il nostro amico qua che sta ululando ;-)
        • ullala scrive:
          Re: Ma documentarsi no?
          - Scritto da: markoer
          - Scritto da: Gurzo2007

          quindi i due ricercatori sono dei cialtroni?

          tutte le aziende citate sono andate a presso a

          dei cialtroni? comprese tutte le testate

          giornalistiche? leggendo in giro mi è parso di

          capire che l'https sia solo il mezzo per

          sfruttare la vulnerabilità di tali

          protocolli...




          http://arstechnica.com/security/news/2009/11/https



          anke questo giornalista ha preso un abbaglio?

          No, è il nostro amico qua che sta ululando ;-)Cioè non c'è scritto HTTPS?Persino nell'URL?Oppure non sai perchè si chiama "legacy renegotiation"?Secondo te è "legacy" perché?e rispetto a quali (evidentemente precedenti) applicazioni e protocolli?Saluti
          • Klut scrive:
            Re: Ma documentarsi no?
            Scusami, posso sapere dov'è che hai letto "legacy renegotiation"?
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: Klut
            Scusami, posso sapere dov'è che hai letto "legacy
            renegotiation"?Bella domanda!Diciamo nei commenti del codice openssl?diciamo oltre tutto nella pactch di ben laurie?http://cvs.openssl.org/chngview?cn=18790diciamo che (diversi anni orsono) ci fu una discussione in lista IETF (cerca sugli archivi) quando si decise di rendere "standard" (e chiamarlo TLS) il protocollo che fino ad allora era stato proprietario di NETSCAPE e che in questa discussione alcuni developpers sostenevano che per retrocompatibilità con precedenti implementazioni il tipo di versione della connessione poteva essere rinegoziata dai "client legacy"?Va bene diciamolo! :)
          • Klut scrive:
            Re: Ma documentarsi no?
            Come tu stesso dici, quella è la proposta di patch per OpenSSL, che consisterebbe nel disabilitare completamente di default la rinegoziazione e introdurre una direttiva opzionale di compilazione per riattivarla.Quindi significa che, una volta introdotta la patch, la direttiva per riattivare la rinegoziazione si chiamerebbe "OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION".Questo significa che da quando la patch è stata approvata, due giorni fa, OpenSSL chiama la rinegoziazione dello standard TSL "legacy", non che qualche tipo di rinegoziazione dello standard TSL si chiamasse "legacy" da prima.Nell'archivio della mailing list di IETF (presumo ti riferissi a questo: http://www.imc.org/ietf-tls/) non sono riuscito a trovare il thread di cui parli in cui si diceva che la rinegoziazione del certificato client fosse già considerata legacy e mantenuta solo per retrocompatibilità.Ho provato a cercare legacy, backward compatibility, retrocompatibility ma non ho trovato niente. Ho provato anche a guardarmi tutti i thread che parlavano di renegotiation, ma sono tanti e può anche essermi sfuggito.Se riesci a ritrovarlo, mi dai un link più diretto? E' una cosa che mi tornerebbe utile sapere per lavoro.
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: Klut
            Come tu stesso dici, quella è la proposta di
            patch per OpenSSL, che consisterebbe nel
            disabilitare completamente di default la
            rinegoziazione e introdurre una direttiva
            opzionale di compilazione per
            riattivarla.

            Quindi significa che, una volta introdotta la
            patch, la direttiva per riattivare la
            rinegoziazione si chiamerebbe
            "OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION

            Questo significa che da quando la patch è stata
            approvata, due giorni fa, OpenSSL chiama la
            rinegoziazione dello standard TSL "legacy", non
            che qualche tipo di rinegoziazione dello standard
            TSL si chiamasse "legacy" da
            prima.
            Non è questo il problema....http://www.faqs.org/faqs/computer-security/ssl-talk-faq/Nelle discussioni che ti ho citato ci si riferiva a questo come "legacy"" Backward compatibility: 1. SSL 3.0 can recognize an SSL 2.0 client hello and fall back to SSL 2.0. An SSL 3.0 client can also generate an SSL 2.0 client hello with the version set to SSL 3.0, so SSL 3.0 servers will continue the handshake in SSL 3.0, and SSL 2.0 server will cause the client to fall back to SSL 2.0."Tutta questa roba è rimasta nel protocollo è può (se implementata) dare luogo ad attacchi altrimenti evitabilissimi.Intendiamoci in reltà il problema è meno drammatico di ciò che sembra...Ma esiste... e tutto sommato se si voleva si poteva ammettere che esisteva già anni fa...In sintesi è questo che volevo dire.Ora si è deciso di metterci una pezza?Ben venga... ma che non mi si dica che si tratta di roba la cui sostanza non era nota da tempo!Sulla reale usabilità poi .. di un exploit di questo tipo... dipende (ripeto) da tante circostanze e francamente non c'è gran motivo di sentirsi meno sicuri di prima.

            Nell'archivio della mailing list di IETF (presumo
            ti riferissi a questo:
            http://www.imc.org/ietf-tls/) non sono riuscito a
            trovare il thread di cui parli in cui si diceva
            che la rinegoziazione del certificato client
            fosse già considerata legacy e mantenuta solo per
            retrocompatibilità.In effetti trovare l'argomento in un sigolo thread (come sempre nei WG IETF) è impossibile... li le discussioni non sono "flames"..Purtroppo ti tocca di ricostruire seguendo i messaggi che si trovano..La questione comunque è stata posta ben più di una volta.Tracce le trovi anche nella vecchia e gloriosa "ssl-talk"In "estremissima" sintesi comunque il problema nasce da 3 issues concomitanti:1) SSL/TLS di per se ha un meccanismo di sessione (ssl session) e quindi una logica "stateful"2) HTTP è totalmente session-less e quindi con una logica "stateless"3) Il meccanismo di fall-back (che io ho chiamato di supporto a client cerebrolesi) che è scritto qui sopra (considera che parliamo del 95-96-97 quando esistevanno solo Netscape e ... solo dopo IE... come client ssl diffusi).Si scelse (a torto o ragione... ma tra un milione di obiezioni) di slvaguardare la retrocompatibilità (fallback) e il supporto a HTTP (con la "speranza" che bastasse aggiungere la S ovvero la comunicazione attraverso uno Socket sicuro così come avveniva attraverso i vecchi e bacati ssl 2 e precedenti...)

            Ho provato a cercare legacy, backward
            compatibility, retrocompatibility ma non ho
            trovato niente. Ho provato anche a guardarmi
            tutti i thread che parlavano di renegotiation, ma
            sono tanti e può anche essermi
            sfuggito.

            Se riesci a ritrovarlo, mi dai un link più
            diretto? E' una cosa che mi tornerebbe utile
            sapere per
            lavoro.Non è semplice ricostruire con questo livello di dettaglio o almeno non è fattibile con una semplice googlata (è roba molto vecchia).Ma se ci riesci fai sicuramente qualcosa di utile per tutti.Spero di esseri stato utile.
          • Klut scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala
            Non è questo il problema....

            http://www.faqs.org/faqs/computer-security/ssl-tal

            Nelle discussioni che ti ho citato ci si riferiva
            a questo come
            "legacy"

            " Backward compatibility:

            1. SSL 3.0 can recognize an SSL 2.0 client
            hello and fall back to SSL 2.0. An SSL 3.0 client
            can also generate an SSL 2.0 client hello with the
            version set to SSL 3.0, so SSL 3.0 servers will
            continue the handshake in SSL 3.0, and SSL 2.0
            server will cause the client to fall back to SSL
            2.0."Scusami ancora, ma questo non c'entra niente col discorso...Lì si sta parlando di SSL 3, in particolare delle modalità con le quali è possibile avviare una sessione SSL 2.0 se client o server non sono compatibili con l'SSL 3.0...Ma la rinegoziazione lato client non è mica una reminiscenza dell'SSL 2.0 che viene supportata in emulazione.E' una caratteristica vera e propria anche del TLS, tant'è che nell'RFC del TLS 1.2 leggo, tra le cose a cui l'implementatore fare attenzione: - Do you support renegotiation, both client and server initiated? While renegotiation is an optional feature, supporting it is highly recommended.Mi sembra l'esatto contrario di considerarla legacy...
            Sulla reale usabilità poi .. di un exploit di
            questo tipo... dipende (ripeto) da tante
            circostanze e francamente non c'è gran motivo di
            sentirsi meno sicuri di prima.La pericolosità è realmente da minimizzare, perché un attacco MITM su Internet proprio su una comunicazione del genere è abbastanza improbabile.Sarebbe già più facile se il MITM fosse all'interno della LAN del client, o di una WAN tipo Fastweb.Fatto sta però che l'SSL è nato proprio per evitare attacchi MITM, sennò tanto vale che ci scambiavamo tutti le chiavi in chiaro, no?;)Quindi rimane una falla sulla carta molto grave.
            In "estremissima" sintesi comunque il problema
            nasce da 3 issues
            concomitanti:

            1) SSL/TLS di per se ha un meccanismo di sessione
            (ssl session) e quindi una logica "stateful"
            2) HTTP è totalmente session-less e quindi con
            una logica "stateless"Si, l'attacco ha buone possibilità di sucXXXXX solo se il protocollo superiore non ha una buona gestione della sessione, e quindi non è possibile avere traccia del fatto che l'interlocutore è cambiato tra una sessione TLS e l'altra.Il fatto che HTTP sia stateless peggiora ancora le cose, visto che per ogni richiesta si avvia una nuova sessione TLS, e si da una nuova possibilità all'attaccante.Però non si può negare che il problema stia proprio in TLS, e in particolare nel fatto che non preveda un proprio meccanismo per poter ricostruire quando una nuova sessione è frutto della rinegoziazione di una precedente.
            3) Il meccanismo di fall-back (che io ho chiamato
            di supporto a client cerebrolesi) che è scritto
            qui sopra (considera che parliamo del 95-96-97
            quando esistevanno solo Netscape e ... solo dopo
            IE... come client ssl diffusi).
            Si scelse (a torto o ragione... ma tra un milione
            di obiezioni) di slvaguardare la
            retrocompatibilità (fallback) e il supporto a
            HTTP (con la "speranza" che bastasse aggiungere
            la S ovvero la comunicazione attraverso uno
            Socket sicuro così come avveniva attraverso i
            vecchi e bacati ssl 2 e precedenti...)Qua non ti ho capito, di che fallback parli?
            Non è semplice ricostruire con questo livello di
            dettaglio o almeno non è fattibile con una
            semplice googlata (è roba molto vecchia).
            Ma se ci riesci fai sicuramente qualcosa di utile
            per tutti.

            Spero di esseri stato utile.Si, magari spendendo qualche ora potrei trovare qualcuno che nel '96 non era d'accordo con le modalità di rinegoziazione, ma il problema è un altro...Fino a una settimana fa, se io avessi voluto implementare un server SSL e avessi cercato informazioni sulla rinegoziazione, non avrei trovato niente che mi dicesse che era lì solo perché serviva ad HTTP ma era considerata già deprecata, considerata legacy o almeno non supportata di default, o supportata ma sotto consiglio di tenere un tracciamento delle sessioni.Avrei trovato solo parti degli RFC in cui mi si consigliava di supportarla.
    • Gurzo2007 scrive:
      Re: Ma documentarsi no?
      scusa ma hai letto la data di notifica ai vendor? 2003...sono 6 anni che la si consoce il baco dell'http trace, e non da agosto 2009
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: Gurzo2007
        scusa ma hai letto la data di notifica ai vendor?
        2003...sono 6 anni che la si consoce il baco
        dell'http trace, e non da agosto
        2009Infatti ho sbagliato a postare quel bug/advisory.. (ho cliccato il link sbagliato)ciò non toglie la SOSTANZA del discorso.. il buco "di protocollo" riguarda un tipo di rinegoziazione "legacy" sostanzialmente legato a HTTPS.
        • AhLaSenilit a... scrive:
          Re: Ma documentarsi no?
          "sostanzialmente" hai tempo da perdere e non sai più come uscirne dalla boiata che hai scritto all'inizio di questo thread, abbandona il campo che è meglio...
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: AhLaSenilit a...
            "sostanzialmente" hai tempo da perdere e non sai
            più come uscirne dalla boiata che hai scritto
            all'inizio di questo thread, abbandona il campo
            che è
            meglio...Io posso pure abbandonare...Ma vorrei un link a una applicazione che non implichi HTTPS e al tempo stessi sia vulnerabile...Certo volere e potere son cose diverse... appunto!Ma, attenendosi ai fatti, se non si può postare un tale link... ci sarà un motivo?
          • lasenilita scrive:
            Re: Ma documentarsi no?
            Probabilmente ragioni sono in termini di opensource, mai pensato che potrebbero esserci delle applicazioni closed che usano quel sistema senza averlo dichiarato al mondo intero (per fortuna loro in questo momento) ?
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: lasenilita
            Probabilmente ragioni sono in termini di
            opensource, Togli pure il probabilmente e sostituiscilo con un sicuramente:)
            mai pensato che potrebbero esserci
            delle applicazioni closed che usano quel sistema
            senza averlo dichiarato al mondo intero (per
            fortuna loro in questo momento)
            ?Certo che ci ho pensato infatti non userei mai un closed source per fare sicurezza!Opinabile fin che vuoi .. ma questo è il mio approccio ed è anche quello dei bodies di certificazione di sicurezza..Mi spiego meglio:Se vuoi avere una cerificazione (ad esempio ITSEC o Common Criteria) ai livelli più alti devi anche dimostrare la sicurezza del codice e quindi anche effettuare la disclosure quantomeno al body che fa l'audit di certificazione!Per l'open source hai la fortuna di potere essere tu (e diversi milioni di altre parti "terze") a fare l'audit...è una garanzia, non assoluta ma comunque in più! perchè rinunciarci?
          • magiaro scrive:
            Re: Ma documentarsi no?
            Il fatto che esistano prodotti/aziende come Oracle, Windows, Skype, iTunes, Cisco ecc e che abbiamo un discreto sucXXXXX di mercato, significa che opensource non è l'unica strada percorribile. Aggiungi che spesso chi decide ai piani alti desidera tenersi stretti i propri successi/metodi/protocolli chiudendo i sorgenti. Come dici tu stesso per ottenere le certificazioni che servono basta aprire il codice a chi certifica, non al mondo, quindi è probabile che anche applicazioni closed siano vulnerabili. E non ci vuole un genio, quando si hanno interessi a fare danni, a scovare quale siano queste applicazioni e sfruttare il baco.
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: magiaro
            Il fatto che esistano prodotti/aziende come
            Oracle, Windows, Skype, iTunes, Cisco ecc e che
            abbiamo un discreto sucXXXXX di mercato,
            significa che opensource non è l'unica strada
            percorribile. Aggiungi che spesso chi decide ai
            piani alti desidera tenersi stretti i propri
            successi/metodi/protocolli chiudendo i sorgenti.
            Come dici tu stesso per ottenere le
            certificazioni che servono basta aprire il codice
            a chi certifica, non al mondo, quindi è probabile
            che anche applicazioni closed siano vulnerabili.
            E non ci vuole un genio, quando si hanno
            interessi a fare danni, a scovare quale siano
            queste applicazioni e sfruttare il
            baco.Non ci vuole neppure un genio a usare --tls-auth in openvpn (aka Read The Fucking Manual)...E ripeto Il problema "closed source" è un non sense in materia di sicurezza.è come dire "speriamo che vada tutto bene"... già speriamo.. di non dover piangere dopo!Ma la sicurezza non è fatta di speranze!
    • markoer scrive:
      Re: Ma documentarsi no?
      - Scritto da: ullala[...]
      Come spiega qui.
      http://www.kb.cert.org/vuls/id/867593

      Riassumendo la vulnerabilità è sfruttabile in
      certe condizioni con certe vulnerabilità lato
      browser e server e comunque sempre legata a HTTPS
      (non a SSL/TLS in se.Leggi il paper originale. La vulnerabilità è legata al protocollo TLS/SSL in sé e non si limita ad HTTP. In fatti è stata dimostrata solo con l'HTTP ma può essere applicata a qualsiasi protocollo che viaggi su TLS/SSL.Un altro tipico errore è credere che si applichi solo a chi usa client certificates, in realtà si può sfruttare anche in altre condizioni.Cordiali saluti
      • ullala scrive:
        Re: Ma documentarsi no?
        - Scritto da: markoer
        - Scritto da: ullala
        [...]

        Come spiega qui.

        http://www.kb.cert.org/vuls/id/867593



        Riassumendo la vulnerabilità è sfruttabile in

        certe condizioni con certe vulnerabilità lato

        browser e server e comunque sempre legata a
        HTTPS

        (non a SSL/TLS in se.

        Leggi il paper originale. La vulnerabilità è
        legata al protocollo TLS/SSL in sé e non si
        limita ad HTTP. In fatti è stata dimostrata solo
        con l'HTTP ma può essere applicata a qualsiasi
        protocollo che viaggi su
        TLS/SSL.

        Un altro tipico errore è credere che si applichi
        solo a chi usa client certificates, in realtà si
        può sfruttare anche in altre
        condizioni.


        Cordiali salutiVeramente è legata ad una specifica issue ovvero quella riportata da Ben Laurie nella patch a opensslhttp://cvs.openssl.org/chngview?cn=18790E.. si riguarda la rinegoziazione su una connessione... e... altrettanto si... Riguarda i certificati" SSL_CTX " in opennssl...e ancora... si molte implementazioni "server" (sarebbe più corretto dire listener) non avendo la necessità di negoziare con un browser cerebroleso non supportano tale "rinegoziazione" (aka non sono vulnerabili).Esempio openvpn (che usa openssl) ....provare per credere! (come diceva Guido Angeli alla tv)Contento?
        • markoer scrive:
          Re: Ma documentarsi no?
          - Scritto da: ullala[...]
          Veramente è legata ad una specifica issue ovvero
          quella riportata da Ben Laurie nella patch a
          openssl
          http://cvs.openssl.org/chngview?cn=18790No, questo è solo un primo workaround applicato ad openSSL, che ovviamente puoi usare per qualsiasi cosa, HTTP o meno.openSSL è solo una libreria. Che sia la libreria di elezione di Apache per implementare l'HTTPS, è solo un possibile uso della libreria stessa. Infatti, la puoi usare anche per creare connessioni SSH e molte altre cose.
          E.. si riguarda la rinegoziazione su una
          connessione... e... altrettanto si...


          Riguarda i certificati
          " SSL_CTX " in opennssl...

          e ancora... si molte implementazioni "server"
          (sarebbe più corretto dire listener) non avendo
          la necessità di negoziare con un browser
          cerebroleso non supportano tale "rinegoziazione"
          (aka non sono vulnerabili).La rinegoziazione è parte del protocollo TLS e non è dovuta al fatto che un browser sia "celebroleso".Per favore documentati prima di spararle ci fai una figura migliore.
          Esempio openvpn (che usa openssl) ....provare per
          credere! (come diceva Guido Angeli alla
          tv)

          Contento?Ti è già stato spiegato in vari post, da me e da altri, in questo stesso thread. Non credo che abbia altro da aggiungere. Faresti te stesso alla fine molto più contento se ti documentassi invece di continuare a spararle ed arrampicarti sugli specchi.Poi se mi chiedi se sono contento... beh sì fai tu :-) preferirei che non ci fosse questa vulnerabilità. Dato che con queste cose ci lavoro, mi complicherà probabilmente la vita per un bel pezzo, visto che avremo migliaia di server da patchare e un pacco di vendor (almeno MS, IBM e Sun) da "pingare" per gli aggiornamenti...Cordiali saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala
            [...]

            Veramente è legata ad una specifica issue ovvero

            quella riportata da Ben Laurie nella patch a

            openssl

            http://cvs.openssl.org/chngview?cn=18790

            No, questo è solo un primo workaround applicato
            ad openSSL, che ovviamente puoi usare per
            qualsiasi cosa, HTTP o
            meno.Vero ciò non toglie che li sta il problema!

            openSSL è solo una libreria. Che sia la libreria
            di elezione di Apache per implementare l'HTTPS, è
            solo un possibile uso della libreria stessa.
            Infatti, la puoi usare anche per creare
            connessioni SSH e molte altre
            cose.
            Vero anche questo ma l'unica necessità che hai di implementare questo tipo di negoziazione (è un fatto storico discusso in lista IETF secoli fa) è un problema dovuto alla "retrocompatibilità" voluta a tutti costi da un gruppo di developpers con "certe implementazioni ssl" in "certi browsers che partivano per "default" in SSLv2 e SSLv1 (addirittura).Senza questa "retrocompatibilità" con browsers (ripeto cerebrolesi) non ci sarebbe mai stata la "rinegoziazione".


            E.. si riguarda la rinegoziazione su una

            connessione... e... altrettanto si...





            Riguarda i certificati

            " SSL_CTX " in opennssl...



            e ancora... si molte implementazioni "server"

            (sarebbe più corretto dire listener) non avendo

            la necessità di negoziare con un browser

            cerebroleso non supportano tale "rinegoziazione"

            (aka non sono vulnerabili).

            La rinegoziazione è parte del protocollo TLS e
            non è dovuta al fatto che un browser sia
            "celebroleso".Leggi sopra... la rinegoziazione è storicamente presente perchè le applicazioni "più comuni" (aka certi browsers) partivano di default secondo il "vecchio schema SSL" (precedente il TLS e il "nuovo" SSL).

            Per favore documentati prima di spararle ci fai
            una figura
            migliore.Non è questo il mio problema...



            Esempio openvpn (che usa openssl) ....provare
            per

            credere! (come diceva Guido Angeli alla

            tv)



            Contento?

            Ti è già stato spiegato in vari post, da me e da
            altri, in questo stesso thread. Non credo che
            abbia altro da aggiungere. Faresti te stesso alla
            fine molto più contento se ti documentassi invece
            di continuare a spararle ed arrampicarti sugli
            specchi.

            Poi se mi chiedi se sono contento... beh sì fai
            tu :-) preferirei che non ci fosse questa
            vulnerabilità. Dato che con queste cose ci
            lavoro, mi complicherà probabilmente la vita per
            un bel pezzo, visto che avremo migliaia di server
            da patchare e un pacco di vendor (almeno MS, IBM
            e Sun) da "pingare" per gli
            aggiornamenti...è anche il mio... ma mi preoccupo solo (quindi mi preoccupo meno di te) delle applicazioni che SO essere vulnerabili non di TUTTE quelle che usano SSL in generale!Quindi presuppongo (a torto o ragione) di essere più contento (o almeno meno indaffarato) di quanto non sia tu...


            Cordiali salutiRicambio.
          • markoer scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala[...]

            No, questo è solo un primo workaround applicato

            ad openSSL, che ovviamente puoi usare per

            qualsiasi cosa, HTTP o

            meno.

            Vero ciò non toglie che li sta il problema!No, il problema sta in qualsiasi applicazione che usi TLS. Stiamo parlando di smart cards, VPN, eccetera.[...]
            Vero anche questo ma l'unica necessità che hai di
            implementare questo tipo di negoziazione (è un
            fatto storico discusso in lista IETF secoli fa) è
            un problema dovuto alla "retrocompatibilità"
            voluta a tutti costi da un gruppo di developpers
            con "certe implementazioni ssl" in "certi
            browsers che partivano per "default" in SSLv2 e
            SSLv1
            (addirittura).
            Senza questa "retrocompatibilità" con browsers
            (ripeto cerebrolesi) non ci sarebbe mai stata la
            "rinegoziazione".Linkami dove sarebbe questa discussione perché mi sa che l'hai fraintesa :-)[...]

            La rinegoziazione è parte del protocollo TLS e

            non è dovuta al fatto che un browser sia

            "celebroleso".

            Leggi sopra... la rinegoziazione è storicamente
            presente perchè le applicazioni "più comuni" (aka
            certi browsers) partivano di default secondo il
            "vecchio schema SSL" (precedente il TLS e il
            "nuovo" SSL).A me sembra che questa roba te la sei inventata adesso, se mi puoi linkare dove l'hai letta - oppure linkami al tuo pusher di fiducia deve fornire roba buona :-)

            Per favore documentati prima di spararle ci fai

            una figura

            migliore.

            Non è questo il mio problema...A me pare che spari cose leggiucchiate e gugolate a caso. Sarà... :-)[...]
            è anche il mio... ma mi preoccupo solo (quindi mi
            preoccupo meno di te) delle applicazioni che SO
            essere vulnerabili non di TUTTE quelle che usano
            SSL in generale!Io sì, dato che sono TUTTE vulnerabili :-) e ne abbiamo un'infinità, dai mobile ai VPN concentrator alle smart card alle USIM...
            Quindi presuppongo (a torto o ragione) di essere
            più contento (o almeno meno indaffarato) di
            quanto non sia tu...Sei di sicuro meno indaffarato, non ho dubbi :-)Cordiali saluti
          • ullala scrive:
            Re: Ma documentarsi no?
            - Scritto da: markoer
            - Scritto da: ullala
            [...]

            Veramente è legata ad una specifica issue ovvero

            quella riportata da Ben Laurie nella patch a

            openssl

            http://cvs.openssl.org/chngview?cn=18790

            No, questo è solo un primo workaround applicato
            ad openSSL, che ovviamente puoi usare per
            qualsiasi cosa, HTTP o
            meno.

            openSSL è solo una libreria. Che sia la libreria
            di elezione di Apache per implementare l'HTTPS, è
            solo un possibile uso della libreria stessa.
            Infatti, la puoi usare anche per creare
            connessioni SSH e molte altre
            cose.



            E.. si riguarda la rinegoziazione su una

            connessione... e... altrettanto si...





            Riguarda i certificati

            " SSL_CTX " in opennssl...



            e ancora... si molte implementazioni "server"

            (sarebbe più corretto dire listener) non avendo

            la necessità di negoziare con un browser

            cerebroleso non supportano tale "rinegoziazione"

            (aka non sono vulnerabili).

            La rinegoziazione è parte del protocollo TLS e
            non è dovuta al fatto che un browser sia
            "celebroleso".

            Per favore documentati prima di spararle ci fai
            una figura
            migliore.



            Esempio openvpn (che usa openssl) ....provare
            per

            credere! (come diceva Guido Angeli alla

            tv)



            Contento?

            Ti è già stato spiegato in vari post, da me e da
            altri, in questo stesso thread. Non credo che
            abbia altro da aggiungere. Faresti te stesso alla
            fine molto più contento se ti documentassi invece
            di continuare a spararle ed arrampicarti sugli
            specchi.

            Poi se mi chiedi se sono contento... beh sì fai
            tu :-) preferirei che non ci fosse questa
            vulnerabilità. Dato che con queste cose ci
            lavoro, mi complicherà probabilmente la vita per
            un bel pezzo, visto che avremo migliaia di server
            da patchare e un pacco di vendor (almeno MS, IBM
            e Sun) da "pingare" per gli
            aggiornamenti...


            Cordiali salutiAh!Mi son dimenticato di dirti che se "fai PING" in attesa di una pacth per openvpn ti conviene aumentare il "timeout default" della tua stack IP di un tempo mooolto consistente!Nell'attesa...Auguri e ri-saluti
          • Ozymandias scrive:
            Re: Ma documentarsi no?
            - Scritto da: ullala
            Ah!
            Mi son dimenticato di dirti che se "fai PING" in
            attesa di una pacth per openvpn ti conviene
            aumentare il "timeout default" della tua stack IP
            di un tempo mooolto
            consistente!

            Nell'attesa...
            Auguri e ri-salutiDa quel poco che ho potuto leggere cercando velocemente su qualche forum, è emerso che:a) Anche OpenVPN è soggetto alla vulnerabilitàb) Per aggirare il problema, al momento viene suggerito di disabilitare il supporto alla rinegoziazione.c) Questa è una mia valutazione: OpenVPN attualmente sta alla finestra in attesa che venga risolto il problema a livello di protocollo, POI implementerà la patch relativa.Quindi, se la soluzione al problema sarà trovata in fretta, la risposta al PING potrebbe essere altrettanto rapida.
          • Pizzuco scrive:
            Re: Ma documentarsi no?
            Finalmente daremo soddisfazione ad ullala!!!È uscita, calda calda, la build 2.1.0_21 di OpenVPN (la uso con grande soddisfazione per due miei Clienti nella build _20 e con configurazioni avanzate facenti uso di vari certificati). Solida, affidabile, NON proprietaria, stabile e performante: ve la consiglio!Qui il log delle modifiche dalla _20 alla _21:http://www.openvpn.net/index.php/open-source/documentation/change-log/71-21-change-log.htmlMa che, per comodità, Vi anticipo:"2009.11.12 -- Version 2.1_rc21* Rebuilt OpenVPN Windows installer with OpenSSL 0.9.8l to address CVE-2009-3555. Note that OpenVPN has never relied on the session renegotiation capabilities that are built into the SSL/TLS protocol, therefore the fix in OpenSSL 0.9.8l (disable SSL/TLS renegotiation completely) will not adversely affect OpenVPN mid-session SSL/TLS renegotation or any other OpenVPN capabilities.* Added additional session renegotiation hardening. OpenVPN has always required that mid-session renegotiations build up a new SSL/TLS session from scratch. While the client certificate common name is already locked against changes in mid-session TLS renegotiations, we now extend this locking to the auth-user-pass username as well as all certificate content in the full client certificate chain."Ciao a Tutti,Carlo
  • LuNa scrive:
    se anche fosse realmente pericoloso ..
    .. lo sapremmo solo dopo il botto :D
  • pippuz scrive:
    man in the browser
    Leggermente OT, visto che non tratta di SSL, ma di un attacco a mio avviso ancora più infido.http://en.wikipedia.org/wiki/Man_in_the_Browser per le basi
  • mosilon scrive:
    la cosa migliore da fare
    i soldi lasciateli a casa - si vive da dio senza banche tra i piedi ke ti fottono i soldi
    • Giulio scrive:
      Re: la cosa migliore da fare
      E la moneta scritturale la sostituisci con le pecore e le galline?
      • Uova di Poiana scrive:
        Re: la cosa migliore da fare
        - Scritto da: Giulio
        E la moneta scritturale la sostituisci con le
        pecore e le
        galline?No, con lingotti d'oro.
        • markoer scrive:
          Re: la cosa migliore da fare
          - Scritto da: Uova di Poiana
          - Scritto da: Giulio

          E la moneta scritturale la sostituisci con le

          pecore e le

          galline?

          No, con lingotti d'oro.Peccato che il valore del denaro non sia più legato all'oro almeno dagli anni 70 ;-)E peccato che i soldi lasciati a casa sotto il materasso si svalutano e basta.Per sfruttare questa vulnerabilità c'è bisogno ovviamente che un attacker sia sulla "linea" tra client e server e sappia usare (e funzioni nella configurazione di rete usata!) molto bene l'ARP spoofing. E comunque, immagino che debba possedere una copia dei tuoi TAN, se vuole farsi un bonifico dal tuo conto :-)Cordiali saluti
          • zi_o_zio scrive:
            Re: la cosa migliore da fare
            - Scritto da: markoer
            Peccato che il valore del denaro non sia più
            legato all'oro almeno dagli anni 70
            ;-)Limpido
            E peccato che i soldi lasciati a casa sotto il
            materasso si svalutano e
            basta.Nebbia all'orizzonte :)Se li vincoli OK. La banca li investe e ti corrispondeuna quota di interessi.Se li lasci sul CC la banca li presta ugualmente. Raddoppiando i tuoi soldi e mettendoli in circolazionecrea inflazione/svalutazione.Paradossalmente sotto il materasso si svalutano di meno. :-)
            Cordiali salutiByeps da grande voglio fare il banchiere alias il p)
    • battagliacom scrive:
      Re: la cosa migliore da fare
      le banche nn hanno soldi=non possono fare finanziamenti=le imprese piccole e grandi non possono investire=pochi prodotti poco tecnologicamente avanzati=medioevo
    • Anonymous scrive:
      Re: la cosa migliore da fare
      - Scritto da: mosilon
      i soldi lasciateli a casa - si vive da dio senza
      banche tra i piedi ke ti fottono i
      soldiQuotato. Ma che non si sappia o le case si riempiranno di drogatoidi succhia-soldi, che si stuprano ragazze e mogli.
      • Peracuttt scrive:
        Re: la cosa migliore da fare

        Quotato. Ma che non si sappia o le case si
        riempiranno di drogatoidi succhia-soldi, che si
        stuprano ragazze e
        mogli.Ma il cervello ogni tanto lo usi?Magnà e Lavurà
Chiudi i commenti