Päivän vakoilu-uutinen kertoo, että Britannian GCHQ on ollut jopa aktiivisempi nettivakoilussaan kuin NSA. Sen ei pitäisi olla yllätys kenellekään, ovathan Britannian valvonta- ja vakoilulait muutenkin omaa luokkaansa länsimaiden joukossa. IRA:n terrori on tuottanut lakeja, joita luulisi löytyvän vain diktatuurimaista.
Britannian liittyminen vakoilukerhoon osoittaa todeksi sen, mistä kirjoitin kirjassani jo kolme vuotta sitten (Yksityisyys - turvaa digitaalinen kotirauhasi). Sähköisten kanavien vakoilu on teknisesti helppoa ja kaikki maat tekevät mahdollisuuksiensa mukaan. Myös kirjassa kerrotut suojautumiskeinot ovat edelleen päteviä. Harva oli kiinnostunut niistä kolme vuotta sitten ja harva on kiinnostunut niistä nytkään. Kun käyttäjä saa itse valita, mukavuus vie aina voiton turvallisuudesta.
Hesarin uutisessa on muutama kiinnostava kohta. Jos GCHQ todella pystyy lukemaan yksittäisiä Facebook-viestejä, sillä täytyy olla joko pääsy Facebookin palvelimille tai keino purkaa https-suojattua dataliikennettä. SSL-tekniikassa voidaan käyttää monia symmetrisiä salaimia, joiden avainpituudet ovat 128-256 bittiä. Niitä on tähän asti pidetty turvallisina.
Google, Facebook, Twitter ja monet muut nettipalvelut siirtyivät muutama vuosi sitten salattuihin yhteyksiin, joiden pitäisi estää runkoverkossa tapahtuva vakoilu. Ilmeisesti näin ei ole. Se herättää monia uusia kysymyksiä, joihin toivomme vastauksia Snowdenilta.
Eräs mahdollisuus on, että urkinta onnistuu vain mobiililaitteilla tehtävästä viestinnästä. Tietokoneen selaimen käyttämät juurivarmenteet ja salaustekniikat on helppo auditoida, mutta mobiilisovelluksista tiedämme paljon vähemmän. Onko niissä takaovia? Ovatko puhelimen sisäiset juurivarmenteet varmasti luotettavia?
Tekstiviestien sekä puheluiden (lanka ja mobiili) vakoilu runkoverkosta on lastenleikkiä, sillä operaattorit vastaavat salauksesta ja voivat purkaa sen valtion määräyksestä -- sikäli kun käyttävät salausta lainkaan. PC- ja mobiilisovellukset ovat eri juttu, koska niissä salaus tapahtuu jo omassa koneessa. Tai niin ainakin luulemme.
Kiinnostavin kysymys on kuitenkin tämä: mikä Euroopan valtioista seuraavaksi joutuu vakoilustaan julkisuuden valokeilaan. Puhtaita pulmusia ei ole. Tuskin edes Suomi.
PS. Ei kannata aliarvioida GCHQ:ta. Sen palveluksessa ollut nuori tutkija Clifford Cocks keksi julkisen avaimen salaustekniikan jo 1974, mutta ei voinut julkisesti kertoa työstään. Niinpä muutama vuosi myöhemmin amerikkalaiset Rivest, Shamir ja Adleman saivat kaiken kunnian ja rahat RSA-menetelmän kehittämisestä. Sitä käytämme vielä tänäkin päivänä.
Britannian liittyminen vakoilukerhoon osoittaa todeksi sen, mistä kirjoitin kirjassani jo kolme vuotta sitten (Yksityisyys - turvaa digitaalinen kotirauhasi). Sähköisten kanavien vakoilu on teknisesti helppoa ja kaikki maat tekevät mahdollisuuksiensa mukaan. Myös kirjassa kerrotut suojautumiskeinot ovat edelleen päteviä. Harva oli kiinnostunut niistä kolme vuotta sitten ja harva on kiinnostunut niistä nytkään. Kun käyttäjä saa itse valita, mukavuus vie aina voiton turvallisuudesta.
Hesarin uutisessa on muutama kiinnostava kohta. Jos GCHQ todella pystyy lukemaan yksittäisiä Facebook-viestejä, sillä täytyy olla joko pääsy Facebookin palvelimille tai keino purkaa https-suojattua dataliikennettä. SSL-tekniikassa voidaan käyttää monia symmetrisiä salaimia, joiden avainpituudet ovat 128-256 bittiä. Niitä on tähän asti pidetty turvallisina.
Google, Facebook, Twitter ja monet muut nettipalvelut siirtyivät muutama vuosi sitten salattuihin yhteyksiin, joiden pitäisi estää runkoverkossa tapahtuva vakoilu. Ilmeisesti näin ei ole. Se herättää monia uusia kysymyksiä, joihin toivomme vastauksia Snowdenilta.
Eräs mahdollisuus on, että urkinta onnistuu vain mobiililaitteilla tehtävästä viestinnästä. Tietokoneen selaimen käyttämät juurivarmenteet ja salaustekniikat on helppo auditoida, mutta mobiilisovelluksista tiedämme paljon vähemmän. Onko niissä takaovia? Ovatko puhelimen sisäiset juurivarmenteet varmasti luotettavia?
Tekstiviestien sekä puheluiden (lanka ja mobiili) vakoilu runkoverkosta on lastenleikkiä, sillä operaattorit vastaavat salauksesta ja voivat purkaa sen valtion määräyksestä -- sikäli kun käyttävät salausta lainkaan. PC- ja mobiilisovellukset ovat eri juttu, koska niissä salaus tapahtuu jo omassa koneessa. Tai niin ainakin luulemme.
Kiinnostavin kysymys on kuitenkin tämä: mikä Euroopan valtioista seuraavaksi joutuu vakoilustaan julkisuuden valokeilaan. Puhtaita pulmusia ei ole. Tuskin edes Suomi.
PS. Ei kannata aliarvioida GCHQ:ta. Sen palveluksessa ollut nuori tutkija Clifford Cocks keksi julkisen avaimen salaustekniikan jo 1974, mutta ei voinut julkisesti kertoa työstään. Niinpä muutama vuosi myöhemmin amerikkalaiset Rivest, Shamir ja Adleman saivat kaiken kunnian ja rahat RSA-menetelmän kehittämisestä. Sitä käytämme vielä tänäkin päivänä.
45 kommenttia:
Hollanti
Bundestrojan-Saksa? (Herkullisia Stasi-vertauksia!)
Jos SSL on onnistuttu purkamaan, siinä on sitten pykälää tai paria isommasta uutisesta kyse. Eiköhän SSL ole vielä toistaseksi jäänyt purkamatta ja Briteissä tiedustelu saa käsiinsä vain salaamattoman nettiliikenteen.
SSL on protokolla, jonka sisällä voidaan käyttää eri salaimia (cipher). 40-bittinen RC4-salain murrettiin jo 1995.
No mutta eikös Facebookia ja muita käyttäessä yhteys muodostu käyttäen vain salaimia, joita ei tiettävästi ole pystytty murtamaan.
Tiettävästi ei.
Tosin pari vuotta sitten liikkui huhu, jonka mukaan NSA olisi tehnyt läpimurron AES:n murtamisessa.
Voimme vain arvailla, kunnes Snowden avautuu tästäkin asiasta.
SSL saadaan avattua väärilä juurivarmenteilla (joihin Järvinen viittaa), mutta se edellyttää man-in-the-middle tekniikan käyttöä eli liikenne avataan ja cryptataan uudestaan. Se tuskin on mahdollista noin suurelle datamäärälle. Onko noita yhtiöitä pakotettu luovuttamaan palvelimiensa julkisten avainten yksityiset avaimet (RSA:n private keys)? Jos näin on, ei man-in-the-middleä tarvita, vaan liikenne voidaan avata myöhemmin haluttaesa.
Voisiko NSA/GCHQ tehdä yhteistyötä Verisignin, Thawten ym. kanssa - joko näiden tieten tai tietämättä? Jospa yksityinen avain onkin peräisin suoraan varmenteen tekijältä?
Hieman käsiteltävän asian vierestä, mutta Facebookin tietoturvajohtaja vaihtoi firmaa ja meni NSA:han töihin vuonna 2010 (katso New York Times : http://www.nytimes.com/2013/06/20/technology/silicon-valley-and-spy-agency-bound-by-strengthening-web.html?pagewanted=all&_r=0)
Vielä tuosta yksityisen avaimen luovuttamisesta: Certificate Autohority eli Verisig, Thawte yms. eivät yleensä tiedä sitä private key'tä, joka on jonkun palvelimen julkisen avaimen takana (on toki mahdolista saada varmenne palvelimelle niin, että CA tietää tuon yksityisen avaimen, mutta sitä ei pidetä tyylikkäänä). Palvelimen yksityisen avaimen saaminen edelyttää yhteistyötä palvelimen haltijan kanssa tai hakkerointia. Jos saa palvelimen yksityisen avaimen, ei tarvitse tehdä man-in-the-middleä avatakseen liikenteen.
Jos saa Certificate Authorityn juurivarmenteen yksityisen avaimen, joutuu silti tekemään man-in-the-middlen avatakseen liikenteen.
Jos saa palvelimen yksityisen avaimen, ei tarvitse tehdä man-in-the-middleä avatakseen liikenteen.
Voisiko olla, että osana yhteistyötä FB, Google ym. ovat luovuttaneet palvelinvarmenteidensa yksityiset avaimet NSA:lle - tai ne on urkittu jonkun myyrän tms. toimesta?
Jos https tekisi NSA/GCHQ:n urkinnan tyhjäksi, ne olisivat varmaankin puuttuneet asiaan ja kieltäneet salattuun liikenteeseen siirtymisen. Hmm... mielenkiintoista.
Vielä SSL:m konfiguroimisesta: on mahdollista, että palvelin luo aina uuden Diffie-Hellman avaimen yhteyden muodostuksessa. Tällöin siitä huolimatta, että hyökkääjä tietää palvelimen yksityisen avaimen, on hyökkääjän tehtävä man-in-the-middle (joka siis vaivatonta), mutta on tehtävä reaaliaikaisesti SSL yhteyden muodostuessa. Tällä turvallisemmalla tavalla configuroidur SSL palvelimet ovat kuitenkin hyvin harvinaisia.
@Petteri
SSL:ää tarvitaan luottamuksellisuuden säilyttämiseen, sitä ilman ei ole käytännössä bisnestä verkossa. Se vasta kalliiksi tulisi, erityisesti Lontoon aseman vuoksi kansainvälisessä rahaliikenteessä.
En oikein jaksa uskoa, että kummallakaan, niin kieltämisellä kuin sen paljastumisella että SSL aukeaa heille helposti uskallettaisiin edes leikitellä. Niin isot vahingot siinä helposti syntyisi, oli todellisuus mitä tahansa.
"Puhtaista pulmusista" olen samaa mieltä, niitä ei juuri ole.
Ausseilla on asian tilaa hyvin kuvaava sanonta "There are only two kinds of people, wankers and liers."
Niin tässäkin tapauksessa. On vain valtioita jotka salakuuntelevat ja valehtelijoita.
Chrome selain näyttää käytetyt salaustekniikat SSL:n yhteydessä. Jos tekniikkana on DHE (Diffie-Hellman Ephemeral) tai ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) niin vaikka SSL istunto on nauhoitettu ei sen avaaminen jälkikäteen onnistu vaikka tietäisi palvelimen yksityisen avaimen (ellei sitten ole muita heikkouksia). Klikkaa web-osoitteen vasemmalla puolella olevaa lukkoa nähdäksesi tiedot (yhteys välilehti).
Esim. https://www.luukku.com/luukku käyttää DHE 'tä (mutta yhteyden voinee muodostaa jopa ilman https'ää). Toinen tässä blogissa mainittu web-site Netposti todentaa asiakkaan osoitteessa todentaminen.posti.fi, joka ei käytä ephemeral avainta, joten nauhoitetut todennukset saadaan avattua, jos serverin pitäjä tekee 'yhteistyötä' tai hakkeroidaan.
Aunakin minä olen kuullut, että Nokia ei saanut myyntilupaa esim. puhelimelle Jenkeissä ennen kuin tarvittat avaimet olivat luovutettu NSA:lle.
EFF:llä on pystyttämässä muuten aika hyvää sivustoa vaihtoehtoisista ohjelmistoista, joiden käytöllä voi yrittää välttää tai ainakin vaikeuttaa merkittävästi tietojen keruuta.
Sivusto löytyy täältä: PISM BREAK.
Asioilla on monta puolta. Ise Briteissä asuneena valitettavasti tarvetta on. Viimeinen tuomio on muutaman päivän takaa. Yrittäjiä on jatkuvasti ja paljon on saatu estettyä . Valvonta vain on tärkeä. Se on retuperällä Suomessa.
Käsitykseni on ollut pitkään että pysyttävä tekemään enemmän kuin julkisuuteen kerrotaan.
Kyllä muutkin maat harrastavat, enemmän vähemmän salassa.
Ei tarvitse sanoa "Verisign, Thawte ym" kun ovat samaa firmaa. Olleet jo yli vuosikymmenen. Ja aikaa sitten Symantec osti Verisignin nuo toiminnot.
Eli enemmänkin voisi kauhistella paljonko valtaa on yhdellä firmalla salauksessa ja tietoturvassa sitten...
"Jos https tekisi NSA/GCHQ:n urkinnan tyhjäksi, ne olisivat varmaankin puuttuneet asiaan ja kieltäneet salattuun liikenteeseen siirtymisen. Hmm... mielenkiintoista."
Olihan se kiellettyä. -90 luvulla USA lait kielsi yli 56 bittisen avaimen. Mutta koska vaatimus oli aikamahdoton valvoa ja aiheutti haittaa pankkitoiminnalle siitä luovuttiin.
Ranskan laki kielsi -90 luvun alussa matkapuheluiden salauksen.
Runkoverkossa puhelut ovat salaamattomia eli luotetaan siihen että verkkoon ei ole asiattomilla pääsyä. Ja jos ei luotettaisi pitäisi kuitenkin antaa purkuavaimet sinne toiseen päähän että sen puhelun saa kuunneltavaksi. Televerkko on suunniteltu aikana, jolloin ei ollut mahdollista käyttää mitään avainten vaihtoprotokollia niiden laskennallisen raskauden takia.
En usko että 128 bittisiä salauksia ainakaan rutiinin omaisesti voi avata. Vaikka se murtuisi olisi työmääärä silti sellainen että muutama vieti/kk olisi mahdollista avata. Ja 256 on kaukana tulevaisuudessa.
Hyökkäys tehdään varmasti jommassa kummassa päässä, kun data on salaamatonta
Ja Verisign pyörittää .com palvelua. Se on kaikkein suurin internetissä. Siis Verisign:llä on .com juuripalvellin hallussaan.
Olihan se kiellettyä. -90 luvulla USA lait kielsi yli 56 bittisen avaimen
Vahvat salaukset oli tarkoitettu sotilaskäyttöön, joten niiden maastavientiin tarvittiin lupa. Ranskassa vahva salaus oli kiellettyä siviileiltä myös maan sisällä. Ja NSA kehitti Clipperiä, jossa oli vahva salaus mutta takaportti sen omaan käyttöön : -)
Huvittavaltahan nämä kuulostavat tämän päivän nettimaailmassa. Ne osoittavat, miten nopeaa kehitys on ollut.
En tarkoittanutkaan laillista kieltämistä vaan yhteistyötä. Kun Google ja FB kerran tekevät yhteistyötä NSA:n kanssa, se olisi voinut kieltää näitä tekemästä https-salauksesta oletusarvoa. Koska näin ei tehty, yhteistyötä ei joko ole tai sitten NSA:lla on keino saada tiedot muutenkin -- joko suoraan palvelimilta tai salaus murtaen.
AES:ää tuskin brute-forcella murretaan, mutta sen kryptografit saattavat tuntea jotain uusia analyysimenetelmiä, jolla työmäärää voidaan vähentää. Hieman samalla tavalla kävi aikoinaan DESin kanssa.
@Petteri
Salauksen, jonka joku yksi taho voi purkaa, mutta muut eivät eivätkä aavista että se on purettavissa on valtavasti etua niille jotka kykenevät.
Liittoutuneet luovuttivat Saksalta takavarikoidut Enigmat ym. kansainyhteisön maille, mutta 'unohtivat' kertoa että britit pystyvät purkamaan sen salauksen. Kyse ei ollut vahingosta vaan harkitusta teosta.
Em. seurauksena UKUSA sopimuksessa olevat osapuolet (UK, US, Kanada, Australia ja Uusi-Seelanti) saivat valtavasti hyödyllistä tietoa brittien kautta aina -60 luvun lopulle asti koska em. maat, joille oli annettu purettavissa olevat salaimet käyttöön. Britit eivät itse asiassa kertoneet asiasta edes jenkeillekään vaan hämäsivät, että heillä on myyriä jotka kertovat heille salauksen purkamisella saadut tiedot.
Samalla tavallahan britit hämäsivät Saksalaisia Huffuf asemilla ja ennen kuin syvyyspommittivat Saksalaisten sukelllusveneitä varmistivat, että alueella oli käynyt ja oli nähtävissä tiedustelukone. Näin Saksalaiset ja muut akselivaltojen jäsenet, eivät osanneet epäillä että britit kykenevät lukemaan heidän salattua liikennettään. Kyse oli tarkoin harkitusta harhautuksesta, jota jatkettiin läpi sodan ja vielä sen jälkeenkin.
Joten intialaisilla, afrikan maiden johtajilla ym., joista monet halusivat itsenäistyä luottivat salaimilla suojattuun liikenteeseen täysin täysin. Liikenteen kuuntelun ja salauksen purkamisen myötä britit lukivat siksi kuin avointa kirjaa heidän kommunikaatiotaan, paljolti myös ajatuksen juoksuaan samalla varoen liikaa ottamasta etunojaa ettei huijaus paljastuisi.
Aivan samalla tavalla jos NSA tai kuka tahansa kykenee purkamaan tai pääsee tavalla tai toisella salaamattomiin taustajärjestelmissä oleviin tietoihin käsiksi, se ilman muuta haluaa että tiedot salataan verkossa koska
a) silloin muut valtiolliset toimijat eivät luultavasti pääse tietohin käsiksi ja siitä on heille etua.
b) käyttäjien luottamus välineesen aiheuttaa saman kuin tuossa toisen maailmansodan jälkeisessä Enigma episodissa. Salaa kuuntelevat pääsevät paljon syvempiin salaisuuksiin käsiksi kuin jos viestit olisivat salaamatomia ja keskustelijat välttelisivät puhumasta asioista suoraan ja niiden oikeilla nimillä.
Hyvä tekninen lyhyt artikkeli tuosta nauhoitetun SSL yhteyden avaamisen estämisestä Diffie-Hellman vaidon avulla: http://www.theregister.co.uk/2013/06/26/ssl_forward_secrecy/
Kannattaa lukea jutun lopussa myös hyvät kommentit tuohon artikkeliin.
SSL saadaan avattua väärilä juurivarmenteilla (joihin Järvinen viittaa), mutta se edellyttää man-in-the-middle tekniikan käyttöä eli liikenne avataan ja cryptataan uudestaan. Se tuskin on mahdollista noin suurelle datamäärälle.
Potentiaalinen riskipaikka on palomuurit, jotka korkkaavat SSL-yhteyden juuri MitM-tekniikalla. Näitähän on kai aika yleisesti isommilla organisaatioilla käytössä.
Kun käyttäjä ottaa ensimmäistä kertaa salattua yhteyttä muurin läpi, selain/postiohjelma valittaa tuntemattomasta CA:sta (esim. FortiGATE CA) ja pyytää hyväksymään poikkeuksen. Tämän jälkeen kaikki sujuu automaattisesti ilman, että käyttäjä mistään huomaa SSL-yhteyksiensä olevan murrettuja. Laitoksen omiin koneisiin varmenne lienee asennettu jo valmiiksi.
Selain muodostaa SSL-yhteyden palomuurin kanssa ja palomuuri toisen SSL-yhteyden vaikka pankin kanssa, ja palomuurilla on välissä salaamaton data käsissään. Aika herkullinen paikka NSA:lle asentaa pieni aliohjelma?
Voidaanko edes olla varmoja, että jokin lukuisista CA:sta ei olisi luovuttanut allekirjoitusavaimiaan ison palomuurivalmistajan käyttöön? Tällöin yhteyden murtamisen voisi huomata vain vertaamalla yhteyden vastapuolen sertifikaattia eri yhteyksillä.
@Anonyymi
Potentiaalinen riskipaikka on palomuurit, jotka korkkaavat SSL-yhteyden juuri MitM-tekniikalla. Näitähän on kai aika yleisesti isommilla organisaatioilla käytössä.
...
Hoh hoijaa, löysääpäs hieman foliota niin kiertää veri paremmin päässä :)
SSL:n protokollassa on selkeitä tunnettuja ongelmia, joita yritetään tilkitä kehittämällä sitä, mutta vedit kyllä aika rankasti mutkia suoraksi ja sen vuoksi päädyit aika huimiin uhkiin.
Ei SSL nyt ihan sentään aivan niin rikki ole kuin esitit.
Voit kokeilla ja todeta itse, että juurivarmennetta ei asenneta tuosta vain vierailemalla jollakin sivustolla ja siitä johtuen kuvaamasi uhka siitä, että palomuuri asentaa sen tuosta vain MitM:llä on mahdotonta ainakin yleisimmillä nykyisillä selaimilla ja ohjelmistoilla nykytiedon mukaan.
Opiskelu- ja kokeiluväline varmenteiden kanssa toimimiseen on näppärä työkalu XCA, joka on vapaa avointa koodia oleva pieni varmennepalvelu -ohjelmisto. Sillä pyörittää helposti vaikka pienen yrityksen sisäistä varmennepalvelua omiin tarpeisiin.
SSL terminointi (ssl-offload) on yleinen ominaisuus kaupallisissa palomuureissa ja sovelluskytkimissä, koska sitä tarvitaan kun palomuuri laitetaan palvelimien eteen tietoturvan, kuormantasauksen, skaalautuvuuden, kertakirjautumisen toteuttamiseksi, ylläpidon helpottamiseksi tai jonkun muun hyvän teknisen syyn vuoksi jota sillä tavoitellaan. Palomuuri toimii silloin ns. reverse-proxynä.
Organisaation rajalla ollevissa reunapalomuureissa en kyllä ole kuullut ssl-offloadingia juuri käytettävän, vaikka olen ollut tekemisissä palomuurien kanssa aika kauan.
Microsoftilla on tietääkseni tuote, joka mahdollistaa sen, että kun käyttäjän käyttämässä päätelaitteessa joka on AD:ssa on AD:n juurivarmenne ja palomuurina m$ palomuurituote (TMG?) niin se voidaan konfiguroida tekemään MitM.
Homma toimii käytännössä niin, että selaimella ulos yritettäessä m$ palomuuri luo lennossa palvelinvarmenteen ja allekirjoittaa sen AD:n omalla juurivarmenteella, joka siis on AD:ssa olevissa työasemissa. Näin siksi, että juurivarmenne ei kelpaa palvelinvarmenteesta.
Sen jälkeen m$ palomuuri voi terminoida ssl:n itseensä ja ottaa toisen yhteyden eteenpäin itse käyttäjän tavoittelemaan palveluun.
Silloin tietysti voidaan kuunnella liikennettä tuossa välissä palomuurista, mutta kyseisen virityksen voi havaita siitä että kun katsot selaimesta yhteyden aikana kuka on allekirjoittanut palvelun käyttämän ssl-varmenteen niin varmentajana näkyy olevan AD:n varmenne, eikä vaikkapa joku tunnettu varmentaja joka siellä pitäisi olla ICSI SSL Notaryn mukaan tai EFF SSL Observatoryn mukaan.
Jos käytät selaimena Firefoxia ja pääset asentamaan lisäosia, niin voit käyttää apuna myös Certificate Patrol lisäosaa, niin huomaat paremmin kuin varmenne tai varmentaja vaihtuu.
Tuo lisäosa aiheuttaa oletusasetuksilla vääriä ilmoituksia koska moni kuormanjako- ja tasauspalvelu (CDN) käyttää apuna Anycastia (sama IP ja domainnimi eri puolilla internettiä useaan kertaan).
Kun näissä palveluissa on sitten eri varmenteita ja varmentajienkin toimesta niin niistä tulee huomautuksia kun liikenne eri ajankohtina ohjautuu eri koneelle ja varmenne vaihtuu siksi. No, Google on alkanut itse käyttää omaa varmennepalveluaan ja yhdenmukaistaa varmenteitaan joten siltä osin ongelma vähenee ajan myötä.
@ac sanoi...
Tuossa olet oikeassa sen juurivarmenteen asentamisen kanssa. Se pitää hyväksyä, poislukien keskitetysti ylläpidetyt ympäristöt.
UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.
Toisaalta IE6:ssa oli bugi, joka mahdollisti juurivarmenteiden lisäämisen etänä. Tuolla reiällä toteutettiin muutama hyökkäys.
Nykypäivänä tehdään myös ikäväkyllä jokerivarmenteita eli mikätahansa.domain.com. Tälläisen varmnenteen joutuminen hukkateille on harmillista. Tälläin esim. Iran vakoili Google-hakuja (DigiNotar)
Selainvalmistajat Firefox/IE ja muut poistavat säännöllisesti juurivarmenteita selaimistaan. Esim Trustware, joka alkoi myöntämään alijuurivarmenteita.
SSL:n ongelma on se, että pitää luottaa kolmanteen tahoon, joka voi olla NSA, Kiinanvaltio, Telia-Sonera jne. juurivarmenteet tuntuvat lisääntyvän koko ajan. Kehenkä myöntäjään sinä luotat?
Selaimissa on vielä se ongelma, että yhtenäistä CRL (revocation list) käytäntöä ei ole. Useimmiten myönnettyä huonoksi todettua voimassa olevaa varmennetta ei saada mitätöityä.
Tuossa olet oikeassa sen juurivarmenteen asentamisen kanssa. Se pitää hyväksyä, poislukien keskitetysti ylläpidetyt ympäristöt.
Totta, mutta näppituntuma on sellainen että 99% käyttäjistä hyväksyy selaimen tarjoamat poikkeukset sen kummemmin ajattelematta.
Toteutustavasta varmaan riippuu tarjotaanko asennettavaksi juurivarmennetta (täältä http://fineid.fi/default.aspx?id=332 voi kokeilla kuinka työlästä asentaminen on) vai pitääkö joka SSL-sivulla hyäksyä poikkeus.
Itse olen törmännyt ilmiöön hyvin samantapaisesti kuin tässä IMAPS-yhteydellä: http://bryars.eu/2011/12/stenaline-ssl-mitm-attacks/ IMAPS:n osalta riittää varmaankin poikkeuksen kertahyväksyntä.
UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.
Ts. kuten ylempänä kirjoitin, SSL:n korkkaavat palomuurit ovat todellinen ongelma ja riskipaikka. Luottamukselliseksi tarkoitettu data on välillä täysin ulkopuolisen softan käsiteltävänä.
Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?
On olemassa man-in-the-middle koneita, joihin asennetaan jonkin Certificate Authorityn juurivarmenteen private key (juridisella pakottamisella saatu). Nämä koneet generoivat tarvittavat certificaatit lennossa. Käyttäjä ei huomaa mitään. Laitteita myydään periaatteessa vain viranomaisille yms., mutta voihan niitä esim myös 'kadota'. Asian paljastivat jo 2011 Wall Street Journal (Surveillance Catalog) ja Wikileaks (Spy Files) - kannattaa lukea laitteiden esitteet, on jaksettava kahlata lutteloa läpi ja etsittävä SSL interception laitteita. Palomuurit, jotka käyttävät organisaation omia certficaatteja ja avaavat niiden avulla SSL liikenteen ovat ikään kuin noiden lievempiä versioita.
SSL:n ongelma on se, että pitää luottaa kolmanteen tahoon, joka voi olla NSA, Kiinanvaltio, Telia-Sonera jne. juurivarmenteet tuntuvat lisääntyvän koko ajan. Kehenkä myöntäjään sinä luotat?
Lähtökohtaisesti en tietysti keneenkään muuhun kuin itseeni. Aito luottamus kasvaa sitä tukevien tekojen ja ajan myötä. Sanelemalla sitä ei voi ansaita :)
Olet erittäin oikeassa siinä, että varmentamisen suurin ja polttavin ongelma on siinä, että kuka tahansa juurivarmenteen selaimiin saava voi tehdä varmenteita ihan kenelle hyvänsä, se on selkeästi väärä olettamus ja riskin paikka.
Em. ongelmaa aiotaan korjata jatkossa, mutta siihen menee vielä tietysti aikaa ennen kuin se saadaan käyttöön.
Ja juuri siitä syystä korkeaa turvallisuutta vaadittaessa ensin poistetaan kaikki varmenteet, siis myös juuri-varmenteet. Ja sitten lisätään luotetut ja todennetut juurivarmeteet uudestaan.
Selaimissa on vielä se ongelma, että yhtenäistä CRL (revocation list) käytäntöä ei ole. Useimmiten myönnettyä huonoksi todettua voimassa olevaa varmennetta ei saada mitätöityä.
Totta. Ja esim OCSP joka on yksinkertaisia CRL:iä nopeampi ja parempi tapa todentaa varmenteen voimassaolo on vielä hyvin vajaasti käytetty.
Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?
Tuolla tarkoitetaan ilmeisesti tässä yhteydessä sitä, että esim. weppipalvelimen edessä on laite johon ssl-yhteys päätetään ja se jatkaa sen jälkeen salaamattomana palvelinryppäälle.
Weppipalvelin pystyy n. 5x nopeammin käsittelemään salaamattomia- kuin salattuja -yhteyksiä.
Totta, mutta näppituntuma on sellainen että 99% käyttäjistä hyväksyy selaimen tarjoamat poikkeukset sen kummemmin ajattelematta.
Ja tässä on juuri se syy, miksi tavan käyttäjille ei voi antaa oikeutta asentaa ohjelmia itse työkoneisiin.
Toteutustavasta varmaan riippuu tarjotaanko asennettavaksi juurivarmennetta (täältä http://fineid.fi/default.aspx?id=332 voi kokeilla kuinka työlästä asentaminen on) vai pitääkö joka SSL-sivulla hyäksyä poikkeus.
Eti tainnut ymmärtää mitä tarkoitin, aiemmassa viestissäni.
Jotta ymmärrät mikäs siinä on vaikeaa, niin tehdään koe.
- asenna jonnekin kone & web-palvelu, vuokraa tai lainaa jos ei ole omia koneita.
- viritä koneelle https palvelu.
- luo itse omat varmenteesi testiä varten, käyttäen vaikka edellä mainittua XCA ohjelmistoa, ei tarvitse ostaa mistään muualta.
Hyvä nyt kun olet saanut ekan vaiheen tehtyä, niin kokeile luoda juurivarmenne (CA bitti päällä) ja saada aikaiseksi se, että kun käyttäjä vierailee kyseisessä palvelussa hänelle tarjotaan hyväksyttäväksi _palvelinvarmennetta_ ja samalla ujutat koneeseen juurivarmenteen.
Right, nyt sulla on sitten, jos onnistuit, käyttäjän koneella juurivarmenne. Tee toinen sivusto jonnekin jonka varmenteet allekirjoitat kyseisellä varmenteella.
Kyse ei siis ole siitä, että a) käyttäjälle tarjotaan juurivarmennetta asennettavaksi ja hän sen onnistuu asentamaan vaan b) käyttäjälle tarjotaan asennettavaksi palvelinvarmennetta ja samalla asentuu juurivarmenne.
Väitän, että on vaikeaa ellei mahdotonta. Uskon, että se onnistuu kun näen ja pääsen koneilemaan itse.
Laita vaikka postia Petterille tai jonnekin tänne hänen bloginsa kommenttiin, missä voi käydä kokeilemassa. Odotan mielenkiinnolla onnistutko :)
Itse olen törmännyt ilmiöön hyvin samantapaisesti kuin tässä IMAPS-yhteydellä: http://bryars.eu/2011/12/stenaline-ssl-mitm-attacks/ IMAPS:n osalta riittää varmaankin poikkeuksen kertahyväksyntä.
Kyse on siitä, että kertahyväksynnällä hyväksyt _palvelinvarmenteen_ asentamisen, sen jälkeen asiaksohjelmasi luottaa että olet todentanut että olet yhteydessä oikeaan paikkaan.
Palvelinvarmennehan ei ole juurivarmenne. Ymmärräthän varmasti eron?
UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.
Aivan jos palvelu toimii proxynä, ja ssl:n terminointia edellytetään niin silloin näin on tehtävä. Epäilemättä monet UTM laitteet sitä tukevat. Osaatko mainita jonkun tahon suomessa joka sitä käyttää?
Ts. kuten ylempänä kirjoitin, SSL:n korkkaavat palomuurit ovat todellinen ongelma ja riskipaikka. Luottamukselliseksi tarkoitettu data on välillä täysin ulkopuolisen softan käsiteltävänä.
Näin on jos em. mainitulla tavalla tehdään.
Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?
Se tarkoittaa juuri sitä miltä se kuulostaa.
SSL terminoidaan palomuuriin, kuormantasaimeen, sovelluskytkimeen tms. jonka tarkoituksena on kuvaamassani tapauksessa vapauttaa taustalla oleva palvelin salaamiselta ym. Sovelluskytkimet jotka tekevät em. temppuja osaavat toimia välimuistina, multiplexata satoja yhteyksiä taustapalvelimiin yhdeksi yhteydeksi, uudelleen kirjoittaa headereita, lisätä ja poistaa niitä, uudelleen kirjoittaa URL:n jne. Kaiken tämän tarkoituksena on taata katkeamaton palvelu clientille, nopeuttaa palveluja, mahdollistaa SSO, tasata kuormaa taustalla oleville palvelimille automaattisesti, estää SQL-injektoita, estää henkilötunnuksia, salasanatiedostoja, jne. tietoturvaan liittyviä tietoja vuotamasta ulos mahdollisen sovellushaavoittuvuuden vuoksi, helpottaa taustapalveluiden huoltamista ym. lukemattomia hyödyllisiä asioita palvelun tuottamisessa. Mutta jotta tämä onnistuisi, on purettava SSL ensin edustakoneessa (ts sovelluskytkimessä) ja sitten ohjata luotetussa sisäverkossa (yleensä paljaana) tieto sovelluspalvelimille. Sieltä sitten taas jos lähdetään ulos ei suojatuihin saitteihin salataan uudestaan SSL:llä tms.
Em. on ihan normaalia nykyään ja tämäkin blogisivusto on sellaisen virityksen takana, toki tässä ei nyt ole ssl:ää mulla päällä mutta voisi yhtä hyvin ollakin. Sama juttu pankeissa jne. hiemankin isommissa web-saiteissa. Sovelluskytkimet eivät ole vain WEB-liikennettä varten vaan ne osaavat hyvin monenlaisia protokollia ja kiihdyttävät niitä merkittävästi. Yksi tyypillinen on CIFS joka hyötyy siitä varsin paljon. Myös LDAP, RDP, SSL-VPN ym.
Merkittävimpiä sovelluskytkimien toimittajia ovat esim F5 (Big-IP) ja Citrix (Netscaler).
Niin, siis nykyään lähes kaikki vähänkin isommat saitit ovat sovelluskytkimien takana ja samat laitteet osaavat sitten purkaa SSL:n välistä pois koska siitä on hyötyä palvelujen tuottamisessa.
Käytännössä siis käyttäjän yhteys selaimesta on hyvin usein sovelluskytkimeen ja sitten siitä eteenpäin salaamatonta itse palvelimeen. Palvelin toki salaa liikenteen jos se ottaa uudestaan yhteyden eteenpäin ja väliin laitetaan vielä usein toinen palomuuri.
Em. on toiminta on aivan normaalia kun tehdään kertakirjautuminen (SSO) mahdolliseksi sovelluksiin. Samalla tekniikalla yrityksen sovelluksia siirretään pilveen, niihin tehdään samalla kertakirjautuminen ym.
Sovelluskytkimistä sen verran, että niitä voi olla sitten iso joukko jos on kyse isosta saitista. Ei ole tavatonta, että kyse on 32 sovelluskytkimen active-active klusterista todella isoissa saiteissa, ja näitä voi sitten olla vielä Anycast tekniikalla ripoteltu eri mantereille.
@ac sanoi...
Aivan jos palvelu toimii proxynä, ja ssl:n terminointia edellytetään niin silloin näin on tehtävä. Epäilemättä monet UTM laitteet sitä tukevat. Osaatko mainita jonkun tahon suomessa joka sitä käyttää?
Niin ne terminoivat yhteyden, tarkistavat sisällön ja tekevät uudestaan salauksen ja välittävät sen kohteeseen.
En tuohon pysty vastaamaan, mutta ominaisuus on kytkettävissä päälle lähes kaikissa Suomessa myytävissä laitteissa.
Osa laitteista esim. Sonicwall on tarkoitettu pikkuyrityksiin, joten kyllä noita ominaisuuksia käytetään.
Kaikki eivät tule ajatelleeksi, että tietoturvatuotteet mahdollistavat melko helposti Suomen lain rikkomisen. Tämä koskee palomuureja, ips, url-filtteröintiä ja virustorjunta -tuotteita.
Alla linkkiä siihen juurivarmenteen asentamiseen käsipelillä.
http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404
ja helppotajuinen esitys tuosta ssl:n tarkistamisesta.
http://www.sourcefire.com/security-technologies/network-security/ssl-encryption-decryption
Pitkästi on kommentoitu, mutta yksi asia on tyystiin unohtunut. Palvelimen oma RSA avain on yleensä paljon heikompi kuin 128-256 bittinen symmetrinen avain. On siis paljon järkevämpää murtaa se, kuin yrittää murtaa yksittäisten istuntojen avaimia. Olisi korkea aika siirtä 256-521 bittisiin ECC avaimiin. mm. AES256:n kanssa pitäisi käyttää 15360 bittistä RSA avainta, jotta oltaisiin edes tasoissa. Mieluusti vielä pidempää, koska AES256 avain on sessikohtainen, mutta RSA avain pysyy samana vuoden tai useita palvelimilla.
Vanha referenssi: http://www.nsa.gov/business/programs/elliptic_curve.shtml
Kaikki eivät tule ajatelleeksi, että tietoturvatuotteet mahdollistavat melko helposti Suomen lain rikkomisen. Tämä koskee palomuureja, ips, url-filtteröintiä ja virustorjunta -tuotteita.
Kaikki eivät myöskään varmasti tule ehkä ajatelleeksi, että melkeinpä mitä tahansa esinettä tai laitetta voi käyttää rikkoakseen Suomen Lakeja.
Hieman tarkemin kun ajattelet, niin et edes tarvitse mitään laitteita tai esinettä Lakien rikkomiseen ...
Joten pointtisi on?
Alla linkkiä siihen juurivarmenteen asentamiseen käsipelillä.
http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404
Tuo dokumentti kuvaa aivan standardin prosessin miten Fortigate Managerissa (tuttu ohjelma) olevasta privaatista CA:sta, jonne on luotu oma juurivarmenne, exportataan se ensin työpöydälle ja sitten asennetaan se selaimen kautta Windowsin varmennevarastoon.
Vastauksesi osoittaa, että et taida vielä ymmärtää asiasta kovin paljoa, postailet viitaten huimiin ominaisuuksiin valmistajien dokumenteissa.
Jotta tämä ei menisi aivan vänkäämiseksi, niin laita toimeksi ja näytä käytännössä että onnistuu. Luo Proof-of-Consept* verkkoon ja postaa sitten nähtäville tänne.
*) Esim PoC -näyttö.
- Proxy-purkki, jonka takaa / läpi https:llä vieraillessa vaikka googlen tms. saitilla asentuu itse luomasi CA varmenne.
- OK, se että selain varottaa ekalla yrityksellä väärästä varmenteesta ja kysyy haluatko tallentaa, siihen vastataan YES hyväksytään.
PoC hyväksymiskriteerit:
- Edellisen jälkeen kun vierailee jollain toisella saitilla myös https:llä, niin saitti onkin allekirjoitettu luomallasi varmenteella.
- Varmenteen on oltava nimen omaan CA-varmenne ja sen on asennuttava Varmentajien varmenteiden joukkoon selaimen tai käyttöjärjestelmän varmennevarastossa ja sillä on oltava riittävät luottoasetukset, jotta se voi toimia juurivarmenteena esim. HTTPS liikenteelle.
- Testi on voitavat toistaa jonkun toisen toimesta, siksi sinun tulee dokumentoida tarvittavat laitteet, ohjelmistot tms. mitä käytit sekä tarvittavat toimenpiteet vaihe vaiheelta riittävällä tarkkuudella.
Ja nyt ei muuta kuin tekemään, jään odottelemaan näyttöä. Varmasti myös joku muukin osoittaa kiinnostusta kun teet siitä videon Youtubeen.
Ei siis mitään: Lataa täältä ensin työpöydälle juurivarmenne ja asenna se ... sellaiseen menevä on täysi hölmö kuin Turkulaiseen Virukseen vitsissä tai jonkun muun Troijalaisen vapaaehtoisesti itse asentava yhtä aivoton hölmö.
PoC:n tarkoituksena ei siis ole todistaa, että suuri osa Internetissä surfaavista on naiveja hölmöjä, se ei ole uutinen. Ei ole ollut enää pitkään aikaan.
PoC:n tarkoituksena on osoittaa, että vaatimaton vierailu jollain palvelinsivulla, palvelinvarmenteen hyväksyminen, voi samalla aiheuttaa juurivarmenteen asentumisen.
ja helppotajuinen esitys tuosta ssl:n tarkistamisesta.
Heh, varmasti on olemassa asioita, joita en vielä ole hoksannut ssl:stä 15v sitä päivittäin käytettyäni töissä, pidettyäni CA:ta ja toimittuani varmenteiden hankkijana ja RA:na isohkolle työnantajalleni, mutta kyllä minulla hieman enemmän kuin perusasiat on varsin hyvin hallussa jo tässä vaiheessa :)
@Sami Lehtinen
Hyvä kommentti.
Toinen asia johon kannattaisi kiinittää huomiota on oletusarvona käytetyt heikot salaimet ja konfiguroida ne pois serverien päästä ja jos nyt jollain on vielä SSL 3.0 tai TLS 1.0 vanhempia asiakasohjelmistoissa päällä niin ne pois päältä.
Kuten jo joku aiemmin mainitsi, niin serverin päässä kannattaa järjestää PFS:ää tukevat protokollat, ECEDH tai EDDHE ohjelmistosta riippuen, neuvoteltavaksi ensin jos clientit niitä tukevat.
PFS:ää HTTPS:n säätö ei ole aivan ongelmatonta, alla olevissa blogeissa niistä enemmän.
How to botch TLS forward secrecy (27 Jun 2013)
ja
SSL Labs: Deploying Forward Secrecy
Jälkimmäisessä SSL Labs blogissa on myös Ivan Ristic'n aiempi kirjoitus Maaliskuulta RC4:n ongelmista.
SSL-terminoinnista...
Niin, siis nykyään lähes kaikki vähänkin isommat saitit ovat sovelluskytkimien takana ja samat laitteet osaavat sitten purkaa SSL:n välistä pois koska siitä on hyötyä palvelujen tuottamisessa.
OK. Pakkohan SSL-putki johonkin on päättää, joten palvelinpäässä on tietenkin luonnollista että liikenteen avaus tehdään ennen varsinaista palvelinta. Siinä ei sinänsä ole mitään väärää.
Ongelma onkin asiakaspään palomuurit, joiden "paremmat" mallit yrittävät päästä tutkimaan SSL-liikennettä. Jos kyse on sähköpostista (ei ihan pieni reikä päästää palomuuria käsiksi IMAP-postilaatikkoon!), riittää oudon poikkeuksen kertahyväksyntä.
Surffailussa asiakas pitää suostutella hyväksymään palomuurin juurivarmenne tai sitten uusi poikkeus aina uusilla https-sivuilla. Edellisen voinee toteuttaa vaikka niin, että palomuuri ei päästä asiakasta suojatuille sivuille lainkaan ellei varmennetta asenna?
Mahtaako tällaisia SSL:n avaavia palomuureja olla todella käytössä Suomessa?
@Anonyymi
Mahtaako tällaisia SSL:n avaavia palomuureja olla todella käytössä Suomessa?
En tiedä ja siksi kysyinkin sitä samaa tuolla jo aiemmin yläpuolella.
Jos on niin pieni julkisuus asiasta voisi tehdä hyvää sen rakentaneille :)
Vielä yksi PFS linkki Netcraftin tilannekatsaukseen asiasta viime viikolta.
SSL: Intercepted today, decrypted tomorrow
Tilannetta ei voi kovin kehuttavaksi sanoa.
Näyttää siltä, että ohjelmistojen tekijöiden ja valmistajien suuntaan on aihetta luoda painetta korjata asia pikaisesti.
@ac sanoi...
Tääll̈́ä on aika monta anonyymia, joten ne menevät helposti sekaisin :)
Pointtini oli tuossa, että kun jokin laite mahdollistaa jonkin toiminteen niin se otetaan helposti käyttöön miettimättä asioita esim. tietosuojan ja yms kannalta. Toki rikoksen pystyy tekemään ihan puhumallakin :)
@anonyymi
Tuo linkkini Fortinetistä oli kuinka se juurivarmenne on asennettava selaimeen, että se Fortinetin ssl-inspection sadaan toimimaan. Yritin tuolla tuoda esille, että juurivarmenetta ei yleensä saa asennettua ihan niin helposti selaimeensa kuin palvelimen varmennetta, jota tuossa itsekkin olet yrittänyt tuoda esille. Pahoittelen, että en osannut asiaa tuoda esille kun yritän pitää tekstini tiiviinä.
Kyllä näitä ssl:n avaavia palomuureja/IPS-laitteita on Suomessa käytössä, mutta onko ominaisuus otettu käyttöön missämäärin niin en tiedä, mutta osa palomuureista joissa on ssl:n avaus on tarkoitettu pk-sektorille, joten laitekantaa on paljon. Tuo on siis nykyisten IPS/UTM-laitteiden vakio-ominaisuus ja kuten yllä sanoin niin asioita ei aina tulla miettineeksi lainsäädännön kannalta.
Silläkin on merkitystä mitä liikennettä tarkistetaan ja mikä sen suunta organissatiossa on, joten ei noiden laitteiden käyttö laitontakaan ole kun sillä tarkistetaan esim. yrityksen weppipalvelimelle menevää liikennettä.
Veikkaisin, että pankit, valtiohallinto, yksityisetyritykset käyttävät noita jo tänä päivänä Suomessa.
Miten menee Lex Nokian suhteen?
Jos firma hankkiin SSL:n avaavan palomuurin ja asentaa oman CA-bitti päällä olevan varmenteensa palomuuriin ja työntekijöidensä koneisiin. Perusteluna SSL liikenteen avaamiselle on se, että palomuuri tutkii liikennettä viruksien yms. varalta. Onko tätä mietitty lainsäädännön kannalta (ja täytyykö miettiä)? Työntejöiden pankkikäynnit ja emailit näkyvät nyt palomuurille avattuina.
Joku anonyymeistä huomautti aikaisemmin, että kyseessä on myös tietoturvaongelma, voihan palomuuri sisältältää takaportin tai siinä voi olla bugeja.
Vai onko Lex Nokia pätevä vain, jos palomuuri tallettaa liikennettä ja sitä tutkitaan yrityksen toimesta? Onko yrityksille myytäviä liikennettä tallettavia palomuureja ylipäänsä olemassa? Ne alkaisivat jo muistuttaa tiedusteluyritysten myymiä SSL avaajia.
Perusteluna SSL liikenteen avaamiselle on se, että palomuuri tutkii liikennettä viruksien yms. varalta. Onko tätä mietitty lainsäädännön kannalta (ja täytyykö miettiä)? Työntejöiden pankkikäynnit ja emailit näkyvät nyt palomuurille avattuina.
Tottahan tätäkin on juristit miettineet. Tässä tulos http://www.finlex.fi/fi/laki/ajantasa/2004/20040516:
6 §
Viestin ja tunnistamistietojen suojaaminen
Tilaaja ja käyttäjä voi suojata viestinsä ja tunnistamistietonsa haluamallaan tavalla käyttäen hyväksi sitä varten tarjolla olevia teknisiä mahdollisuuksia, jollei laissa toisin säädetä. Suojauksen toteuttamisella ei saa häiritä verkkopalvelun ja viestintäpalvelun toteuttamista tai käyttämistä.
Sähköisen viestinnän teknisen suojauksen purkavan järjestelmän tai sen osan hallussapito, maahantuonti, valmistaminen ja levittäminen on kielletty, jos järjestelmän tai sen osan ensisijaisena käyttötarkoituksena on teknisen suojauksen oikeudeton purku.
Viestintävirasto voi antaa hyväksyttävästä syystä luvan poiketa 2 momentissa tarkoitetusta kiellosta.
Lakiin liittyvä hallituksen esitys on HE 125/2003 http://www.eduskunta.fi/valtiopaivaasiat/he+125/2003 ja suojauspykälän perustelut löytyvät PDF-version sivuilta 53-55.
Aiheen vierestä:
Microsoftin Windowsin tämänpäiväisistä turvapäivityksistä kun lukee mitä ne sisältävät, herää kysymys mahtavatko ne kaikki virheet tulla sinne aivan sattumalta. Olisi NSA:lle helppoa pyytää Microsoftia laittamaan kuvan avaamiseen liittyvä uusi haavoittuvuus tai Defenderiin liittyvä admin-oikeudet takaava haavoittuvuus edelliseen päivitykseen, ihan vain jotta NSA pääsee käsiksi haluamiinsa verkkoon kytkettyihin koneisiin. Koska tuo on mahdollista, olisi naiivia kuvitella ettei sitä käytettäisi myös hyväksi.
En ihmettelisi jos Snowdenin suuri paljastus liittyisi yritys-/teollisuusvakoilun ohella tarkoituksella NSA:n pyynnöstä suunniteltuihin haavoittuvuuksiin jotka poistetaan ennen tai sitten kun virustorjuntayhtiöt saavat niistä vihiä.
Lähetä kommentti