- Liittynyt
- 22.10.2016
- Viestejä
- 11 756
Siirretty muualta
Sitä, mihin palvelimeen käyttäjä on yhteydessä ei voi kätevästi salauksella piilottaa, koska sen näkee niistä ip-pakettien headereista ja ne tiedot on pakko olla siellä, että paketti voidaan reitittää oikeaan osoitteesen
Nimenomaan tässä mitä ehdotat ei olisi mitään järkeä. Se, että paljastettaisiin, mitä tiedostoja haetaan antaisi salakuuntelijalle hyvin paljon informaatiota, jota salakuuntelijalle todellakaan ei haluta antaa.
Väität että "olisi helppo korjata" kertomatta mitään teknistä tapaa miten se oikeasti toteutettaisiin. Tosiasiassa se ei todellakaan olisi niin helppo korjata.
Tässä ratkotaan nyt melko olematonta ongelmaa. Se, että joku varmennustapa ei ole tuettu ei ole ongelma kuin pellepelottomille jotka haluavat asennevammasyistä käyttää jotain antiikkisia tai itse huonosti koodattuja systeemeitä.
Tässä on periaatteellisella tasolla järkeä, nykyinen tapa sotkea varmennus ja salaus keskenään ja niputtaa ne yhteen on tyhmä, mutta:
Ehdotuksesi vaatisi, että sitä HTTP-protokollaa laajennettaisiin tukemaan niitä varmennustietoja.
Että ratkaisusi on jälleen täysin ristiriidassa ongelmasi kanssa. Haluat ratkoa ongelmaa, että "varmennustapa ei ole kaikkialla tuettu" tuomalla uuden varmennustavan joka ei ole tällä hetkellä missään tuettu.
Sen sijaan että modataan kaikki maailman systeemit tukemaan sinun uutta varmennustapaasi, on järkevämpää että sinä vaan alat tukemaan niitä yleisiä varmennustapoja.
Sen sijaan: Tätä ehdotustasi voisi perustella sillä, että sillä säästettäisiin kaistaa kun saataisiin välityspalvelimet jälleen toimimaan julkiselle datalle, joka halutaan varmentaa.
Eli ehdotuksesi ei ole huono, mutta perustelet sitä täysin väärillä asioilla.
Höpöhöpö. Yksityisyyden kannalta ei ole oleellista, että haenko sivuja facebookista vai instagramista. Mutta yksityisyyden kannalta voi olla hyvin oleellista, että käynkö minä katsomassa sieltä instagramista avaruusrakettien vai pornotähtien kuvia.
Se, että salakuuntelija saa selville IP-osoitteen muttei mitään siitä, mitä sieltä IP-osoitteesta haetaan on oikein järkevä kompromissi.
... mutta tämä on teknisesti paljon raskaampi ratkaisu joka hidastaa selvästi sekä lisää huomattavasti globaalia kaistantarvetta.
Nykyinen oletustoimintatapa on hyvä kompromissi sen yksityisyyden ja nopeuden/kaistantarpeen väliltä.
Valitettavasti sinä meuhkaat asioista, jotka eivät nykymuodossaan ole suuria ongelmia, ja tarjoat tilalle ratkaisuita jotka joko tekevät näistä ongelmista oikeita ongelmia, tai joilla on huomattavat muut haittavaikutukset.
Koko HTTP:n nykyisen salaustavan ongelmana on se, että useimpia käyttötarkoituksia ajatellen se salaus on aivan väärässä paikassa, HTTP- ja TCP-protokollien välissä. Mahdollinen salakuuntelija siis näkee kyllä aivan hyvin DNS-pyynnöt ja sen, mihin palvelimeen internetin käyttäjä on yhteydessä
Sitä, mihin palvelimeen käyttäjä on yhteydessä ei voi kätevästi salauksella piilottaa, koska sen näkee niistä ip-pakettien headereista ja ne tiedot on pakko olla siellä, että paketti voidaan reitittää oikeaan osoitteesen
- ainoastaan itse HTTP-protokolla hyötykuormineen on salattua. Useimmissa käyttötarkoituksissa salauksen voisi aivan hyvin siirtää pykälän ylemmäksi niin, että ei salattaisikaan HTTP-protokollaa, vaan pelkästään sen hyötykuorma.
Nimenomaan tässä mitä ehdotat ei olisi mitään järkeä. Se, että paljastettaisiin, mitä tiedostoja haetaan antaisi salakuuntelijalle hyvin paljon informaatiota, jota salakuuntelijalle todellakaan ei haluta antaa.
Myös koko sertifikaattijärjestelmä on suunniteltu huonosti, koska sertifikaatit assosioidaan vain domain-nimiin ja vieläpä niin, että useilla sertifikaattien myöntäjillä on alidomainienkin kanssa ongelmia. Monessa tapauksessa sivuston ylläpitäjä ehkä haluaisi oman sertifikaatin yhteisellä palvelimella olevalle sivustolleen, jolla ei ole omaa domainia. Tällaisia tapauksia ovat esimerkiksi unix-palvelinten ~käyttäjänimi-hakemistoissa olevat sivustot. Ongelma olisi helppo korjata muuttamalla tapaa, jolla sertifikaatit assosioidaan sisältöön.
Väität että "olisi helppo korjata" kertomatta mitään teknistä tapaa miten se oikeasti toteutettaisiin. Tosiasiassa se ei todellakaan olisi niin helppo korjata.
Paljon permacomputing-ystävällisempi tapa toteuttaa tiedon alkuperän varmennus voisi olla esimerkiksi sellainen, että käytetty varmennustapa salausalgoritmeineen ja allekirjoituksineen olisi kerrottu salaamattoman HTTP:n otsakkeessa, ja itse hyötykuorma olisi sitten aivan normaalisti salaamattomana. Tällöin sisältöön pääsisi helposti käsiksi myös sellaisella asiakaskoneella, joka ei kyseistä varmennustapaa tue.
Tässä ratkotaan nyt melko olematonta ongelmaa. Se, että joku varmennustapa ei ole tuettu ei ole ongelma kuin pellepelottomille jotka haluavat asennevammasyistä käyttää jotain antiikkisia tai itse huonosti koodattuja systeemeitä.
Palvelimenkaan ei varsinaisesti tarvitsisi sitä tukea, vaan tarjottua staattista sisältöä vastaavat tiivisteet digitaalisine allekirjoituksineen voivat olla staattisesti palvelimen kiintolevyllä tiedostoissa, joista ne sitten liitetään HTTP:n vastausotsakkeeseen. Niitä ei siis laskettaisi dynaamisesti joka ikistä HTTP-pyyntöä varten. Itse staattista sisältöähän ei ole mitään syytä salata, koska jokainen voi sen joka tapauksessa nähdä täysin samanlaisena vierailemalla sivustolla itse.
Tässä on periaatteellisella tasolla järkeä, nykyinen tapa sotkea varmennus ja salaus keskenään ja niputtaa ne yhteen on tyhmä, mutta:
Ehdotuksesi vaatisi, että sitä HTTP-protokollaa laajennettaisiin tukemaan niitä varmennustietoja.
Että ratkaisusi on jälleen täysin ristiriidassa ongelmasi kanssa. Haluat ratkoa ongelmaa, että "varmennustapa ei ole kaikkialla tuettu" tuomalla uuden varmennustavan joka ei ole tällä hetkellä missään tuettu.
Sen sijaan että modataan kaikki maailman systeemit tukemaan sinun uutta varmennustapaasi, on järkevämpää että sinä vaan alat tukemaan niitä yleisiä varmennustapoja.
Sen sijaan: Tätä ehdotustasi voisi perustella sillä, että sillä säästettäisiin kaistaa kun saataisiin välityspalvelimet jälleen toimimaan julkiselle datalle, joka halutaan varmentaa.
Eli ehdotuksesi ei ole huono, mutta perustelet sitä täysin väärillä asioilla.
Ylipäätään tuo salausprotokollan sijoittaminen protokollapinossa HTTP- ja TCP-protokollien väliin palvelee hyvin lähinnä tiettyjä harvoja käyttötarkoituksia, joista yksi nyt sattuu olemaan verkkopankit. Yksityisyyttähän se ei juuri paranna syystä, jonka jo ensimmäisessä kappaleessa kerroinkin.
Höpöhöpö. Yksityisyyden kannalta ei ole oleellista, että haenko sivuja facebookista vai instagramista. Mutta yksityisyyden kannalta voi olla hyvin oleellista, että käynkö minä katsomassa sieltä instagramista avaruusrakettien vai pornotähtien kuvia.
Se, että salakuuntelija saa selville IP-osoitteen muttei mitään siitä, mitä sieltä IP-osoitteesta haetaan on oikein järkevä kompromissi.
Yksityisyyden kannalta parempi ratkaisu olisi salata koko IP-protokolla, minkä monet VPN-palvelut tekevätkin.
... mutta tämä on teknisesti paljon raskaampi ratkaisu joka hidastaa selvästi sekä lisää huomattavasti globaalia kaistantarvetta.
Nykyinen oletustoimintatapa on hyvä kompromissi sen yksityisyyden ja nopeuden/kaistantarpeen väliltä.
Valitettavasti näitä ilmiselviä ongelmakohtia ei jostain syystä monikaan näytä haluavan korjata, vaan käyttävät näitä (aivan keinotekoisesti aiheutettuja) ongelmia perusteluna milloin minkäkin asian tai käyttötavan kieltämiselle. Varsinkin kaikenlainen itse tekeminen nähdään uhkana.
Valitettavasti sinä meuhkaat asioista, jotka eivät nykymuodossaan ole suuria ongelmia, ja tarjoat tilalle ratkaisuita jotka joko tekevät näistä ongelmista oikeita ongelmia, tai joilla on huomattavat muut haittavaikutukset.
Viimeksi muokattu: