Lek in e-mailclients maakt het mogelijk om afzender te spoofen
Door een kwetsbaarheid in tientallen e-mailclients is het mogelijk om de afzender van een e-mail te spoofen, waarbij beveiligingsmaatregelen zoals DMARC en spamfilters kunnen worden omzeild, zo stelt beveiligingsonderzoeker Sabri Haddouche. Het probleem is onder andere aanwezig in Apple Mail, Mozilla Thunderbird, verschillende Microsoft-clients, Yahoo! Mail en andere programma's.
De kwetsbaarheid wordt veroorzaakt door een Request for Comments (RFC) van de Internet Engineering Task Force uit 1992. In deze RFC wordt een manier aanbevolen om niet-ASCII-karakters binnen e-mailheaders op zo'n manier te encoderen dat het de e-mailservers die de e-mail verwerken niet zal verwarren. De meeste e-mailclients en webinterfaces blijken de string na het decoderen niet goed te sanitizen, waardoor de spoofingaanval mogelijk is. Het gespoofte afzenderadres wordt volgens Haddouche niet door de e-mailserver gedetecteerd, zodat spoofingbeveiliging als DMARC of spamfilters wordt omzeild.
Het spoofinglek werd door Haddouche in 33 verschillende producten aangetroffen en is in 8 producten inmiddels verholpen. Voor 12 andere producten zijn patches ontwikkeld, maar nog niet uitgerold. Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat. Mailbird heeft de melding van de onderzoeker zonder verder antwoord gesloten. Leveranciers van de 12 resterende producten hebben niet aangegeven of ze het probleem zullen verhelpen.
De onderzoeker maakte vandaag zijn bevindingen openbaar en publiceerde een tool genaamd Mailsploit waarmee e-mailadressen kunnen worden gespooft. Alle leveranciers werden 3 maanden voor de openbaarmaking door Haddouche geïnformeerd.
Reacties (21)
05-12-2017, 19:40 door
Briolet
Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat.
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.
Door Briolet:
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.
Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat.
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.
Waarom niet in beide, server en clients?
05-12-2017, 22:34 door
Bitwiper
Door Briolet:
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.
Dat was ook mijn eerste reactie na het lezen van het artikel. Maar de onderzoeker bedoelt niet dat je met de kwetsbare mail clients afzenderadressen kunt spoofen (ja duh), maar dat kwetsbare mail clients in ontvangen mails het From: adres niet laten zien zoals je zou verwachten!Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat.
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.
Zie https://www.mailsploit.com/.
Door Anoniem: In ander nieuws: ROT13 is gekraakt!
Nah, gewoon nog een keer ROT13 encrypten. Moet je van goeden huize komen om dat te vinden.Door Bitwiper: Maar de onderzoeker bedoelt niet dat je met de kwetsbare mail clients afzenderadressen kunt spoofen (ja duh), maar dat kwetsbare mail clients in ontvangen mails het From: adres niet laten zien zoals je zou verwachten!
De ontdekkers omschrijven het probleem als The spoofing is not detected by Mail Transfer Agents (MTA) aka email servers, therefore circumventing spoofing protection mechanisms such as DMARC (DKIM/SPF) or spam filters.[/qoute]
Inderdaad is een gevolg dat clients die zich wel normaal aan een RFC houden dan content kunnen tonen die door kan gaan als gespoofde content, maar het probleem ligt toch echt bij security fouten in de mail servers die DMARC slecht controleren en dus content doorlaten die gespoofd kan zijn. Het aanpassen van de mail clients is slechts symptoombestreiding. Goed toepassen van DMARC is toch echt een kwetstie van het security probleem bij de mail server waar je in vertrouwd oplossen.
Inderdaad is een gevolg dat clients die zich wel normaal aan een RFC houden dan content kunnen tonen die door kan gaan als gespoofde content, maar het probleem ligt toch echt bij security fouten in de mail servers die DMARC slecht controleren en dus content doorlaten die gespoofd kan zijn. Het aanpassen van de mail clients is slechts symptoombestreiding. Goed toepassen van DMARC is toch echt een kwetstie van het security probleem bij de mail server waar je in vertrouwd oplossen.
Door Briolet:
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat.
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Won't fix is niet een goed antwoord op securityproblemen. Dan heb je wat uit te leggen. Het verbaast me overigens niet van Mozilla, die laten jarenlang overduidelijke problemen zitten omdat er een paar developers met een tekort aan social skills zich willen laten gelden en niet met kritiek kunnen omgaan. Dat soort types komen vaak voor in de open source wereld. "Works for me" is hun adagium.
06-12-2017, 06:34 door
SPer
Door Anoniem: In ander nieuws: ROT13 is gekraakt!
Ceasar draait zich 13 keer om in zijn graf , zullen we maar over gaan op ROT14 ;-)
06-12-2017, 09:29 door
Briolet
Door Anoniem:
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Door Briolet:…Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Klopt, maar dat staat hier ook niet ter discussie. Het gaat om zaken als DMARC misleiden door spoofing. En een ontvangende cliënt kan nooit een DMARC controleren, dat kan alleen de ontvangende server betrouwbaar doen. Als het dus om een cliënt met bugs gaat, moet het om de verzendende cliënt gaan.
Ik heb net die testsite bekeken. Ze bedoelen toch de ontvangende cliënt, hoewel ik dan het hele verhaal over DMARC niet goed begrijp.
Ik heb ook via die testsite een mailtje aan mezelf gestuurd. Met apple mail cliënt zie ik echter niets van misleiding. Ik zie gewoon een heel corrupt afzenderveld.
Via Gmail zie ik:
En via mijn eigen server zie ik:
En ook als ik naar DMARC kijk zie ik geen misleiding:
Ik zie duidelijk wie de echte afzender is.
Edit: Op mijn telefoon staat blue mail. Ook daar zie ik alleen een corrupte afzender.
Ook via Thunderbird op mijn laptop zie ik alleen een corrupte afzender. En ik zie dat het DKIM getekend is door mailsploit.com. Dus ook daar geen misleiding.
Dus bij alle 3 geteste mail cliënten zie ik niets van spoofing
Ik heb ook via die testsite een mailtje aan mezelf gestuurd. Met apple mail cliënt zie ik echter niets van misleiding. Ik zie gewoon een heel corrupt afzenderveld.
Via Gmail zie ik:
"BEGIN / … <demo@mailsploit.com>
En via mijn eigen server zie ik:
"BEGIN /…END@mai
En ook als ik naar DMARC kijk zie ik geen misleiding:
Authentication-Results: ?xxx; dmarc=none header.from=mailsploit.com?
Authentication-Results: ?xxx; dkim=permerror (bad message/signature format)?
Authentication-Results: ?xxx; dkim=permerror (bad message/signature format)?
Ik zie duidelijk wie de echte afzender is.
Edit: Op mijn telefoon staat blue mail. Ook daar zie ik alleen een corrupte afzender.
Ook via Thunderbird op mijn laptop zie ik alleen een corrupte afzender. En ik zie dat het DKIM getekend is door mailsploit.com. Dus ook daar geen misleiding.
Dus bij alle 3 geteste mail cliënten zie ik niets van spoofing
Door Briolet:
Klopt, maar dat staat hier ook niet ter discussie. Het gaat om zaken als DMARC misleiden door spoofing. En een ontvangende cliënt kan nooit een DMARC controleren, dat kan alleen de ontvangende server betrouwbaar doen. Als het dus om een cliënt met bugs gaat, moet het om de verzendende cliënt gaan.
Door Anoniem:
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Door Briolet:…Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Klopt, maar dat staat hier ook niet ter discussie. Het gaat om zaken als DMARC misleiden door spoofing. En een ontvangende cliënt kan nooit een DMARC controleren, dat kan alleen de ontvangende server betrouwbaar doen. Als het dus om een cliënt met bugs gaat, moet het om de verzendende cliënt gaan.
DMARC word niet gespoofed. De MTA doet netjes een DMARC check op het verzendende domein. Door bugs in een hele stapel clients geven deze het verzendende domein echter niet goed weer. Oftewel, client side problem bij de *ontvangende* client. Mailsploit heeft een script om het te testen en is sowieso de moeite van het lezen waard. Betere uitleg dan dit artikel.
Dit probleem kan het best worden opgelost op mailservers omdat dat de aangewezen plek is om malformed From te schonen. Dat is de sterkste manier om dit probleem aan te pakken, en dat beaamt de ontdekker van deze exploit zelf ook:
"Haddouche tells WIRED that email providers and firewalls can also be set to filter out his attack, even if email clients remain vulnerable."
waarmee je de spoofing dus ook voorkomt bij Opa Harrie de internet leek die zijn PC nooit update. Dit is een logische conclusie indien je de exploit ook inhoudelijk begrijpt. Het is immers sterk om een string te lezen tot de string terminator \0, de fout is dat de valide data (de echte From) voorafgegaan wordt door \0, en die fout wordt niet veroorzaakt door de mail client.
Sterker, het is ronduit misleidend om dit een 'lek in mailclients' te noemen in de kop van dit artikel, en met die onzorgvuldigheid zet security.nl de leken hier op het verkeerde been. Het is een zwakte in MTAs. Toegegeven, mailclients -kunnen- deze zwakte mitigeren met extra code, maar dat is zoals hierboven ook al meerdere malen terecht opgemerkt, symptoombestrijding.
"Haddouche tells WIRED that email providers and firewalls can also be set to filter out his attack, even if email clients remain vulnerable."
waarmee je de spoofing dus ook voorkomt bij Opa Harrie de internet leek die zijn PC nooit update. Dit is een logische conclusie indien je de exploit ook inhoudelijk begrijpt. Het is immers sterk om een string te lezen tot de string terminator \0, de fout is dat de valide data (de echte From) voorafgegaan wordt door \0, en die fout wordt niet veroorzaakt door de mail client.
Sterker, het is ronduit misleidend om dit een 'lek in mailclients' te noemen in de kop van dit artikel, en met die onzorgvuldigheid zet security.nl de leken hier op het verkeerde been. Het is een zwakte in MTAs. Toegegeven, mailclients -kunnen- deze zwakte mitigeren met extra code, maar dat is zoals hierboven ook al meerdere malen terecht opgemerkt, symptoombestrijding.
06-12-2017, 11:01 door
Jan-Marten Spit
Door Anoniem: Won't fix is niet een goed antwoord op securityproblemen.
Een gebrek aan vakkennis wel?
Je anonieme social skills en geldingsdrang druipen er van af. Kan je wel met kritiek om gaan?
Dat Mozilla werkelijk niks gaat doen is onjuist. UIt dit probleem zijn een vijftal bug reports onstaan waar één van serieus naar gekeken wordt op dit moment, drie staan nog klaar voor beoordeling en de laatste is afgeschoten "Bug 1423440 - Remove @ from real name" met als reden dat dit heel veel klachten gaat opleveren als bijvoorbeeld je bedrijf "Man @ Work" heet.
Zie onderstaande link voor meer informatie:
https://bugzilla.mozilla.org/show_bug.cgi?id=1423430
Zie onderstaande link voor meer informatie:
https://bugzilla.mozilla.org/show_bug.cgi?id=1423430
Door Jan-Marten Spit:
Een gebrek aan vakkennis wel?
Je anonieme social skills en geldingsdrang druipen er van af. Kan je wel met kritiek om gaan?
Door Anoniem: Won't fix is niet een goed antwoord op securityproblemen.
Een gebrek aan vakkennis wel?
Je anonieme social skills en geldingsdrang druipen er van af. Kan je wel met kritiek om gaan?
Ja, dat zie je ook hoe ik niet reageer op kritiek dat ik fout zat door Briolet (wat niet zo is). Briolet heeft zichzelf hersteld, dus reageren is niet nodig.
Jijbakken (tu quoque) draagt niet bij aan de discussie.
Door Anoniem: Dat Mozilla werkelijk niks gaat doen is onjuist. UIt dit probleem zijn een vijftal bug reports onstaan waar één van serieus naar gekeken wordt op dit moment, drie staan nog klaar voor beoordeling en de laatste is afgeschoten "Bug 1423440 - Remove @ from real name" met als reden dat dit heel veel klachten gaat opleveren als bijvoorbeeld je bedrijf "Man @ Work" heet.
Zie onderstaande link voor meer informatie:
https://bugzilla.mozilla.org/show_bug.cgi?id=1423430
Zie onderstaande link voor meer informatie:
https://bugzilla.mozilla.org/show_bug.cgi?id=1423430
Uit de link maak ik op dat je ontwikkelaar bent, want ik kan hem niet zien (access denied). Er zijn diverse manieren om dit op te lossen vrijwel zonder false positives. Als andere partijen het ook kunnen, moet Mozilla het ook lukken.
Technisch: Man @ Work is geen email adres en behoeft dus geen aanpassing. Er staan spaties in en het "domein" bestaat uit slechts 1 label. Bij een email adres verwacht je minstens 2 labels (d.w.z.: domeinnaam.tld). Domeinnamen en tld moeten aan regels voldoen. Het is misschien niet nodig die regels te handhaven.
Een van de tests is deze:
From: "potus@whitehouse gov" <demo@mailsploit com>
een alternatieve schrijfwijze zou zijn:
From: potus@whitehouse gov <demo@mailsploit com>
(onschadelijk gemaakt door punt voor tld te verwijderen, de adressen vormen 1 aaneengesloten whitespaceloze string)
Op dergelijke emails moet een mail filter ingrijpen. Een mail client kan een duidelijke waarschuwing tonen. Sommig email clients tonen geen email adressen alleen de omschrijving, en dat maakt dit zeer gevaarlijk.
Ik ben overigens tegen mail server level rewriting. Email moet worden doorgegeven as-is. Geen gerommel. Dat is in het verleden al zeer gevaarlijk gebleken, met name bij Microsoft Exchange, die "defecte" email automagisch repareert. Daardoor kan bijvoorbeeld een bijlage met virus door Microsoft Exchange worden hersteld nadat een voorgeschakelde mailscanner er geen bijlage in kon ontdekken.
Nee ik ben geen ontwikkelaar en ook heb ik geen account op hun bug tracker het is voor mij gewoon publiekelijk inzichtbaar, ik kan de site gewoon openen met Chrome en Safari. Wel kan ik even een update geven mocht niemand bovenstaande URL kunnen openen:
De bug die als urgent werd bestempeld binnen Mozilla vanmiddag is opgelost en staat momenteel gereed voor test. Het ging om een module JS Mime die een zogenaamde null-byte of wel een soort van spatie verkeerd doorgaf waardoor de verwerking naar de GUI zeg maar niet goed ging.
Als ik het goed begrijp zal de mailclient na de patch is doorgedrukt is de e-mails met een 0 byte character wel binnen komen maar het hele from veld zal vervangen worden met de tekst "Invalid" of iets dergelijks. Hieronder de laatste reacties van de bug tracker:
-------------
Ben Bucksch (:BenB) (Reporter) -
Comment 3 • 4 hours ago
@Jörg, as I said, we should simply strip the null byte. Not replace it.
---------
Ben Bucksch (:BenB) (Reporter) -
Comment 4 • 4 hours ago
If we replace it, I would consider it an active attack, and I'd replace the *entire* local part with "[invalid]". No legitimate email address contains null bytes, so we should proactively protect the user.
----------------
Jorg K (GMT+1) (Assignee) -
Comment 5 • 44 minutes ago
Created attachment 8935130 [details] [diff] [review]
jsmime.patch - WIP
Here's your fix.
Note that is doesn't work when the message is already in the mail store since the old header will be served by Mork from the DB to the UI.
I need to add some tests.
---------------
Jorg K (GMT+1) (Assignee) -
Comment 6 • 17 minutes ago
Created attachment 8935141 [details] [diff] [review]
jsmime.patch (v2)
Final fix with test. Anyone can review ;-) First in, best dressed.
De bug die als urgent werd bestempeld binnen Mozilla vanmiddag is opgelost en staat momenteel gereed voor test. Het ging om een module JS Mime die een zogenaamde null-byte of wel een soort van spatie verkeerd doorgaf waardoor de verwerking naar de GUI zeg maar niet goed ging.
Als ik het goed begrijp zal de mailclient na de patch is doorgedrukt is de e-mails met een 0 byte character wel binnen komen maar het hele from veld zal vervangen worden met de tekst "Invalid" of iets dergelijks. Hieronder de laatste reacties van de bug tracker:
-------------
Ben Bucksch (:BenB) (Reporter) -
Comment 3 • 4 hours ago
@Jörg, as I said, we should simply strip the null byte. Not replace it.
---------
Ben Bucksch (:BenB) (Reporter) -
Comment 4 • 4 hours ago
If we replace it, I would consider it an active attack, and I'd replace the *entire* local part with "[invalid]". No legitimate email address contains null bytes, so we should proactively protect the user.
----------------
Jorg K (GMT+1) (Assignee) -
Comment 5 • 44 minutes ago
Created attachment 8935130 [details] [diff] [review]
jsmime.patch - WIP
Here's your fix.
Note that is doesn't work when the message is already in the mail store since the old header will be served by Mork from the DB to the UI.
I need to add some tests.
---------------
Jorg K (GMT+1) (Assignee) -
Comment 6 • 17 minutes ago
Created attachment 8935141 [details] [diff] [review]
jsmime.patch (v2)
Final fix with test. Anyone can review ;-) First in, best dressed.
Hier een overzicht van de 5 bugs die hieruit onstaan zijn en ik zet gelijk even de huidige status erbij:
Bug 1423432 - From addresses with null character are cut off (opgelost/test)
Bug 1423437 - Do not unescape email addresses (wordt beoordeeld)
Bug 1423439 - Strip highly unusual characters from the email address (wordt beoordeeld)
Bug 1423440 - Remove @ from real name (Dit verzoek is gesloten/Rejected)
Bug 1423444 - Remove domains from real name part (Is nog niks mee gedaan " Pending" )
Aan de discussies in de twee bugs met status beoordeeld, ziet het er naar uit dat de Mozilla ontwikkelaars dit toch wel graag willen oplossen. Ze zijn er alleen nog niet uit hoe het aan te pakken.
Bug 1423432 - From addresses with null character are cut off (opgelost/test)
Bug 1423437 - Do not unescape email addresses (wordt beoordeeld)
Bug 1423439 - Strip highly unusual characters from the email address (wordt beoordeeld)
Bug 1423440 - Remove @ from real name (Dit verzoek is gesloten/Rejected)
Bug 1423444 - Remove domains from real name part (Is nog niks mee gedaan " Pending" )
Aan de discussies in de twee bugs met status beoordeeld, ziet het er naar uit dat de Mozilla ontwikkelaars dit toch wel graag willen oplossen. Ze zijn er alleen nog niet uit hoe het aan te pakken.
Een email-client die geen last had van dit lek, blijkt Oeclassic, https://www.oeclassic.com/
"OE Classic is completely unaffected".
Ik begin steeds meer waardering te krijgen voor deze client.
Simpel en doeltreffend, en ook nog behoorlijk veilig.
De betaalde Pro-versie (2.8) heeft er weer een aantal nieuwe features bij gekregen zie ik.
Men is van plan om het verder uit te bouwen, maar neemt daar wel de tijd voor...
"OE Classic is completely unaffected".
Ik begin steeds meer waardering te krijgen voor deze client.
Simpel en doeltreffend, en ook nog behoorlijk veilig.
De betaalde Pro-versie (2.8) heeft er weer een aantal nieuwe features bij gekregen zie ik.
Men is van plan om het verder uit te bouwen, maar neemt daar wel de tijd voor...
Door Jan-Marten Spit: Sterker, het is ronduit misleidend om dit een 'lek in mailclients' te noemen in de kop van dit artikel, en met die onzorgvuldigheid zet security.nl de leken hier op het verkeerde been. Het is een zwakte in MTAs. Toegegeven, mailclients -kunnen- deze zwakte mitigeren met extra code, maar dat is zoals hierboven ook al meerdere malen terecht opgemerkt, symptoombestrijding.
De titel ("Lek in e-mailclients maakt het mogelijk om afzender te spoofen") is correct.
MTA's controleren (meestal) het juiste adres en ze kunnen een email als geverifieerd doorlaten of markeren. De ontvanger ziet echter in een kwetsbare mail lezer als Thunderbird een geheel ander adres afgeleid uit het "display from" adres, en trekt wellicht de (onjuiste) conclusie dat het de werkelijke verzender is. Dat is natuurlijk niet zo, het is gespoofed d.m.v. een van de exploittechnieken. Zelfs een succesvolle reply naar het valse From: adres is mogelijk.
Het is dus een zwakte in email clients dat de verkeerde email adressen worden getoond. Mail client producenten dienen het dus te herstellen.
Door Anoniem:
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Won't fix is niet een goed antwoord op securityproblemen. Dan heb je wat uit te leggen. Het verbaast me overigens niet van Mozilla, die laten jarenlang overduidelijke problemen zitten omdat er een paar developers met een tekort aan social skills zich willen laten gelden en niet met kritiek kunnen omgaan. Dat soort types komen vaak voor in de open source wereld. "Works for me" is hun adagium.
Door Briolet:
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Mozilla en Opera lieten weten dat ze het probleem niet zullen verhelpen, aangezien het volgens hen om een probleem aan de serverkant gaat.
En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.
Won't fix is niet een goed antwoord op securityproblemen. Dan heb je wat uit te leggen. Het verbaast me overigens niet van Mozilla, die laten jarenlang overduidelijke problemen zitten omdat er een paar developers met een tekort aan social skills zich willen laten gelden en niet met kritiek kunnen omgaan. Dat soort types komen vaak voor in de open source wereld. "Works for me" is hun adagium.
Dit soort mensen werken ook gewoon bij bedrijven hoor.
Kwestie blijft, klopt de implementatie volgens RFC? Daarna, klopt de RFC?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
