Helgdagarna är här, på något sätt, och så är SSL.com-nyhetsbrevet i november. I år kan semesterförberedelser verka mer överväldigande än någonsin. Det kan till och med verka som att hålla koll på din internetsäkerhet är för skrämmande en uppgift att ta itu med. Vi är här för att berätta att den typen av tänkande är nonsens - titta bara på alla saker som hände förra månaden!
SSL.com stöder ACME-protokollet
Den 13 november SSL.com meddelade stöd för ACME-protokollet. Nu kan våra kunder enkelt dra nytta av denna populära SSL /TLS automatiseringsverktyg.
Ursprungligen utvecklade Internet Security Research Group och publicerades som en internetstandard i RFC 8555, Förenklar ACME förnyelse och ersättning av SSL /TLS certifikat. Det gör det lättare för webbplatsägare att hålla sig uppdaterad med certifikat på sina webbplatser.
Du kan läsa mer om fördelarna med SSL.coms ACME-implementering i vår blogginlägg tillkännager lanseringen. När du är redo att komma igång, kolla in vår styra till certifikatutfärdande och återkallande med ACME, och vårt how-to om ACME-automatisering för Apache- och Nginx-serverplattformarna.
Kongressen godkänner IoT: s cybersäkerhetsproposition
Passerad av den amerikanska kongressen den 17 november 2020 och går till Vita huset för presidentens underskrift, Internet of Things Cybersecurity Improvement Act ”Kräver att National Institute of Standards and Technology (NIST) och Office of Management and Budget (OMB) vidtar specifika åtgärder för att öka cybersäkerhet för IoT-enheter (Internet of Things).”
In en artikel om Hot post, Lindsey O'Donnell förklarar att den federala åtgärden är utformad för att sätta stopp för säkerhets- och sekretessfrågor som länge har tappat IoT-enheter, och det gör det på ett sätt som överensstämmer med befintliga industristandarder och bästa praxis. Hon skriver:
IoT Cybersecurity Improvement Act har flera olika delar. För det första föreskrivs att (National Institute of Standards and Technology) måste utfärda standardbaserade riktlinjer för minsta säkerhet för IoT-enheter som ägs av den federala regeringen. Office of Management and Budget (OMB) måste också införa krav för federala civila myndigheter att ha informationssäkerhetspolicyer som överensstämmer med dessa NIST-riktlinjer.
Enligt lagen måste federala myndigheter också implementera en policy för avslöjande av sårbarheter för IoT-enheter, och de kan inte skaffa enheter som inte uppfyller säkerhetsriktlinjerna.
O'Donnell rapporterar vidare att ansträngningarna för att reglera IoT fortsätter att vara en världsomspännande insats, med säkerhetsrekommendationer från Europeiska unionens byrå för nätverks- och informationssäkerhet och löften från Storbritannien att utfärda krav på lösenord och säkerhetsuppdateringar.
HTTPS-Only Mode Erbjuds i Firefox 83
Mozillas Firefox 83, släppt den 17 november, erbjuder användarna en Endast HTTPS-läge. Genom att aktivera det kommer webbläsaren automatiskt att söka efter HTTPS-anslutningar och be om tillstånd innan du fortsätter till en webbplats som inte stöder säkra anslutningar. Som Mozillas blogginlägg påminner oss om att det vanliga HTTP-protokollet kan visas av dem som vill stjäla eller manipulera data. HTTP över TLS, eller HTTPS, fixar det genom att skapa en krypterad anslutning mellan din webbläsare och webbplatsen du besöker, vilka framtida angripare inte kan läsa.
Även om de flesta webbplatser idag stöder HTTPS, är vissa webbplatser fortfarande beroende av HTTP. Eller ibland är en osäker HTTP-version av en webbplats den som lagras i dina bokmärken eller nås via äldre länkar och kan vara standard utan hjälp av en webbläsare som prioriterar säkra HTTPS-anslutningar.
Som Mozilla-bloggen förklarardet är enkelt att aktivera det nya läget nu:
Om du är angelägen om att prova den här nya säkerhetsförbättringsfunktionen är det enkelt att aktivera HTTPS-läge:
- Klicka på Firefox menyknapp och välj “Inställningar”.
- Välj "Sekretess och säkerhet" och bläddra ner till avsnittet "Endast HTTPS-läge".
- Välj "Aktivera Endast HTTPS-läge i alla fönster".
Apples hantering av OCSP-begäranden ger upphov till integritetsproblem
Den här månaden lät ett par människor larm om Big Sur efter att serverproblem avslöjade att Apple spårar och avslöjar en hel del om sina användare när de kontrollerar signerad applikationskod. I huvudsak skickade certifikatkontrollkoden ut en utvecklares "digitala fingeravtryck" via HTTP med vanlig text när en applikation startades. Vad betyder det? Thomas Claburn av Registret säger det kortfattat nog: "Apple såväl som vem som helst som avlyssnar nätverksvägen kan åtminstone länka dig med din offentliga IP-adress till de typer av program du använder."
I kölvattnet av att denna information offentliggjordes lovade Apple att inte längre logga IP-adresser. Också från Registret Artikeln:
För att ytterligare skydda integriteten har vi slutat logga in IP-adresser som är kopplade till kontroller av utvecklar-ID-certifikat, och vi kommer att se till att alla samlade IP-adresser tas bort från loggar, säger Apple.
Silicon Valley-titan sa också att den planerar att implementera ett krypterat protokoll för återkallande av certifikat för utvecklar-ID-certifikat, att vidta åtgärder för att göra dess servrar mer motståndskraftiga och att ge användarna en opt-out-mekanism. Registret förstår att certifikatkontrollerna är kryptografiskt signerade av Apple, så att de inte kan manipuleras under transitering utan upptäckt, även om de kan observeras, och nu kommer Apple att svepa den kommunikationskanalen i kryptering för att skydda den från nyfikna ögon.
Dessutom har Apple slutat tillåta tredjepartsappar som brandväggar och VPN att blockera eller övervaka trafik från sina egna appar och operativsystemsprocesser till Apples servrar i Big Sur. Det här är ett problem för dem som vill analysera sin nätverkstrafik helt eller helt enkelt inte vill att deras trafik ska gå till Apples servrar.
Även om Register-artikeln tar en högtidlig ton är den ganska uppmätt. För en mer passionerad tolkning i slutändan bryter Jeffery Paul också ner säkerhetsimplikationerna på sin blogg.
