Domanda:
Perché non ci fidiamo di un certificato SSL scaduto di recente?
sharptooth
2013-02-25 11:47:35 UTC
view on stackexchange narkive permalink

Ogni certificato SSL ha una data di scadenza. Supponiamo ora che il certificato di un sito sia scaduto un'ora fa o un giorno fa. Tutto il software per impostazione predefinita rifiuterà semplicemente di connettersi al sito o emetterà avvisi di sicurezza.

Questo è accaduto di recente a Windows Azure Storage e poiché la maggior parte del software nei servizi dipendenti era impostata su il rifiuto di connettere molti servizi ha subito un grave degrado.

Qual è la logica qui? Voglio dire, un giorno fa il certificato era valido e tutti erano felici di usarlo. Ora un giorno dopo è ufficialmente scaduto e non piace più a nessuno.

Ho letto questa risposta e non la trovo convincente per questo caso limite specifico. Per ogni modello di sicurezza esiste un modello di minaccia.

Qual è il modello di minaccia qui? Cosa sarebbe potuto accadere da oggi fino a un giorno fa che un certificato è considerato inutilizzabile a tal punto che ci rifiutiamo persino di connetterci al sito?

Vorresti bere da un cartone di latte che è passato solo due giorni dalla data di scadenza?
@Shadur: Mai sentito parlare di essere stato avvelenato da un certificato SSL.
Non sarei sorpreso se la revoca del certificato smettesse di funzionare a quel punto. Non c'è bisogno di informare il cliente della revoca, poiché è già scaduta e quindi non valida.
@Shadur certo, ma prima senti l'odore del latte per verificare se è spento. In caso contrario, lo assaggi provvisoriamente. Se il latte non è spento, usa il latte.
@Shadur Assolutamente, e più persone dovrebbero - su questo pianeta si spreca troppo cibo perfettamente buono.
@Smalltown2k Dubito che esista un test dell'olfatto per un certificato compromesso che sia affidabile quanto quello per il latte acido.
Recentemente ho bevuto Tylenols scaduto nel 2006. Il mal di testa è sparito. È la mia bottiglia "scorta a vita".
[Shelf-life] (http://en.wikipedia.org/wiki/Shelf_life) è il nome ... e i certificati SSL non hanno una data di scadenza
@zigg ha concordato, c'è un rischio ma non è un motivo per cancellare tutto il latte. Dipende dal latte che stai sniffando, non sarei neanche lontanamente fiducioso con la carne oltre il suo appuntamento. La metafora si traduce in sicurezza, credo.
@woliveirajr Ne sei sicuro? Microsoft ha smesso di accettare i certificati RSA a 512 bit in IE non molto tempo fa. Una volta erano "freschi".
@zigg: Non sono sicuro di aver capito il tuo punto. Stai parlando di questo [avviso di sicurezza] (http://support.microsoft.com/kb/2661254/en-us)? Che i certificati RSA a 512 bit, sebbene non scaduti, non sono stati più accettati, perché lo ha deciso Microsoft? Va bene, MS può decidere cosa accettare o meno ei suoi utenti decidono se applicare o meno l'aggiornamento. L'emittente, inoltre, può dichiarare che in alcune circostanze il certificato viene revocato, prima che sia scaduto ...
@woliveirajr Non si può ignorare il fatto che tutte le chiavi private hanno una durata finita con un allegria "perché Microsoft ha deciso così". Sarebbe uno stupido usare un certificato a 512 bit nel 2013, a maggior ragione usarne uno che hai generato e pubblicato quando i certificati a 512 bit erano ancora accettabili.
@zigg: sì, sono totalmente d'accordo con quello. Il punto della domanda, del commento, della risposta, ecc. È che quando un certificato è scaduto, non ha senso continuare a utilizzarlo, come se avesse una durata di conservazione. Ciò non significa che tutti i certificati debbano essere considerati attendibili a occhi chiusi solo perché non sono ancora scaduti.
@woliveirajr Ok, penso che stessimo parlando a scopi incrociati ... Per il tuo punto, sì, è vero, la non scadenza non garantisce il non compromesso; lontano da esso. Ma è un meccanismo utile per mantenere fresche le coppie di chiavi, se vuoi.
@Shadur, Cosa c'è di sbagliato in questo? Viene fatto tutto il tempo.
Dieci risposte:
Thomas Pornin
2013-02-25 18:43:06 UTC
view on stackexchange narkive permalink

Quando un certificato è scaduto, il suo stato di revoca non viene più pubblicato. Cioè, il certificato potrebbe essere stato revocato molto tempo fa, ma non sarà più incluso nel CRL. La data di scadenza del certificato è la data limite per l'inclusione della CRL. Questo è il motivo ufficiale per cui i certificati scadono: per mantenere limitata la dimensione del CRL.

(Il motivo non ufficiale è che i proprietari dei certificati paghino una quota annuale.)

Quindi non puoi fidarti di un certificato scaduto perché non puoi verificarne lo stato di revoca . Potrebbe essere stato revocato mesi fa e tu non lo sapresti.

Il tuo * motivo non ufficiale * non corrisponde ai certificati autofirmati (gratuiti) che devono scadere anche loro!
Bene, in questo momento sto rinnovando il mio certificato SSL gratuito ed è così fastidioso che sto seriamente pensando di passare a una CA non libera. Sospetto che StartSSL lo faccia apposta (i certificati gratuiti sono pubblicità, per attirare l'attenzione).
Stai usando o hai già provato la suite [* OpenSSL *] (http://www.openssl.org/)?
Sapresti che la revoca è recente perché ti ricorderesti che ha funzionato ieri o la scorsa settimana.
@ThomasPornin - sì, personalmente adoro StartSSL, ma utilizzo anche l'opzione verificata di livello 2. Era ancora il certificato jolly più economico che ho trovato. Inoltre, apprezza il fatto che utilizzino effettivamente un sistema di autenticazione basato su certificato lato client per i loro account.
@ThomasPornin Quindi lanciamo la nostra CA non commerciale - [con blackjack e prostitute] (https://www.youtube.com/watch?v=z5tZMDBXTRQ)
@Kaz e se questa è la prima volta che vedi quel certificato?
Questo è vero solo per metà, RedHat dice: [Per impostazione predefinita, i CRL non contengono informazioni sui certificati scaduti revocati. Il server può includere certificati scaduti revocati abilitando tale opzione per il punto di emissione.] (Https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System_Common_Criteria_Certification/8.1/html/Admin_Guide/Revocation_and_CRLs.html#Revocation) Microsoft anche dice [... Puoi abilitare un'impostazione di registro su una CA per assicurarti che i certificati revocati che sono scaduti non vengano rimossi dal CRL.] (http://technet.microsoft.com/en-us/library/cc737180%28v = ws.10% 29.aspx)
Alcune CA possono includere certificati scaduti in CRL, soggetti a una data limite che è successiva alla data di scadenza del certificato (e possibilmente infinitamente remota in futuro), ma è specifico della CA e i verificatori non possono contare su di essa a meno che non sia documentata come un'estensione CRL appropriata. Non esiste un'estensione standard per questo (ce n'è una specifica per Microsoft, però). Il cut-off regolabile è una buona idea, ma questa è ancora una data di scadenza (scadenza sulle informazioni di revoca, non sul certificato stesso) e non può essere utilizzata in modo affidabile fino a quando non diventa ampiamente supportata (e al momento non lo è).
@TobiasKienzler, Link interrotto. Di cosa si tratta?
@Pacerier Aww, stupido copyright ... [Qui] (https://www.youtube.com/watch?v=BGi6Q1pNbS0) è un altro tentativo, o [kym] (http://knowyourmeme.com/memes/im- andando-costruire-il-mio-parco-a-tema-con-blackjack-e-prostitute). Non che il video abbia contribuito a questa risposta: P
@TobiasKienzler, Non ottengo affatto il collegamento. Di cosa si tratta?
@Pacerier Stavo rispondendo al [commento di Thomas] (http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently/31482?noredirect = 1 # comment48658_31482) sull'inconveniente di CA "libere" con "allora gestiamo la nostra CA" ma nel tentativo di essere divertente citando il buon vecchio Bender "inizierò il mio parco, con blackjack e prostitute. Infatti, dimentica il parco e il blackjack "...
@ThomasPornin, in realtà esiste un'estensione standard quando si interroga lo stato del certificato tramite un servizio OCSP.Vedere RFC 6960, "4.4.4. Archive Cutoff".
Sam Whited
2013-02-25 12:03:25 UTC
view on stackexchange narkive permalink

Una buona domanda. La risposta più semplice è che avere una data di scadenza garantisce di avere un "audit" ogni tanto. Se non ci fosse una data di scadenza e qualcuno smettesse di usare un certificato (e proteggere la chiave privata), nessuno lo saprebbe mai. Tuttavia, avendo una data di scadenza, ti assicuri che l'utente torni dalla società che gli ha venduto il certificato SSL e gli paghi molti più soldi err, intendo, ha una verifica e viene riconvalidato come la persona o il servizio a cui dichiara di essere (cercherò di lasciare fuori da questa domanda le lamentele sull'attuale modello di sicurezza Internet).

Il problema diventa quindi: se hai un periodo di grazia in cui ignori i certificati scaduti, quanto dura? Un giorno? Una settimana? Un mese? Ad un certo punto devi semplicemente smettere di fidarti del certificato; se fai questo punto un giorno dopo la scadenza, puoi ancora chiederti: "Cosa sarebbe potuto succedere tra oggi e ieri?" E cadi in un loop.

In sostanza, hai ragione: le persone non smettono magicamente di proteggere le loro chiavi private non appena arriva la data di scadenza (o potrebbero aver smesso di proteggerle molto tempo fa e nessuno lo sa perché non li hanno revocati e non sono ancora scaduti). La data di scadenza non dice nulla sulla sicurezza del certificato, ma se non hai un taglio mai saprai che un certificato può essere dimenticato mentre con uno almeno sai così tanto .

+1 per "Se hai un periodo di grazia in cui ignori i certificati scaduti, quanto tempo dura?". Questa è la vera ragione, credo, per cui un periodo di grazia non funzionerebbe mai: semplicemente estende artificialmente il periodo di validità, il che significa che potresti anche usare un periodo di validità più lungo per cominciare. Quale * tutto * il software implementerebbe nello stesso modo.
Mente, il "sacco di soldi" è un po 'iperbole; rapidssl non fa pagare più di cento dollari per un certificato di due anni ...
Vale anche la pena notare che le autorità di certificazione eseguono un'infrastruttura per convalidare i certificati, questa infrastruttura ha costi di gestione, quindi avere persone che rinnovano i certificati ogni tanto fa bene alla loro attività e mantiene tutto in funzione.
@Shadur +1 per RapidSSL; Li uso su tutti i miei siti ed è stato un piacere lavorare con loro (il modello di sicurezza potrebbe essere rotto, ma almeno ci sono alcune buone aziende là fuori che non cercheranno di fregarti ad ogni turno). .. Come puoi immaginare, ho avuto alcune brutte esperienze con altri fornitori in passato, quindi per favore perdona il mio scherzo nella risposta :)
Solo il mio 2c ... Se sei un cliente abbastanza grande, puoi ottenere anche certificati VeriSign "normali" (non EV, ecc.) Per <$ 100 / anno. I certificati interni Verisign sono ancora più economici, a circa 1/4 del prezzo.
+1. Si * potrebbe * progettare un periodo di grazia che è più di una semplice estensione del periodo di validità: sarebbe un periodo durante il quale il certificato funzionerebbe, ma con un avviso. Tuttavia, la domanda è se il costo dell'aumento della complessità varrebbe la pena. Affinché il periodo di grazia sia efficace, tutto il software tra il server certificato e l'utente finale dovrebbe comprendere e prestare attenzione a questa sfumatura aggiuntiva. Attualmente, la maggior parte dei software non ti dice nemmeno se un certificato è scaduto ... dà solo un errore di connessione.
-1
@Michael Giusto - se la guida a 10 km / h oltre il limite di velocità di 100 km / h viene eliminata, allora tutti guidano 110 e si lamentano del biglietto che ottengono a 113 perché "avevano superato solo 3". La stessa inflazione si applica.
@MichaelKjörling: Dipende da cosa fa ogni componente software con le informazioni. Ecco perché dico che tutto il software tra il server certificato e l'utente finale, comprese le connessioni C2C, dovrebbe comprendere e prestare attenzione. Quello che dovrebbero fare con le informazioni di avviso richiede decisioni di progettazione separate per ogni parte di software. Non sembra qualcosa che volerebbe molto bene.
@LarsH: Che ne dici di una CA che fornisce un meccanismo per la routine di controllo della scadenza protetta da Captcha che sarebbe garantita utilizzabile per un mese dopo la scadenza del certificato, in modo che qualcuno che volesse assicurarsi che la propria connessione a `https: //mybank.example. com` was legit potrebbe farlo, a scapito di un piccolo sforzo, anche se il certificato fosse scaduto, ma nessun proprietario del certificato vorrebbe che i clienti affrontassero quella seccatura.
@supercat Nessuno vorrebbe occuparsi del problema, come hai detto, tuttavia, questo è essenzialmente lo stesso che mostrare semplicemente un avviso "Questo servizio utilizza un certificato scaduto" e consentire all'utente di fare clic. Se il cliente è abbastanza esperto da verificare con un captcha o abbastanza ignorante solo da fare clic, è abbastanza esperto (o abbastanza ignorante) da premere semplicemente il pulsante "okay, accetta questo certificato anche se è scaduto".
@SamWhited: Che ne dici di fare in modo che le autorità di certificazione forniscano funzioni separate "Elenca certificati correnti revocati" e "Elenca certificati scaduti di recente che vengono revocati", ma quest'ultima funzione è molto più lenta della prima? Se quest'ultima funzione riportava l'interruzione in cui i certificati sarebbero stati rilasciati, i browser potevano informare le persone che la loro connessione stava funzionando lentamente perché il certificato era scaduto, ma era comunque sicuro.
Ancora non capisco davvero il punto di voler farlo, ma certo; potresti mantenere due CRL e aggiungere qualcosa a OCSP. Non ha senso avere un periodo di grazia o un periodo di soft-fail.
@SamWhited: L'idea sarebbe quella di disporre di un meccanismo di degrado del servizio tale da consentire alle aziende di avere un forte incentivo a rinnovare i propri certificati in modo tempestivo, ma allo stesso tempo garantire che interruzioni momentanee non indeboliscano la sicurezza.
@supercat Suona come un eccesso di ingegneria per un problema che non esiste per me. Se una società non può essere disturbata a rinnovare i propri certificati in tempo, dubito che un preallarme farà qualcosa. In sostanza si tratta solo di anticipare la data di scadenza (anche se con un soft fail invece di un hard fail).
@SamWhited: Ho riscontrato certificati SSL falliti come utente, ma sono stati risolti abbastanza rapidamente. I siti che non hanno l'aggiornamento automatico dei certificati probabilmente non sono quelli in cui la sicurezza è un problema molto scottante, ma da un punto di vista filosofico sembrerebbe meglio che un sistema rimanga sicuro se pratico.
@supercat Non sono in disaccordo, semplicemente non penso necessariamente che questo tipo di sistema possa aiutare. I commenti probabilmente non sono il posto migliore per discuterne. Ping me in chat se vuoi davvero continuare questa conversazione.
zigg
2013-02-25 18:43:24 UTC
view on stackexchange narkive permalink

Se ci fosse un periodo di grazia universale di cinque giorni, nessuno si accorgerebbe della scadenza dei certificati fino a cinque giorni dopo, lasciandoti con lo stesso effetto netto di rifiutare immediatamente un certificato scaduto. È il fatto che le connessioni SSL smettano di funzionare che crea la pressione.

Sospetto che sarebbe più produttivo per le applicazioni client SSL avvisare ad alta voce dell'imminente scadenza del certificato, in modo che gli utenti di quelle applicazioni possano fare pressione sul loro fornitori di servizi in anticipo.

+1 per consentire alle applicazioni client di emettere un avviso prima della scadenza del certificato, indipendentemente da un protocollo ufficiale del periodo di grazia. (Disattivabile, ovviamente!)
+1 per il monitoraggio, ma funziona solo se i messaggi raggiungono una persona e gli avvisi che entrano nei log devono ancora essere notati. Tutti i certificati del nostro server web sono monitorati da Nagios per le date di scadenza, il testo rosso riceve molta attenzione. E l'autorità di rilascio del certificato probabilmente stava inviando comunque e-mail a qualcuno a intervalli di 60/30/15/7/1 giorni sulla scadenza.
@james Complimenti a te per aver guardato i tuoi certificati e anche le CA che avvertono, ma penso che il mio punto sia valido: se i * clienti * iniziassero a lamentarsi, i fornitori di servizi che non lo erano proprio così in cima alle cose avrebbero qualche pressione esterna da ottenere i loro atti insieme prima che iniziassero i guai.
Fino a quando qualcosa non esplode e smette di funzionare, dubito che più di una minuscola frazione di clienti dirà qualcosa. Fare clic su ignora o tornare tra un giorno o due supponendo che l'amministratore stia lavorando al problema, è molto meno sforzo che cercare di capire come contattare un amministratore del sito per segnalare il problema.
Potrebbe esserci un'attività periodica che viene eseguita quotidianamente, che esplora l'archivio certificati e produce avvisi per tutti i certificati che stanno per scadere.
@DanNeely Buon punto. A volte divento un po 'troppo ottimista, eh.
dr jimbob
2013-02-26 00:14:52 UTC
view on stackexchange narkive permalink

Sono d'accordo che il sistema attuale non sia ottimale.

Un sistema di certificati migliore potrebbe avere un periodo di stato "giallo" per i certificati che stanno per scadere ("verde" indica un certificato valido e "rosso "essendo un certificato scaduto), con scadenza entro 1 mese. Ogni certificato di N anni scadrà dopo N anni + 1 mese, anche se idealmente sarebbero aggiornati entro il periodo di N anni. Tuttavia, durante l'ultimo mese ogni applicazione che utilizza un certificato dovrebbe presentare una lieve indicazione di avvertimento all'utente. Per la navigazione sul web, potresti fare qualcosa come colorare l'URL in giallo invece che in verde, con un messaggio al passaggio del mouse / clic in tal senso:

Il certificato di questo sito web scadrà il 25 marzo 2013 e devono essere aggiornati dal proprietario del dominio prima della scadenza. Il certificato è ancora perfettamente valido e dovrebbe essere completamente attendibile in questa data, ma le applicazioni che si basano su questo certificato smetteranno di funzionare il 25 marzo 2013 se il certificato non viene aggiornato entro tale data.

Sarebbe perfetto? Probabilmente no, poiché alcune applicazioni potrebbero non passare questi messaggi all'utente e la data di scadenza sarà comunque raggiunta. Inoltre, ci deve essere un accordo codificato in uno standard per quanto tempo prima della scadenza dei certificati devono essere aggiornati (un giorno? Una settimana? Due settimane? Un mese?). Ma sembra decisamente essere un miglioramento.

(Certo, sono d'accordo che Microsoft abbia davvero lasciato cadere la palla quando ha lasciato scadere il proprio certificato Azure: questo è un segno di incompetenza per una piattaforma che cerca di supportare le applicazioni aziendali ).

Questa dovrebbe essere la risposta selezionata.
H.-Dirk Schmitt
2013-02-25 16:19:50 UTC
view on stackexchange narkive permalink

La risposta è semplice come il business: "Il conto non viene pagato"

L'autorità di certificazione dichiara per un periodo di tempo distinto che questo certificato è valido. Ma questo non dice molto sull'affidabilità dell'autorità di certificazione e sui processi da parte del proprietario del certificato.

Shadur
2013-02-25 16:49:23 UTC
view on stackexchange narkive permalink

Ha a che fare con la percezione e le corrette pratiche di sicurezza.

Quando crei un certificato con, diciamo, una scadenza di un anno, in pratica dici "Non possiamo garantire l'integrità del certificato per più di un anno, quindi distribuiremo un nuovo certificato prima di allora . "

Quindi un sito con un certificato scaduto è un segno che gli amministratori non mantieni la loro promessa di rinnovare entro il tempo che si sono prefissati, il che suggerisce cattive pratiche di sicurezza.

È lo stesso motivo per cui ti becchi l'inferno per aver perso un funziona bene o perché i prodotti hanno una data di scadenza.

1) Utilizzando una ciphersuite non sicura in avanti è necessario garantire la segretezza della chiave privata anche dopo la scadenza del certificato 2) I compromessi si verificano in momenti casuali, quindi non si può dire "posso mantenere la chiave sicura per un anno". Quindi il confronto delle merci deperibili non è adatto.
woliveirajr
2013-02-25 23:48:32 UTC
view on stackexchange narkive permalink

La durata di conservazione potrebbe essere una cosa interessante per alcuni prodotti: il produttore afferma che garantisce che il prodotto sarà valido per un certo periodo ma non può garanzia che le proprietà originali saranno presenti se si consuma il prodotto dopo quel periodo.

Un certificato ha la stessa cosa: ha un periodo in cui l'emittente dichiara che è valido. Durante questo periodo il certificato dovrebbe essere ok. E se non lo è, ci sarà qualche richiamo a riguardo: un elenco di revoche da parte dell'emittente dirà al mondo intero "non fidarti di nuovo di quel certificato, perché in qualche modo potrebbe essere compromesso".

Dopo la data di scadenza, l'emittente non terrà più traccia di quel certificato: ha superato la data in cui era buono, quindi chiunque abbia ancora fiducia in esso dovrebbe farlo basandosi solo sul suo credo, non sull'emittente (o su chiunque altro) .

Dopo la data di scadenza, il certificato non è cattivo, rotto, puzzolente ... semplicemente non è più garantito che sia stato revocato. E perché non ci fidiamo di un certificato SSL scaduto di recente è perché vogliamo sicurezza e utilizziamo i certificati per garantire qualcosa. Se non possiamo essere sicuri che sia stato (o sarebbe) revocato , non puoi essere sicuro che sia stato compromesso e non hai alcuna sicurezza nell'usarlo ...

Jan Schejbal
2013-02-25 18:47:53 UTC
view on stackexchange narkive permalink

Oltre alle cose già menzionate (è buona norma cambiare tali chiavi su base regolare, le CA vogliono essere pagate, riesaminano l'identità, ecc.), c'è anche una ragione tecnica. I browser informano che non possono verificare la validità del certificato.

I certificati possono essere revocati, ovvero contrassegnati come non validi, nel caso in cui le loro chiavi vengano compromesse, la CA si accorga che sono state emesse in modo errato, ecc. Queste informazioni sulla revoca sono garantito per essere fornito durante il periodo di validità, ma non dopo. Ciò consente di mantenere ridotte le dimensioni CRL (Certificate Revocation List). Sebbene i CRL siano usati raramente oggi in SSL basato su browser, ciò potrebbe influire anche su altri mezzi di controllo della validità.

Per questo motivo, l'applicazione della data di validità ha senso tecnico e non viene eseguita semplicemente perché "i certificati dovrebbero essere rinnovato per garantire che i nuovi audit "e" le CA vogliano essere pagati ".

Cosa aggiunge questa risposta a [quella di Thomas Pornin] (http://security.stackexchange.com/a/31482/2138)?
Nux
2013-02-25 21:34:15 UTC
view on stackexchange narkive permalink

L'impostazione della data di scadenza per i certificati viene eseguita più o meno per lo stesso motivo per cui dovresti cambiare la password di tanto in tanto e avere una politica per far sì che gli utenti la cambino di volta in volta. Non sempre necessario ma a volte potrebbe tornare utile.

Ad esempio, il tuo ex dipendente che ha il tuo lavoro (interno) CA potrebbe firmare il suo sito web di phising e tu non noteresti alcuna differenza in tutto tra il suo sito e il sito della tua banca (incluso il tuo browser che dice che la connessione è sicura). Avere una data di scadenza almeno sulla CA interna ti fa cambiare di tanto in tanto ed evitarlo.

Puoi ancora dire "Non mi interessa" e impostare la data del certificato ad es. 2300 (se sei il titolare di CA). Ovviamente le autorità commerciali esterne potrebbero voler farti impostare la data di scadenza della tua licenza ;-).

Chloe
2013-02-26 04:47:38 UTC
view on stackexchange narkive permalink

Dipende da cosa ti stai assicurando. È relativamente sicuro. Equivale a uno zero-day, l'uomo nel mezzo attacco. Un utente malintenzionato dovrebbe sapere che il certificato è scaduto, sapere che usi quel certificato e inserirsi tra te e il server nell'arco di pochi giorni. Se stai custodendo segreti nucleari, è troppo rischioso fidarsi. Se invii il numero della tua carta di credito, andrà bene per alcuni giorni o settimane (non che tu sia responsabile comunque). Se scrivi un blog sui dittatori in Iran, mentre sei in Iran, stai rischiando la vita e potrebbe non valerne la pena.



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