Krypteringsgrunder
HTTPS och meddelandekryptering är inte samma sak
Skillnaden mellan att skydda en anslutning och att kryptera ett meddelande innan det lämnar webbläsaren.
Publicerad: 29 mars 2026
Gränser för den aktuella implementationen
Den aktuella klienten krypterar texten i webbläsaren och bär det krypterade innehållet i URL:en. Lösenordet som delas separat finns inte i länken. Det finns ingen applikationsserver som lagrar, hämtar, raderar eller förbrukar meddelanden en enda gång.
Mer sammanhang
Föreställ dig två kuvert.
Det första färdas genom en bevakad tunnel, öppnas på destinationen och lämnas över till kontorspersonalen. Det liknar HTTPS.
Liknelsen är ofullständig. Webbservrar är inte kontor, TLS är ingen tunnel och JavaScript förvandlar gärna enkla liknelser till arkitekturdiagram. Skillnaden är ändå användbar.
Utan HTTPS kan någon på nätverksvägen kanske observera eller ändra trafiken.
Collogue måste använda HTTPS oavsett eventuell ytterligare meddelandekryptering. Webbläsarkryptering som levereras över en opålitlig anslutning kan bytas ut innan den körs.
HTTPS skyddar resan. Applikationen på destinationen kan fortfarande behandla innehållet.
Om den gör det är ett beslut som fattas av applikationen.
Med kryptering i webbläsaren omvandlar sidan klartext till krypterad text innan begäran om att skapa meddelandet skickas.
Det gör inte TLS valfritt. Anslutningen transporterar fortfarande identifierare, krypterad text, applikationskod och driftmetadata. En angripare som kan ändra sidan kan påverka krypteringsprocessen.
En meningsfull säkerhetsgranskning beaktar minst fyra tillstånd.
Klartext finns i avsändarens webbläsare.
Hoten omfattar skadliga tillägg, skript, skadlig kod, personer som tittar över axeln och oavsiktlig kopiering och inklistring.
Begäran kan innehålla klartext eller krypterad text beroende på applikationen.
Klartext finns i mottagarens webbläsare.
Mottagaren kan läsa den – och det kan även tillräckligt privilegierad programvara på enheten.
Ett säkerhetspåstående som bara beskriver ett av dessa tillstånd är ofullständigt.
- kopiera klartext före krypteringen;
- skicka nyckeln till en annan slutpunkt;
- försvaga slumpgenereringen;
- byta ut en algoritm;
- ändra destinationslänken.
Detta är inget argument mot kryptering i webbläsaren. Det är ett argument för exakta hotmodeller, säker leverans, Content Security-kontroller, öppenhet kring källkoden, reproducerbara byggen där det är praktiskt och oberoende granskning.
Klientsidig kryptering kan skapa en annan gräns när applikationen aldrig får meddelandets nyckel.
Kontrollera även här Collogue i stället för att generalisera.
Kan någon på nätverket läsa eller ändra den här anslutningen utan större ansträngning?
I vilken form når meddelandet applikationen?
Vem har det som krävs för att dekryptera det?
Hur länge och hur ofta kommer tjänsten att lämna ut det?
Dessa kontroller kompletterar varandra. Ingen ska ta åt sig äran för de andras skydd.
Nej. HTTPS skyddar den levererade applikationen, begäranden, identifierare och krypterad text mot observation och manipulation på nätverket.
Ja. TLS avslutas normalt hos tjänsten, varefter applikationen behandlar de inskickade värdena.