End-to-endversleuteling is een extra laag, geen vrijbrief om TLS-waarschuwingen te negeren of gemanipuleerde code te vertrouwen.
TLS en end-to-endversleuteling creëren twee verschillende grenzen. Die grenzen zijn ook belangrijk bij het beoordelen van VPN’s en proxy’s. TLS beschermt doorgaans de verbinding tussen je apparaat en de dienst; correcte, geauthenticeerde end-to-endversleuteling beschermt de gespreksinhoud tot aan het apparaat van de ontvanger. De TLS-laag kunnen lezen betekent niet noodzakelijk dat ook de end-to-endversleutelde inhoud leesbaar is, maar daaruit volgt niet dat TLS-beveiliging onbelangrijk is.
Als een tussenpartij de beveiligde verbinding kan beëindigen, kan die mogelijk niet alleen de overgedragen gegevens bekijken, maar ook antwoorden of de code van de webapp wijzigen. Daarom is “TLS omzeilen met LVR1” geen geschikte beschrijving van de beveiliging van een berichtenapp.
Hoe maakt een rootcertificaat inspectie mogelijk?
Bij een HTTPS-verbinding controleert het apparaat de certificaatketen van de server en de hostnaam. Als een tussenpartij een certificaat presenteert dat de app geldig vindt, kan die twee afzonderlijke verbindingen opzetten: één met de gebruiker en één met de echte server. De tussenpartij is dan het eindpunt van een van de TLS-verbindingen, niet een afluisteraar die de versleuteling heeft gekraakt door alleen naar pakketten te kijken.
Alleen een willekeurig certificaat installeren is niet genoeg; de app moet het vertrouwen en ook de verbindingscontroles moeten slagen. De Android-documentatie over netwerkbeveiligingsconfiguratie legt uit dat het vertrouwensbeleid per app kan verschillen. Apps die Android 7.0 of hoger als doelplatform hebben, vertrouwen standaard geen door gebruikers toegevoegde certificaten, tenzij ze anders zijn geconfigureerd.
Dit is een algemeen technisch mechanisme. Zonder bewijs kun je er geen conclusies uit trekken over een specifieke provider, een land of een incident. Een storing of filtering alleen bewijst niet dat TLS met succes is geïnspecteerd.
Wat is zichtbaar als TLS wordt geopend?
| Soort gegevens of situatie | Mogelijk gevolg van TLS-inspectie |
|---|---|
| Inhoud die alleen door HTTPS wordt beschermd | Een vertrouwde tussenpartij kan mogelijk de leesbare tekst zien |
| Een bericht dat al met de geldige sleutel van de ontvanger is versleuteld | De tussenpartij ziet doorgaans versleutelde tekst, niet de berichttekst |
| Routeringsgegevens, sessiegegevens of aanvullende verzoeken | De mate van blootstelling hangt af van het formaat en het ontwerp van de dienst |
| Webappcode die via dezelfde route binnenkomt | Wijziging van de code kan de beveiliging van het eindpunt bedreigen |
| De dienst is onbereikbaar of verkeer wordt geblokkeerd | Versleuteling alleen herstelt de verbinding niet |
De inhoudsbescherming van E2EE hangt ook af van de authenticiteit van de sleutel van de ontvanger en de integriteit van de software aan beide kanten. Als een aanvaller de oorspronkelijke sleutel vervangt of de app manipuleert die het bericht vóór de versleuteling ziet, is alleen de aanwezigheid van AES of ML-KEM niet voldoende.
Waarom heeft de webversie betrouwbare TLS nodig?
Een webapp ontvangt uitvoerbare code doorgaans van de server. Kwaadaardige code kan vóór versleuteling of na ontsleuteling toegang tot de inhoud krijgen. End-to-endversleuteling kun je niet los beoordelen van de manier waarop code wordt geleverd en uitgevoerd.
Ook bij een geïnstalleerde versie zijn de authenticiteit van het pakket, updates en de integriteit van het besturingssysteem belangrijk. Pakketondertekening en hashcontrole zijn nuttig, maar vormen geen volledige beveiligingstest van de app. Het dreigingsmodel van Livara stelt ook dat als een aanvaller zowel het bestand als de weergegeven hash wijzigt, een overeenkomende hash op zichzelf de authenticiteit niet bewijst.
Wat claimt Livara?
Volgens de beveiligingsdocumentatie van Livara gebruiken directe berichten LVR1 en compatibele privégroepen LGS1. De documentatie beschrijft de combinatie van P-256 en ML-KEM-768 en de versleuteling van berichtinhoud. Dit zijn productclaims, geen resultaten van een onafhankelijke audit in dit artikel.
Dezelfde pagina vermeldt ook dat routeringsmetadata behouden blijven en dat publicatiekanalen openbaar zijn. De juiste conclusie is dus niet dat “alle informatie verborgen is” of dat “geen vertrouwen in het netwerk nodig is”. De conclusie is dat bescherming van privé-inhoud apart moet worden beoordeeld van de verbinding, sleuteloverdracht, appcode en metadata.
Wat moet je doen bij een certificaatwaarschuwing?
- Negeer een waarschuwing van de browser of app niet om een gevoelig gesprek voort te zetten.
- Controleer de datum van het apparaat en het exacte adres van de dienst; niet elke certificaatfout is een aanval.
- Gaat het om een zakelijk beheerd apparaat, vraag dan de bevoegde beheerder naar het beheerbeleid en de geïnstalleerde certificaten; wijzig beheerde instellingen niet op eigen initiatief.
- Installeer geen certificaat of profiel alleen omdat een onbekend bericht dat vraagt.
- Vergelijk bij gevoelige gesprekken de sleutelvingerafdruk via een onafhankelijk kanaal met je gesprekspartner; sleutelcontrole vervangt het oplossen van een TLS-waarschuwing niet.
Veelgestelde vragen
Lost een VPN al deze problemen op?
Nee. Een VPN kan veranderen waar verkeer wordt waargenomen, maar herstelt niet automatisch een besmet apparaat, een kwaadaardig vertrouwd certificaat of gemanipuleerde webcode.
Is authenticatie zonder een wachtwoord te versturen voldoende?
Nee. Het authenticatieprotocol, sessiebeheer en berichtversleuteling hebben verschillende functies. Een valse inlogpagina of kwaadaardige code kan de invoer van de gebruiker al onderscheppen voordat het protocol wordt uitgevoerd.
Praktisch uitgangspunt: E2EE is een waardevolle laag; beschouw het niet als toestemming om certificaten, de authenticiteit van de app of sleutelverificatie te negeren.
