Protokollan ominaisuudet
rsa
dss
pgp
TLS-protokollan kättely
Paras lähde TLS-protokollan toiminnan ymmärtämiseen on sitä käsittelevä standardi (RFC-5246: The Transport Layer Security (TLS) Protocol Version 1.2). Tärkein ja monimutkaisin osa-alue protokollassa koskee kättelyä, jonka aikana osapuolet tunnistavat toisensa, neuvottelevat käytettävästä salauksesta ja neuvottelevat yhteyden aikana käytettävistä salausavaimista. Lisäksi suurin osa erilaisista ongelma- ja virhetilanteista johtuu siitä, että toinen kättelyn osapuolista ei hyväksy vastapään tarjoamia varmenteita tai salausalgoritmeja.
Seuraavassa on esitetty TLS-protokollan version 1.2 kättelyn kulku, kopioituna RFC-tekstistä. Versiossa 1.3 kättely tulee muuttumaan siten, että asiakas lähettää opportunistisesti enemmän tietoja itsestään käynnistäessään kättelyn, jolloin yhteys voidaan usein muodostaa vähemmällä keskustelulla. Periaatteessa tämä ei tule muuttamaan protokollan ominaisuuksia, mutta nopeuttaa kättelyä tyypillisesti useilla kymmenillä tai jopa sadoilla millisekunneilla.
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not
always sent.
TLS-kättelyn vaiheet toimivat karkeasti kuvattuna seuraavalla tavalla (kuten edellä mainitaan, tähdellä merkityt eivät ole pakollisia vaiheita):
- ClientHello: Asiakasohjelmisto aloittaa kättelyn lähettämällä session tunnisteena toimivan satunnaisnumeron ja kertomalla tukemansa ominaisuudet (esim. pakkaus- ja salausalgoritmit).
- ServerHello: Jos sekä asiakkaan että palvelimen tukemien ominaisuuksien listoilta löytyy käytettävissä oleva yhdistelmät, palvelin ilmoittaa yhteydessä käytettävät ominaisuudet.
- Certificate*: Palvelin lähettää käyttämänsä varmenteen ja siihen liittyvän varmennepolun.
- ServerKeyExchange*: Palvelin käynnistää yhteyden salauksen avaintenvaihdon. Sanoman sisältö riippuu aiemmin neuvotelluista avaintenvaihdon algoritmeista. Nykyään yleisimmin päädytään Diffie-Hellman -algoritmiin ja sanoma sisältää palvelimen allekirjoittamat satunnaisluvut, jotka myöhemmin yhdistettynä asiakkaan satunnaislukuihin muodostavat satunnaisen kertakäyttöisen salausavaimen. Palvelimen allekirjoituksen perusteella asiakas voi todentaa, että palvelimen edellisessä sanomassa (Certificate) lähettämät varmenteet ovat palvelimen hallinnassa.
- CertificateRequest*: Jos palvelin vaatii myös asiakkaan tunnistautuvan varmennepohjaisesti, palvelin kertoo asiakkaalle hyväksyttävät varmennetyypit ja varmentajat.
- ServerHelloDone: Palvelin ilmoittaa lähettäneensä toistaiseksi kaikki kättelyyn liittyvät sanomat ja odottavansa asiakkaan vastausta.
- Certificate*: Jos palvelin pyysi asiakasta tunnistautumaan (CertificateRequest) ja asiakkaalta löytyy yksi tai useampia hyväksyttävissä olevia varmenteita, asiakas lähettää varmenteet.
- ClientKeyExchange: Asiakas lähettää vastineensa aiemmin palvelimen lähettämään avaintenvaihdon käynnistyssanomaan (ServerKeyExchange). Useimmiten sanoma sisältää Diffie-Hellman -haasteen vastauksen, jonka perusteella molemmat osapuolet kykenevät muodostamaan yhteisen kertakäyttöisen salausavaimen.
- CertificateVerify*: Jos asiakas lähetti varmenteita (CertificateRequest, Certificate), asiakas lähettää edellisten kättelyn vaiheiden allekirjoituksen, joka on muodostettu käyttäen varmenteisiin liittyviä yksityisiä avaimia. Siten palvelin voi todentaa, että varmenteet ovat asiakkaan hallinnassa.
- ChangeCipherSpec: Asiakas kertoo vaihtavansa salattuun yhteyteen käyttäen tiettyjä salaualgoritmeja.
- Finished: Asiakas kuittaa kättelyn päättyneeksi.
- ChangeCiprherSpec: Palvelin kertoo vaihtavansa salattuun yhteyteen käyttäen tiettyjä salaualgoritmeja.
- Finished: Palvelin kuittaa kättelyn päättyneeksi.
- Application Data: Asiakas ja palvelin vaihtavat keskenään tietoja TLS-yhteydellä.
Jokainen TLS-protokollan vaiheista voi päätyä virheeseen, jolloin virheen havainnut osapuoli lähettää toiselle osapuolelle virhesanoman. Kaikki virhesanomat (ks. alla) ovat kuvattu tarkemmin RFC-dokumentissa ja niihin perehtyminen voi auttaa vianselvityksessä merkittävästi.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Useimmat virhetilanteet johtavat TLS-protokollan kättelyn tai muun sanomanvaihdon keskeytymiseen (fatal). Varoitukset (warning) ovat varsin harvinaisia.
Salausalgoritmeista
TLS tarvitsee toimiakseen yhdistelmän erilaisia salausalgoritmeja. Sallitut yhdistelmät vaihtelevat TLS-protokollan versionumeron mukaan. Jokaisella valitulla salausalgoritmilla on vaikutus yhteyden turvallisuuteen. Erityisesti vanhemmat TLS-versiot tukevat hyvinkin turvattomia yhdistelmiä, kun taas uusimmissa (1.2 & 1.3) versioissa vaaralliset yhdistelmät ovat harvinaisempia.
TLS-yhteys muodostuu konsensusperiaatteella siten, että turvallisin yhteyden osapuolten tukema yhdistelmä valitaan käyttöön. Teknisten toteuttajien on kuitenkin oltava tietoisia mahdollisista yhdistelmistä ja varmistettava, että toteutukset tukevat turvallisia ja estävät vaaralliset yhdistelmät. Tätä varten on tarjolla erilaisia apuvälineitä kuten Mozilla SSL Configuration generator ja standardeja kuten kansalliset kryptografiset vahvuusvaatimukset.
Alla on esitetty yksi esimerkki mahdollisista salausalgoritmien yhdistelmistä. Yhdistelmä on turvallisimmasta päästä, eivätkä vanhemmat ohjelmistot välttämättä tue jokaista mainituista ominaisuuksista.
| Algoritmin tyyppi | Algoritmin tunniste | Kuvaus |
|---|---|---|
| Algoritmiyhdistelmän koko nimi | ECDHE-ECDSA-AES-256-GCM-SHA384 | TLS 1.2 -versiossa standardoitu yhdistelmä |
| Avaintenvaihto | ECDH - Elliptic Curve Diffie-Hellman | Diffie-Hellman -algoritmin avaintenvaihto, jota käytetään tietoliikenneyhteyden alustamiseen. |
| Sessiokohtaiset avaimet | E - Ephemeral | Varsinaista viestien salausta varten muodostetaan kertakäyttöiset avaimet, jotka vaihdetaan osana avaintenvaihtoa. Tämä vaikeuttaa tietoliikenteen salauksen purkamista myöhemmin, vaikka osapuolten käyttämien varmenteiden salausavaimet vaarantuisivatkin. |
| Tunnistautuminen | ECDSA - Elliptic Curve Digital Signature Algorithm | Osapuolet tunnistautuvat suorittamalla allekirjoitusoperaation elliptisten käyrien avaimilla ja varmenteilla. |
| Salaus | AES-256-GCM | Tietoliikenne salataan käyttäen AES-256 -algoritmia Galois-Counter -tilassa. |
| Sisällön eheys | AEAD | Sisällön eheyttä ei tarvitse erikseen tarkistaa, koska GCM sisältää jo tarvittavat ominaisuudet. |
| Tiivistefunktio | SHA384 | Tiedon sijaan allekirjoitetaan tiivisteitä, jotka muodostetaan algoritmilla SHA-384. |
Forward secrecy
Kun julkisen avaimen salausjärjestelmän yhteydessä käytetään kertakäyttöisiä satunnaisia salausavaimia, yksittäisen sanoman salausavaimien vaarantuminen ei vaaranna muiden sanomien turvallisuutta. Ominaisuus tunnetaan nimellä forward secrecy tai joskus perfect forward secrecy.
Forward secrecy toimii siten, osapuolet tunnistavat toisensa hyödyntäen varmenteita ja sähköisiä allekirjoituksia. Tämän jälkeen muodostetaan satunnainen salausavain käyttötarkoitukseen suunnitellulla avaintenvaihdon algoritmilla (yleensä Diffie-Hellman) ja käytetään satunnaista salausavainta myöhemmissä vaiheissa. Salausavain tuhotaan välittömästi yhteyden päätyttyä, joten salauksen purkaminen ei ole enää mahdollista.
Ennen forward secrecy -ominaisuutta palvelimen yksityisen avaimen vaarantuminen on johtanut siihen, että tietoliikenteen turvallisuus on vaarantunut takautuvasti. Jos jollakulla on ollut hallussaan esimerkiksi tietoliikenteen äänite aiemmista yhteyksistä, niiden sisältö on ollut myöhemminkin purettavissa. Forward secrecy onkin kehitetty antamaan lisäsuojaa varmenteiden yksityisten avaimien vaarantumista vastaan.
Listan TLS:n tukemista forward secery -algoritmiyhdistelmistä pystyy tulostamaan seuraavalla komennolla. Komento sisältää lisäksi valitsimet, jotka poistavat yleisesti turvattomina pitämät salausalgoritmit listalta.
$ openssl ciphers -v 'HIGH+ECDH HIGH+DH !aNULL'
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256) Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256) Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(128) Mac=SHA256
ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256) Mac=AEAD
DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128) Mac=AEAD
DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
Laajemmissa yritysympäristöissä forward secrecy aiheuttaa valitettavasti haasteita. Usein on tarpeen, että yrityksen tietoliikennettä pystytään suojaamaan tunkeilun havaitsemisjärjestelmillä (engl. Intrusion Detection System) ja estämisjärjestelmillä (engl. Intrusion Prevention System). Aiemmin em. järjestelmille voitiin antaa kopiot yrityksen palvelimien yksityisistä avaimista, jolloin tuotteet kykenivät tarkkailemaan ikäänkuin sivusta tietoliikennettä purkaen tietoliikenteen salauksen.
Ongelma on kierrettävissä mm. siten, että tietoliikenteen tarkkailu sijoitetaan varsinaisten palvelimien ja TLS-terminoinnin (esimerkiksi älykäs kuormantasaaja) väliin. Lisäksi palvelinsovelluksiin voidaan upottaa agentit, jotka ottavat ylös muodostetut kertakäyttöiset salausavaimet ja välittävät ne tietoliikennettä tarkkaileville tuotteille. Molemmat vaihtoehdot monimutkaistavat teknistä toteutusta merkittävästi.