Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.
Post - Z80Fan
16
« il: 29 Giugno 2018, 23:21:56 »
quindi, questi "tizi", visto che non sono capaci di creare una nuova coppia nick/password, possono usare il vecchio nick ed usare un file al posto della password, e ... la cosa dovrebbe mettere a tacere una volta per tutte RadionDick e tutti i suoi seguaci Ma io non riesco ancora a capire questo ragionamento: la gente sta veramente venendo da te a dirti "gne gne non mi registro sul tuo sito perchè altrimenti usi la password per accedere a tutti gli altri siti con cui ho la stessa password" ? Non si rendono proprio conto che stanno facendo la figura dei ritardati mentali? Probabilmente si meriterebbero anche di vedersi gli account compromessi (non certamente da te, ma prima o poi un sito che usano sarà violato e allora tanti auguri). Inoltre è palese che se qualcuno viene a dirti tali ritardaggini è solo perchè vuole diffamarti; se implementi la cosa dei file probabilmente direbbero che quando fai l'upload tu gli formatti il disco e mandi tutto al governo russo...
17
« il: 29 Giugno 2018, 22:41:10 »
- ti tocca per forza comprare un dominio, che sono come minimo 20-30 Euro all'anno Nah, riesci a trovarli anche intorno a 10-15 (e tipicamente il primo anno de lo danno a prezzo stracciato, quindi puoi anche provare e poi farlo scadere). Per esempio ho provato la procedura per acquistare downthebunker.com su register.it e te lo danno a 0.90 per il primo anno, e quando ho scelto 2 anni mi faceva 24 euro, quindi 12 all'anno. Ovviamente pagando subito 10 anni ti fa 10.2 all'anno ma non credo sia una soluzione. Probabilmente vorrai comprare anche la "protezione identità" che non mostra i tuoi dati nel whois, però a mente non ricordo quanto costa. EDIT: un amico mi ha indicato questo registrar: https://www.namesilo.com/Ci ha comprato un dominio .bid per 1.89$ con protezione whois inclusa. che e' un costo pure, visto che a noi di quattrini non ne entrano, che ci stiamo gia' mettendo corrente, macchine (che accese 24h/24 si usurano e vanno considerati i ricambi), oltre che tempo personale Fai una seria valutazione su questo, perchè ormai i servizi di hosting VPS sono molto più convenienti rispetto a gestire l'hardware in proprio: il tier base su DigitalOcean o Linode è di 5 dollari al mese e anche se ti danno un core e mezzo giga di ram girano su mostri Xeon e quindi viaggiano di brutto; inoltre hanno connettività gigabit o superiore verso Internet (Linode addirittura ha un download verso il VPS di 40 Gbps su tutti i tier ) Probabilmente se fai anche solo il conto dell'elettricità che usi per tenere acceso un bidoncino che fa da server ti escono più di 5 euro al mese, specialmente qui in Italia dove la corrente costa un botto... non vedo come possano sfondare il modulo di autenticazione Di solito quando si parla di brute-force non si intende che attivamente fanno tentativi di intrusione, ma si assume che ti hanno già rubato i dati dal database e quindi hanno già l'hash di destinazione che devono cercare di matchare con un qualche plaintext. cosa te pare dell'autenticazione tramite hash di un file da uploadare piuttosto che password da digitare?
droppo questa cosa, lascio la classica password da digitare, o entrambe, selezionando poi quale si desidera usare?
Dal punto di vista della sicurezza non fa né caldo né freddo: una volta che il file gigante è stato hashato, hai ridotto l'informazione alla lunghezza dell'hash, e all'attaccante basta solo trovare qualche testo che genera lo stesso hash del tuo file gigante. Io direi di lasciare solo la password tradizionale e implementare l'hashing con quelle funzioni che ti descrivevo prima; in questo modo saresti già meglio del 99.9999% dei login "fatti in casa" che ci sono su Internet.
18
« il: 29 Giugno 2018, 21:04:09 »
Plz do some reading about storing passwords, hashing on its own is not common practice! Never roll your own, md5 and base64 is so trivial to reverse you might as well store plain text. Fix that before worrying about https.
questa e' vera? se si, cosa si fa?
Si, è vera. MD5 è molto semplice e quindi velocissimo da computare ed inoltre ha diverse vulnerabilità scoperte. Per memorizzare password come minimo serve una funzione di hash crittografica, come la serie SHA, anche se è meglio già oggi orientarsi verso SHA-2 visto che per SHA-1 è stata trovata una collisione. Però la soluzione "moderna" (fra virgolette perchè esiste da vent'anni) è usare delle funzioni di hashing specificatamente studiate per memorizzare password, come bcrypt e la più nuova scrypt. L'idea di queste funzioni è che applicano una procedura in più iterazioni (come parametro configurabile) in modo da rendere molto più lenta l'operazione di hashing; l'idea è che un uso corretto della funzione (ovvero controllare la password) è una operazione una-tantum e quindi anche se è un po' più lenta non è un problema, mentre i metodi brute-force vengono penalizzati. Il parametro di iterazione è configurabile e sarebbe da aumentare man mano che la potenza di calcolo media aumenta in modo da mantenere circa costante il tempo che sarebbe necessario per un completo brute-force. Quindi, "cosa si fa?": usa o bcrypt o se puoi scrypt, con l'opportuno salt e un parametro di iterazione più alto possibile senza inficiare nel carico del tuo server (a spanne direi di tararlo in modo che impieghi circa 100ms a password) Riguardo la cosa del GDPR, come tutte le cose lui non "forza" o "richiede" nulla, sta al gestore del dato fornire un risk-assestment riguardo alle soluzioni che implementa per garantire la sicurezza del dato. C'è comunque da tener conto che il linguaggio del GDPR richiama sempre lo "stato dell'arte" nella tecnologia di protezione dei dati, e in un certo senso "si aspetta" che venga seguito lo stato dell'arte, ovviamente dove possibile e senza esagerare (nel senso che un panettiere non è tenuto ad avere un datacenter con guardie armate). Vedi ad esempio: https://gdpr-info.eu/art-32-gdpr/Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk [...] Quindi diciamo che tu puoi anche fare a meno di applicare la cifratura al trasporto, però è molto probabile che se mai qualcuno dovesse avere i suoi dati personali rubati da un attacco MITM mentre navigava sul tuo sito, probabilmente ti contesteranno che HTTPS è una tecnologia diffusa e di economica applicazione (economica sia di tempo che di danaro) e quindi non aveva senso non applicarla. Ovviamente non sono un avvocato quindi prendi quello che ho detto con un grosso grano di sale.
19
« il: 21 Giugno 2018, 21:08:28 »
Client-Server asymmetric encryption Chiamasi HTTPS. è inutile creare soluzioni "casalinghe" quando ci sono sistemi già rodati inclusi nei browser. Qualsiasi browser che supporti Javascript già implementa HTTPS, ed è attivo anche se l'utente ha disabilitato gli script. Inoltre JS è decisamente più lento di un codice nativo, nonostante gli incredibili JIT che ormai includono tutti i browser principali.
20
« il: 20 Giugno 2018, 23:34:26 »
2) e che tra browser e server, anche senza HTTPs, ci sarebbe un tunnel criptato Occhio che hashare la password sul client non vuol dire "cifrare", perchè l'hash stesso diventerebbe la password: metti che la password "hunter2" viene hashata in "12345", e viene inviata al server (che eventualmente fa un secondo hash+salt per compararla a quella memorizzata nel DB), effettivamente è come se "12345" fosse la password in se, e quindi al malintenzionato che ti ha fatto MITM e ha letto il traffico basta fare un replay della tua procedura di autenticazione (trasferendo quindi l'hash) per farsi tornare un token di autenticazione. E' vero che questo impedisce al MITM di avere la password originale ("hunter2") (semprechè la funzione di hash eseguita dal client sia crittograficamente forte, altrimenti con delle semplici rainbow tables si possono trovare vari plaintext per un certo hash), però non previene la protezione dell'account.
21
« il: 07 Giugno 2018, 19:15:05 »
Cosa ne pensate? Che in questo modo potresti non presentare l'agreement a una persona che putacaso ha lo stesso IP di un'altra che ha già confermato (ad esempio se entrambi stanno su una rete privata che esce dallo stesso IP pubblico). Comunque noto che c'è tanta confusione dietro cosa dice e non dice il GDPR: non è che dice di non dover memorizzare nessun dato sensibile, ma semplicemente dice che ogni volta che tu memorizzi un dato sensibile, devi documentare per cosa lo usi, perchè ti è necessario memorizzarlo e per quanto tempo prevedi di memorizzarlo. Diciamo che "l'innovazione" del GDPR rispetto a leggi precedenti (complesa la porcata italiana) è che non ci sono più regole fisse e checkbox da riempire per essere in regola, ma regna il concetto di risk assestment dove tu gestore del dato sensibile dichiari i tuoi processi, le tue motivazioni, e i metodi che usi per memorizzare, gestire e proteggere il dato sensibile. Considerando che (credo) tu non devi memorizzare alcun dato sensibile anche solo per leggere il contenuto del sito pubblico (quindi non ti serve essere loggato), non dovresti aver bisogno di mostrare alcuna informativa, mentre ad esempio quando un utente si registra o accede per la prima volta con un nuovo profilo, puoi presentare la schermata di accettazione e quando l'utente conferma ti segni un booleano nel database per dire che l'utente ha accettato l'informativa. In questo modo non hai bisogno di trafficare con i cookie quando un utente non è loggato, e quando uno è loggato avrà o un cookie o il token di sessione nell'URL (come fanno vari framework se si accorgono che i cookie sono disabilitati), e quindi con quello puoi risalire all'agreement guardando i dati dell'utente associato a quel token.
22
« il: 26 Maggio 2018, 11:14:08 »
ma come fai ad avere 3000-mila pixel scrreen? un errore-di-sbaglio? un magheggio alla Neo dentro matrix? magia voodoo?
Con uno schermo 21:9 Ho solo dovuto vendere un rene e mezzo ma poi sai che visuale.
23
« il: 24 Maggio 2018, 20:27:57 »
Quest'ultimo ha un check per le dimensioni dello schermo (e del browser usato) e vorrei che fosse fruibile anche sugli smartphone dove lo screen e' tipicamente 420x260 o giu' di li Non hai bisogno di controlli programmatici (es. in JS) per adattarti alla dimensione dello schermo, basta che usi un layout flessibile, che HTML di suo nasce già, devi solo star attento o a non dare dimensioni o posizioni fisse (che non siano in %) in CSS (eccetto per un eventuale min-width che volente o nolente a un certo punto dovrai dare una dimensione minima al sito), oppure organizzare elementi (tipo pulsanti) in tabelle (che è un enorme taboo nel web-development moderno). Diciamo che la tua home page già adesso è largamente flessibile; l'unico problema sono i tre pulsanti principali (vedi prima figura); si potrebbe risolvere la cosa togliendo la table e mettendo dei div flottanti a sinistra (così quando non c'è spazio a destra cadono uno sotto l'altro), oppure inserirli in un layout flessibile in modo che si ridimensionino. Come buona pratica sarebbe da evitare di usare le table per il layout, però metodi "comodi" per ottenere lo stesso risultato (flexbox) sono tecnologie relativamente moderne (HTML5 e CSS3), e assumendo che si voglia lasciare il sito accessibile a browser più vecchi, si può lavorare con le table in layout fixed: <table style="table-layout: fixed; width:100%; max-width: 600px; margin: 0 auto 0 auto"> <tbody> <tr> <th> <a href="reloaded/durcheinander/"> <img style="width:95%" src="index_full_data/icon-harlock.png" alt="Durcheinander (secteur privé)"></a> </th>
<th> <a href="chunk_of/stuff"> <img style="width:95%" src="index_full_data/icon-folder-pirate.png" alt="Chunks"></a> </th>
<th> <a href="reloaded/bazaar/mylast.php"> <img style="width:95%" src="index_full_data/icon-marketplace.png" alt="Bazaar"></a> </th> </tr>
<tr> <th>Durcheinander</th> <th>Chunks</th> <th>Bazaar</th> </tr>
</tbody> </table> Come tocco finale metterei un "min-width: 350px" sullo style del body, e ottieni un risultato come nella seconda figura.
24
« il: 21 Aprile 2018, 01:09:39 »
per i forum e' pura inutile morbosa paranoia. No, non lo è, è la corrente best practice. E' come se tutto il discorso fosse BBS vs Web nella metà dei 90: "che roba inutile è il Web, trovo tutto quello di cui ho bisogno anche sulla mia BBS preferita e il web non è supportato dal mio Commodore 64. Che senso ha che il mio panettiere apra un sito web invece che una pagina su una BBS qualunque? Così può mettere delle foto sfuocate e delle GIF animate?" Un forum potrebbe permettere di accedere alle informazioni pubbliche in solo HTTP, ma la navigazione dopo il login dovrebbe essere possibile solo in HTTPS, in quanto hai dei token di sessione (memorizzati nei cookie tipicamente) che sono privati e garantiscono la tua identità, se e solo se la comunicazione client-server è mantenuta protetta in qualche modo. Magari a te non interessa di essere protetto durante l'uso del servizio, ma se io fornisco un servizio a terzi, i quali si fidano abbastanza di me da creare un account, con una password che sappiamo tutti essere la stessa che usano in 18000 siti diversi, il minimo che posso fare è creare una comunicazione sicura. Ovviamente poi devo fornire un server sicuro, perchè hai voglia ad avere un canale sicuro se poi hai SQL injection da tutte le parti. Per lavoro tra le altre cose ho sviluppato dei gestionali interni sottoforma di web-application: tutta roba di cui neanche un byte uscirà mai su Internet, eppure gira tutta HTTPS only (con certificati self-signed installati nei singoli computer manualmente o attraverso una policy di Active Directory). La maggiorparte di security breaches avviene all'interno di una rete locale, dove tipicamente si assume che tutti i dispositivi siano fidati; l'unica soluzione è assumere che la rete sia insicura appena fuori dall'interfaccia. NSA è uno dei pochi siti di cui io sono parzialmente responsabile e che non ha ancora supporto HTTPS, principalmente perchè vogliamo cambiare piattaforma che ahimè non riusciamo a trovare il tempo per avviare. Che porta la gente a sentirsi piu' sicura nel riversare in rete Km di puttanate personali (foto, filmati, selfie, etc), tutta spazzatura, che ammazza pure i browser che non lo supportano. Non capisco come le due cose siano collegate. L'unica cosa che HTTPS garantisce in questo contesto è che il sito con cui stai interagendo è proprio il sito che tu credi (=autenticazione), che il contenuto scambiato arriverà esattamente come l'hai mandato senza possibilità che una terza parte lo abbia modificato (=integrità), e che, meno importante in questo caso che il contenuto è già pubblico, che una terza parte non possa leggere il contenuto senza permesso (=privacy). Un esempio che mi viene in mente dove è importante l'integrità è per evitare che un ISP introduca nella pagina degli elementi quali pubblicità o messaggi indesiderati; questa non è fantasia e succede attualmente (è diffuso negli USA, dove gli ISP sono molto più stronzi di quelli che abbiamo noi, a causa del loro regime di monopolio fanno un po' come gli pare). ma la rete wifi e' criptata gia' di suo Ha una cifratura molto semplice che è banalmente reversibile, specialmente se già conosci la PSK (la "password"), che è il modo normale in cui tutti gli access point "free wifi" che ci sono in giro agiscono. https://security.stackexchange.com/questions/12596/can-a-hacker-sniff-others-network-data-over-a-wireless-connectione perche' ci deve essere il lucchetto per visitare un sito di ricette di cucina? che senso ha? Il senso è che non ha senso NON farlo. Siamo nel 2018, tutti i provider di hosting forniscono HTTPS gratuitamente, tutti i webserver supportano da eoni HTTPS con le più recenti versioni di TLS, ed è banalissimo avere un certificato legittimo e rinnovarlo con gli strumenti che dicevo prima. Che senso ha NON usarlo? Cosa hai concluso togliendo autenticazione/integrità/privacy? Così puoi usare il tuo vecchissimo dispositivo che è obsoleto per tutto incluso il navigare il web moderno, che probabilmente gira su un OS obsoleto con decine di falle di sicurezza, e che in qualsiasi caso probabilmente non riuscirebbe a renderizzare la pagina? Tu mi chiedi che senso ha per un sito di ricette, io ti chiedo: è così assurdo e fuori dal mondo avere un minimo di garanzia sui dati che ricevo? Non ha senso volere che i dati siano effettivamente arrivati dal sito che ho richiesto, senza che qualcuno nel mezzo mi abbia redirezionato su un fake che mi spiega come fare una torta avvelenata, oppure che mi inserisca nella pagina un widget nascosto che mina i bitcoin dal mio PC, o magari lo usa per rendermi parte di una botnet? La S in HTTPS non vuol solo dire che non possono leggerti la password. e come la mettiamo con le app di faccia libro che ti chiedono le generalita' per autenticare le mille mila puttanate dei siti che oggi ti chieno proprio faccia libro come mezzo di autenticazione?
questa roba e' una infelice breccia nella falsa sicurezza di https Adesso mi devi spiegare cosa c'entra HTTPS con l'autenticazione stile OAuth, al di fuori dello scambio di token che necessariamente è HTTPS-only perchè altrimenti non avrebbe neanche senso farlo. Perche' di fatti lo e'! Https esiste da una vita, eppure e' proprio ora che i social stanno impennando che si e' imposto per qualsiasi cosa necessiti di faccia libro per l'autenticazione. Basta dire boiate.Per l'ennesima volta, il motivo per cui HTTPS è consigliato e ormai quasi obbligatorio più che in passato è perchè i sistemi di deploy si sono perfezionati a tal punto che la sua attivazione e gestione non è più qualcosa che riescono a fare solo i guru. Non è uscito Zuckemberg dagli inferi minacciando di dannare per l'eternità chiunque non inserisse un pulsante "Login con Facebook" in ogni pagina del mondo, che comunque sarebbe un discorso indipendente da HTTPS. Sarebbe come dire "La gente riempie il web è pieno di GIF animate, dannato TCP/IP!". la maggior parte delle volte in cui ho bisogno di un pdf, di un datasheet, il sito di turno mi ha chiede faccia libro (dirottando su https) per poter scaricarlo scaricare. Quindi da questo tu deduci che è tutta colpa di HTTPS, invece che degli sviluppatori figli di puttana che per farti scaricare un documento prima ti fanno loggare così possono tracciarti e rivendere i dati a fine di marketing? Credi che eliminando HTTPS dal mondo un tale tipo di funzionamento non sarebbe possibile? Si, probabilmente Facebook (o Google o Twitter o tutti gli altri che nonostante rivendano i dati degli utenti per far soldi, alla sicurezza ci tengono eccome) non fornirebbero mai un metodo di autenticazione se non è possibile eseguire un handshake su una connessione sicura, ma questo non ferma di sicuro migliaia e migliaia di siti che sono ancora HTTP-only e hanno form di login su cui passa tutto in chiaro. Sai tipicamente cosa faccio quando trovo uno di quei siti? Chiudo la pagina e trovo un altro posto. Mio personale consiglio: http://www.datasheetcatalog.com che è pure HTTP-only, come piace a te. I social sono il core delle informazioni che girano in rete. Loro hanno cambiato la rete. Loro hanno imposto nuove strutture di pensiero e di linguaggio, sia umano che tecnico. ErLang per esempio, prima lo trovavi quasi solo db-mnesia per comprare i boglietti aerei, o in certe app di nicchia, oggi e' uno dei pilastri di faccia libro, e non solo!. Sono i social che hanno distrutto i forum strappandone l'utenza. Sono loro che hanno marcato la differenza con la vecchia internet, quella insicura dell'era dell'http ed ftp, roba non criptata, e sempre loro rappresentano la maggiore fonte di traffico (quantomeno da quanto risulta dai link dei datacenter che abbiamo analizzato) per la massa che gira e rimbalza in rete. Ok, i social media sono i siti più visitati. E QUINDI?Arrivare da questo data-point a masturbare tutta una cospirazione su come HTTPS sia richiesto solo perchè I SOCIAL I SOCIAL!!! è una cosa assurda che non sta né in cielo né in terra. Io non ho mai usato Facebook, Twitter, Instagram, Snapchat e tutte quelle cose lì, le cose che più si avvicinano a un social sono YouTube e Reddit, ma uso HTTPS su ogni sito che posso, e sopratutto non creo account o faccio login se sono su una connessione non cifrata. NSA è letteralmente l'unico sito non sicuro su cui sono loggato. Il sito delle ricette di cucina continua a rimbalzarmi il browser perche' non supporta https Quel messaggio indica che il tuo client e il server non sono riusciti a mettersi d'accordo su una versione di SSL/TLS e su un cifrario da usare, probabilmente perchè il tuo client supporta solo versioni molto vecchie di una o dell'altro (SSL è deprecato da moltissimo tempo ormai, e TLS 1.0 è di recente passato a considerato poco sicuro). Soluzione: usa un browser più aggiornato. Quando anche una schedina da 30 euro come il RPI3 riesce a far girare Firefox/Chromium completi a una velocità ragionevole, non c'è motivo di insistere a usare macchine e software datato, al di fuori di strani esperimenti. Insistere a usare hardware e software obsoleto non è molto diverso dai tizi che tanto vai a deridere che insistono ad usare i bidoni SGI come un PC moderno. If you are not an idiot, then https is worthless "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." - Edward Snowden
25
« il: 20 Aprile 2018, 18:35:41 »
A giudicare dai dati raccolti da datacenter, dal 1995 al 2015 abbiamo tutti quanti usato HTTP per BBS e forum senza che nessuno si preoccupasse della paranoia della password in chiaro durante l'autenticazione Da come l'hai scritto sembra che HTTPS l'abbiano inventato l'altro ieri così per sport senza un motivo preciso; la realtà è che è nato nel '96 come HTTP su SSL e nel 2000 c'è stato il primo RFC per HTTP su TLS. Oggi e' diventato un MUST! I siti si stanno convertendo tutti in HTTPS, tutti gridano che altrimenti e' insicuro E fanno bene, perchè HTTP È insicuro, ovvero non fornisce garanzie su autenticazione, privacy e integrità, che sono i capisaldi della sicurezza nelle telecomunicazioni; non serve solo a fare in modo che non ti rubino la password. Inoltre la potenza di calcolo dei dispositivi moderni (coadiuvata da tutte le accelerazioni hardware) è tale che l'overhead di TLS è molto basso. In precedenza l'ostacolo principale era il costo di procurarsi un certificato, la "difficoltà" dell'impostazione del server (che era data più dalla scarsità di guide e tutorial che da una difficoltà operativa; alla fine non è altro che dare certificato e chiave privata al web server e attivare HTTPS), e la necessità di periodicamente rinnovare il certificato, ma al giorno d'oggi i prezzi sono calati parecchio e oltretutto con iniziative come Let's Encrypt il certificato è gratuito e inoltre si automatizza il processo di deploy e renew. L'unica cosa che è successa negli ultimi 3 anni, come dici tu, è che il deploy di HTTPS si è semplificato talmente tanto che la sua presenza non è più qualcosa "di più" da aggiungere a un sito, ma è la normalità, e un sito solo HTTP ha qualcosa "di meno". Ora, il fatto in se', e' non e' pericoloso, visto il giochino dei crackers "funziona" solo a patto di essere fisicamente sulla stessa subnet della possibile vittima; Non è necessariamente vero: MITM significa genericamente inserirsi nel path di comunicazione di due peer, che può verificarsi anche a livello 3, per esempio in un ISP. Ci sono poi altre tecniche che permettono di creare un MITM (tipo arp poisoning) che funzionano solo nella stessa subnet (e di conseguenza nello stesso layer-2), ma non sono le uniche possibili. cosa che pero' accade davvero p.e. in ufficio, o in un piccolo LUG, e se molti possono farlo a casina loro, la cosa diventa mediatica. Oppure, anche peggio, accade in una rete wireless, visto che per sua natura è un media condiviso. Visto che difficilmente convincerai la gente a non usare il wireless, ne va di suo che bisogna trattare qualsiasi rete in uscita come potenzialmente insicura e quindi bisogna inserire degli strumenti che possano garantirne la sicurezza (come quando si usa il TCP che garantisce che i pacchetti saranno consegnati tutti, in ordine e senza errori). E' un fatto oggettivo: la internet v1 e' insucura, http e' insicuro! ecco la notizia in bocca a quelli che con le notizie di questo tipo campano come avvoltoi sulle carcasse delle carogne. Sono vent'anni che ci si preoccupa della sicurezza del web, quindi non è una notizia per gli addetti ai lavori. Lo è invece per la "gente comune" che usa i sistemi informatici come elettrodomestici e quindi non sa e non fa caso a tutti questi problemi di privacy nel loro operato; da questo la necessità di insegnare di controllare se c'è "il lucchetto verde in alto a sinistra" quando si visita il sito della banca o di qualche istituzione. Ma e' mai successo in 20 anni di utenza che qualcuno si sia sentito cosi' minacciato da doversi trincerare dietro SSL e crittografia? Prova a chiederlo a tutte quelle persone che vivono in paesi con regini dittatoriali dove le vie di comunicazione sono totalmente sotto sorveglianza e puoi essere condannato a morte per aver detto qualcosa di "sbagliato". Inoltre, pure io nel mio piccolo se devo accedere a un sito di home banking o e-commerce preferirei che la mia comunicazione sia sicura (=autenticazione, privacy, integrità), grazie mille. Eppure ... 20 anni fa nemmeno era "sano" postare Gigabyte di foto, il proprio cuBo appeso al filo di un tanga su faccia libro, per poi craniarsi: oh, se mi fottono l'account questa roba la vedono tutti! 20 anni fa il web era usato da 16 milioni di utenti, la maggiorparte tech-savy, mentre adesso ci sono più di 4 MILIARDI di utenti, dall'ingegnere aerospaziale alla diva che posta foto del culo su instagram. Non puoi paragonare cosa è "normale" oggi a quello che era "normale" 20 anni fa, dopo una crescita esponenziale come questa. Quando la gente usava internet in modo sano, la risposta era tipicamente: "ma chi se ne fotte se mi bucano la password? al piu' scrivono barzellette al posto mio, o sbirciano il gossip provato in MP. Nulla di compromettente", perche' la vita, quella vera, non era mai stata digitalizzata sulla rete!
Oggi e' invece percepito come una tragedia inaccettibile: internet e' La Vita (un suo simulacro, ovviamente), tutto cio' che non puo' essere postato, documentato, perde di significato perche' (ecco il baco mentale) se gli altri non lo vedono anche solo potenzialmente (metti che ti do l'amicizia?), tu non esisti, e quindi oddio se mi fottono le foto su faccia libro (come se non fossero gia' tutte condivisi ed accessibili a tutti), oddio mi fottono gli MP con dentro chissa' quali segreti segretissimi, oddio! Paragonare il WEB (e non l'Internet che sono due cose estremamente diverse) al solo set dei social media è una grossolana e miope generalizzazione. E continuo a non capire perchè devi tornare sempre a parlare dei social network (che sono solo UNA delle applicazioni che girano sul Web e di conseguenza su Internet) come se HTTPS fosse una cosa che è stata introdotta solo per quello. (l'inferno e' qui, ma mettere a posto i problemi tipo di flash? con i vari troiani? tutto sto schifo l'ha aggiunto internet v2, e sembra non voler far nulla per porvi rimedio .... ah, gia' HTML5 ... forse) Flash è stato criminalizzato e indicato come obsoleto da quasi una decina d'anni (nel 2010 il famoso scontro Apple-Flash), e ad oggi vengono solo portati avanti aggiornamenti di sicurezza, con Adobe che indica il 2020 come fine definitivo del supporto. La maggioranza dei siti che dipendevano da Flash (uno su tutti, YouTube) sono stati convertiti a HTML5+JS, ed è già qualche anno che puoi navigare sul Web senza aver bisogno di Flash installato (mi sono accorto giusto oggi che sul computer di casa non ho Flash installato perchè stavo cercando di accedere alla console web di vmware, che questa versione dipende ancora da Flash ma già le versioni più nuove hanno una nuova interfaccia HTML5). Un'altra tecnologia simile sono gli applet Java, ma che per nostra fortuna non avevano mai preso piede e quindi sono essenzialmente già estinti. Difatti ci si mette 21 ore a compilare firefox, di cui 8 sono per tutta la roba di sicurezza (ci cui SSL e' solo una minuscola parte) che si deve portare dietro per non parlare di quanto sia difficile accedere a siti SSL con brower come Netscape che nemmeno possono avere layer crittografici. Quindi il succo di tutto questo è che Firefox è lento a compilarsi? Meglio che il mondo ignori la sicurezza così puoi risparmiare un po' di tempo? Non è una scusa valida. Netscape (che ironicamente è stato il primo a sviluppare HTTP over SSL nel lontano '96) sarebbe in qualsiasi caso inusabile nel web moderno, con o senza HTTPS, a causa della mancanza di supporto ai vari standard creati nell'ultima decade. sta portanto a trincerare il proprio traffico (e letteralmente il proprio cuBo) dietro VPN VPN che al 100% sono implementate come un tunnel dentro SSL/TLS... bisognerebbe creare una VPN in chiaro, così possiamo evitare di compilare TLS. Tutto questo, ironicamente, ha portato Google a sostituire le macchine di confine backbone tra "internet" ed il coro cluster-core, con delle RPI, uniche archietture largamente disponibili, facilmente clusterizzabili in torri di computazione, abbastanza potenti, e sopratutto immuni dalle vulnerabilita' con cui in molti hanno sfondato SSL ed ammenicoli usando un approccio diverso. Perdonami ma non ci credo nemmeno un po', prima di tutto perchè Spectre e Meltdown colpiscono anche ARM, secondo perchè quelle falle sono mitigabili in software, terzo perchè se proprio avevano problemi con i processori Intel potevano sostituirli con processori AMD, e non di sicuro da dei processorini low-power come quelli del Raspberry Pi (di cui neanche la versione 3 ha un'ethernet Gigabit), e quarto perchè i router e i firewall del calibro che userebbe Google non girano su x86 ma hanno tutta una serie di dataplane che gestiscono il traffico con ASIC custom.
26
« il: 20 Aprile 2018, 13:16:56 »
Ok il commento contro i social media, ma non ho capito qual'è il problema con l'HTTPS.
27
« il: 17 Aprile 2018, 21:43:35 »
Stasera sfortunatamente sono di corsa quindi non posso scrivere "Il Papiro", però ti punto giusto a questo tizio che ha fatto vari esperimenti con NN che giocano a Super Mario e Mario Kart: https://www.youtube.com/watch?v=qv6UVOQ0F44(altri video li trovi sul canale) Appena ho un po' di tempo libero ripasso per dare qualche altra informazione.
28
« il: 11 Aprile 2018, 20:52:04 »
Qualcosa mi dice che se fossero messi a paragone di uno Xeon o un Epyc, prenderebbero grosse bastonate. Purtroppo POWER va avanti solo perchè dietro c'è IBM e tutta una serie di clienti enterprise che hanno talmente tanto software che è più economico comprare costosissimo hardware custom piuttosto che riscriverlo. ARM con decine e decine di core è invece interessante nel campo networking, per router e firewall ad alte prestazioni, dove il workload è seriale su una singola connessione ma embarassingly parallel tra tutte le connessioni.
29
« il: 06 Febbraio 2018, 19:32:36 »
Ci lavoro io; ho anche la certifica MikroTik MTCNA. Sono veramente delle belle macchinette, l'hardware è molto economico per le funzionalità e RouterOS è un mostro di configurabilità. A quanto ne so RouterOS gira sopra un kernel Linux ma proprietario; non ho mai indagato se hanno della documentazione per il bootloader per lasciarti caricare un tuo OS custom... Secondo le risposte di QUESTO post sul forum ufficiale, se contatti MikroTik ti possono fornire i sorgenti di tutto il software GPL che hanno modificato, quindi per lo meno puoi integrare il tuo kernel custom con il loro. Se chiedi molto gentilmente probabilmente ti possono seguire nel tuo scopo, magari a patto che non distribuisci nulla...
30
« il: 30 Gennaio 2018, 18:39:33 »
Bellissima!
|