/t/ - Tecnologia

04/23 cioè aprile 2023, cioè è scaduta da 11 mesi

>>910
Quella è un'immagine di stock, la vera scade poi.

>Andare in ufficio postale: non sono riusciti a risolvere
Domanda stupida: hai provato ad andare in un altro ufficio? Te lo dico perché è arcinoto che un buon 80% della riuscita dell'operazione dipende da chi trovi allo sportello

>>912
E' un buon consiglio, lunedì vado in sede centrale e vedo cosa mi dicono.
Tette per il disturbo.

Dovrei loggare qui.

???

>>934
sembra uno di quegli indirizzi presi dalle mail truffa

>>935
Il sito è poste.it ed è persino non https. La mia idea è che li stiano hackerando da mattina a sera e rubando di tutto, ma tant'è…

>>936
no semplicemente non sanno gestire il sito che è pieno di bug

>>937
Sì ma l'https è lo standard da circa 10 anni. Hai miliardi di dineri di milioni di italiani e non metti neanche quello?

Non avete idea del clusterfuck di cascate di sub-sub-subappalti a bodyrenters che e' l' IT alle poste. Gli impiegati allo sportello sono cotti. Voglio vedere chi sono i gonzi che si compreranno le prossime quote

>>938
Lol avevo sbagliato a leggere
Non so cosa dire anon, vai a rompere le palle in diversi uffici centrali

>>940
Anzi, anziché fare file da coglioni alle poste che tanto il massimo che possono fare è aprire una segnalazione vai di servizio clienti telefonico

>>936
Ormai con i browser che si lamentano se ti connetti a "http" manca poco a che siano migrati tutti su "https"

Il sito delle poste, essendo stato scritto col culo, è molto più complicato da riconfigurare come "solo https" (anche se tutta la parte di autenticazioni e dati sensibili è in "https" fin dal primo giorno)

Il fatto è che le risorse "http" fino a un po' di anni fa erano molto più economiche da servire

>>942
Qualsiasi parte in http può essere usata per compromettere le parti in https, mixed content è una zappa sui piedi sempre e comunque.
Pagina tutta in https tranne una singola immagine in http? Un hacker può fottersi i tuoi cookie di login se riesce a fare MITM sulla richesta all'immagine, a meno che il sito non sia fatto molto bene e abbia messo il flag Secure sul cookie (pieno così di siti che se lo dimenticano).

>>943
Non capisco perché http è più economico?

>>1094
Perché ti arriva "in chiaro".

Ti arriva una stringa minuscola di richiesta ("GET /index.html" e poco altro) e tu non devi far altro che una print del contenuto sul socket.

Invece HTTPS:
- il client attiva la connessione e propone uno scambio di key
- il server decide se accettare e propone a sua volta key+challenge basandosi sulla request del client
- il client verifica dalla propria lista di key valide che la key-chain di appartenenza del server è proprio quella dichiarata con la challenge; se è OK allora conferma che il canale è crittografato e invia (crittografando) la request "GET /index.html")
- il server convalida la request del client e decrittografa la request, ottenento "GET /index.html"
- il server prepara il contenuto da spedire, e lo crittografa, e quindi sul socket fa la print del crittografato
- il client decifra il contenuto, verificando con la chiave e anche col checksum, e se è tutto a posto la richiesta è conclusa.

Quindi sia lato client che lato server c'è una caciara di lavoro perché prima bisogna prepararsi entrambi a crittografare (e assicurarsi che l'altro coincida con le key, e che il server abbia una key valida non scaduta e che sia inserita in una delle key-chain approvate (cioè quale authority ha convalidato la key del server).

La lista delle authorities è nel file .mozilla/firefox/[istanza.profilo]/cert9.db (profilo, se non configurato, è "default", mentre istanza è una sequenza di 8 caratteri casuali).

Tale db si può aprire con sqlite. Per esempio, per vedere le prime due:

>sqlite3 cert9.db
> select * from nssPublic limit 2;
"Google Internet Authority… CyberTrust Baltimore Microsoft…"

>>1096
l'HTTP/3 (QUIK?) doveva essere la risposta (viaggiare su UDP, cioè connectionless, e avere tutto già dentro il primo pacchetto, cioè evitare l'handshaking/scambiochiavi).

Sta prendendo lentamente piede ma non è detto che diventerà uno standard.

Comunque il fatto è che è tutto un enorme castello di standard nuovi costruito su standard vecchissimi.

Il TCP fu pensato per linee lente e "rumorose", e quindi tutta la trafila di connessione, di ripetizione pacchetti, addirittura di "urgent" bit, e cazzatine assurde.

Lo standard va ripensato daccapo, presumendo linee veloci e pacchetti jumbo.

Perfino IPv6 è una merda: poche buone idee, addressing ridicolmente esagerato (bastavano 64 bit di indirizzi, ce ne hanno messi 128), routing letteralmente da incubo, più parecchi dei vecchi vizietti di IPv4 (ed infatti è comunque nato il dynamic assignment di indirizzi, che era proprio ciò che l'IPv6 voleva evitare).

>>1096
Un'altra dura giornata passata a inventarsi cose insomma
https://github.com/MicrosoftDocs/azure-docs/issues/52297

>>1096
La metti come se servisse fare un nuovo handshake per ogni singola richiesta, in pratica ne basta uno per connessione.

>>1097
>TCP
>cazzatine assurde
TCP è praticamente ottimale anche sulla carta.
>la trafila di connessione
Letteralmente 3 pacchetti, il minimo necessario per allineare mittente e destinatario.
>ripetizione pacchetti
Solo se non sono stati confermati, e comunque c'è il buffer circolare e il fast NACK quindi un singolo pacchetto perso non pianta tutto.
>linee "rumorose"
O congestionate (in altre parole: utilizzate in maniera significativa), c'è una ragione per cui tutti i videogiochi che usano UDP reimplementano CUBIC e compagnia bella.
>Perfino IPv6 è una merda
Magari la merda sei tu, che parli a sproposito di cose che non conosci.

>>1099
È pur sempre un bel costo in termini di traffico e di capacità di calcolo. È vero che grosso modo dal 2020 è diventato meno rilevante. Ed è vero che è un costo accettabile perché la differenza fra crittografato e "in chiaro" è troppo spesso rilevante sia per il client che per il server.

Ma la domanda era "perché HTTP è più economico".

Alcune grosse aziende, come la F5, hanno tentato di vendere apparati esterni che si preoccupano di fare un po' tutto, dal firewall alla crittografia al load-balancing, ma a parte clienti super-grossi non hanno avuto grandissima penetrazione di mercato. Quando hai poche migliaia di connessioni l'ora, ti conviene davvero fare tutta la caciara dell'HTTPS sul server.

>>1105
TCP è ottimale su linee lente e disturbate, cioè su quelle su cui è nato. Fu pensato abbastanza bene, per cui si usa ancor oggi. Ma non è più ottimale.

Quando hai a che fare con linee veloci e poco disturbate (come la fibra ottica, dove la perdita di un pacchetto in transito è un avento decisamente raro), i limiti del TCP (come il contenuto massimo dei pacchetti, MTU) si vedono e si sentono forte. E un sacco di gente non può upgradare la propria network aziendale perché ci sono ancora apparati ottimizzatissimi per il canonico kilobyte e mezzo di MTU anziché per i jumbopacket da nove kilobytes o altre soluzioni più pulite. E quindi il cruft del legacy del vecchiume che "costa pazienza e soldi" aggiornare, resta tutto lì, come nel 2020, come nel 2010, come nel 2000…

Fun fact: Fastweb ritirò dal mercato dei router vecchi e bruttissimi, comprati "ricondizionati" da qualche americano che stava svecchiando il parco macchine, e li rifilò ai clienti da 10 mbit. Qualche anno dopo li svecchiò ma anziché rottamarli li conservò in magazzino perché un upgrade del firmware consentiva di portarli a 100 mbit. Erano un casino da configurare lo stesso. Insomma, furono ripuliti col pennelluccio antipolvere e rifilati ai clienti business che chiedevano la 100 mbit (a Milano nel 2015 già era operativa la 100/100 FTTH). Insomma, quegli aggeggi vissero tre volte, e non escluderei che dopo la terza rottamazione li abbiano venduti a qualche società estera (gli africani letteralmente comprano a prezzo stracciato tutti i nostri apparati più obsoleti), magari facendoci pure guadagno.

>>1105
p.s.: linee "rumorose" sono da intendersi "disturbate", cioè dove la probabilità che un bit trasmesso arrivi a destinazione non è proprio "quasi 100%".
"Congestionate" equivale a "rumorose" solo quando tutti trasmettono contemporaneamente sullo stesso canale (ma lì si parlava di dorsali, backbone, non della ethernet 10 megabit casalinga degli anni '90).