Verkkoprotokollat ja niiden turvallisuus

Kuva 20.1 TCP/IP kerros

Verkkosovelluksiin (ja protokolliin) kohdistuu eri verkkokerroksilla tietoturvauhkia. Tätä voidaan havainnollistaa ISO/OSI -kerrosmallilla. Todellisuudessa tiedonsiirtotapahtumien kokonaisuus muodostaa monimutkaisen järjestelmän, ja hajautettujen sovelluksien, verkkotekniikoiden ja tiedonsiirtoyhteyksien ymmärtäminen tapahtuu parhaiten kuvaamalla niitä kerrosmallilla. Kuva 20.1 esittää 4-kerroksisen Internet-protokollapaketin ja niiden välisen vuorovaikutuksen eri kerroksilla (ja kommunikointiosapuolten väliset vastinkerrokset). Eri kerrosten tasoilla toimii useita verkkoprotokollia, joista osa on melko yleisiä ja muita, jotka on räätälöity tietyille verkkoarkkitehtuureille.

Protokolla eli yhteyskäytäntö on säännöstö eli standardi, joka kertoo miten eri kerrosten välistä tiedonsiirtoa käsitellään. Tämä määrittelee ja mahdollistaa tiedonsiirron yhteysosapuolten välillä.

Sovelluskerroksen tietoturva

Seuraavaksi käsitellään miten sovelluskerroksen protokollat voidaan suojata, miten sovelluskerros voidaan suojata, sekä miten eri protokollia voidaan hyödyntää tiettyjen tietoturvatakuiden saavuttamiseksi.

Email (S/MIME) ja viestiohjelmien tietoturva

MIME (Multipurpose Internet Mail Extensions) määrittelee tavan, jolla sähköpostiviestejä pystytään välittämään erilaisia merkistöjä käyttäen, ja jolla viesteihin voidaan sisällyttää liitetiedostoina kuvia tai muita dokumentteja.

• Määrittelee sähköpostin salauksen ja allekirjoittamisen julkisen avaimen salausta käyttäen.
• Sen avulla voidaan varmistaa viestin luottamuksellisuus (ei sivullisten tietoon), alkuperäisyys (kuka on viestin laatija) ja muuttumattomuus. Jotta kaksi käyttäjää voisivat luotettavasti vaihtaa viestejä S/MIME- standardin mukaisesti, kummallakin on oltava tunnustetun julkisen tahon allekirjoittama varmenne.

Sovellukset

• S/MIME-standardi kuvaa sähköpostin ja allekirjoituksen paketoinnin MIME-standardin mukaisesti lähetettävään sähköpostiin.
• Useimmiten ei ole olemassa erillisiä S/MIME-ohjelmia, vaan eri ohjelmissa on sisäänrakennettuna omat S/MIME-toteutuksensa. Useimmiten lyhennettä “S/MIME” ei edes mainita ohjelmissa, mutta käytännössä sähköpostiohjelmien sisäänrakennetut sähköpostin salaus- ja allekirjoitusmahdollisuudet noudattavat S/MIME-standardia.
• Aikaisemmin S/MIME-toteutusten välillä on ollut yhteensopivuusongelmia, mutta S/MIME versio 3:n ja uusien ohjelmaversioiden myötä yhteensopivuus on parantunut.

HTTPS

• RFC2818
• Tarjoaa suojatun yhteyden kommunikointiosapuolten välille, tiedot salataan ennen lähettämistä TLS-protokollan (tai vanhentuneen miltei samanlaisen SSL-protokollan) avulla. HTTPS-yhteyksiä käytetään suojattuun liikennöintiin ja maksunvälityksiin WWW-ympäristössä.
• TLS-salausta käytettäessä tarvitaan varmenne (sertifikaatti). Varmenteen avulla käyttäjä voi paremmin selvittää, minkä palvelimen kanssa verkossa todellisuudessa asioi.
• Selaimessa käytetty protokolla on HTTPS, kun osoite alkaa “https://”.
• Normaalisti HTTPS-protokolla käyttää TCP-porttia numero 443.

Anonyymi ja sensuurivapaa kommunikointi (syventävä)

Anonyymi nimetön viestintä on kaksiteräinen miekka. Toisaalta halutaan pitää kiinni sananvapauden oikeuksista, mutta kuitenkin halutaan pitää viestinnän osapuolet vastuussa, mikäli ilkeämielistä keskustelua esiintyy. Esimerkiksi demokratiaa kannattavat saattavat haluta ottaa käyttöön anonymiteettiä takaavia järjestelmiä, kun halutaan kommunikoida demokratiaa tukahduttavia järjestelmiä vastaan.

Anonyymiys voidaan parhaiten saavuttaa hajauttamalla tiedonsiirtoa ja reitittämällä se uudelleen useiden verkkorakenteiden yli. Sipulireititys edustaa tällaista anonyymia viestintäverkkoa (ACN, Anonymous Communication Networks). Tor-verkko on yleisin ja suosituin toteutus tällaisesta verkkototeutuksesta. Kommunikointiosapuolet liikennöivät (tyypillisesti kolmen) sipulireitittimen kautta monikerroksisessa salatussa peiteverkossa. Tor-asiakas valitsee ensin (tyypillisesti kolme) sipulireitittimen, syöttösolmun, keskisolmu/(t) ja poistumissolmun. Asiakas muodostaa päästä päähän -suojatun kanavan syöttösolmuun (TLS:ää käyttäen), jonka avulla asiakas luo toisen päästä päähän -suojatun liikennevirran keskisolmuun. Lopuksi asiakas käyttää tätä asiakas-keskikanavaa aloittaen päästä päähän -suojatun liikennevirran poistumissolmuun. Tuloksena olevaa polkua kutsutaan piiriksi. Tor-asiakkaat kommunikoivat piiriensä kautta varmistaakseen lähettäjän nimettömyyden. Kaikki tiedot siirretään tämän piirin kautta ja salataan kolmeen kertaan ja jokainen solmu vastaa yhden kerroksen salauksen purkamisesta.

Siirtoyhteyskerroksen tietoturva

Tässä osiossa kerrotaan sovelluskerroksen alla olevan kuljetuskerroksen turvallisuudesta protokollapinossa.

TLS

Sovelluskerroksen protokollat perustuvat siirtokerroksen luottamuksellisuus-, eheys- ja todennusmekanismeihin. Näitä ominaisuuksia tarjoaa sovellus- ja kuljetuskerroksen tasolla TLS (Transport Layer Security). Tässä osiossa, kuvataan yksinkertaistettuna TLS-protokollan perustoteutus. Yksityiskohtaisempi aiheen käsittely, mukaan lukien TLS-historia ja aiemmat haavoittuvuudet ovat Sovellettu Kryptografia -luvussa.

Uusimmista ja suosituimmista TLS-versioista 1.2 ja 1.3 keskittyvät erityisesti kättelytapahtumaan. TLS-versiosta riippumatta kättely hoitaa salaukseen käytettävät yksityiskohdat, jotka sovelluskerrosprotokollien olisi muuten käsiteltävä itse. Yksityiskohtia ovat mm. liikennöivien osapuolien todentaminen, käytettävistä salakirjoitusalgoritmeistä, tarvittavista salausavainten toiminnoista ja salausavainten vaihdoista sopiminen.

Kuva 20.2: TLS-kättely: Vertailu TLS 1.2: n (vasemmalla) ja TLS 1.3:n (oikea), lukuun ottamatta asiakkaan todennuksen valinnaisia vaiheita.

Kättelytapahtumat eroavat kahden TLS-version välillä, kuten kuvassa 20.2 esitetään. Keskustelu aloitetaan TLS 1.2:sta, kuten kuvassa vasemmalla. Asiakas ja palvelin neuvottelevat, mitä TLS -versiota ja salauspaketteja käytetään yhteensopivuuden takaamiseksi jopa heterogeenisten viestintäkumppaneiden kesken. Lisäksi palvelin- ja asiakasvarmenteiden vaihtoa käytetään toistensa todentamiseen, kun taas asiakkaan todennus on valinnainen toiminto (jätetään pois kuvasta 20.2). Sertifikaatit sisältävät viestintäkumppanien tunnisteita verkkopalvelimien verkkotunnuksina ja niiden tarkistetut julkiset avaimet.

Kolmanneksi viestintäkumppanit saavat symmetrisen avaimen, jota voidaan käyttää tiedonsiirron suojaamisessa. Avaimen saamiseksi asiakas voi salata juuri luodun symmetrisen avain palvelimen julkisen avaimen (esim. RSA) alla. Vaihtoehtoisesti kumppanit voivat saada avaimen käyttämällä Diffie-Hellman-Merkle avaintenvaihtoa (DHKE, Diffie-Hellman Key Exchange). DHKE tarjoaa TLS:lle täydellisen salauksen eteenpäin. Tämä estää hyökkääjiä purkamasta viestintää, vaikka palvelimen yksityinen avain vuotaa. Lopuksi kättelytapahtuma vahvistaa tiedonsiirtoistunnon eheyden. Tästä lähtien osana tiedonsiirtovaihetta TLS-kumppanit käyttävät salattua avainmateriaalia salaukseen ja todentamaan myöhemmän viestinnän.

Kuvan 20.2 oikealla puolella oleva TLS 1.3 versiossa kättelytapahtuma on toteutettu tehokkaammin. TLS 1.3 vähentää edestakaisten tiedonsiirtopakettien vaihtojen määrän yhdeksi (1-RTT) turvatakuista tinkimättä. TLS 1.3 ei enää tue RSA-pohjaista avainten vaihtoa DHKE:n hyväksi. Siksi asiakas “arvaa” valitun avainsopimusprotokollan (esim. DHKE) ja lähettää sen avainosuuden heti ensimmäisessä vaiheessa. Tähän palvelin vastaa valituilla parametreillä, joilla määritellään kättelytapahtumassa käytettävät protokollat, salausavaimet, varmenne ja allekirjoitus (CertificateVerify -viestissä). Jos asiakas oli yhteydessä palvelimeen jo aiemmin, TLS 1.3 tukee kättelyä jopa ilman ylimääräistä edestakaista pakettiliikennettä (0-RTT)-eteenpäin salassapidon ja toiston heikkenemisen kustannuksella pyritään mahdollisten hyökkäysten ehkäisyyn.

Seuraavaksi lyhyesti siitä, kuinka TLS tarjoaa suojaa yleisiä verkkohyökkäyksiä vastaan. Ensin ajatellaan verkossa olevan hyökkääjän, joka salakuuntelee viestiliikennettä. Hyökkääjä haluaa saada tietoonsa salaisuuksia seuratusta/kaapatusta TLS-suojatusta liikenteestä. Koska käyttäjätiedot on salattu, salaisuuksia ei voida päätellä. Toiseksi IP-spoofing hyökkäyksessä hyökkääjä voi hyökätä minkä tahansa TLS-kumppanin liikenteeseen yrittäen saada tätä hyväksymään vääriä tietoja. Jos hyökkääjä syöttää liikennöintiosapuolelle tietoja, hyökkääjältä puuttuu tarvittava salainen avain salatun sisällön syöttämiseen. Kolmanneksi tietoja ei voida myöskään muuttaa, koska TLS suojaa tietojen eheyttä käyttämällä todennettuja salaus- tai viestitodennuskoodeja.

Lopuksi, jopa vahva MITM-hyökkäys estetään todentavien varmenteiden avulla varmistaen kommunikointiosapuolet - ellei MITM -hyökkääjä kykene antamaan oikeita varmenteita, joihin TLS-kumppanit luottavat. TLS-protokolla takaa myös, että hyötykuorma saapuu sovellukseen oikeassa järjestyksessä, havaitsee pudonneen ja muokatun sisällön ja estää tehokkaasti myös toistohyökkäykset, mikäli yritetään lähettää sama liikenne uudelleen hyötykuorman kopioimiseksi. Tästä huolimatta TLS ei estä hyökkääjiä viivästyttämästä tiedonsiirtopaketteja tai estämästä koko viestintää.

Kysymys 1

Mikä ero on tiedonsiirron suojauksessa TLS1.2 ja TLS1.3 versioiden kättelytapahtumassa?

Versioiden välillä ei ole mitään eroa juuri kättelytapahtumassa.

TLS1.2 version toteutuksessa kättelytapahtuma on toteutettu kohteliaammin kommunikointiosapuolten esittelyssä.

TLS1.3 versio ei kerro mitään tietoja kommunikointiosapuolelle.

TLS1.3 versio toteuttaa kättelytapahtuman tehokkaammin ja vähentää pakettiliikenneettä säilyttäen kuitenkin turvallisuuden.

TLS1.2 ei toteuta kättelytapahtumaa kommunikointia aloitettaessa.

PKI

Toistaiseksi on vain oletettu, että viestintäkumppanit voivat saada luotettavasti julkisia avaimia toisiltaan. Miten aktiivisten hyökkääjien tilanteessa voidaan varmistaa luottamus epävarman kanavan kautta vaihdettuihin julkisiin avaimiin? Perusongelma on se, miten yhteysosapuolet voivat luoda turvallisen julkisen/yksityisen avainparin kommunikoidakseen turvallisesti. Julkisen avaimen infrastruktuuri (PKI, Public Key Infrastructure) tarjoaa ratkaisun luotettavien julkisten avainten (ja epäsuorasti niiden yksityisen avaimen) hallintaan. Valtion virastot tai erilliset organisaatiot, joita nimitetään varmentajiksi (certificate authority CA), ovat tahoja, jotka myöntävät ja seuraavat niin sanottuja varmenteita yhteisöjen (yksilöiden, palvelimien, reitittimien jne.) puolesta. Eli on olemassa määritelty taho, joka ylläpitää myönnettyjä varmenteita, varmistaa niiden oikeutuksia ja voimassaoloa sekä poistaa vanhentuneita varmenteita.

Oletetaan, että käyttäjä haluaa hankkia luotettavan varmenteen ja vastaavan avainmateriaalin. Tätä varten käyttäjä luo ensin julkisen/yksityisen avainparin omalle laitteistolleen. Yksityistä avainta ei koskaan jaeta kenellekään. Julkisesta avaimesta tulee osa varmenteen allekirjoituspyyntöä (CSR), jonka käyttäjä lähettää varmentajalle. Ennen kuin varmentaja allekirjoittaa varmenteen, käyttäjän on pyydettäessä todistettava henkilöllisyytensä varmentajalle (esim. verkkotunnuksen hallussapito: nimi HTTPS-varmenteelle tai henkilötunnukset S/MIME-varmenteelle). Varmentajan allekirjoitus estää väärentämisen, koska kuka tahansa voi nyt tarkistaa varmenteen käyttämällä varmentajan julkista avainta. Tuloksena oleva varmenne kytkee käyttäjän henkilöllisyyden ja julkisen avaimen. Lisäksi se sisältää varmentajan tiedot ja varmenteen voimassaoloajan. Varmenteen muoto ja PKI-hallintatiedot on määritelty RFC 1422:ssä ja ITU-X.509:ssä.

Nykyisessä PKI-mallissa on myös haasteita, kuten tapaukset, joissa varmentajat ovat myöntäneet varmenteita erehdyksessä tai pakotettuina väärille tahoille. Myös varmentajien omaan infrastruktuuriin tapahtuneiden hyökkäysten kautta hyökkääjät ovat onnistuneet luomaan väärennettyjä varmenteita. Varmentajat julkaisevat luetteloa vanhentuneista/peruutetuista varmenteista. Tiedot haetaan käyttämällä TLS-kättelyissä online-sertifikaatin tilaprotokollaa (OCSP, Online Certificate Status Protocol), joka on määritelty RFC 6960:ssä. Jotta vältetään väärät, mutta vahvistetut varmenteet, verkkoselaimissa tulee olla aktiivisesti päivitettynä myönnetyt oikeelliset varmennelistat. TLS-asiakas, esim. selain, voi kieltäytyä hyväksymästä varmenteita, jotka eivät ole hyväksyttyjä tai varmennetusti voimassa olevia. Puhutaan varmenteen läpinäkyvyydestä (CT, Certificate Transparency). Se estää hyökkääjiä hyödyntämästä julkaisemiaan kelvottomia varmenteita. Näin varmenteiden omistajat ja varmentajat kykenevät huomaamaan, yrittävätkö haitalliset osapuolet väärinkäyttää henkilöllisyyttään (esim. verkkotunnuksia).

Luottamusverkko on vaihtoehtoinen hajautettu PKI-järjestelmä, jossa käyttäjät voivat luoda ja allekirjoittaa varmenteet ilman varmentajaa. PGP-järjestelmä ja sen näkyvä toteutus GNU Privacy Guard (GPG) on hyvä esimerkki, jossa palvelun käyttäjät keskenään todistavat toistensa avaimen aitouden.

Lisää PKI-asiaa löytyy Sovellettu kryptografia -luvusta.

Kysymys 1

Tietoturvassa julkisen avaimen infrastruktuuri (PKI) tarkoittaa?

Julkisten rakennusten lukitusjärjestelmien avainten hallinta on keskitetysti hoidettu.

Kommunikointiosapuolet voivat luoda turvalliset salausavaimet ja kommunikoida keskenään turvallisesti.

Kaikki avainten luomisen tietot ja avaimet ovat julkisesti saatavilla

Sähköistä avainkaappia, jonka avulla kadonnut sähköinen avain voidaan palauttaa

Käyttäjä voi olla varma omien sähköisten avaintensa turvallisuudesta.

TCP-tietoturva (syventävä)

TLS suojaa TCP -hyötykuormia ja estää istunnon kaappaukset sekä paketti-injektion. Mutta entä TLS-yhteyksien tai muiden, ei-TLS-yhteyksien TCP-ylätunnisteiden yhteyksien turvallisuus? Itse asiassa hyökkääjät voivat yrittää käynnistää TCP-nollaushyökkäyksiä, joiden haittatarkoituksena on katkaista TCP-yhteys kohteeseen. Tätä varten he arvaavat kelvollisen sekvenssin numeron ja väärentävät TCP-segmentit, kun RST-lippu on asetettu. Jos väärennetty sekvenssinumero osuu tiedonsiirron liukuikkunaan, vastaanottaja lopettaa yhteyden. Käytännössä tähän ongelmaan käytetään pääasiassa kahta ortogonaalista ratkaisua:

1. TCP/IP-pinojen on varmistettava vahva satunnaisuus (alkuperäiselle) järjestysnumeron luomiselle.
2. Estä RST-segmentit järjestysnumeroilla, jotka kuuluvat liukuikkunan keskelle. Käsitteellisesti nämä puolustukset ovat tehottomia hyökkääjiä vastaan, jotka voivat luotettavasti manipuloida TCP-segmenttejä (esim. laskemalla hyötykuorman ja asettamalla RST lipun). Kilpa-olosuhteet mahdollistavat off-path-hyökkääjien käynnistämät RST-hyökkäykset, vaikka he voivat päätellä oikean sarjanumeron. SYN Flooding-hyökkääjä lähettää jatkuvasti TCP SYN-segmenttejä ja pakottaa palvelimen varaamaan resursseja puoliksi avattuihin TCP-yhteyksiin. Kun palvelimet rajoittavat puoliksi avattujen yhteyksien lukumäärää, oikeat asiakkaat eivät kykene enää muodostamaan TCP-yhteyksiä palvelimelle. Vähentääkseen puolittain avattujen istuntojen määrää palvelimet voivat poistaa satunnaisen puoliksi avatun istunnon aina, kun uusi istunto yritetään luoda. Tämä voi mahdollisesti poistaa samalla hyvänlaatuisia istuntoja. Käyttöjärjestelmissä on otettu puolustuskäyttöön SYN evästeet järjestelmällisempänä vastauksena SYN-tuloihin. Kun tämä toiminta on käytössä, palvelin ei heti sulje puoliksi avattua yhteyttä, kun vastaanotetaan TCP-yhteyspyyntö. Se valitsee alustavan järjestysnumeron (ISN) käyttämällä tiivistefunktiota lähde- ja kohde -IP-osoitteiden, SYN-porttinumeroiden, ja palvelimen tunteman salaisen numeron yli. Palvelin lähettää asiakkaalle muodostamansa ISN:n SYN/ACK-sanomassa. Jos pyyntö on lailliselta lähettäjältä, palvelin vastaanottaa kuittauksen sisältävän ACK-viestinumeron, joka on ISN plus 1. Varmistaakseen, onko ACK peräisin hyvänlaatuiselta lähettäjältä, palvelin laskee uudelleen SYN-evästeen edellä mainittujen tietojen avulla ja tarkistaa, vastaako kuittauksen ACK-segmentin numero miinus yksi SYN-evästettä. Jos näin on, palvelin avaa TCP-yhteyden, ja alkaa vasta sitten käyttää resursseja. DoS -hyökkääjän pitäisi tuhlata paljon omia resurssejaan ja selvittää todellisen lähettävän IP-osoitteen oikean ISN-numeron häirinnän mahdollistamiseksi. Tällainen toimintamekanismi tasoittaa resurssien kulutuksen oikeudenmukaisuutta eli tarjoaa kaikille yhteyttä pyytäville osapuolille palvelua tasaisesti.

UDP-tietoturva (syventävä)

Mikä TLS on TCP:lle niin Datagram TLS (DTLS) on UDP:lle. Seuraavaksi tarkastellaan lisäsuojauksen toteuttamista UDP-näkökulmasta. Toisin kuin isoveli TCP, UDP on suunniteltu siten, että sovelluskerrosprotokollien on käsiteltävä avainmekanismit itse (tai sietää sitä mikä puuttuu), mukaan lukien pakettien uudelleenjärjestäminen, luotettava kuljetus ja tunnistus.

Koska UDP on yhteysvapaa protokolla (osapuolet eivät tiedä toistensa lähetystapahtuman etenemistä eivätkä sen tilaa), UDP-päätepisteet eivät epäsuorasti varmista kumpikaan toisen IP-osoitetietoja ennen viestinnän aloittamista. Jos osoitetietoja ei käsitellä kommunikointiyhteyden aloittamiseksi ja ylläpitämiseksi, UDP-protokolla on alttiina IP-spoofing-hyökkäyksille. Koska UDP-yhteyksissä ei yhteysosapuolten tietoja tarkasteta eikä IP-tason tietojakaan seurata/varmisteta. Yleensä tätä uhkaa vastaan suojautuakseen on minkä tahansa UDP-pohjaisen sovellusprotokollan huolehdittava IP-tason turvallisuusmekanismeista itse.

Heijastavat DDoS-hyökkäykset ovat IP-spoofing -hyökkäysten erityinen alaluokka. Tässä hyökkääjät lähettävät IP-paketteja, joissa lähde IP-osoite vastaa DDoS-kohdetta. Jos vastaanottajat (nimeltään heijastimet) vastaavat heti tällaisiin paketteihin, heidän vastauksensa ylikuormittavat uhrin lähettämällä ei-toivottuja vastauksia. Tämä yleinen haavoittuvuus johtuu IP-osoitteen vahvistuksen puutteesta UDP:ssä. Myös monet muut UDP -pohjaiset protokollat ovat samalla tavoin alttiita heijastumiselle (liikennettä levitetään hallitsemattomasti). Heijastushyökkäykset muuttuvat amplifikaatiohyökkäyksiksi, jos vastaukset ovat merkittävästi suurempia kuin pyynnöt, jotka tehokkaasti kuluttavat kaistanleveyttä hyökkäyksessä. Ellei sovellustason protokollissa vahvisteta osapuolten IP-osoitteita tai pakoteta todennusta, UDP-pohjaisten protokollien haavoittuvuus säilyy. Mikäli protokollan muutokset rikkoisivat yhteensopivuuden, toteutuksissa suositellaan asettamaan rajoituksia liikennöinnin nopeudelle, jolla asiakkaat voivat laukaista pyyntöön nähden suurta kaistanleveyttä edellyttäviä vastauksia. Vaihtoehtoisesti, ei-pakolliset pyynnöt vahvistus-/todennuspalveluista voidaan ottaa huomioon.

QUIC (HTTP/2 + TLS) (syventävä)

QUIC on uusin siirtokerroksen protokolla, jonka tukemia verkkoselaimia suositellaan käytettäväksi. QUIC tarjoaa nopeamman tiedonsiirron käyttämällä UDP:tä HTTP:n sijaan TCP:n kautta. QUIC oli alun perin Googlen suunnittelema, ja IETF standardoi sen vuonna 2021. Sen päätavoite on parantaa viestintäkykyä käyttämällä multipleksattuja yhteyksiä (tekniikka, jossa monesta eri lähteistä tulevat tietovuot yhdistetään yhdeksi tietovuoksi). QUIC suunniteltiin turvalliseksi, toisin kuin aiemmat protokollat. Teknisesti QUIC käyttää suurinta osaa TLS 1.3:ssa kuvatuista käsitteistä, mutta korvaa TLS-tietuekerroksen omalla rakenteellaan. Tällä tavalla QUIC ei voi salata vain hyötykuormaa, vaan myös suurimman osan otsikkotiedoista. UDP-pohjainen QUIC “korvaa” TCP-kolmisuuntaisen kättelyn omalla kättelyllään, joka integroi TLS-kättelyn. Tämä eliminoi TLS:n edestakaiset viestinvälitykset. QUIC integroi ainoat kaksi TLS 1.3-kättelyviestiä omassa kättelytapahtumassaan (vrt. kuva 20.2). QUIC-palvelimet tarkistavat osoitteet kättelyn aikana, eivätkä ne saa ylittää tiettyjä vahvistuksia ennen osoitteiden tarkistamista (nykyinen IETF-standardiluonnos määrittelee kertoimen kolme).

Internetkerroksen tietoturva

Vaikka sovellus- ja kuljetuskerroksen suojaus auttavat tarjoamaan kokonaisvaltaisen suojauksen, on myös syytä lisätä turvamekanismeja verkkokerrokseen. Korkeampien kerrosten turvamekanismit eivät välttämättä suojaa organisaation sisäisiä verkkoyhteyksiä haitalliselta liikenteeltä. Jos ja kun haittaohjelma havaitaan pääkoneissa, on liian myöhäistä, kun kaistanleveys on jo käytetty. Toinen suuri ongelma on, että ylemmän kerroksen aiemmin kuvatut suojausmekanismit (esim. TLS) eivät kätke tai suojaa IP -otsikoita. Tämä tekee kommunikoivien päätelaitteiden IP-osoitteet salakuuntelijoiden nähtäväksi ja jopa muokattaviksi MITM-hyökkääjän osoitteeksi.

IPv4 tietoturva

IP Spoofing-haku: IP-spoofing-hyökkäysten juurisyyt ovat Internet -protokollassa (IP) ja tämä vaikuttaa sekä IPv4- että IPv6-protokollaan. Periaatteessa haitalliset asiakkaat voivat vapaasti lähettää liikenteen millä tahansa mielivaltaisella IP-osoitteella. Onneksi useimmat palveluntarjoajat suorittavat poistosuodatuksen ja hylkäävät liikenteen IP-osoitteista, jotka tulevat verkkotunnuksensa ulkopuolella. Lisäksi Unicast Reverse Path Forwarding (uRPF) mahdollistaa sen, että reitittimet poistavat liikenteen IP-osoitteista, joiden he olisivat odottaneet saapuvan muista rajapinnoista.

Sirpalehyökkäykset: IPv4:n on paloiteltava tietopaketit (Protocol Data Unit), jotka ylittävät enimmäispakettikoon, jonka verkko pystyy siirtämään. Tämän määrittelee maksimaalinen tiedonsiirtoyksikkö (MTU, Maximum Transmission Unit). Vaikka pakettien paloittelu on yksinkertaista, tiedonsiirron eheytys ei usein sitä ole ja tämä on johtanut vakaviin turvallisuusongelmiin. Esimerkiksi Teardrop-hyökkäys hyödyntää sitä, että käyttöjärjestelmät voivat yrittää säilyttää valtavia hyötykuormia kootessaan uudelleen koko TCP-segmentin useista paloitelluista tietopaketeista. Pakettien pilkkominen mahdollistaa myös DNS:ään kohdistettuja välimuistin myrkytyshyökkäyksiä (cache poisoning attack), koska hyökkääjät voivat kohdistaa hyökkäyksen pienempään hakutilaan hyökkäämällä vain aloittamattomiin paloiteltuihin paketteihin. Lopuksi pakettien paloittelu voi auttaa hyökkääjiä kiertämään yksinkertaisia hyötykuorman tarkastuksia, hajottamalla hyötykuorma useiden paloiteltujen pakettien osien päälle.

VPN:t ja IPSec: Monet organisaatiot haluavat liikenteen olevan täysin salattua sen poistuttua heidän verkostaan. He voivat esimerkiksi haluta yhdistää useita yksityisten verkkojen kokonaisuuksia organisaation omaksi Intranetrakenteeksi yleisen internetverkon kautta. Myös työnantajat ja työntekijät haluavat tehdä joustavaa työtä, jossa ihmiset voivat työskennellä kotoa käsin tai muodostaa yhteyden hotellihuoneesta tai lentokentän oleskelutilassa turvallisuudesta tinkimättä. Kattava virtuaalinen yksityisverkko (VPN, Virtual Private Network) muodostaa yhteyden kahden tai useampien erillisten verkkojen välille toteuttaen turvallisen tiedonsiirtoväylän epäluotettavien verkkorakenteiden sisään.

On olemassa monia tiedonsiirronsuojausprotokollia, jotka mahdollistavat virtuaaliset tunnelit (VPN), esim. Point-to-Point Tunneling Protokolla (PPTP) (vanhentunut), TLS (esim. OpenVPN) tai Secure Socket Tunneling Protokolla (SSTP), jne. Ohessa havainnollistus yhdestä yleisestä VPN-toteutuksesta, Internet Protocol Security (IPSec). Kuvan 20.4 mukaisesti työntekijä työskentelee kotiverkossaan, työntekijän asiakaslaite (VPN-asiakas) kapseloi lähtevät IPv4-datagrammit IPSec kehykseen ja salaa IPv4-hyötykuorman, joka sisältää TCP- tai UDP -segmenttejä tai muita tiedonsiirron ohjaussanomia. Yrityksen yhdyskäytävä tunnistaa saapuvan IPSec-datagrammin, purkaa sen salauksen ja purkaa sen IPv4-datagrammin ennen sen välittämistä kohdepalvelimelle. Jokainen palvelimen vastaus on myös yhdyskäytävän salaama. IPSec tarjoaa tiedonsiirrossa myös tietojen eheyden, alkuperätodennuksen ja uusintahyökkäyksen estämisen. Nämä takuut riippuvat kuitenkin valitusta IPSec-toteutuksesta. Vain suositeltu ja laajalti käytössä oleva ESP (Encapsulation Security Payload) -protokolla (osa IPSec toteutusta) tarjoaa nämä takuut, mukaan lukien luottamuksellisuuden ja alkuperän todentamisen. Sitä vastoin vähemmän suosittu/käytetty AH (Authentication Header) -protokolla tarjoaa vain eheyttä. Useat muutkaan tunnelointiprotokollat, kuten GRE (Generic Routing Encapsulation), kerros 2 tunnelointiprotokolla (L2TP) tai MPLS (Multiprotocol Label Switching) eivät tarjoa CIA-mallin mukaisia turvallisuustakuita. Epäluotettavissa verkoissa, joissa tarvitaan esim. GRE:n moniprotokollatukea tai siirtokaistojen monijakelu-toimintoja, on suositeltavaa käyttää niitä yhdessä IPSec:n kanssa.

Kuva 20.3: IPSec kuljetus- ja tunnelointitilojen vertailu. Kaikki alkuperäisten pakettien salattu tieto on IPSec toteutuksessa harmaalla.

Koko IPSecin tarjoama tila/kokoonpano/standardi on laaja. Tässä esittelemme vain lyhyesti, että IPSec tukee kahta toimintatilaa: tunnelointitilaa ja kuljetustilaa, verrattuna kuvaan 20.3. Kuljetustilassa vain IP-hyötykuorma - ei alkuperäinen IP-otsikko - on suojattu. Tunnelimuoto on toimiva vaihtoehto, jos kahden verkon reunalaitteet (reitittimet/yhdyskäytävät) ovat IPSec-tietoisia ja kykenevät IPSec vaatimukset toteuttamaan. Silloin muiden palvelimien/isäntien ei tarvitse huolehtia IPSecistä. Reunalaitteet kapseloivat jokaisen siirretyn IP -paketin otsikot mukaan lukien.

Kuva 20.4: IPSec kuljetusmoodin asiakas-palvelin liikennöinti.

Tämä toteutus luo käytännössä turvallisen tunnelin kahden reunalaitteen väliin. Vastaanottava reunalaite purkaa IPv4-datagrammin ja lähettää sen edelleen oikealle kohteelle verkon sisällä käyttämällä tavallista IP-edelleen lähetystä. Tunnelitilassa keskeiset neuvottelut kahdella reunalaitteella voivat käsitellä yhteyksiä kaikkien isäntien puolesta omissa verkoissaan. Lisäetu on, että myös IP-otsikot (mukaan lukien lähde-/kohdeosoite) salataan.

Kun suuri määrä päätepisteitä käyttää IPSeciä, IPSec-avainten manuaalisesta jakamisesta tulee haastavaa. RFC 7296 määrittää Internet Key Exchange-protokollan (IKEv2). Lukijat havaitsevat samankaltaisuuden TLS:n ja IKE:n välillä, koska IKE vaatii myös ensimmäisessä kättelytapahtumassa neuvottelun salausalgoritmeista ja muista parametreistä, esim. osapuolten tunnistetiedoista ja varmenteista.

NAT: IPv4-osoitteiden vähyyden vuoksi osoitteenmuunnos (NAT, Network Address Translation) oli suunniteltu siten, että yksityiset IP-osoitteet voidaan yhdistää ulkoisesti reititettävään IP-osoitteeseen NAT-laitteella. Lähtevän IP-paketin osalta NAT-laite vaihtaa yksityisen lähteen IP-osoitteen lähtevän linkin julkiseen IP-osoitteeseen. Tässä on epäsuoraa, mutta tahatonta turvallisuushyötyjä. Ensinnäkin NAT hämärtää todellisen sisäisen IP-osoitteen ulkomaailmasta. Mahdolliselle hyökkääjälle IP-paketit näyttävät tulevan NAT-laitteelta, eivät todelliselta isännältä NAT-laitteen takana. Toiseksi NAT-yhdyskäytävät, kuten kotireitittimet, estävät hyökkääjiä pääsemästä suoraan verkon sisäisiin isäntiin (ellei porsaanreikiä verkkoon avata portin edelleen lähetyksen tai UPnP:n kautta).

Linkkikerroksen tietoturva

Tässä osassa käsitellään linkkikerroksen turvallisuutta, enimmäkseen linkkikerroksen loogisia osia. Fyysistä osaa käsitellään tarkemmin myöhemmässä luvussa

Porttiperusteinen pääsynvalvonta (IEEE 802.1X) (syventävä)

IEEE 802.1X on porttipohjainen autentikointi sekä kiinteän että langattoman verkon suojaamiseen. Ennen kuin käyttäjä voi käyttää verkkoa linkkikerroksessa, hänen on autentikoitava kytkin tai käyttöoikeus haluttuun yhteyspisteeseen (AP, Access Point), joko fyysisen verkon tai langattoman verkon kautta. Kuva 20.5 esittää tyypillisen IEEE 802.1X-kokoonpanon. Kuvassa ovat asiakaslaitteet sekä autentikoinnin yhteyspiste (kytkin tai tukiasema). Tarvittava ohjelmisto on tyypillisesti saatavana useille käyttöjärjestelmille tai se voidaan toimittaa myös piirisarjan toimittajilta. Pyynnön esittäjän (asiakkaan), joka haluaa käyttää verkkoa, on käytettävä Extensible Authentication -protokollaa (EAP). EAP-protokolla muodostaa yhteyden autentikointipalvelimeen (AuthS) todentajan kautta. EAP on päästä päähän (asiakas-todennuspalvelin)-protokolla. Kun uusi asiakas (anoja) on yhdistetty autentikointilaitteeseen, autentikoijan portti on asetettu luvattomaan tilaan (pääsy estetty ulkoverkkoon), joka sallii vain IEEE 802.1X-liikenteen. Muu korkeamman kerroksen liikenne, kuten TCP/UDP, on estetty. Todentaja lähettää EAP-identiteettipyynnön asiakaslaitteelle. Asiakaslaite vastaa EAP-vastauspaketin kanssa, joka välitetään edelleen AuthS:lle ja joka tyypillisesti vahvistaa tai hylkää pyytäjän vastauspaketin. Onnistuneen vahvistuksen jälkeen todentaja avaa asiakaslaitteelle portit päästääkseen korkeamman kerroksen liikenteen läpi. Kun pyynnön esittäjä kirjautuu ulos, EAP-autentikoija (todentaja) kirjaa asiakaslaitteen ulos ja asettaa portit estämään kaiken muun kuin EAP-liikenteen.

Kuva 20.5: EAP protokolla

Ulkoverkkojen linkkikerroksen tietoturva (syventävä)

IEEE802.1X on tarkoitettu paikallisverkoille ja protokollille, kuten Point-to-Point Protocol (PPP). Sen vastineet ulkoverkkojen käyttöön ovat PPP over Ethernet (PPPoE) tai High-Level Data Link Control (HDLC) laajakaistaverkoille (WAN). Ne tarjoavat asiakkaille keinoja muodostaa yhteys Internetiin Internet-palveluntarjoajiensa avulla. PPP(oE) on tässä yhteydessä laajimmin käytetty protokolla, jota käyttävät miljardit lähetyslaitteet maailmanlaajuisesti. Vaikka Internet-palveluntarjoajat ovat standardissaan vapaaehtoisia, ne yleensä velvoittavat asiakkaan todennuksen. Tämän avulla pystytään pitämään asiattomat käyttäjät poissa verkosta. Suosittuja esimerkkejä tällaisista todennusprotokollista PPP:n käyttämä salasanan todennusprotokolla (PAP), haaste-vaste kättelyn todennusprotokolla (CHAP) tai mitkä tahansa EAP:n tukemat todennusprotokollat. PAP:n käyttöä ei suositella, koska se välittää asiakastiedot yksinkertaisesti (liian heikko nykyisin). Sen sijaan CHAP käyttää kohtuullisen turvallista haaste-vastetodentamista, joka on kuitenkin altis useille bruteforce-hyökkäyksille, jossa tallennetut todennusistunnot sisältävät heikkoja kirjautumistietoja.

Verkon segmentointi (syventävä)

MAC- ja ARP-spoofing toteutukset havainnollistavat hienosti, kuinka hauras suojaus verkkokerroksessa on. Tästä johtuen käytäntönä on pyrkiä jakamaan verkkoarkkitehtuurit, eli fyysisen verkon rakenne, useisiin pienempiin verkkoalueisiin (kokonaisuuksiin). Tätä kutsutaan verkon segmentoinniksi. Erittäin kriittiset ympäristöt, kuten arkaluontoiset armeija- tai ohjausverkot, käyttävät fyysistä segmentointia. Fyysisesti tehtynä verkkona kaapelien ja johtojen hinta on melko kallis, joten virtuaaliverkon segmentoinnista on tullut suosittu vaihtoehto. Virtuaaliset lähiverkot (VLAN, Virtual Local Area Network) ovat de facto-standardi virtuaalisen segmentoinnin käyttöön Ethernet -verkkototeutuksissa. VLAN-verkot voivat erottaa arkaluontoiset verkkosegmentit (esim. sisäiset palvelimet) vähemmän arkaluontoisista (esim. vieras WiFi). VLAN-verkot pakottavat reitittimet näkemään ja reagoimaan liikenteeseen ja rajoittavat hyökkääjien aiheuttamaa uhkaa/haittaa koko lähiverkolle. On tärkeää huomata, että verkon segmentointi (esim. VLAN-verkkojen kautta) ei välttämättä edellytä VPN-verkkojen siltaamista muihin verkkoihin. Jos kaikki verkkosegmentit ovat paikallisia, reititin, joka on osa useita aliverkkoja, voi yhdistä ne toisiinsa - mieluiten täydennettynä suojatuilla palomuurikäytännöillä, jotka ohjaavat verkkojen välistä viestintää IP-kerroksessa.

VLAN-hyppyhyökkäykset mahdollistavat hyökkääjän (joka esiintyy isäntälaitteena) pääsyn yhden VLAN-verkon kautta muihin liitettyihin VLAN-verkkoihin. Näin hyökkääjä saa käytettyä VLAN-verkkojen resursseja, joita normaalisti rajoitettaisiin. VLAN-verkon tarkoituksena on erottaa ja eriyttää verkkorakenteen resursseja toisistaan. VLAN-verkon ensisijaisia hyökkäysmenetelmiä on kaksi: Kytkimen-spoofing ja kaksinkertainen koodaus.

Kytkimen spoofing-hyökkäyksessä hyökkäävä isäntä esiintyy kanavakytkimenä, joka vastaa tunnisteiden ja kanavien protokollista (esim. IEEE802.1Q tai Dynamic Trunking Protocol). Hyökkääjä onnistuu nyt pääsemään useiden VLAN-verkkojen liikenteeseen. Esimerkiksi tietyille porteille on määritetty nimenomaisesti tietty kanavarooli ja muut ovat vain pääsyportteja. Myös kaikki automaattiset runkoneuvotteluprotokollat voidaan poistaa käytöstä.

Kaksinkertaisen koodauksen hyökkäyksessä hyökkääjä onnistuu muokkaamaan alkuperäistä kehystä lisäten siihen kaksinkertaiset tunnisteet ja lähettämään muokatun kehyksen useammille VLAN-verkolle lisäämällä kaksi VLAN-tunnusta sen lähettämään kehykseen. Kohde VLAN-verkko käsittelee vain ulomman kehyksen tunnisteen ja välittää kehyksen eteenpäin seuraavalle VLAN-verkolle. Hyökkäys on yksisuuntainen, eikä paluupaketteja rajoiteta. Näin hyökkääjä pääsee käsiksi verkon liikenteeseen.

Organisaatiot, kuten palveluntarjoajat, jotka virtualisoivat palveluja voimakkaasti, saavuttavat rajoituksen nopeasti. Rajana on hieman alle 4096 VLAN-verkkoa palvelujen eristämiseen. Virtual eXtensible LAN (VXLAN) ratkaisee tämän rajoituksen ottamalla käyttöön kapselointimenetelmän usean vuokralaisen ympäristöihin. Toisin kuin linkkikerroksessa toimivat VLAN-verkot, VXLAN:it toimivat verkkokerroksessa linkkikerroksen verkkojen jäljittelemiseksi. VXLAN sallii käytännössä jopa 16 miljoonaa erillistä verkkoa, jotka voidaan lisäksi yhdistää VLAN-toiminnolla. Kuten VLAN-verkot, myös VXLAN-verkot eivät pyri tarjoamaan luottamuksellisuutta tai eheyttä yleisesti. Sen sijaan ne ovat keino segmentoida verkkoja. Pahin uhka voi kuitenkin olla verkkokerroksessa, VXLAN-paketit voivat kulkea Internetissä ja sallia hyökkääjien pistää väärennettyjä tietoja VXLAN-pakettitietoihin. Siksi on oltava varovainen tiedonsiirron ohjauksessa, esim. suodattamalla verkon reunasta VXLAN-paketit, jotka sisältävät kelvollisen VXLAN-päätepisteen IP-osoitteen.

Langaton tietoturva (syventävä)

Verrattuna kaapeloituihin verkkorakenteisiin, langaton lähiverkko on erittäin altis tietoturvariskeille johtuen median lähetysluonteesta, joka mahdollistaa helposti salakuuntelun. Historia tuntee useita epäonnistuneita yrityksiä lisätä eheyttä ja luottamuksellisuutta WLAN-tiedonsiirtoon. Alkuperäinen langattomien verkkojen suojaus WEP (Wired Equivalent Privacy) -protokolla käytti symmetristä avaimen salausmenetelmää, jossa isäntä jakaa avaimen tukiaseman kanssa (AP, Access Point) siirtokaistan ulkopuolella. WEP:llä oli useita suunnitteluongelmia. Ensinnäkin 24-bittinen alustusvektori (IV, Initial Vector) toi heikkouden esiin rajoittamalla uniikkien IV vaihtoehtojen määrän noin 16 miljoonaan. Tämä pakettien määrä voidaan käyttää nopeissa yhteyksissä alle kahdessa tunnissa (24-bittiä tarjoaa maksimissaan 16 miljoonaa uniikkia alustusvektoria. Tämän jälkeen seuraavat paketit ja niiden IV toistuu jo käyteyttynä). Ottaen huomioon, että IV:t lähetetään vastaanottajalle pelkkänä tekstinä, salakuuntelija voi helposti havaita tämän uudelleenkäytön ja toteuttaa hyökkäyksen löytääkseen toistuvan IV:n. Hyökkääjän on mahdollista selvittää verkon käyttämä WEP-avain saadessaan samalla alustusvektorilla salatuista paketeista tietoonsa verkon käyttämän WEP-avaimen. Lisäksi RC4 salausalgoritmin käyttö altistaa toteutuksen Fluhrer, Martin ja Shamir (FMS)-hyökkäyksille, jossa hyökkääjä voi palauttaa salausavaimen RC4-salatussa tietopakettivirrassa kaappaamalla riittävän suuren viestien määrän kyseisessä tietopakettivirrassa. Lisäksi WEP:n suojauksen käyttämä lineaarinen CRC oli erinomainen havaitsemaan satunnaisia linkkivirheitä, mutta ei pysty paljastamaan luotettavasti haitallisia viestimuutoksia.

Väliaikainen standardi nimeltä Wi-Fi Protected Access (WPA) kehitettiin nopeasti säilyttämään laitteistojen yhteensopivuutta taaksepäin, kun WPA2:ta kehitettiin. WPA käyttää Temporary Key Integrity -protokollaa (TKIP), mutta ylläpitää RC4-yhteensopivuutta. Esijaettu avain (PSK, Preshared Key) (tunnetaan myös nimellä WPA-Personal), on samanlainen kuin WEP-avain. PSK:ta käytetään kuitenkin eri tavalla, nonce ja PSK tiivistetään aika-avaimen luomiseksi. Tämän jälkeen kryptografista sekoitustoimintoa käytetään yhdistämään väliaikainen avain, Temporal MAC (TMAC) ja sekvenssilaskuri, jonka tuloksena on yksi salausavain (128 bittiä) ja toinen eheyden avain (64 bittiä). Tämän seurauksena jokainen paketti on salattu ainutlaatuisella salausavaimella FMS-hyökkäysten välttämiseksi. Lisäksi WPA laajentaa WEP alustusvektorin 48 bittiin. Useat uudet kehyksen otsikkokentät sisältävät lisätietoja mm. sekvenssitarkistus (FCS)-kentän, CRC-32-tarkistussummakentän virheiden korjaamiseksi sekä kentän eheyden tarkastuksen hajautustoimintoa varten. Taaksepäin yhteensopivuuden varmistamiseksi tehdyistä kompromisseista johtuen WPA:lla on kuitenkin omat heikkoutensa. Keskeisimpänä heikkoutena on esimerkkinä: mikäli WPA suojaus havaitsee yrityksen pakettien manipuloinnista, se sulkee koko verkon ja uudelleen autentikoi kaikki ko. verkon käyttäjät. Tämän kaltainen toiminto katkaisee verkkoyhteyden hetkeksi kaikilta käyttäjiltä. Hyökkääjä voi jatkuvalla tahallisella häirinnällä pitää verkkoa jatkuvassa uudelleen tunnistustilassa, eikä verkkoa voida käyttää normaalisti.

Wifi Alliance standardoi päivityksenä WPA2:n vuonna 2004. WPA2 perustuu tehokkaampiin laitteistoihin (edellyttää käytettävältä laitteistolta suurempaa laskentatehoa vrt. aiempiin salauksiin) ja se tukee 128-bittistä AES-tilaa salauslohkon ketjutusviestillä Authentication-CCP (Counter Mode Cipher Block Chasing Message Authentication Code Protocol). Se tarjoaa myös parannetun 4-suuntaisen kättelyn ja väliaikaisen avaimen luontimenetelmän (joka ei kuitenkaan sisällä salausta eteenpäin). Vaikka tämän kättelytapahtuman toteutukset olivat epävarmoja, yleinen kättelymetodologia on virallisesti tarkistettu ja sen uskotaan edelleen olevan turvallinen.

Vuonna 2018 hyväksyttiin uusi WPA3-standardi, johon asteittain siirrytään ja lopulta lopetetaan WPA2 käyttö. WPA3 poistaa tiedonsiirron salassapidon ongelmat, jotka olivat puutteena WPA:ssa ja WPA2:ssa. PSK korvataan uudella avainjakelulla, jonka nimi on samanaikainen todennus (SAE, Simultaneous Authentication of Equals) perustuu IETF:n Dragon key -avainvaihtoon. WPA3-Personal-tila käyttää 128-bittistä salausta, kun taas WPA3-Enterprise käyttää 192-bittistä salausta.

Edellä oletettiin, että WLAN-käyttäjien ja tukiasemien välillä on yhteinen salaisuus, josta istuntoavaimet voidaan johtaa. Yrityksissä WLAN-yhteyksien pääsynvalvonta hoidetaan yleensä käyttämällä vahvaa todennusta, esim. IEEE802.1X-standardia. Ihannetapauksessa WLAN-käyttäjillä on omat asiakassertifikaatit, jotka tarjoavat paljon paremman suojan kuin mikään muu kohtuullisen käyttäjäystävällinen salasana. Sitä vastoin avoimesti saatavilla olevissa verkoissa, kuten lentokentillä tai ravintoloissa jne. yleisissä tiloissa saatavilla oleva langaton asiakasverkko, PSK:ita tai sertifikaatteja ei saa olla (mikäli haluttaisiin turvallista, luotettavaa, suojattua tiedonsiirtoa). (Tässä yhteydessä on tiedostettava ja erotettava halutaanko suojata tiedonsiirtoa vai rajoittaa verkkoon pääsyä.) Vahvan salauksen puuttuessa se jättäisi viestinnän suojaamatta. Opportunistinen langaton salaus (OWE, Opportunist Wireless Encryption) käsittelee tätä avointa ongelmaa. Sen sijaan, että käytetään PSK:ta WPA2/3-nelivaihesta kättelytapahtumaa, asiakas ja tukiasema käyttävät kaksisuuntaista salaisuutta, joka on johdettu alkuperäisestä Diffie-Hellman-Merkle-avaintenvaihtomenetelmästä.

Palautusta lähetetään...