Van hun blog:Thunderbird 52.3.0 is gebaseerd op Firefox 52.3.0 ESR. Nieuwer als 44 en dus geen support voor ArcFour.

Onzin. Thunderbird is gebaseerd op Gecko als basis, net als Firefox (zolang het nog duurt)
Maar Gecko bepaalt de ondersteunde ciphers niet, en de makers van Firefox is een andere groep mensen dan de makers van Thunderbird. Dus blijf ik de vraag stellen: wordt RC4 nog steeds ondersteund in Thunderbird?

JA, zo te zien is RC4 in Thunderbird default nog steeds enabled!!!
Niet wat je misschien zou verwachten.
In ieder geval zijn 4 RC4-ciphers nog steeds enabled in Thunderbird 45.8.0 (uitgekomen in maart 2017).
Of in de paar Thunderbirdversies die hierna nog uitkwamen RC4 er alsnog is uitgegooid, zou erg toevallig zijn.
(geloven is goed, controleren is beter!) ;>)

Dus gebruikers van Thunderbird kunnen het beste even kijken in de Config Editor... van Thunderbird.
Door even "SSL3" in het zoekveld in te vullen, verschijnt een window met ciphers die Thunderbird kan ondersteunen,

Komen er ciphers in voor met RC4 enabled, dan zou ik ze voor de zekerheid zelf maar even uitzetten.
Als je het aan laat staan, vrees ik dat je alleen maar een waarschuwing krijgt als een mailServer RC4 wil gebruiken,
maar waarschijnlijk zal RC4 wél gewoon blijven werken als je die waarschuwing negeert.
Alleen Ciphers die disabled (="false") zijn in Thunderbird, zal Thunderbird nooit gebruiken.

Ook de tripleDES is niet meer van deze tijd en biedt 112 bits security tegenover moderne ciphers minimaal 128.
De meeste mailservers ondersteunen tegenwoordig de betere ciphers ook wel.
Je kan dus overwegen om ook meteen tripleDES op "false" te zetten met een dubbelklik op het cipher.

@17:23 Dus je wilt SSL3 gebruiken, maar dan zonder RC4 en 3DES? Omdat dat veiliger zou zijn?
Wat als je SSL3 mailserver alleen 3DES en DES40 aan kan?

Er is in Config Editor van ThunderBird v52.3.0 geen "rc4" * te vinden, behalve deze setting:

security.tls.unrestricted_rc4_fallback false (standaard)

De "security.ssl3" ciphers zijn rsa, aes, gcm, ede3 (triple des) en chacha20_poly1305.

Dan moet je genoegen nemen met die zwakkere encryptie ciphers of een andere mailserver nemen.
Dat RC4 in versie 52.3.0 er wel uit is gemieterd (bericht 19:19) toont wel aan dat je dat beter niet meer kan gebruiken.


Goed zo (en bedankt voor deze info)
Dat is dan zeker na maart dit jaar nog aangepast en geen probleem meer voor wie v52.3.0 of nieuwer (kunnen en willen) installeren.

Degenen die voorlopig genoodzaakt zijn om v45.8.0 te gebruiken doen er goed aan om wel op de RC4-ciphers te letten.
(zoals bijv. i.g.v. XP zonder ondersteuning van sse, en de nieuwste versie van Tails (3.1) gebruikt ook nog 45.8.0)

Even een topic kaap: Ik zie op https://www.xs4all.nl/service/diensten/email/installeren/algemene-instellingen.htm dat bij XS4All, nog steeds maximaal SSL wordt gebruikt met POP3? Waarover je dus je usernaam en wachtwoord stuurt (met Open WiFi bijvoorbeeld, maar ook als je vanaf een andere provider inlogt).

In de laatste versie van Thunderbird zie ik de mogelijkheid STARTTLS, zou dat niet veel veiliger zijn?

Het is nieuw voor mij dat Thunderbird achter loopt met security op Firefox (NSS). Ik dacht dat als SSL3 uit Firefox gesloopt werd, dat dit dan ook voor Thunderbird zou gelden.

Het probleem met STARTTLS is dit: in geval van een "Man-In-The-Middle" (MITM) -aanval kan de STARTTLS opdracht
weer door de MITM worden verwijderd. Er wordt in dat geval geen beveiligde verbinding opgezet.
Met SSL/TLS krijg je een foutmelding ten teken dat het niet is gelukt om een SSL/TLS verbinding op te zetten tussen
server en client. SSL/TLS is daarom veiliger dan STARTTLS.

Ik vermoedde dat eerst ook, maar als je het niet goed controleert, kun je het nooit zeker weten, vond ik.
Helaas bood in dit geval zelfs de zoekmachine geen direct antwoord op de vraag of RC4 er wel of niet nog steeds in zat.
Alleen de config editor bood uitkomst. En dat moet je maar net weten.
Je bent zomaar uren kwijt met zoeken als je geen weet van deze dingen hebt, maar je leert er wel wat van!

Eens opgezocht in een oude versie, welke waarden bedoel je dan precies concreet?
Dat is niet helemaal duidelijk.
Deze allemaal naar false?

security.ssl3.ecdhe_ecdsa_rc4_128_sha
security.ssl3.ecdhe_rsa_rc4_128_sha
security.ssl3.rsa_rc4_128_md5
security.ssl3.rsa_rc4_128_sha
security.ssl3.rsa_des_ede3_sha

Maar wat is het risico eigenlijk?
Neem aan dat dat security risico alleen aan de orde is als je op een netwerk van een ander zit?

Wat is nou het risico van RC4, nou nou, dan loop je een eind achter zeg.
Beetje forum aan het bevuilen met oude topics?
Het probleem met RC4 is uitgebreid besproken op security.nl en internet. Ga maar zoeken.

Volgens mij wordt hie gewoon een vraag gesteld om welke waarden het concreet gaat, het topic bespreekt het probleem wel maar geeft uiteindelijk geen concreet antwoord. Dus helemaal geen rare vraag en de topic vraag is van relatief recente datum dus mag je er ook op inhaken als je er een vraag over hebt.

Het risico is een minder veilige verbinding met de emailserver (de encryptie is minder sterk en het gebruikte protocol ook).
De kans dat iemand hierdoor zich toegang weet te verschaffen tot je email-logingegevens en/of je mails wordt dus groter.
Dat risico loop je thuis ook, wanneer bijv. je router een keer wordt gehackt.

Is het een groot risico? Nou nee, ik vind zelf van niet in dit geval. Maar security houdt in dat je alle mogelijk risico's probeert te beperken als dat kan, want zelfs als een risico je in je leven 1x zou treffen door onzorgvuldigheid is dat 1x teveel. Mijn motto is: als je het eenvoudig, veilig en privacyvriendelijk kúnt verhelpen zonder ernstige ongewenste bijwerkingen, dan kan je het misschien beter ook maar doen.

security houdt risico bepaling in, als de kans 1 op 60 miljard is dat iemand je RC4 verbinding kan of beter gezegd ZAL gaan hacken dan weet je wat het echte risico is.
Risico is niets voor niets kans X impact en de kans dat je RC4 verbinding van je eigen nietszeggende email account op die manier wordt gehackt is vrijwel nihil..
Als je een miljarden business bent of een politiek orgaan dan is de kans opeens wat groter en zou je je iets meer zorgen moeten maken..
Dat is volgens mij security..niet standaard van qualys/nessus rapportages napraten svp..

Blijft staan : de minimale vraag om welke about:config waarden het concreet ging.

Simpel 'Ja, dat klopt" had al volstaan.
Of
Nee. het zijn deze waarden ,.. ,.. ,..

Dus, nogmaals, om welke waarden in de about:config ging het nou concreet?

Wat maakt dat nou uit. En je vergeet dat security juist ook vooral preventief moet zijn: er kwamen misschien in de praktijk nog geen hacks voor met RC4, maar na een onbepaalde tijd kon dat heel anders zijn. Er kwamen steeds meer zwakheden aan het licht bij RC4 en de laatste kwetsbaarheid deed de deur dicht. De theorie bracht kwetsbaarheden aan het licht, en ze hadden weliswaar nog geen concrete voorbeelden waarbij iemand was gehackt, maar dat wilden ze ook liefst voorkomen.
Daarbij waren er zoveel betere alternatieven dat men RC4 ook niet meer zo nodig had zodat men besloot RC4 uit te faseren, bij Firefoxbrowsers om te beginnen in 2016, en om onbekende redenen pas ca. een jaar later uit Thunderbird.
Als je een bijdetijdse Thunderbird versie gebruikt (wat altijd het veiligst is) dan kún je niet eens meer RC4 gebruiken.
Wil je nauwkeuriger weten wat er precies allemaal met RC4 mis is, dan moet je echt op RC4 op internet zoeken, en ook op deze site zijn er berichten over kwetsbaarheden van RC4 geweest en hebben mensen dat geprobeerd nader uit te leggen. Het is onzinnig om dat hier allemaal te herhalen.

Zelf gebruik ik geen oude Thunderbird versie, maar het ziet er uit alsof het klopt.
security.ssl3.rsa_des_ede3_sha is alleen nodig als je een ouderwetse of amateuristische mailserver moet gebruiken.
Je kan het uitzetten ("false") als je altijd sterke encryptie van je verbinding verlangt, en niet te gemakkelijk wilt toestaan wanneer dat niet het geval is. Des loopt daarbij over ssl3 wat ook nog eens een minder veilig protocol is.
(bij RC4 is dat ook zo, maar er bestaan dus ook meerdere problemen met RC4 zelf)
Zie voor verduidelijking van ssl3 problemen bijv. https://www.security.nl/posting/405492/%22Ernstig+SSL-lek+vooral+risico+bij+open+wifi-netwerken%22 en de link daarin naar het topic van Erik van Straten.

Dank voor je antwoord.