Salauksen perusteet
HTTPS ja viestien salaus eivät ole sama asia
Yhteyden suojaamisen ja viestin salaamisen ero ennen kuin viesti poistuu selaimesta.
Julkaistu: 29. maaliskuuta 2026
Nykyisen toteutuksen rajat
Nykyinen asiakas salaa tekstin selaimessa ja kuljettaa salatun sisällön URL-osoitteessa. Erillään jaettu salasana ei kuulu linkkiin. Sovelluspalvelinta, joka tallentaisi, hakisi, poistaisi tai käyttäisi viestejä vain kerran, ei ole.
Lisää taustaa
Kuvittele kaksi kirjekuorta.
Ensimmäinen kulkee valvotun tunnelin läpi, avataan määränpäässä ja luovutetaan toimistohenkilöstölle. Se muistuttaa HTTPS:ää.
Vertaus on puutteellinen. Verkkopalvelimet eivät ole toimistoja, TLS ei ole tunneli ja JavaScript muuttaa yksinkertaiset vertaukset mielellään arkkitehtuurikaavioiksi. Ero on silti hyödyllinen.
Ilman HTTPS:ää joku verkon varrella voisi ehkä tarkkailla tai muuttaa liikennettä.
Colloguen on käytettävä HTTPS:ää riippumatta mahdollisesta viestin lisäsalauksesta. Epäluotettavan yhteyden kautta toimitettu selaimen salaus voidaan vaihtaa ennen sen suorittamista.
HTTPS suojaa matkan. Määränpään sovellus voi silti käsitellä sisällön.
Jos se tekee niin, kyse on sovelluksen tekemästä päätöksestä.
Selaimessa tehtävässä salauksessa sivu muuttaa selkotekstin salaustekstiksi ennen kuin viestin luomista koskeva pyyntö lähetetään.
Se ei tee TLS:stä valinnaista. Yhteys kuljettaa edelleen tunnisteita, salaustekstiä, sovelluskoodia ja käyttömetatietoja. Hyökkääjä, joka pystyy muuttamaan sivua, voi vaikuttaa salausprosessiin.
Mielekäs turvallisuusarviointi ottaa huomioon vähintään neljä tilaa.
Selkoteksti on lähettäjän selaimessa.
Uhkiin kuuluvat haitalliset laajennukset, komentosarjat, haittaohjelmat, olan yli katsovat henkilöt sekä tahaton kopiointi ja liittäminen.
Pyyntö voi sisältää selkotekstiä tai salaustekstiä sovelluksesta riippuen.
Selkoteksti on vastaanottajan selaimessa.
Vastaanottaja voi lukea sen — ja myös riittävän etuoikeutettu laitteen ohjelmisto voi tehdä sen.
Turvallisuusväite, joka kuvaa vain yhtä näistä tiloista, on puutteellinen.
- kopioida selkotekstin ennen salausta;
- lähettää avaimen toiseen päätepisteeseen;
- heikentää satunnaisuuden tuottamista;
- vaihtaa algoritmin;
- muuttaa kohdelinkkiä.
Tämä ei ole argumentti selaimessa tehtävää salausta vastaan. Se on argumentti täsmällisten uhkamallien, turvallisen toimituksen, Content Security -kontrollien, lähdekoodin läpinäkyvyyden, käytännöllisten toistettavien koontiversioiden ja riippumattoman auditoinnin puolesta.
Asiakaspuolen salaus voi luoda toisen rajan, kun sovellus ei koskaan saa viestin avainta.
Tarkista tässäkin Collogue sen sijaan, että yleistät.
Voiko joku verkossa lukea tai muuttaa tätä yhteyttä ilman suurempaa vaivaa?
Missä muodossa viesti saapuu sovellukselle?
Kenellä on tarvittava tieto sen salauksen purkamiseen?
Kuinka pitkään ja kuinka usein palvelu luovuttaa sen?
Nämä tarkistukset täydentävät toisiaan. Mikään niistä ei saa ottaa kunniaa muiden suojauksesta.
Ei. HTTPS suojaa toimitettua sovellusta, pyyntöjä, tunnisteita ja salaustekstiä verkossa tapahtuvalta tarkkailulta ja manipuloinnilta.
Kyllä. TLS päättyy yleensä palvelussa, minkä jälkeen sovellus käsittelee lähetetyt arvot.