SSL/TLS Best Practices
Verkkoliikenne on jo suojattua, eikö se riitä?
Tänä päivänä jo yli puolet verkkoliikenteestä kulkee salattuna. Tämä on hyvä suuntaus, mutta pelkkä salauksen lisääminen verkkosivulle ei ole lopullinen ratkaisu. SSL/TLS-salauksen purkaminen vaatii hurjasti konevoimaa, eikä sen onnistuminen siitäkään huolimatta ole varmaa. Verkkorikollisten on paljon helpompaa etsiä palvelimestasi tietoturva-aukko ja hyödyntää sitä. Kun palvelimelle on päästy, on mahdollista kaapata myös varmenteen Private Key, jolloin itse salaus on myös rikottu.
Erilaisia palvelinalustoja on paljon. Suosittuja web- palvelinalustoja ovat esimerkiksi Apache, NGINX ja IIS.
Jos palvelimesi on palveluntarjoajan kautta hankittu, on todennäköistä, että se on suojaukseltaan kohtuullisella tasolla. Tämä luonnollisesti riippuu siitä, miten aktiivinen toimija palveluntarjoajasi on. Oman palvelimesi turvan voit tarkistaa SSL Server Testillä (SSL Labs) .
Jos yllämainitun linkin kautta avautuvat tiedot eivät kerro sinulle mitään, kannattaa kääntyä asiantuntijoiden puoleen. Ota yhteyttä meihin, jos emme osaa auttaa, osaamme ohjata sinut oikeaan suuntaan ja säästää aikaasi. Osaamme SSL/TLS-varmenteiden käytön, mutta emme edes yritä syleillä koko tietoturvamaailmaa, koska se rikkoisi fokuksemme: Parasta palvelua SSL/TLS-varmenteissa.
RSA-, vai ECC-avain?
Useimmille palveluille ja sivustoille riittää 2 048-bittisten RSA-avainten tarjoama suoja. Julkisen avaimen RSA-algoritmi on laajalti tuettu, mikä tekee tämän tyyppisistä avaimista turvallisen oletusvaihtoehdon. 2048 bitin avaimet tarjoavat noin 112 bitin suojan. Järeämpää suojaa tavoiteltaessa tulee huomioida, että RSA-avaimet eivät skaalaudu kovin hyvin. Esimerkiksi 128 bittisen suojauksen saamiseksi tarvitaan 3 072-bittinen RSA-avain, joka on huomattavasti hitaampi. Vaihtoehtona ovat ECC (Elliptic Curve Cryptography) -avaimet, jotka tarjoavat paremman suojan sekä suorituskyvyn. 256 bitin ECC-avaimella saadaan 128 bitin suojaus. Jotkin vanhemmista clienteista eivät tue ECC:tä, mutta nykyaikaisilla clienteillä tätä ongelmaa ei ole.
Suojaa Private key
Käsittele Private Key:tä huolellisesti, tähän käsiksi pääseminen tulisi rajoittaa käytännöllisyyden rajoissa mahdollisimman suppealle henkilömäärälle.
Private Key tulee generoida tietoturvallisesti luotetussa/suojatussa ympäristössä ja suojata salasanalla, mikäli ne tallennetaan erillisinä tiedostoina. On myös erillisiä laitteistoja (Hardware Security Module/HSM), joilla avaimet voidaan säilyttää suojattuina. Nämä tosin ovat hintavia ja usein käytössä vain isommilla organisaatioilla.
Mikäli on syytä epäillä Private Key:n vaarantumista, revokoi varmenteet ja luo uudet avaimet.
Varmenteet tulee uusia ajoissa ja tarpeeksi usein. Nykysäädösten mukaan kaikkein julkisten SSL/TLS-varmenteiden elinikä on maksimissaan noin yksi vuosi. Varmennetta uusittaessa tulisi aina myös luoda uudet avaimet, ellei samojen avainten käyttämiseen ole pakottavaa syytä.
Hostname-kattavuus
Varmista, että varmenne kattaa kaikki osoitteet/isäntänimet, joita haluat käyttää palvelussasi tai sivustollasi. Näin vältät tästä johtuvat virheilmoitukset, jotka hämmentävät käyttäjiä ja herättävät epäluottamusta.
Useimmissa tapauksissa tulee myös varmistaa, että varmenne toimii palvelun osoitteille sekä www-etuliitteellä, että ilman (esimerkki.com / www.esimerkki.com). Nyrkkisääntönä on, että suojatulla verkkopalvelimella tulee olla varmenne, joka on voimassa jokaiselle DNS-nimelle, joka on määritetty osoittamaan siihen.
Lisää kaikki tarvittavat verkkotunnukset varmenteen Subject Alternative Name (SAN) -kohtaan, koska kaikki uusimmat selaimet eivät tarkista varmenteen Common Namea vahvistusta varten.
Valitse luotettava CA
Varmennetuottajille suoritetaan säännöllisiä auditointeja, mutta toiset CA:t suhtautuvat tietoturvaan vakavammin kuin toiset. Parhaan vaihtoehdon valitseminen ei ole välttämättä helppoa, mutta yksi keino on tarkastella CA:n historiaa, ja mikä tärkeintä, miten se on reagoinut kohtaamiinsa ongelmiin ja onko virheistä otettu opiksi.
Varmennetuottajan tulee tarjota vähintään tuki sekä Certificate Revocation -listaukselle (CRL) että Online Certificate Status -protokollalle (OCSP) ja optimaaliselle suorituskyvylle.
Kaikki CA:t tarjoa kuin domain validoituja (DV) varmenteita. Lisäksi kannattaa tarkistaa löytyykö varmennetuottajalta tuki sekä RSA-, että ECDSA-avain-algoritmillä tuotetuille varmenteille. Suorituskykyetujensa vuoksi ECDSA:sta saattaa tulla tulevaisuudessa kannattavampi vaihtoehto.
Varmenteiden hallintaympäristön käytettävyys vaihtelee eri varmennetoimittajilla. Etenkin tapauksissa, joissa tarvitaan suuri määrä varmenteita, on hyvä valita CA, joka tarjoaa hyvät työkalut varmenteiden hallintaan.
Valitse CA, joka tarjoaa myös teknisen tuen tuotteisiinsa liittyen.
SHA (Secure Hash Algorithm)
Varmenteen suojaustasoon vaikuttaa sekä sen allekirjoittamiseen käytetyn yksityisen avaimen, että hajautusalgoritmin (SHA/Secure Hash Algorithm) vahvuus. Aiemmin varmenteissa käytettiin SHA1-algoritmia, jota pidetään nykyisin turvattomana siinä ilmenneiden haavoittuvuuksien vuoksi.
Tämän seurauksena on siirrytty käyttämään SHA2 -algoritmia, eivätkä valveutuneet CA:t ole toimittaneet SHA1-algoritmilla allekirjoitettuja varmenteita enää vuoden 2016 jälkeen.
DNS CAA Record
DNS:n CAA-merkinnän avulla domainin omista voi tarvittaessa rajoittaa, mitkä varmennetoimittajat voivat myöntää varmenteita kyseiselle domainille. Jos tietuetta ei ole määritetty/se on tyhjä, ei myöskään rajoitetta ole. Mikäli CA:lla on käytössä automatisoitu prosessi varmenteiden myöntämiseksi, sen tulee tarkistaa DNS CAA -tietueet. Tämä vähentää varmenteiden epäasianmukaista myöntämistä. Englanninkieliset ohjeet CAA-merkinnän lisäämiseen löytyy täältä.
Myös CAA-recordin tarkistamiseen löytyy työkaluja useista eri lähteistä, täältä löydät Entrustin vastaanvan hakukoneen.
Mixed Content -ongelma
Selain varoittaa, että sivustosi ei ole turvallinen. Tarkempi kuvaus paljastaa, että sivustolla on ns. Mixed Content- ongelma. Sisällössä oleva linkki johtaa toiseen html-sivuun, joka ei käytä https-liikennettä vaan on http -linkki. Alla mahdollisia ratkaisuja palvelimen konfigurointiin.
Lähde: badssl.com
HTTP Strict Transport Security (HSTS)
Tällä menetelmällä ehkäistään tilanne, jossa verkkorikollinen on pääse käsiksi käyttäjän ja web-sivuston väliseen liikenteeseen, eli toteutetaan ns. "man-in-the-middle" (MITM) hyökkäys. Taustana tälle on se, että jos web-sivustolle mennään antamalla selaimeen esimerkiksi vain domain-nimi: ssl-apua.fi, on ensimmäinen pyyntö, joka palvelimelle tulee, aina salaamaton. Tai, jos sivulle mennään linkillä https://ssl-apua.fi - sama juttu. HSTS-asetus palvelimella pyrkii pakottamaan kaiken liikenteen salatuksi, eli opastaa selainta, että tänne web-sivustolle pitää tulla https-liikenteellä.
Content Security Policy (CSP)
Jotta päästään kohtuullisen turvalliseen web-palveluun, tämäkin asetus kannattaa edellä mainitun lisäksi ottaa käyttöön. Tämä blokkaa mahdollisuuden käyttää turvattomia (http) linkkejä kolmansien osapuolten toimesta, eli sen, että joku kumppanisi tai muu ulkopuolinen taho lisää linkin omille sivuilleen ja linkittää sinne tietoa sinun sivuiltasi. Content Security Policy pakottaa tämänkin liikenteen salatuksi. Lisätietoa ja määritysohjeet Mozillan sivulla tämän linkin takana.
Vanhentuneet tai poistuneet Cipher Suitet
Cipher suite, joka palvelimelle on määritelty (näitä on yleensä useita), määrittää sen kuinka selaimen ja palvelimen välinen yhteys autentikoidaan ja mitä kryptausmenetelmää käytetään. Cipher Suiteja ovat esimerkiksi TLS 1.0 - 1.2 ja tuoreimpana TLS 1.3.
Käytä vain voimassaolevia, turvallisia Cipher Suiteja palvelimella.
SSL/TLS-protokollia on kuusi: SSL v2, SSL v3, TLS v1.0 ,TLS v1.1, TLS v1.2 ja TLS v1.3. SSL v2- ja SSL v3-protkollat ovat jo vanhentuneita ja niitä ei tule käyttää. Maaliskuussa 2021 IETF (The Internet Engineering Task Force) antoi julkaisun, jonka mukaan myös TLS 1.0 ja TLS 1.1 prokollat on muodollisesti poistettu käytöstä. Tämän myötä näiden käyttöä ei enää suositella, joskin osa selaimista on evännyt tuen näille jo aiemmin (Chrome, Firefox, Internet Explorer).
Lähde: badssl.com
Palvelimen/sovellusten PEN-testaus
PEN-Testaus on ystävällismielistä hakkerointia, joka suoritetaan suunnitellusti ja luvallisesti. Testaukseen erikoistuneet asiantuntijat pyrkivät löytämään haavoittuvuuksia palvelustasi ennalta sovituin tavoin. Tavoitteena on löytää palvelusta sellaisia puutteita, jotka voisivat mahdollistaa vihamielisen hyökkäyksen tai tietomurron kohteeseen. PEN-testauksen tuloksena saadaan raportti löydöksistä ja jopa korjausehdotuksia.
PEN-testaus on turvallinen tapa selvittää palveluiden mahdollinen haavoittuvuus. PEN-testausta tarjoavat myös kotimaassamme esimerkiksi jotkin tähän erikoistuneet IT-alan yritykset.
Suositeltava tapa tehdä PEN-testaus on kohdistaa se testiympäristöön. PEN-testaus voi olla hyvinkin tunkeileva ja vaikka tarkoituksena ei ole rikkoa kohdejärjestelmä, se voi aiheuttaa tiedon korruptoitumista ja palvelun rikkoontumista. Vaikka PEN-testaus on syväluotausta palvelun heikkouksiin, sen jäljiltä voi jäädä haavoittuvuuksia.
Lähes kaikki järjestelmät voivat sisältää haavoittuvuuksia, joiden löytäminen on aikaa vievää. Joskus niitä ei omin neuvoin edes voi korjata. Usein haavoittuvuudet löytyvät jostain kolmannen osapuolen komponentista, johon voi vaikuttaa ainoastaan komponentin tekijä.