en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Rassegna sulla sicurezza di giugno 2020

Benvenuti a questa edizione di giugno del riepilogo sulla sicurezza di SSL.com. L'estate è arrivata, la pandemia continua, così come le notizie sulla sicurezza digitale! Questo mese daremo un'occhiata a:

Se stai cercando un SSL /TLS certificato per il tuo sito, dai un'occhiata al conveniente e di alto valore di SSL.com Opzioni.

Il Senato prende in considerazione le backdoor di crittografia obbligatoria

Questo è un po 'yikes-y. Mentre gran parte del paese sta considerando di ridimensionare il potere delle forze dell'ordine, tre senatori hanno introdotto a Conto Draconiano che costringerà le aziende tecnologiche a creare "backdoor" di schemi di crittografia che consentiranno alle forze dell'ordine di accedere ai dati in transito e sui dispositivi. Come Vice Magazine Scheda madre sinteticamente inserito il loro titolo, "I repubblicani che non comprendono la crittografia introducono Bill per romperla".

Il disegno di legge dei senatori Lindsey Graham (R-South Carolina), Tom Cotton (R-Arkansas) e Marsha Blackburn (R-Tennessee) è stato ampiamente e ampiamente criticato dall'industria tecnologica, dai difensori dei diritti civili e da molti con buon senso. Come quello di Thomas Claburn articolo nel registro spiega:

Il disegno di legge richiede a qualsiasi azienda presentata con un mandato - "produttore del dispositivo, un fornitore di sistema operativo, un fornitore di servizi di elaborazione remota o un'altra persona" - per aiutare le autorità "ad accedere alle informazioni memorizzate su un dispositivo elettronico o per accedere alle informazioni elettroniche memorizzate in remoto. "

 Non specifica come deve essere gestita la crittografia, ma solo che dovrebbe essere annullabile se scomodo per le autorità ...

 … La crittografia, va detto, previene anche una discreta quantità di criminalità mantenendo cose come i conti bancari online e la navigazione web ragionevolmente sicuri. Mandare una backdoor, che matematicamente chiunque potrebbe trovare, potrebbe non essere la mossa più saggia.

Purtroppo, questo tentativo di legislazione non è nemmeno particolarmente nuovo, solo l'ultima pigra iterazione di un tentativo di aggirare la sicurezza digitale per rendere le cose più facili per i Poteri che sono.

Da asporto di SSL.com: SSL.com non supporta l'insicurezza imposta dal governo: quando la crittografia end-to-end è fuorilegge, solo i fuorilegge avranno la crittografia end-to-end. Si noti anche questa citazione dall'articolo di Vice: "L'unico avvertimento è" a meno che le azioni indipendenti di un'entità non affiliata non rendano tecnicamente impossibile farlo ", il che sembra escludere la realtà attuale, ovvero che le stesse aziende tecnologiche lo hanno reso impossibile per decrittografare i dati memorizzati su un telefono crittografato con un passcode o i messaggi scambiati in app crittografate end-to-end. "

Il governo degli Stati Uniti prevede di utilizzare HTTPS su tutti i siti Web .gov

In buone notizie tardive, il governo degli Stati Uniti ha annunciato l'intenzione di aggiungere il dominio ".gov" all'elenco di precaricamento HTTP Strict Transport Security (HSTS). Per ora, alcuni siti governativi continueranno a offrire HTTP per renderli accessibili agli utenti, con l'intenzione di raggiungere il punto in cui tutti i server web .gov useranno HTTPS per impostazione predefinita.

Ma questo è il governo federale ed è importante notare che nulla di tutto ciò avverrà dall'oggi al domani. Piuttosto, gli Stati Uniti stanno lavorando per mettere il dominio .gov nell'elenco dei precarichi HSTS, che alla fine lo farà reindirizzare gli utenti a comunicare tramite HTTPS come impostazione predefinita.

Da gli annunci del governot:

Si noti che stiamo annunciando l'intenzione di precaricare il TLD, ma in realtà non lo precaricherà oggi. Se lo facessimo, alcuni siti web governativi che non offrono HTTPS diventerebbero inaccessibili agli utenti e non vogliamo avere un impatto negativo sui servizi sulla nostra strada per migliorarli! In realtà il precaricamento è un semplice passo, ma per arrivarci occorrerà uno sforzo concertato tra le organizzazioni governative federali, statali, locali e tribali che usano una risorsa comune, ma spesso non lavorano insieme in quest'area ... Con uno sforzo concertato, potremmo precaricare. gov entro pochi anni.

Nel frattempo, secondo lo stesso annuncio, il governo preparerà i singoli siti per la transizione, tenendo presentazioni e sessioni di ascolto e precaricando automaticamente tutto nuovi Domini .gov che iniziano a settembre. Hanno anche creato un nuovo listino per il feedback delle agenzie governative sulle sfide che si aspettano di affrontare.

Da asporto di SSL.com:  Ormai tutti i siti Web dovrebbero usare HTTPS, quindi questa è una buona idea, anche se in movimento lento. Prenderemo quello che possiamo ottenere!

Comcast e Mozilla Strike Deal DoH per Firefox

Comcast è il primo provider di servizi Internet a collaborare con Mozilla per fornire ricerche DNS crittografate in Firefox. L'accordo tra le due società arriva dopo una disputa sulla privacy dell'ISP e se DNS su HTTPS toglie la capacità degli ISP di tracciare gli utenti e mantenere cose come il controllo parentale.

Jon Brodkin in Ars Technica spiega che Comcast sarà il primo ISP ad aderire al programma Trusted Recursive Resolver di Firefox, unendosi a Cloudflare e NextDNS. Il programma, secondo quell'articolo, “richiede che i provider DNS crittografati si incontrino criteri di privacy e trasparenza e si impegna a non bloccare o filtrare i domini per impostazione predefinita "a meno che non sia specificamente richiesto dalla legge nella giurisdizione in cui opera il risolutore". "

In precedenza, i due attuali partner non erano d'accordo su DNS su HTTPS, il che impedisce alle persone di vedere cosa stanno facendo i browser di ricerca DNS, rendendo piuttosto difficile il monitoraggio da parte degli ISP. Dall'articolo di Ars Technica:

La partnership Comcast / Mozilla è degna di nota perché gli ISP hanno combattuto i piani per distribuire DNS su HTTPS nei browser e il lavoro di Mozilla sulla tecnologia è in gran parte inteso a impedire agli ISP di spiare la navigazione dei propri utenti. Nel settembre 2019, gruppi industriali tra cui la lobby dei cavi NCTA di cui Comcast appartiene hanno scritto un file lettera al Congresso opporsi ai piani di Google per DNS crittografato in Chrome e Android. Comcast ha dato membri del Congresso a presentazione di lobby che ha affermato che il piano DNS crittografato "centralizzerebbe [e] la maggior parte dei dati DNS mondiali con Google" e "darebbe a un provider il controllo del routing del traffico Internet e grandi quantità di nuovi dati su consumatori e concorrenti". La presentazione del lobbismo di Comcast ha anche lamentato il piano di Mozilla per Firefox.

Mozilla a novembre ISP accusati di mentire al Congresso per diffondere confusione sul DNS crittografato. Mozilla's lettera al congresso ha criticato Comcast, indicando un incidente nel 2014 in cui Comcast "inseriva annunci negli utenti connessi ai suoi hotspot Wi-Fi pubblici, creando potenzialmente nuove vulnerabilità di sicurezza nei siti web". Mozilla ha affermato che a causa dell'incidente di Comcast e di altri che hanno coinvolto Verizon e AT&T, "Riteniamo che tali misure proattive [per implementare DNS crittografati] siano diventate necessarie per proteggere gli utenti alla luce dell'ampio record di abuso dei dati personali da parte dell'ISP". Mozilla ha anche sottolineato la mancanza di regole sulla privacy della banda larga nel paese, che erano ucciso dal Congresso nel 2017 su richiesta degli ISP.

Ma questo sembra essere ormai passato, con un accordo firmato tra le due società a partire da marzo, e l'aspettativa che il DNS crittografato di Comcast arriverà anche su Chrome abbastanza presto.

Da asporto di SSL.com: È bello vedere un ISP entrare a far parte del DNS crittografato, ma dovresti comunque leggere Xfinity di Comcast politica sulla riservatezza se sei un cliente.

AddTrust External CA Il certificato radice è scaduto

The AddTrust External CA certificato di origine scaduto maggio 30, 2020. Sebbene la maggior parte degli utenti non sarà interessata da questa scadenza, è comunque degna di nota. Alcuni certificati emessi in passato dalla catena SSL.com alla radice CA USERTrust RSA di Sectigo tramite una firma incrociata intermedia dalla radice AddTrust. Ciò è stato fatto per garantire la compatibilità con i dispositivi legacy che non includono la radice USERTrust.

Fortunatamente, i dispositivi che do includere la radice USERTrust, che è la stragrande maggioranza, non sarà influenzata dalla scadenza. In tal caso, che sarà vero per tutti i browser, sistemi operativi e dispositivi mobili moderni, il software sceglierà semplicemente un percorso di fiducia che porta a USERTrust e ignorerà il certificato AddTrust scaduto. Abbiamo spiegato tutto all'inizio del mese, quindi se stai cercando maggiori dettagli, potresti volerlo vai al nostro post sul blog del 2 giugno. Per mantenere la compatibilità con i dispositivi meno recenti, i proprietari di siti Web con certificati SSL.com USERTrust possono scaricare certificati sostitutivi intermedi e radice tramite i pulsanti seguenti:

SCARICA I CERTIFICATI INDIVIDUALI

SCARICA I CERTIFICATI CONFEZIONATI

Utenti che si affidano a SSL precedente /TLS client, inclusi OpenSSL 1.0.xe GnuTLS, dovrebbe rimuovere il certificato AddTrust scaduto dal loro archivio principale del sistema operativo. Vedi il nostro post sul blog per collegamenti a correzioni per Red Hat Linux e Ubuntu.

Da asporto di SSL.com: Se disponi di certificati USERTrust emessi da SSL.com, puoi (e dovresti!) Scaricare un nuovo bundle CA dal nostro sito Web e installali sul tuo server.
Grazie per aver visitato SSL.com! In caso di domande, contattaci tramite e-mail all'indirizzo Support@SSL.com, chiama 1-877-SSL-SECUREoppure fai clic sul link della chat in basso a destra in questa pagina. Puoi anche trovare risposte a molte domande comuni di supporto nel nostro base di conoscenza.

 

Iscriviti alla Newsletter di SSL.com

Non perdere nuovi articoli e aggiornamenti da SSL.com