Basis van versleuteling
HTTPS en berichtversleuteling zijn niet hetzelfde
Het verschil tussen een verbinding beschermen en een bericht versleutelen voordat het de browser verlaat.
Gepubliceerd: 29 maart 2026
Grenzen van de huidige implementatie
De huidige client versleutelt tekst in de browser en draagt de versleutelde inhoud in de URL. Het apart gedeelde wachtwoord staat niet in de link. Er is geen applicatieserver die berichten opslaat, ophaalt, verwijdert of als eenmalig bericht verwerkt.
Verdere context
Stel u twee enveloppen voor.
De eerste wordt door een bewaakte tunnel vervoerd, op de bestemming geopend en aan het personeel van het kantoor overhandigd. Dat lijkt op HTTPS.
De analogie is onvolmaakt. Webservers zijn geen kantoren, TLS is geen tunnel en JavaScript verandert eenvoudige analogieën graag in architectuurdiagrammen. Toch is het onderscheid nuttig.
Zonder HTTPS kan iemand op het netwerkpad het verkeer mogelijk bekijken of wijzigen.
Collogue moet HTTPS gebruiken, ongeacht eventuele extra berichtversleuteling. Browsercryptografie die via een onbetrouwbare verbinding wordt aangeleverd, kan vóór uitvoering worden vervangen.
HTTPS beschermt de reis. De applicatie op de bestemming kan de inhoud nog steeds verwerken.
Of dat gebeurt, is een beslissing van de applicatie.
Bij versleuteling in de browser zet de pagina platte tekst om in versleutelde tekst voordat het verzoek om het bericht te maken wordt verzonden.
Dat maakt TLS niet optioneel. De verbinding vervoert nog steeds identificatoren, versleutelde tekst, applicatiecode en operationele metadata. Een aanvaller die de pagina kan wijzigen, kan het versleutelingsproces beïnvloeden.
Een zinvolle beveiligingsbeoordeling kijkt naar minstens vier toestanden.
De platte tekst bestaat in de browser van de afzender.
Risico’s zijn onder meer kwaadaardige extensies, scripts, malware, meekijken en per ongeluk kopiëren en plakken.
Het verzoek kan platte tekst of versleutelde tekst bevatten, afhankelijk van de applicatie.
De platte tekst bestaat in de browser van de ontvanger.
De ontvanger kan die lezen – en voldoende geprivilegieerde software op dat apparaat ook.
Een beveiligingsclaim die maar één van deze toestanden bespreekt, is onvolledig.
- platte tekst vóór versleuteling kopiëren;
- de sleutel naar een ander eindpunt sturen;
- de generator voor willekeur verzwakken;
- een algoritme vervangen;
- de bestemmingslink wijzigen.
Dit is geen argument tegen browsercryptografie. Het is een argument voor nauwkeurige dreigingsmodellen, veilige implementatie, Content-Security-maatregelen, transparantie van de broncode, reproduceerbare builds waar dat praktisch is en onafhankelijke beoordelingen.
Versleuteling aan de clientzijde kan een andere grens creëren wanneer de applicatie de berichtsleutel nooit ontvangt.
Ook hier geldt: controleer Collogue in plaats van algemene aannames te doen.
Kan iemand op het netwerk deze verbinding ongemerkt lezen of wijzigen?
In welke vorm bereikt het bericht de applicatie?
Wie beschikt over wat nodig is om het te ontsleutelen?
Hoe lang en hoe vaak geeft de dienst het terug?
Deze maatregelen vullen elkaar aan. Geen ervan mag de verdienste van een andere maatregel opeisen.
Nee. HTTPS beschermt de geleverde applicatie, verzoeken, identificatoren en versleutelde tekst tegen manipulatie en observatie op het netwerk.
Ja. TLS wordt normaal gesproken bij de dienst beëindigd; daarna verwerkt de applicatie de verzonden waarden.