Mozilla schakelt tls 1.0 en 1.1 uit in Firefox Nightly

Mozilla heeft tls 1.0 en 1.1 uitgeschakeld in de Nightly-versie van zijn browser Firefox. De bedoeling is dat de verouderde encryptiestandaarden vanaf maart volgend jaar, in de stabiele versie, niet meer werken.

Mozilla had al eerder aangekondigd dat het tls 1.0 en 1.1 zou uitschakelen in zijn browser en vanaf nu accepteert de testversie van Firefox geen verbindingen via de verouderde standaarden. Gebruikers krijgen dan een foutmelding te zien. De bedoeling was dat Firefox Nightly vanaf oktober tls 1.0 en 1.1 zou uitschakelen, maar dat is dus iets eerder gebeurd, zegt Mozilla.

Er zijn weinig problemen te verwachten, omdat vorig jaar al 94 procent van de sites over was op tls 1.2 en 1.3, die alle grote browsers blijven ondersteunen. Sites die nog niet over zijn, zouden dat snel moeten doen. Tls staat voor transport layer security en is een standaard voor de versleuteling van webverkeer. De eerste versie van tls dateert van ongeveer twintig jaar geleden. Behalve Mozilla zullen andere browserbouwers ook stoppen met de ondersteuning van tls 1.0 en 1.1, waaronder Google, Apple en Microsoft.

Reacties (13)

[Rudie_V]

Zelf al te configureren via about:config:
http://kb.mozillazine.org/Security.tls.version.*
security.tls.version.min;3

Of user.js
user_pref("security.tls.version.min", 3);

[Reactie gewijzigd door Rudie_V op 23 juli 2024 13:43]

[CAPSLOCK2000]

We zullen wel hard door moeten zetten met TLS1.3.
Momenteel is TLS1.2 eigenlijk de enige variant die breed ondersteunt wordt. Mocht er een groot gat in TLS1.2 gevonden worden (en dat is altijd en op ieder moment mogelijk) dan hebben we een groot probleem.

We kunnen eigenlijk niet meer wachten met het uitschakelen van TLS1.0 en TLS1.1, maar de ondersteuning voor TLS1.3 is nog erg beperkt. Heel gek is dat niet, de standaard is pas anderhalf jaar oud, maar lastig is het wel. Het komt er dus op neer dat veel van onze software alleen met TLS1.2 kan werken. Als er iets mis gaat is er voor veel software geen alternatief.

Eigenlijk zou de volgende beveiligingsstandaard ook al klaar moeten staan. Het liefst zou ik nu al beginnen met de invoer van TLS1.4, maar daar heb ik nog nooit van gehoord. Er is vast wel iemand aan het werk, maar het zal nog wel jaren duren voor daar iets uit komt. Als er in de tussentijd een gat gevonden wordt in TLS1.2 zitten we weer in hetzelfde schuitje waarin de hele wereld afhankelijk is van één protocol.

[Darkstriker]

Het probleem daarmee is natuurlijk dat het implementeren en onderhouden van meerdere standaarden tegelijkertijd enorm kostbaar is. Er zijn wel meer standaarden die in feite een soort SPF vormen op het internet, net als TLS. Er zijn in het verleden wel vaker grote beveiligingsgaten gevonden maar geen daarvan heeft uiteindelijk tot een ineenstorting geleid. Schade was er uiteraard wel, maar ik zou niet durven gissen of die groter was dan de extra kosten van de nodige redundantie om de schade te voorkomen.

[Keypunchie]

Zelf al een tijdje uit gehad, maar toch irritant als een van je favoriete sites verouderde TLS gebruikt. Heb hun destijds wel gecontact, maar de prio is vaak 0 bij beheerders van sites waar het geld niet direct via e-commerce wordt verdiend.

Ben dus erg blij met dit initiatief, want alleen dit krijgt die laatste paar procent echt in beweging.

En dat terwijl dit helemaal niet zo ingewikkeld is. Een kleine aanpassing in je webserver instellingen.

[DDX]

Soms niet even kleine aanpassing omdat de server/device gewoon geen tls1.2 support.
Ik noem bijvoorbeeld RedHat Enterprise 5, die zit nog in extended support maar tls1.2 support gaat RedHat niet meer inbouwen.

Dan kan je zelf openssl/apache ed gaan compilen maar dan val je weer buiten de RedHat support.

[FreezeXJ]

Tuurlijk, maar misschien wordt het dan ook tijd om eens aan een server-upgrade te denken. Je hoeft niet heel erg actief bij te blijven, maar inmiddels verwacht ik dat eigenlijk iedereen op RHEL7 zit, behalve wat oudjes die niet meer in ontwikkeling zijn (of heel druk aan het plannen hoe ze modern kunnen doen) en op RHEL6 leven.

[Keypunchie]

RHEL 5 heeft nog maar voor een jaar (extended) support. Voor een webhost zou je daar sowieso al een paar jaar geleden aan vervanging hebben moeten gaan denken.

[CAPSLOCK2000]

Ik ben blij dat Firefox deze stap neemt en ik hoop dat "we" (als samenleving) deze keer doorduwen.
Het probleem met dit soort veranderingen is altijd dat er nog oude sites/applicaties zijn die niet meer worden onderhouden. Het is maar een klein percentage, maar als het net de site is die jij veel nodig hebt, dan is het erg lastig. Meestal geven mensen dan de schuld aan hun eigen webbrowser, niet aan de site. Met een andere browser werkt de site immers wel nog, dus dan zal het wel aan Firefox liggen. Meestal is er wel een backwards-compatibility optie maar dat is te lastig voor de meeste gebruikers.
Eigenlijk zou je dan moeten besluiten om zo'n site niet meer te gebruiken, maar zo werken mensen niet. Features winnen het meestal van security.

* CAPSLOCK2000 gebruikt zelf ook nog altijd een site die wachtwoorden via HTTP verstuurt omdat ik nog geen acceptabel alternatief heb gevonden.

[wica]

Het probleem is, als jij je server wel netjes up to date houd en verouderde TLS uitschakelt. Dat je dan kans hebt, dat je klanten gaan klagen, omdat ze devices gebruiken, die het niet ondersteunen.

Vandaag de dag, hebben wij nog wel eens last van een klant van een klant, die geen SNI ondersteund.
Mijn persoonlijke mening, is dan pech voor die klant van de klant. Maar zakelijk wordt er niet altijd zo tegen aangekeken. Ook internet radio devices van rond de 2008, zullen geen TLS 1.2 ondersteunen.

Nog maals, persoonlijk ben ik er voor deze devices geen dienstverlening meer te bieden, maar zakelijk is dat spijtig genoeg anders.

[Jeoh]

De klant van de klant zal dan waarschijnlijk nog op Windows XP met IE draaien. Die kan dan Chrome 47 installeren om alsnog bij de website te kunnen komen.
Grootste deel van het TLS 1.0 / 1.1 verkeer bij ons was simpelweg API calls die by default TLS 1.0 gebruiken. Het aantal 'echte' gebruikers was minimaal. Aanzetten van TLS 1.3 gaf ook een grappig effect, binnen een dag was 35% van het verkeer TLS 1.3 ipv 1.2

[Balance]

Op Tweakers kan je met TLS 1.3 verbinden sinds mei 2019 (Development-iteratie #155). Chrome 77 geeft bijvoorbeeld het gebruik van de volgende protocollen aan:

The connection to this site is encrypted and authenticated using TLS 1.3, P-256, and AES_256_GCM.

De buren bij Hardware.Info gebruiken nog TLS 1.2.

The connection to this site is encrypted and authenticated using TLS 1.2, ECDHE_RSA with P-256, and AES_256_GCM.

Edit: Aantal andere populaire websites (Chrome 77):

• Wikipedia.org: TLS 1.2, ECDHE_ECDSA with X25519, and CHACHA20_POLY1305.
• Google.com: QUIC, X25519, and AES_128_GCM.
• YouTube.com: QUIC, X25519, and AES_128_GCM.
• Reddit.com: TLS 1.2, ECDHE_RSA with X25519, and AES_128_GCM.
• Twitter.com: TLS 1.2, ECDHE_RSA with P-256, and AES_128_GCM.
• Facebook.com: TLS 1.3, X25519, and AES_128_GCM.

Complimenten dus voor het ontwikkelteam van Tweakers door voor te lopen op veel grote spelers!

[Reactie gewijzigd door Balance op 23 juli 2024 13:43]

[Jeoh]

Tweakers ondersteunt dan weer geen Poly1305-ChaCha20, wat jammer is voor de mobiele gebruikers. Ook nog een hoop zwakke ciphers die je eigenlijk altijd wel zonder problemen kan uitzetten.

[JerX]

Er zijn weinig problemen te verwachten, omdat vorig jaar al 94 procent van de sites over was op tls 1.2 en 1.3, die alle grote browsers blijven ondersteunen

Die ervaring heb ik niet, vooral niet in de zakelijke omgeving. Wat opvalt is dat overheden wereldwijd de boel zeker niet op orde hebben. Al helemaal niet in China.. maar goed das geen verassing.