Beveiligingsoverzicht van juni 2020

Beveiligingsnieuws van juni van SSL.com: Senaat stelt achterdeurtjes voor versleuteling, HTTPS voor .gov, DoH met Firefox en Comcast voor, AddTrust External CA root verloopt.

gerelateerde inhoud

Wil je blijven leren?

Abonneer u op de nieuwsbrief van SSL.com, blijf op de hoogte en veilig.

Welkom bij deze juni-editie van SSL.com's Security Roundup. De zomer is aangebroken, de pandemie gaat door en dat geldt ook voor het nieuws over digitale veiligheid! Deze maand gaan we kijken naar:

Als u op zoek bent naar een SSL /TLS certificaat voor uw site, kijk dan eens naar de betaalbare, hoge waarde van SSL.com opties.

Senaat om verplichte achterdeurtjes voor versleuteling te overwegen

Deze is een beetje leuk. Terwijl een groot deel van het land overweegt de macht van de wetshandhaving terug te schroeven, hebben drie senatoren een Draconische rekening dat zal technologiebedrijven dwingen om een ​​'backdoors'-encryptieschema te creëren waarmee wetshandhavers toegang kunnen krijgen tot gegevens die onderweg zijn en op apparaten. Zoals Vice Magazine's moederbord leg het beknopt in hun kop, "Republikeinen die de encryptie niet begrijpen, introduceren een wetsvoorstel om het te breken."

Het wetsvoorstel van senatoren Lindsey Graham (R-South Carolina), Tom Cotton (R-Arkansas) en Marsha Blackburn (R-Tennessee) is breed en grondig bekritiseerd door de technische industrie, voorstanders van burgerrechten en velen met gezond verstand. Zoals die van Thomas Claburn dit artikel in The Register legt uit:

Het wetsvoorstel vereist dat elk bedrijf dat een bevel krijgt - "fabrikant van apparaten, een aanbieder van een besturingssysteem, een aanbieder van computerservices op afstand of een andere persoon" - autoriteiten helpt bij het verkrijgen van toegang tot informatie die is opgeslagen op een elektronisch apparaat of tot op afstand opgeslagen elektronische informatie. "

 Het specificeert niet hoe met encryptie moet worden omgegaan, alleen dat het ongedaan moet worden gemaakt als het lastig is voor autoriteiten ...

 ... Het moet gezegd worden dat versleuteling ook een behoorlijke hoeveelheid misdaad voorkomt door zaken als online bankrekeningen en surfen op het web redelijk veilig te houden. Een achterdeur verplicht stellen, wat wiskundig gezien iedereen kon vinden, is misschien niet de meest wijze zet.

Helaas is deze poging tot wetgeving niet eens bijzonder nieuw, alleen de laatste luie herhaling van een poging om digitale beveiliging te omzeilen om het de Powers That Be gemakkelijker te maken.

De afhaalmaaltijd van SSL.com: SSL.com ondersteunt geen door de overheid opgelegde onveiligheid - wanneer end-to-end-encryptie verboden is, zullen alleen outlaws end-to-end-encryptie hebben. Let ook op dit citaat uit het Vice-artikel: 'Het enige voorbehoud is' tenzij de onafhankelijke acties van een niet-gelieerde entiteit het technisch onmogelijk maken om dit te doen ', wat de huidige realiteit lijkt uit te sluiten, namelijk dat technologiebedrijven het zelf onmogelijk hebben gemaakt. om gegevens te decoderen die zijn opgeslagen op een telefoon die zijn gecodeerd met een toegangscode, of berichten die zijn uitgewisseld in end-to-end gecodeerde apps. '

Amerikaanse regering is van plan HTTPS te gebruiken op alle .gov-websites

In goed, laat nieuws, de Amerikaanse regering heeft aangekondigd het is de bedoeling om het ".gov" -domein toe te voegen aan de HTTP Strict Transport Security (HSTS) -voorlaadlijst. Voorlopig zullen sommige overheidssites HTTP blijven aanbieden om ze toegankelijk te houden voor gebruikers, met de bedoeling het punt te bereiken waarop alle .gov-webservers standaard HTTPS zullen gebruiken.

Maar dit is de federale regering en het is belangrijk op te merken dat dit allemaal niet van de ene op de andere dag zal plaatsvinden. Integendeel, de VS werken eraan om het .gov-domein op de HSTS-preloadlijst te plaatsen, wat uiteindelijk zal gebeuren gebruikers omleiden om via HTTPS te communiceren als standaard.

Vanaf kondigde de regering aant:

Merk op dat we een intentie aankondigen om de TLD vooraf te laden, maar deze vandaag niet daadwerkelijk vooraf te laden. Als we dat zouden doen, zouden sommige overheidswebsites die geen HTTPS aanbieden ontoegankelijk worden voor gebruikers en we willen geen negatieve invloed hebben op onze diensten om ze te verbeteren! Eigenlijk is vooraf laden een eenvoudige stap, maar om daar te komen, is gezamenlijke inspanning vereist van de federale, staats-, lokale en tribale overheidsorganisaties die een gemeenschappelijke hulpbron gebruiken, maar niet vaak samenwerken op dit gebied ... Met gezamenlijke inspanning kunnen we vooraf laden. gov binnen enkele jaren.

Ondertussen bereidt de regering volgens diezelfde aankondiging individuele sites voor op de overgang, houdt ze presentaties en luistersessies en laadt ze automatisch alle nieuwe .gov-domeinen vanaf september. Ze hebben ook een nieuwe listserv gemaakt voor feedback van overheidsinstanties over de uitdagingen die ze verwachten aan te gaan.

De afhaalmaaltijd van SSL.com:  Alle websites overal zouden nu HTTPS moeten gebruiken, dus dit is een goed idee, hoewel het een langzaam bewegend idee is. We nemen wat we kunnen krijgen!

Comcast en Mozilla Strike Firefox DoH Deal

Comcast is de eerste internetprovider die dit doet partner met Mozilla om versleutelde DNS-zoekopdrachten in Firefox te bieden. De deal tussen de twee bedrijven komt na een geschil over ISP-privacy en of DNS via HTTPS de mogelijkheid van ISP's wegneemt om gebruikers te volgen en zaken als ouderlijk toezicht te onderhouden.

Jon Brodkin in Ars Technica legt uit dat Comcast de eerste ISP zal zijn die zich aansluit bij het Trusted Recursive Resolver-programma van Firefox, dat zich aansluit bij Cloudflare en NextDNS. Volgens dat artikel vereist het programma 'dat gecodeerde DNS-providers moeten voldoen privacy- en transparantiecriteria en beloof domeinen niet standaard te blokkeren of te filteren 'tenzij specifiek vereist door de wet in het rechtsgebied waarin de resolver actief is'. ''

Eerder waren de twee nu-partners het niet eens over DNS via HTTPS, wat voorkomt dat mensen kunnen zien wat DNS-lookups-browsers maken, waardoor monitoring door ISP's behoorlijk moeilijk wordt. Uit het Ars Technica-artikel:

De samenwerking tussen Comcast en Mozilla is opmerkelijk omdat ISP's hebben gevochten tegen plannen om DNS via HTTPS in browsers in te zetten, en Mozilla's werk aan de technologie is grotendeels bedoeld om te voorkomen dat ISP's snuffelen in het browsen van hun gebruikers. In september 2019 schreven branchegroepen, waaronder de NCTA-kabellobby waartoe Comcast behoort, een letter aan het congres bezwaar maken tegen de plannen van Google voor versleutelde DNS in Chrome en Android. Comcast gaf congresleden a lobby presentatie die beweerde dat het gecodeerde DNS-plan 'een meerderheid van de wereldwijde DNS-gegevens bij Google zou centraliseren' en 'één provider controle zou geven over de routering van internetverkeer en enorme hoeveelheden nieuwe gegevens over consumenten en concurrenten'. De lobbypresentatie van Comcast klaagde ook over het plan van Mozilla voor Firefox.

Mozilla in november beschuldigde ISP's van liegen tegen het Congres om verwarring over gecodeerde DNS te zaaien. Mozilla's brief aan het Congres bekritiseerde Comcast, wijzend op een voorval in 2014 waarin Comcast "advertenties injecteerde aan gebruikers die waren verbonden met zijn openbare Wi-Fi-hotspots, waardoor mogelijk nieuwe beveiligingsproblemen op websites werden gecreëerd." Mozilla zei dat vanwege het Comcast-incident en anderen waarbij Verizon en AT&T betrokken waren, "Wij geloven dat dergelijke proactieve maatregelen [om gecodeerde DNS te implementeren] nodig zijn geworden om gebruikers te beschermen in het licht van de uitgebreide staat van dienst van ISP-misbruik van persoonlijke gegevens." Mozilla wees ook op het gebrek aan privacyregels voor breedband in het land gedood door het Congres in 2017 op verzoek van ISP's.

Maar dat lijkt nu in het verleden te zijn, met een ondertekende overeenkomst tussen de twee bedrijven vanaf maart, en de verwachting dat de gecodeerde DNS van Comcast ook snel genoeg naar Chrome zal komen.

De afhaalmaaltijd van SSL.com: Het is goed om te zien dat een ISP aan boord komt met gecodeerde DNS, maar je moet nog steeds Comcast's Xfinity lezen Privacybeleid als je een klant bent.

AddTrust External CA Het basiscertificaat is verlopen

De AddTrust External CA root certificaat verlopen op mei 30, 2020. Hoewel de meeste gebruikers geen hinder ondervinden van deze vervaldatum, is het toch opmerkelijk. Sommige certificaten die in het verleden door SSL.com zijn uitgegeven, koppelen aan Sectigo's USERTrust RSA CA-root via een tussenliggende cross-ondertekend door de AddTrust-root. Dit werd gedaan om compatibiliteit te garanderen met oudere apparaten die de USERTrust-root niet bevatten.

Gelukkig apparaten die do inclusief de USERTrust-root, die de overgrote meerderheid zijn, wordt niet beïnvloed door de vervaldatum. In dat geval, wat geldt voor alle moderne browsers, besturingssystemen en mobiele apparaten, kiest de software eenvoudig een vertrouwenspad dat naar USERTrust leidt en negeert het verlopen AddTrust-certificaat. We hebben dit allemaal aan het begin van de maand uitgelegd, dus als je op zoek bent naar meer details, wil je dat misschien wel ga naar onze blogpost van 2 juni. Om de compatibiliteit met oudere apparaten te behouden, kunnen website-eigenaren met SSL.com USERTrust-certificaten vervangende tussencertificaten en rootcertificaten downloaden via de onderstaande knoppen:

INDIVIDUELE CERTIFICATEN DOWNLOADEN

DOWNLOAD GEBUNDELDE CERTIFICATEN

Gebruikers die vertrouwen op oudere SSL /TLS clients, inclusief OpenSSL 1.0.x en GnuTLS, zou het verlopen AddTrust-certificaat uit hun OS-rootopslag moeten verwijderen. Zie onze blogpost voor links naar oplossingen voor Red Hat Linux en Ubuntu.

De afhaalmaaltijd van SSL.com: Als u USERTrust-certificaten heeft die zijn uitgegeven door SSL.com, kunt u (en moet!) Een nieuwe CA-bundel downloaden van onze website en installeer ze op uw server.
Bedankt voor het bezoeken van SSL.com! Als u vragen heeft, neem dan contact met ons op via e-mail op Support@SSL.com, bel 1-877-SSL-SECURE, of klik gewoon op de chatlink rechtsonder op deze pagina. U kunt ook antwoorden op veel voorkomende ondersteuningsvragen vinden in onze kennis basis.

 

We willen graag uw feedback

Vul onze enquête in en laat ons uw mening over uw recente aankoop weten.