Domanda:
Quanto è importante l'ora locale per la sicurezza?
Martin Thoma
2018-09-11 23:36:12 UTC
view on stackexchange narkive permalink

Di recente volevo vedere cosa succede quando cambio l'ora locale con qualcosa di ovviamente sbagliato. Ho provato l'anno 2218, quindi 200 anni nel futuro. Il risultato: non potevo più accedere a nessun sito web (non ne ho provati troppi, però). Ho ricevuto questo errore:

enter image description here

Immagino che NET :: ERR_CERT_DATE_INVALID significhi che un certificato HTTP non è valido . Ma di solito c'è un'opzione "avanzata" che mi permette di ignorarla. Non così qui. Inoltre, mi chiedo perché dice "il tuo orologio è avanti": se Chrome conosce l'ora corretta, perché non ci vuole per il confronto?

Venendo alla mia domanda: quanto è importante l'ora locale per la sicurezza ? Se un utente malintenzionato può modificare arbitrariamente l'ora del sistema, quali tipi di attacchi lo consentono? Sono stati segnalati casi in cui la manipolazione del tempo era una parte cruciale?

"se Chrome conosce l'ora corretta, perché non ci vuole per il confronto?"- Non so come lo stia verificando, ma 200 anni nel futuro sono piuttosto ovviamente errati.È possibile sapere che qualcosa non è corretto senza sapere quali siano effettivamente i dati _corretti_.
Ciò non riguarda solo i browser.Quando succede qualcosa a un server e l'ora del sistema viene modificata / desincronizzata, anche di poche ore, potrebbe causare problemi di connessione ad altri servizi nella rete (mi è successo più volte).
Probabilmente chrome non conosce l'ora corretta, ma sa che la validità del certificato è fuori dai limiti.
[Questo video] (https://www.youtube.com/watch?v=ylfyezRhA5s) di LiveOverflow fa un ottimo lavoro nel mostrare alcuni dei problemi che possono derivare da una cattiva gestione del tempo.
@AndrolGenhald Quindi Chrome è stato deliberatamente progettato per fallire dopo un certo periodo di tempo?
@Acccumulation Come ho detto, non mi sono preoccupato di controllare come è implementato.Potrebbe essere che se vede un certificato scaduto più di 10 anni fa presume che il tuo orologio sia sbagliato.
@Acccumulation Potrebbe essere basato anche sulla data di rilascio della versione corrente.
@AndrolGenhald Immagino che Chrome stesso abbia una ricerca dell'ora con i propri server dell'ora incorporati. Sono sicuro che utilizzi l'ora locale, ma non sarei affatto sorpreso se una ricerca dell'ora di rete si verificasse in Chrome per conoscere "tempo "reale" indipendentemente da ciò che dice l'ora locale.
Anche in questo caso solo speculazioni, ma il protocollo TLS codifica anche (spesso) l'ora del server locale, che potrebbe essere confrontata con l'ora locale.
"Ma di solito c'è un'opzione" avanzata "che mi permette di ignorarla. Non così qui"> vedo "Avanzate".Sì, è disattivato, ma penso che * potresti * essere in grado di fare clic su di esso
@ConorMancone: Chrome non può essere certo che le chiavi utilizzate dai suoi server attendibili non verranno violate nei prossimi 200 anni.Se l'orologio del computer dice che ora è il 13/9/2218 ma quello che * sembra * essere il server dell'ora attendibile segnala che è il 13/9/2018, Chrome non avrebbe modo di sapere se il server è sincero o se il computer èl'orologio è corretto e il server è un falso bugiardo, usando una chiave che è stata violata negli ultimi 200 anni dal 2018.
Almeno il browser ti sta dicendo che il tuo orologio locale è probabilmente sbagliato.Ci è voluto troppo tempo per rintracciare quando il browser non ce l'ha detto.
Nove risposte:
Mike Ounsworth
2018-09-11 23:54:00 UTC
view on stackexchange narkive permalink

Hai un sacco di domande in ballo.

Immagino che NET :: ERR_CERT_DATE_INVALID significhi che un certificato HTTP non è valido.

Sì .

Ecco il certificato per help.ubuntu.com:

Certificate for help.ubuntu.com

Noterai che ha le date Valido dal e Valido fino al; se provi ad accedere a un sito protetto da questo certificato al di fuori di queste date, il tuo browser si lamenterà. Il motivo per cui i certificati scadono è (tra gli altri motivi) per costringere i webmaster a continuare a ricevere nuovi certificati utilizzando le ultime funzionalità di crittografia e altre nuove funzionalità di sicurezza nei certificati.

Quando il tuo browser sta cercando di decidere se si fida di un certificato, utilizza l'orologio di sistema come fonte definitiva di verità per il tempo. Certo, proverà a usare NTP, ma se tu (l'utente amministratore) gli hai detto esplicitamente che i server NTP sono sbagliati, beh, sei il capo.

Se un utente malintenzionato può modificare arbitrariamente l'ora del sistema, quali tipi di attacchi lo consentono?

Consideriamo separatamente personal computer e server. Non ho fatto alcuna ricerca qui, solo fuori dalla mia testa.

Personal Computer

  • Gli utenti spesso giocano con il loro orologio di sistema per aggirare "30- giorno di prova "cose ​​tipo. Se sei l'azienda il cui software viene utilizzato illegalmente in questo modo, lo considereresti un problema di sicurezza.
  • Siti Web contraffatti. È molto più facile hackerare i vecchi certificati scaduti: forse utilizzava crittografia di 10 anni che è facilmente crackabile, o forse il server è stato compromesso 6 anni fa ma le CA non tengono traccia delle informazioni sulla revoca per così tanto tempo (credito dell'idea: risposta di @immibis). Se un utente malintenzionato può modificare l'orologio di sistema, non verranno visualizzati gli avvisi.

Server

  • Registrazione. Quando si investiga su una violazione della sicurezza, se gli orologi dei server non sono sincronizzati, può essere molto difficile mettere insieme tutti i log per capire esattamente cosa è successo e in quale ordine.
  • Accessi. Cose come l'autenticazione a 2 fattori OTP è solitamente basata sul tempo. Se gli orologi di un server si trovano dietro un server diverso, potresti guardare qualcuno che inserisce un codice OTP, quindi usalo sul server che si trova dietro perché quel codice non è ancora scaduto.
Inoltre, ovviamente, negazione del servizio. Se il server utilizza alcuni servizi Web di terze parti tramite HTTPS, le richieste inizieranno a non riuscire proprio come ha fatto il browser sopra.
w.r.t.accessi, non è interessata solo l'autenticazione a 2 fattori OTP.Kerberos richiede che i computer siano ragionevolmente sincronizzati ("per prevenire attacchi di replay").I domini Windows, che utilizzano Kerberos, ad esempio, richiedono che i computer si trovino entro 5 minuti l'uno dall'altro (per impostazione predefinita) o non è possibile ottenere l'autorizzazione sul dominio.
Un altro problema, sollevato al DEF CON di quest'anno, è il fatto che qualcuno potrebbe registrare un sito Web precedentemente registrato e potrebbe anche avere un certificato valido a cui il proprietario precedente ha accesso.La data di scadenza garantisce che ciò non durerà a tempo indeterminato.
I certificati algo deboli potrebbero essere revocati.La ragione di molti certificati di breve durata è, a mio parere soggettivo, il denaro.
@bradbury9 Forse.I browser si lamenteranno delle vecchie crittografie (ex MD5 / SHA1) o delle funzionalità di sicurezza mancanti (Certificate Transparency), _ ** se ** _ la vittima utilizza un browser aggiornato.Potrei sbagliarmi, ma penso che in realtà siano i browser, non le CA, a spingere la decisione per una durata massima del certificato di 2 anni, e la CA con la durata del certificato più breve - Let's Encrypt a 3 mesi - è completamente gratuita.
Votato per "beh, tu sei il capo".A volte gli utenti possono essere i loro peggiori nemici, non importa quanto sia buono il sistema di sicurezza.:-)
user253751
2018-09-12 06:12:18 UTC
view on stackexchange narkive permalink

Uno dei motivi è che i record di revoca del certificato non vengono conservati dopo la scadenza del certificato.

Supponiamo che io abbia rubato il certificato di Google 10 anni fa. Google se ne accorse immediatamente e revocò il loro certificato. Poiché il certificato è scaduto negli ultimi 10 anni, la voce di revoca è stata cancellata. Se ho impostato il tuo orologio indietro di 10 anni a quando era valido, posso impersonare Google e il tuo browser non se ne accorgerà, perché non saprà che è stato revocato.

Mi sembra che tu descriva il contrario della domanda.OP mostra che quando si modifica l'ora locale, il browser accetta la modifica e agisce di conseguenza.Semmai questo comportamento rende possibile l'attacco che descrivi, non sembra impedirlo.
@Suma, per motivi di sicurezza, Chrome utilizzerà sempre l'ora del computer dell'utente.Il browser dice "Questo certificato è scaduto il 2018-12-09 ed è attualmente il 2218-08-06, quindi il certificato non può essere considerato attendibile ed è necessaria una pagina di errore del certificato".Dopo aver determinato che è necessaria una pagina di errore del certificato, Chrome tenta di creare una pagina appropriata, indovinando la causa principale del problema.In questo caso Chrome ha intuito che forse il certificato non ha effettivamente 200 anni, forse il tuo orologio è sbagliato.Quindi Chrome ti ha suggerito di cambiare l'orologio.
schroeder
2018-09-11 23:48:47 UTC
view on stackexchange narkive permalink

La tua domanda è generica, ma se un utente malintenzionato può modificare l'orologio di sistema locale, può avvelenare i registri della propria attività. In questo modo, possono nascondere la loro attività in modo che sembri avvenuta in passato (e forse oltre la finestra in cui gli amministratori stanno cercando l'attività) o in coincidenza con l'attività di altri utenti.

Ad esempio, se entri in un sistema nel cuore della notte, puoi impostare l'orologio in modo che sia a mezzogiorno del giorno precedente, fare la tua attività, quindi reimpostare l'orologio. Chiunque ispeziona i log presumerà che l'utente normale abbia svolto l'attività (o non la veda affatto tra le normali attività dell'utente).

Questo è il motivo per cui è importante impostare l'orologio in modo che sia sincronizzato con una fonte esterna autorevole. Questo e che tutti i registri di tutte le fonti possono essere adeguatamente correlati.

Questo non risolve il motivo per cui un orologio non sincronizzato è un problema in questo caso particolare.
È una domanda ampia e ho affrontato una parte di essa.
Hm ... questo è vero solo se sono coinvolti più sistemi, giusto?Perché i log vengono solitamente scritti riga per riga (aggiunti a un file di testo).Questo significa che l'attaccante potrebbe "rallentare il tempo" senza preavviso, ma se l'attaccante "tornasse indietro nel tempo" (rendendo le voci di registro non cronologiche) sarebbe facilissimo individuare quelle in cui ha manipolato il tempo.
@AustinHemmelgarn Il titolo "Quanto è importante l'ora locale per la sicurezza?"Beh, un po 'si adatta.
@MartinThoma come noteresti le voci di registro che hanno il tempo fraudolento?
Questo è anche il motivo per cui alcune soluzioni di registrazione includono numeri di sequenza con le voci o, ad esempio, perché i log del kernel di Linux utilizzano secondi dall'avvio.
@schroeder `for i in range (1, len (loglines)): if loglines [i] ['time']
Schwern
2018-09-14 00:48:28 UTC
view on stackexchange narkive permalink

Se un utente malintenzionato può modificare arbitrariamente l'ora di sistema, quali tipi di attacchi lo consentono?

Oltre i certificati ...

RNG con seed male

Potrebbero essere in grado di sfruttare un generatore di numeri casuali con seed male. Usare il tempo come seme accadeva molto prima che interfacce di numeri casuali migliori si rendessero conto che non ci si poteva fidare del programmatore medio per fornire un buon seme. Un utente malintenzionato può sfruttarlo impostando l'ora del sistema su un orario in cui il generatore di numeri casuali produrrà l'output desiderato.

Ovviamente, l'attaccante può risparmiarsi un sacco di problemi semplicemente aspettando un tempo desiderabile .

UUID

UUIDv1 e v2 dipendono entrambi dall'indirizzo MAC e dall'ora. L'indirizzo MAC può essere scoperto. Essere in grado di impostare l'ora significa che ora possono controllare quale UUID viene assegnato successivamente. Ad esempio, potrebbero essere in grado di duplicare l'UUID di un account amministrativo per se stessi. Ovviamente, UUIDv1 e v2 non sono pensati per essere sicuri , ma solo per essere unici . Se vuoi essere sicuro e unico, utilizza UUIDv4, ma c'è un sacco di software che utilizza UUIDv1 e v2 in modo inappropriato.

Lavori periodici

Molti sistemi hanno processi critici che vengono eseguiti periodicamente in determinati giorni e volte. L'aggressore può perdere tempo per manipolarlo.

Molti sistemi hanno finestre di manutenzione che si verificano in determinati momenti. L'utente malintenzionato potrebbe reimpostare continuamente il tempo per rimanere in questa finestra e mantenere il sistema spento per la manutenzione.

Se c'è un processo ad alta intensità di risorse che si verifica periodicamente, può rovinare il tempo in modo tale che più di quei processi sono in esecuzione allo stesso tempo. Se il sistema non limita il numero di processi simultanei, ciò può inondare il sistema.

Oppure puoi andare dall'altra parte e reimpostare continuamente il tempo per evitare che venga eseguito un processo di manutenzione critica.

Watchdog

Il sistema potrebbe avere processi watchdog che cercano troppe o troppo poche azioni che avvengono in una finestra di tempo. Il watchdog può scegliere di intraprendere azioni di manutenzione automatica come il riavvio di macchine o l'arresto dei servizi. Un utente malintenzionato può manipolare il tempo per far sembrare che la frequenza sia troppo alta o troppo bassa facendo scattare il watchdog e causando l'arresto di un sistema funzionante.

Fonte per UUIDv4: [Sezione 4.4] (https://tools.ietf.org/rfc/rfc4122.txt)
+1 Buona risposta, ma non sono sicuro di essere totalmente d'accordo.1) gli RNG crittografici vengono seminati da cose diverse dall'orologio, ad esempio: seed precedente, eventi IO del disco, eventi dei pacchetti di rete, quindi il pieno controllo dell'orologio non darà il tuo pieno controllo del seme.2) anche l'UUIDv4 non è inteso come sicuro: _ "4.4. Algoritmi per la creazione di un UUID da numeri veramente casuali o pseudo-casuali" _ quindi qualsiasi software che utilizza un UUID come segreto del client è probabilmente un cattivo software.3) Ottimo punto sui lavori periodici e sui watchdog, un altro buon esempio è l'avanzamento dell'orologio per saltare la scansione pianificata dell'antivirus.
@MikeOunsworth Certo, se lo fai bene i primi due non sono un problema, ma ... 1) [La quantità di codice che viene seminata con `time` ti scioccherà] (https://github.com/cerca? q = srand + time & type = Code).2) Un sacco di software espone i propri UUID.
@Schwern Buona discussione!1) `srand` non pretende di essere un RNG crittograficamente sicuro.`srand (time ());` va bene se, ad esempio, stai generando mappe di texture;se le persone usano "srand" per generare segreti crittografici, allora sì, sarebbe un problema.2) Non sono sicuro del perché sia un problema?Nel nostro software basiamo il nostro modello di sicurezza sul presupposto che gli aggressori possano capire i valori UUID se lo desiderano.Quindi, se uno sviluppatore deve esporre un UUID per qualsiasi motivo, qualunque sia.Gli UUID (come qualsiasi altro tipo di ID) non devono essere utilizzati come token di autenticazione.
"* Nel nostro software basiamo il nostro modello di sicurezza sul presupposto che gli aggressori possano individuare i valori UUID se lo desiderano. *" Eccellente.Molti software non lo fanno.Si tratta di attacchi che sfruttano piccoli errori di sicurezza comuni.
@Schwern Oh capisco.Non stai parlando di come viene costruito _buon_ software, stai parlando di come viene costruito _bad_.Touché.
supercat
2018-09-13 20:06:46 UTC
view on stackexchange narkive permalink

Ci sarebbero due possibili situazioni in cui un computer che pensa che l'anno sia il 2038 cerca di connettersi al mondo esterno e tutto nel mondo esterno dice che è il 2018:

  1. L'orologio del computer è sbagliato.

  2. L'anno è in realtà il 2038 e ogni cosa in quello che sembra essere il mondo esterno viene falsificato, utilizzando certificati del 2018 che sono stati violati vent'anni da allora.

Sebbene attacchi di quella forma sarebbero abbastanza difficili da portare a termine che la prima possibilità sarebbe in pratica molto più probabile, proteggersi dalla seconda sarebbe richiedono la conferma che l'orologio del computer è sbagliato.

Hm.E dove traccia la linea?Qual è una differenza accettabile per il mondo esterno?
@MartinThoma: Se l'orologio di un computer è compreso nell'intervallo in cui i suoi certificati sono validi, i certificati sono probabilmente validi.Se l'orologio del computer è al di fuori di tale intervallo, è possibile (e in alcuni casi probabile) che i certificati siano effettivamente validi ed è semplicemente l'orologio del computer che è in errore, ma un computer non può essere certo che un server orario esterno sia affidabile senzaun certificato valido all'ora indicata dal computer.Se i time server esterni riportano costantemente orari "nel passato", ciò suggerirebbe che ...
... una diagnostica sull'orologio del computer in futuro sarà più utile di un messaggio che dice che tutti i certificati sono scaduti, ma dovrebbe consentire la possibilità che un utente guardi un messaggio "L'orologio del tuo computer dice che è il 2018, ma tuttialtro dice che è il 2012 "e dice" È il 2018; i server che affermano il 2012 hanno torto, probabilmente così deliberatamente ".
Quindi la tua linea è un anno solare.Ciò significa che 365 giorni sbagliati in un anno bisestile andrebbero bene, ma un giorno in più non lo è.
@MartinThoma: Gli orari accettabili dipenderanno dai certificati installati dal computer in un determinato momento.
birdwes
2018-09-14 06:02:50 UTC
view on stackexchange narkive permalink

Se stai utilizzando un solo controller di dominio Windows, o parte della sua rete, una differenza di orario di soli cinque o pochi minuti può essere fondamentale: Kerberos Time Tolerance

Una volta ho avuto a che fare con un server Windows SBS 2008 guasto e ho dovuto trovare un modo per entrare come SISTEMA per leggere il registro eventi.

Si è scoperto che una sovratensione aveva reimpostato l'orologio del BIOS CMOS sul controller di dominio, riportandolo alla data di progettazione del sistema, alcuni anni prima. Il risultato è che i biglietti Kerberos non possono essere emessi.

I biglietti Kerberos sono validi solo per pochi minuti.

Edheldil
2018-09-12 20:16:03 UTC
view on stackexchange narkive permalink

Un altro esempio (leggermente contorto) di un attacco contro un computer con tempo di sistema in ritardo è fornire record DNS obsoleti da una zona protetta con DNSSEC.

Ad esempio, se il client chiedesse l'indirizzo www.example.com, l'attaccante potrebbe rispondere con un riferimento al proprio server DNS e una prova (scaduta) della non esistenza di un record DS, ad esempio. com dal momento in cui example.com non era ancora firmato e successivamente pubblica record DNS contraffatti per qualsiasi cosa nella zona example.com.

Devuan User
2018-09-12 01:06:09 UTC
view on stackexchange narkive permalink

Potrebbe essere considerato un falso e non avere sempre sincronizzato l'orologio del computer potrebbe avere i suoi vantaggi e svantaggi. Quelli ovvi sono quelli già indicati. Un vantaggio è che i siti web non conosceranno la tua data reale, anche se questo entrerebbe più nella privacy che nella sicurezza di per sé, normalmente la privacy è considerata parte della sicurezza.

Non lo so molto sull'enumerazione NTP ma è usata nel pentesting, quindi è un fattore da tenere in considerazione per la sicurezza.

"Il Network Time Protocol è un protocollo per la sincronizzazione dell'ora attraverso la rete, questo è particolarmente importante utilizzando Directory Services. Esiste un numero di server dell'ora in tutto il mondo che possono essere utilizzati per mantenere i sistemi sincronizzati tra loro. NTP utilizza la porta UDP 123. Tramite l'enumerazione NTP è possibile raccogliere informazioni come elenchi di host collegati al server NTP, IP indirizzi, nomi di sistema e sistemi operativi in ​​esecuzione sul sistema client in una rete. Tutte queste informazioni possono essere enumerate interrogando il server NTP. " fonte: " https://www.greycampus.com/opencampus/ethical-hacking/ntp-enumeration"

Questa risposta manca di dettagli concreti che mi siano utili.Qual è uno scenario in cui danneggia il fatto che i siti Web non conoscano l'ora locale sulla mia macchina?In che modo è un problema di privacy?
Se stai usando una VPN o un proxy e il tuo sistema usa un fuso orario diverso da quello che dovrebbe avere il tuo IP ... allora chiunque considererebbe che stai usando una VPN o un proxy.La maggior parte dei proxy e delle VPN non sono in grado di nascondere l'orologio del tuo sistema operativo per impostazione predefinita e i siti web possono leggerlo (quindi indicando il luogo in cui vivi anche se utilizzi un proxy / VPN, quindi abbattendo la tua privacy)
@DevuanUser ci sono molte condizioni che devono essere applicate: 1) il sito dovrebbe cercare il tuo IP rispetto alla posizione e cercare il fuso orario, 2) il javascript sulla pagina dovrebbe interrogare l'ora locale e inviarlo di nuovo ail server, 3) la tua VPN dovrebbe trovarsi in un fuso orario diverso da quello in cui ti trovi.Queste sono condizioni importanti e non dovrebbero essere ignorate in una descrizione così breve.
Anche questo non sembra rispondere alla domanda sul cambiamento dannoso del tempo.
Ebbene, il creatore del thread si è interrogato sulla sicurezza e ho dato una risposta in modo che comprenda possibili problemi quotidiani che potrebbero sorgere con l'orologio sincronizzato o meno.D'altra parte però ... aggiungerò un'altra risposta.
L'enumerazione NTP non si applica alla situazione
"L'enumerazione NTP non si applica alla situazione" la domanda è "Quanto è importante l'ora locale per la sicurezza?"Il modo in cui il 99% degli utenti di Internet sincronizza la propria macchina con l'ora locale è tramite l'utilizzo di server ntp in modo da capire come si relaziona davvero una cosa con l'altra.--- Aggiunta fonte, nota per il futuro, grazie ---
* "Un vantaggio è che i siti web non conosceranno il tuo vero appuntamento" * - il tuo vero appuntamento è lo stesso di tutti gli altri.Siamo nello stesso universo e abbiamo solo l'unico flusso temporale concordato che abbiamo in comune.Come lo spazio.(Esercizio: nasconderò in quante dimensioni sono in questo momento, per motivi di sicurezza. Cosa? Ne hai indovinate tre? Dannazione! Come lo sapevi?)
Il protocollo NTP scambia solo timestamp in UTC, indipendentemente dalle impostazioni del client e del server.Quindi il massimo che un server NTP potrebbe ottenere è che la macchina da un determinato IP non è sincronizzata entro un certo periodo.Ironia della sorte, se è costantemente fuori sincronia per un periodo fisso, i dati possono essere utilizzati per tracciare la macchina anche dopo la modifica dell'indirizzo IP.Rispetto alla macchina regolarmente sincronizzata che avrà un periodo di offset simile con altre macchine nella regione.
@Wildcard Essendo pedante, si potrebbe dire che il tempo è relativo.Nella maggior parte dei casi non importa, ma ad es.per il GPS lo fa.Quindi non abbiamo tutti lo stesso tempo.Inoltre, TAI è una media di diversi orologi atomici proprio a causa di questo problema.(Ad ogni modo, sono d'accordo con il punto generale che questo argomento / risposta non ha molto senso)
Puoi evitare di fornire la tua ora _local_ semplicemente impostando il fuso orario del tuo browser su UTC.Questo è ciò che fa Tor Browser, ad esempio, ma è ancora chiaramente in grado di rilevare la scadenza del certificato.
PrashantKC
2018-09-13 21:44:33 UTC
view on stackexchange narkive permalink

Molti software, specialmente quelli che funzionano in un cluster, la sincronizzazione dell'ora è molto importante. Quindi, se qualcuno gioca con il tempo, il software in esecuzione su questo sistema causerà molti problemi, specialmente con la sincronizzazione. Questo alla fine conterà come impatto sul servizio.

Benvenuto!Sembra più un commento che una risposta completa.Consiglio di rimuoverlo e aggiungerlo come commento su una delle altre risposte, oppure di aggiungere informazioni sufficienti per trasformarlo in una risposta completa.
Penso che per scrivere un commento devi avere almeno 50 punti: https://stackoverflow.com/help/privileges


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...