Thunderbird waarschuwt gebruikers voor PGP keys die gaan verlopen
De ontwikkelaars van Thunderbird hebben een nieuw versie van het Release Channel uitgebracht die onder andere gebruikers waarschuwt als hun PGP key binnen 31 dagen verloopt. PGP keys worden gebruikt om versleuteld met anderen te mailen. PGP keys hebben als veiligheidsmaatregel standaard een verloopdatum. Dit moet de impact van een gestolen key beperken.
Thunderbird gaf voorheen pas een waarschuwing als gebruikers met een verlopen PGP key wilden mailen. Met Thunderbird 141.0 zal de e-mailclient nu proactief een duidelijke waarschuwing in het venster voor het opstellen van e-mail laten zien wanneer de key binnen 31 dagen verloopt. Volgens de ontwikkelaars maakt dit de inbox van gebruikers proactief.
Een andere nieuwe feature is de mogelijkheid om inkomende e-mailberichten direct via notificaties van het onderliggende besturingssysteem te archiveren. Het is daardoor niet meer nodig om naar Thunderbird zelf te gaan voor het archiveren van berichten. De twee features zijn beschikbaar in Thunderbird 141. Deze versie bevind zich in het Release Channel waar de meeste Thunderbird-gebruikers geen gebruik van maken.
De meeste gebruikers werken namelijk met een Thunderbird ESR-versie. ESR staat voor extended support release en betreft een versie die voornamelijk beveiligingsupdates en bugfixes ontvangt. Thunderbird blijft een bepaalde ESR-versie lange tijd ondersteunen. Grote nieuwe features worden alleen bij de overstap naar een nieuwe ESR-versie toegevoegd.
Met het Release Channel worden sneller nieuwe features aan de e-mailclient toegevoegd. Volgens het ontwikkelteam maakt op dit moment tien tot twintig procent van de Thunderbird-gebruikers gebruik van het Release Channel. Overstappen van ESR naar Release Channel vereist het downloaden van de laatstgenoemde versie en het installeren in dezelfde directory waar de ESR-versie zich in bevindt.
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Een uitleg hierover staat in https://gnupg.org/gph/en/manual.html#AEN526.
Zelf heb ik er last van dat mijn hoofd een beetje gaat duizelen bij alle master/sub keys. Ik vind het prettig om het te begrijpen zoals het was in PGP 2.x. Een RSA sleutel voor zowel signing als encryption. Natuurlijk is MD5 wat PGP 2.x gebruikt helemaal achterhaald, maar los van de leeftijd van de software werkte het goed en eenvoudig. Er was zelfs een alternatieve versie van Disastry van PGP 2.6.3ia multi die alle algoritmes van RFC 4880 toevoegde aan PGP 2.x. Helaas is Disastry overleden bij een bergbeklimming.
De DH/DSS sleutels die er vroeger waren (vanwege patenten op RSA tot september 2000) hadden de beperking dat het ondertekenen met 1024 bit asymmetrische sleutels gebeurde. Dat was achteraf gezien onveilig. Maar het was een standaard van de VS dus daar viel niets aan te veranderen.
Met 'gpg --gen-key --expert' kan je dat oude gevoel een beetje terughalen, maar er is geen garantie dat je sleutel dan blijft werken met alle software die er ook is. Het beste is om de standaard instellingen te gebruiken net zoals iedereen.
Anoniem 17:45
Zorg voor een goede backup van je secret key en revoke je hele PGP sleutel als daar aanleiding voor is. Of maak vooraf een revocation certificate aan die je bij deze backup bewaart.
Je realiseert je dat je ook niet kunt weten _of_ die aanleiding daarvoor er is ?
Met een verloopdatum is er in elk geval een uiterste grens aan het misbruik - analoog aan TLS certs .
Verder is PGP ecosysteem natuurlijk op sterven na dood - revocation cert verspreiding is twijfelachtig .
Als je alleen maar hobbymatig met een handvol contacten werkt kun je die - als je dan twijfelf over je key - nog wel de revocation sturen .
Merk op dat ongeveer de enige groep waar PGP gebruik nog echt zichtbaar is (CERT teams) dus inderdaad werken met jaarkeys .
Logisch - ze hebben relatief veel en onvoorspelbare correspondenten , en als teamleden vervangen worden is het - hoe integer en correct die ook zijn - ook wenselijk dat die niet meer eeuwig "potentieel" de cert key zouden kunnen weten/hebben.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?