Newsgroup: it.lavoro.informatica
Titolo: Controllo integrità wireshark

oggi ho voluto provare il controllo di integrit� dei file
scaricati, come da istruzioni ho scaricato e istallato
HashCalc, poi ho scaricato il software che mi interessa
ovvero wireshark-setup-1.0.8.exe poi ho scaricato la
sua signature SIGNATURES-1.0.8.txt ed ho provato
a calcolare entrambi, ma da valori completamente diversi.
Per la verit� sul sito si dice anche che:
It is signed with key id 0x21F2949A
ma non so come utilizzare questa chiave e se la chiave
� 0x21F2949A oppure il file di testo linkato
Aiuto please

 scaricati
HTTP non ti garantisce già che quello che scarichi corrisponde a quello che c'è 
sul server??? 
-- 
_______________________
Luc (36, CO)
Statement has no effect
_______________________

 sul server??? 
In effetti TCP garantisce l'integrita'. Credo che fare un controllo 
manuale sia molto NERD (qualita' apprezzata in certi circoli) :D
Ciao,
Vale

 manuale sia molto NERD (qualita' apprezzata in certi circoli) :D
C'è chi su USENET mette la propria PGP key sui messaggi postati... ROTFL!


C'� chi su USENET mette la propria PGP key sui messaggi postati... ROTFL!
Quello eventualmente lo si fa per poter controllare l'autenticita' del
messaggio, non necessariamente l'integrita'.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 C'è chi su USENET mette la propria PGP key sui messaggi postati... ROTFL!
Gia'...che idioti eh? Per fortuna che nella tua azienda ai programmatori non
fanno i test da sysadmin, altrimenti non so dove saresti ora...
(si', lo so che si vede che e' un fake, ma era solo per dare un esempio)


 manuale sia molto NERD (qualita' apprezzata in certi circoli) :D
Il tcp garantisce solo che quello che viene trasmesso arrivi, non che
sia pure corretto quello che c'� dentro!

 sul server??? 
Per niente! E soprattutto, nessuno ti garantisce che quello che c'� sul server
sia vero e non taroccato!

 server sia vero e non taroccato!
Per la verita', quello neppure md5 lo fa, visto che un qualunque cracker
della domenica che riesca a sostituire il software sul server con delle
versioni troianizzate, sostituira' anche il file di checksum md5.

Torna a studiare...
Data link ha solo il controlllo d'errore sui frames, ma nessun
meccanismo di recovery.
Psysical link non ha neanche il controllo di errore.
Saluti.


 Psysical link non ha neanche il controllo di errore.
E controllo d'errore non � neanche automaticamente associato a recovery,
se � per questo :)

 ancora pi� in basso (physical e data link layer).
Pi� che altro � il contrario. L'IP di suo non fa controlli di integrit�,
si affida ai livelli *superiori*, in questo caso il TCP. I controlli a
livello fisico e datalink assicurano solo che quello che entra ad un capo
del link esca allo stesso capo, ma NON che non sia stato modificato *prima*
di entrare, ad esempio su un gateway che impazzisce e corrompe i pacchetti.
Ed il controllo di errore del TCP � debole, � un semplice checksum non
necessariamente in grado di rilevare tutti gli errori (pacchetti con dati
diversi potrebbero generare lo stesso checksum, al contrario del CRC).

 versioni troianizzate, sostituira' anche il file di checksum md5.
Ma il checksum md5 tipicamente lo trovi in pi� posti! Il problema tipico
� quando scarichi da un mirror, che potrebbe essere stato taroccato, ma
il checksum lo confronti con quello preso dal sito originale, non con 
quello sul mirror. E' inverosimile che un cracker riesca a taroccare
*tutti i checksum su tutti i server*.

 manuale sia molto NERD (qualita' apprezzata in certi circoli) :D
quindi se mentre stai scaricando un file io vengo l� e ti stacco la rete, 
il tcp ti garantisce che quel file sar� integro sul tuo pc?

 sul server??? 
Direi di no.
Chi non ha avuto modo di frequentare corsi specifici sull'argomento
"security" in genere puo' partire da qui:
http://www.cs.auckland.ac.nz/~pgut001/tutorial/
Leggerseli tutti costa un po' di tempo e sicuramente oggi
saranno obsoleti, ma probabilmente ne vale comunque
la pena
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Il 11 Giu 2009, 14:12, Sentenza <sent...@STACEPPAosteriafuoriporta.net> ha
scritto:

Mi domando certa gente cosa studia...manco le basi :-( Ma infatti sta al
call center o cosi dice.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 protocolli di livello OSI più basso quali TCP ed IP
Ovviamente, pensando io ad oggetti, dire che HTTP garantisce, vuol dire che lo 
fa con una delle sue "classi base"... Ho solo semplificato, al limite.


 X-Complaints-To: 
ab...@eternal-september.org
:-P 


 il tcp ti garantisce che quel file sar� integro sul tuo pc?
E mettiamo anche la botta finale! I protocolli di error correction 
garantiscono solo che i dati arrivino corretti nella memoria del computer...
ma NON che il computer non li scriva male sul disco! ;)

 che c'� sul server???
ma manco per sogno. 
 

 manuale sia molto NERD (qualita' apprezzata in certi circoli) :D
Pensa a risponde' ar telefono e lascia stare i protocolli di rete, non fanno
per te.


 computer... ma NON che il computer non li scriva male sul disco! ;)
le correzioni di errore garantiscono l'integrit� del il singolo 
pacchetto, non l'integrit� dell'intero file che per ovvie ragioni pu� 
essere controllata solo alla fine e soprattutto i protocolli non la 
verificano. da qui, appunto, la verifica manuale del checksum.

 pensando io
?!?!?!?!?!?!

 verificano. da qui, appunto, la verifica manuale del checksum.
Il tcp garantisce anche che tutti i pacchetti arrivino, cosa che unita
al controllo di errore "in teoria" garantirebbe l'arrivo corretto. Questo
per� assume che la trasmissione sia un unico stream sequenziale, cosa che
invece non � necessariamente.

 ma manco per sogno.
Allora internet è un inferno! :P 


 Il tcp garantisce anche che tutti i pacchetti arrivino, 
si ho capito cosa vuoi dire, ma le garanzie di affidabilit� che ti da il 
tcp sono sul canale e non sull'integrit� della trasmissione nel suo 
insieme. per dirne una (che poi � il caso pi� frequente se non l'unico) 
se si interrompe la connessione il tcp ti garantisce che fino a quel 
momento i dati sono stati trasmessi integri, ma capire che la 
trasmissione non � completa spetta ai protocolli che ci stanno sopra. in 
realt� afaik non te lo dice nemmeno http (fatto salvo capirlo dall'header 
content-length, che per� non � obbligatorio).

ma alla fine... se scarico wireshark
perch� tra il file scaricato e la sua signature
i valori sono diversi?

 i valori sono diversi?
boh, chi puï¿œ saperlo?
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/



La so', la so': stai scaricando con fastweb, quindi e' tutta colpa
DELLA RETE. :)


Sentenza wrote:

Se parliamo di checksum md5, non ne avrebbe bisogno.
Non � difficile taroccare (anche) un eseguibile (bench� non in maniera 
arbitraria) facendo in modo che abbia lo stesso checksum md5 dell'originale.
Se poi � l'autore stesso a farlo (creando una copia /buona/ e una 
/cattiva/ della sua applicazione), sono possibili anche taroccamenti 
arbitrari, sempre con lo stesso checksum md5.

 Allora internet � un inferno! :P 
E non sai quanto!
Ciao,
Marco


 sul server???
Ma pensa te...
Saluti.
Luciano

> arbitrari, sempre con lo stesso checksum md5.
Ma chi ? Due eseguibili con lo stesso hash md5 ??? E come di grazia
faresti ad ottenerli ?

enricoe wrote:

Beata giovent�!
http://www.mscs.dal.ca/~selinger/md5collision/

 Beata gioventù!
http://www.mscs.dal.ca/~selinger/md5collision/
Chapeau! E poi dicono che ili non serve a niente.

 Saluti.
Guarda che ogni giorno scarichiami milioni di byte e non mi sembra di navigare 
il televideo su un canale che si vede maluccio, con tutta l'"insalata" a video 
che comporta... 




Perch� Giove � in opposizione con Saturno :)
I motivi possono andare da "� stato taroccato sul server" fino a
"il tuo computer ha problemi e scrive male i dati"... per saperlo
devi prelevarlo da UN ALTRO sito e vedere se succede la stessa cosa!

 arbitrari, sempre con lo stesso checksum md5.
Vabb� tra un p� tiriamo in ballo gli alieni e i savi di sion :-)))

 l'"insalata" a video che comporta...
il checksum verifica l'integrit� *dell'intero* *file*. un file pu� essere 
corrotto non solo perch� non ha ricevuto correttamente dei pacchetti tcp 
(cosa che non accade mai) ma pi� banalmente perch� il download non � 
completo (cosa che invece pu� accadere eccome).
vediamo se ci si arriva.

 DELLA RETE. :)
...verissimo...occhio che LA RETE vi cura tutti.... :)
A te poi ha l'inquadratura fissa come su skai....ocio...:)

 
ma a te che checksum vengono di quello che hai scaricato?

 completo
Questa banalità non era argomento di discussione. Qui si parla di scaricare un 
file da 10K, ricevere 10K, ed assicurarsi che siano i corretti 10K. 


 corretti 10K.
bravo. adesso spieghi alla platea in che modo il protocollo http 
*garantisce* (per usare le stesse tue parole) che se tu ricevi un file da 
10k siano esattamente 10k anche sul server e non sia invece un download 
parziale.

 parziale.
Non so, non tratto molto il web. Faccio cose più serie, anche se ammetto ieri 
di aver smanettato con SOAP (ma poi mi sono fatto la doccia). :P


 Vale

 Faccio cose più serie, anche se ammetto ieri
tu sei solo un'immane, stupido, arrogante testa di $$ ignorante.
Soprattutto, un ignorante, che gode come un riccio ad esser sputtanato
giornalmente su ogni argomento ti capiti di scoreggiare.
Un programmatore che ignora anche la minima base di crittografia, e
mischia checksum con HTTP, con battutina da cretino su SOAP, è pronto
per la rottamazione.

 per la rottamazione.
Questa me la devi spiegare.
un programmatore che si occupa di gestionali, o microcontrollori su
apparecchiature embedded (due estremi della programmazione) deve per
forza sapere di protocolli di rete, crittografia e quant'altro???
e se non li sà è considerato vecchio???
se veramente la pensi così mi sa che ti manca una buona fetta del
mercato ICT.
queste cose le sanno sistemisti o chi si occupa di applicazioni per
apparati di rete (tipo CISCO e altri), o chi per passione lì ha
studiati.
per molti di voi queste cose erano nel piano di studi all'università,
ma mi rendo conto che non sì è prestata molta attenzione alla lezione.
ciao

 studiati.
Questo spiega perch� i programmatori fanno un casino ogni volta che
devono realizzare un'applicazione di rete! ;)

Sentenza ha scritto:



Applicazione "di rete" != "applicazione web".
Si possono realizzare "applicazioni di rete" che non usano http
(ho aperto centinaia se non migliaia di socket, fino a qualche
anno fa..).


 anno fa..).
scusa, sbaglio o l'argomento della discussione era la verifica di 
integrit� di un file tramite checksum?
se � stato tirato in ballo l'http piuttosto che le applicazioni web � 
solo per l'ignoranza di chi l'ha fatto. non c'entrano una beata ceppa.
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 studiati.
Quoto. Per me programmatore la rete *DEVE* funzionare. Importa sega come. Ho 
ben altro da farci sopra.
Un pilota di F1 deve guidare l'auto. E' il meccanico che gliela deve 
assemblare. 


 anno fa..).
E questo esattamente c'entra...??

 ben altro da farci sopra.
Per esempio, SAPERE COME USARLA???

 Per esempio, SAPERE COME USARLA???
Certo. Io faccio una richiesta ed attendo una risposta o un errore. Questo è 
sapere come usarla. Conoscere i pacchetti, i checksum e comunque cosa ci sta 
sotto non è compito specifico del programmatore. 


 forza sapere di protocolli di rete, crittografia e quant'altro???
no.

 Quoto.
Allora TACI, ignorante, invece di intervenire in thread su argomenti
di cui non sai nulla.
Mentecatto troller.

 sotto non � compito specifico del programmatore. 
Quindi tu decidi di usare UDP invece di TCP perch� � pi� leggero, e sei 
convinto di non essere tenuto a sapere che i pacchetti udp arrivano come gli
pare e quando gli pare senza garanzie n� correzioni di errore, e poi ti
stupisci pure perch� la tua applicazione non funziona, giusto?

 Quindi tu decidi di usare UDP invece di TCP perché è più leggero
Assolutamente no. Noi, per esempio, usiamo entrambe le modalità. La prima per 
gli "alert", la seconda per lo scambio dati.
E le app funzionano. 


 E le app funzionano.
SBRUOTFL.
Signori, un Pirla con checksum certificato.

 E le app funzionano. 
E funzionano magari perch� SAI che tcp lo devi usare in un modo e udp in un
altro, neh? ;)

 altro, neh? ;)
non infierire, dai.
Non è un bello spettacolo da vedersi, lascialo agonizzare

 Non � un bello spettacolo da vedersi, lascialo agonizzare
Fino ad adesso pensavamo in molti qui che lui fosse un pirla, ma almeno 
come programmatore pensavamo (anche qui, penso, in molti) che fosse 
bravo. E' giunta l'ora di rivedere le nostre opinioni? :-D

 altro, neh? ;)
Si, ma li mi fermo. In un auto so come si usa il cambio, ma non conosco tutti i 
meccanismi/ingranaggi che ci stanno sotto. Non capite, eh... 


 bravo. E' giunta l'ora di rivedere le nostre opinioni? :-D
Ah... Ah... Ah... Mi avete beccato a rubbbare lo stipendio, eh... :P 


 ciao

 Non � un bello spettacolo da vedersi, lascialo agonizzare
Non sono d'accordo. O meglio, tendenzialmente sono d'accordo con Luc.
Un programmatore non � tenuto a conoscere lo stack OSI/ISO, la
composizione dei datagram e cos� via. Deve conoscere quale strumento
utilizzare, sicuro, per� non � tenuto a conoscere i dettagli
implementativi.
Poi, se li conosce, meglio. 
-- 
Ciao!
Luca

 implementativi.
uh... di grazia, dove sarebbero i "dettagli implementativi"?
a casa mia scrivere un programma che utilizza un protocollo di rete 
senza sapere dove finiscono le garanzie del protocollo e dove iniziano i 
controlli applicativi si chiama *cialtronaggine* (ad essere gentili). il 
risultato � il solito programma che sta in piedi perch� tira vento da 
quattro parti.
ribadisco poi il concetto che l'argomento introdotto dall'op non ha 
proprio niente a che vedere con la programmazione, tantomeno la 
programmazione di rete, semmai � un problema che si pone l'utente 
internet esperto quale dovrebbe essere il frequentatore di questo gruppo 
a prescindere dalla sua specializzazione.
infine una domanda: ma non � che qui dentro si faccia abuso di frasi del 
tipo "non � tenuto a conoscere" riferite al programmatore?


 In effetti TCP garantisce l'integrita'. 
ma quando mai? :-)
d.

 del tipo "non � tenuto a conoscere" riferite al programmatore?
Pu� essere. Ma non � nemmeno corretto pensare che un programmatore
debba sapere tutto di tutto.
-- 
Ciao!
Luca

 ma quando mai? :-)
Noto che la confusione regna anche tra voi "sistemisti", eh... :) 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 composizione dei datagram e così via.
Grazie, qualcuno ha capito. Purtroppo ILI è pieno di SSSS (sistemisti 
sapientoni saccenti sinistri). Stessa definizione che do delle caccole 
appiccicate sotto le scrivanie... :) 


 Poi, se li conosce, meglio.
Continuate a svicolare sul punto cruciale.
A me non può fregarmene di meno la conoscenza che tu/lui/chicchessia
debba avere sui protocolli.
Sono tendenzialmente d'accordo, anche se penso che un programmatore di
oggi che ignora TCP e lo stack sia come un laureato in Filosofia che
non ha studiato greco. Può essere un ottimo filosofo, ma non avrà
alcune chiavi di metodo e interpretazione importanti.
Se però il Pirla (tm) interviene a piè pari in un thread dove si parla
di checksum, dando sfoggio di ignoranza e rispondendo da ignorante
supponente - come definisci uno che parlando di checksum e MD5 tira in
ballo il "controllo di HTTP" ? - si dà la zappa sui piedi.
Ha scritto una marea di cazzate perchè è INcompetente sulla materia.
Una persona di media intelligenza si astiene dall'intervenire, in
questi casi.
Non verrò mai a discutere di te in merito all'eleganza di una classe
di oggetti per un programma: non ne ho la competenza, me ne sto zitto
senza provocarti.
E' chiaro ora ?

 ballo il "controllo di HTTP" ? - si d� la zappa sui piedi.
Quoto, casso, se quoto! Prima fa lo sborone e poi dice che certe cose non le
deve sapere. Ma strarotfl!!!
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 deve sapere. Ma strarotfl!!!
è questo il punto: è un volgare provocatore, ignorante, mediocre come
tecnico, senza cultura, egoista e se ne vanta, rompendo i coglioni
anche in thread tecnici dove dovrebbe solo star zitto e muto.
Ma basta vedere il troll dove lo Sfigato Pirla sfoggia la sua
anzianità da programmatore per capire che qua dentro decine di Pecore
lo seguono contente....

 anche in thread tecnici dove dovrebbe solo star zitto e muto.
E cmq a me i programmatori\sviluppatori con i paraocchi non piacciono:
creano applicativi che attappano la rete per poi dare la colpa ai network
administrator.
Ai tempi della token ring, 16 Mb/s, ho avuto a che fare con sviluppatori in
visual basic che creavano query terrificanti!
Oggi, fortunatamente, sono graziati da una grande ampiezza di banda a costi
accessibili.


Poi, se li conosce, meglio. 
Sono concetti che si imparano in 15 minuti e in internet ci sono una
marea di diagrammi colorati che evidenziano layer per layer come si
chiama quello che ci passa sopra, che protocollo viene usato per la
trasmissione ed eventualmente che hardware lavora a che livello.
Questo per avere un quadro generale, un minimo di proprieta' di
linguaggio e per capirsi quando parli con qualcuno a fini
implementativi.
Poi volendo si puo' scendere piu' in basso e guardare cose c'e' in un
segmento TCP o UDP tanto per capire un minimo le differenze, vantaggi
e svangatti.
Guardare, per cultura personale, se devi imparare a memoria quanti
flag ci sono e la lunghezza di ogni campo gia' ti conviene pensare di
sforzarti un po di piu' e prendere una certificazione.
Dire che si tratta di stronzate solo perche' uno non le usa mi pare
andasse in voga alle scuole medie.
Saluti.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 sapere tutto di tutto.
fra sapere tutto e rispondere in quel modo c'è di mezzo il saper fare il 
proprio mestiere.
francamente, riguardo all'argomento della discussione, posso 
tranquillamente capire che non ci sia interesse e che (giustamente) si 
consideri a ragion veduta questi controlli inutili. ma dire "non sono 
tenuto a conoscere" è una risposta che, sentita da un collaboratore, non 
denota particolare intelligenza.

 lo seguono contente....
Non penserai mica di essere l'unico qui dentro che vede le cose come
stanno!:-)
Ignoralo, � ridicolo quanto insignificante.
Saluti.
Luciano

 Ignoralo, è ridicolo quanto insignificante.
lo confesso: è il mio pelouche antistress :-D