slo | eng

TLS/SSL (Transport Layer Security/Secure Socket Layer)

Sergej Rožman, 5. 3. 2008

Uvod

TLS (Transport Layer Security) je standardizirana verzija protokola SSL (Secure Socket Layer), ki je bil razvit pri korporaciji Netscape Communications za izmenjavo zasebnih dokumentov preko povezav skozi nevarna omrežja (npr. Internet).

SSL protokol je bil predstavljen leta 1994. 1999 leta je bil izdelan standard za TLS protokol verzije 1.0, ki je interno predstavljen kot SSL verzije 3.1. To je danes aktualna verzija.

TLS protokol uporablja šifriranje, ki temelji na kombinaciji asimentričnih in simetričnih postopkov ter uporablja pretočni ali blokovni način šifriranja. TLS in SSL imajo vgrajeni vsi danes prisotni spletni brkljalniki in zaradi tega je najbolj razširjen protokol za varno komuniciranje. Veliko spletnih strani uporablja TLS ali SSL protokol pri vpogledu v zaupne informacije, npr. številke kreditnih kartic.

Značilnosti in standardi

TLS protokol v verziji 1.0 je standardiziran s strani IETF (The Internet Engineering Task Force) v standardu RFC 2246. Njegov predhodnik SSL nima internetnega standarda, ampak je opisan le v publikaciji izdani od korporacije Netscape Communications [SSL].

Netscape je rezerviral naslednje številke za vrata aplikacijskih protokolov nad SSL:

aplikacijski protokol številka TCP vrat
https 443
ssmtp 465
nntps 563
SSLshell 614
ssl-ldap 636
ftps-podatki (ftps-data) 989
ftp-kontrolni (ftps) 990
telnets 992
imap4 (imaps) 993
pop4 (pops) 995

Pri snovanju TLS protokola so imeli v mislih naslednje lastnosti:

Zaupnost

TLS protokol mora zagotavljati zaupnost in celovitost prenosa podatkov med dvema sistemoma.

Medsebojna združljivost

TLS protokol je standardiziran. Skladnost s standardom v splošnem zagotavlja medsebojno komunikacijo naprav različnih proizvajalcev, ki jim ni treba poznati natančne implementacije protokolov na drugi strani.

Kljub skladnosti s standardom je možno, da različne implementacije med sabo v nekaterih primerih ne morejo vzpostaviti komunikacije. Standard namreč omogoča uporabo več vrst overjanja in šifrirnih postopkov, vendar ne predpisuje, da morajo vsi sistemi imeti vgrajene vse vrste. Če se klient in strežnik ne moreta uskladiti o uporabi skupnih varnostnih parametrov, potem seje med njima ni mogoče vzpostaviti.

Razširljivost

TLS protokol je zasnovan tako, da je možno brez večjih predelav dodajati nove šifrirne postopke brez vpliva na združljivost s trenutnimi verzijami. Protokol trenutno pozna približno trideset kombinacij overjanja, šifriranja in zaščite podatkov (MAC).

Učinkovitost

Šifrirne operacije, še posebno asimetrične, so računsko zelo zahtevne. Iz optimizacijskih razlogov ima TLS protokol možnost začasnega pomnenja končanih sej. Standard priporoča možnost pomnenja sej najdlje do 24 ur.

V kolikor pride v tem času do nove zahteve po komunikaciji z istim klientom, se lahko uporabi stara shranjena seja, ki že vsebuje vse potrebne varnostne parametre. S tem se izognemo potratnemu začetnemu usklajevalnemu postopku in izberemo poenostavljen usklajevalni postopek.

O vsaki seji si strežnik shrani sledeče parametre:

  • identifikator seje, ki nedvoumno določa sejo,
  • certifikat nasprotne strani,
  • varnostne parametre,
  • metodo stiskanja podatkov,
  • glavni ključ,
  • oznako – zastavico, ki označuje, če je sejo mogoče ponovno uporabiti.

Iste parametre mora poznati tudi klient, da je sposoben nadaljevati sejo.

Posamezna seja lahko vsebuje tudi več sočasnih povezav, ki uporabljajo iste parametre. Tudi v tem primeru pri vzpostavljanju uporabimo poenostavljen usklajevalni postopek.

Protokolni sklad

TLS protokol je sloj med transportnim in aplikativnimi sloji. Preverjanje vrstnega reda prihajajočih paketov in sprememb ter napak v paketih prepušča nižje ležečemu protokolu, zato mora biti ta zanesljiv (TCP, ne UDP).

Osi TCP/IP TCP/IP s TLS
aplikacijski sloj aplikacijski sloj aplikacijski sloj
predstavitveni sloj
sejni sloj TLS
transportni sloj TCP, UDP TCP
omrežni sloj IP IP
povezavni sloj omrežje omrežje
fizični sloj

Težko presodimo ali TLS sodi med aplikativne ali k transportnemu sloju.

Glede na dejstvo, da je ponavadi TLS sloj integralni del aplikacij, npr. spletnih strežnikov in spletnih brkljalnikov, bi presodili, da bolj sodi k aplikativnim slojem.

Vendar obstajajo tudi produkti, ki jih neodvisno od aplikacij namestimo na sistem in tako v protokolni sklad neodvisno od aplikativnih slojev namestimo TLS sloj. Ta zagotavlja komunikacijo preko TLS protokola različnim aplikacijam (POP3, IMAP, LDAP, SMTP…) brez posegov v samo aplikacijo. Primer produkta te vrste je stunnel (http://www.stunnel.org/).

Nad TLS sloj lahko namestimo celo nekatere nižje ležeče omrežne sloje, npr. PPP, in tako dobimo funkcionalnost tuneliranja. S povezovanjem omrežij na ta način lahko zgradimo navidezno zasebno omrežje (VPN).

Pri izdelavi nove aplikacije, ki ima vgrajen TLS protokol, nam ni treba od začetka pisati vseh procedur in funkcij za overjanje, šifriranje, delo s certifikati ipd. V ta namen že obstajajo izgotovljene knjižnice (npr. http://www.openssl.org/). S tem zmanjšamo možnost varnostnih napak v implementaciji, saj veliko število uporabnikov ves čas testira izgotovljene procedure in razvijalci sproti odpravljajo ugotovljene nepravilnosti.

Sestava protokola TLS

Sestava TLS protokolnega sloja

usklajevalni
protokol		 alarmirni
protokol 		protokol
sprememba
šifritanja
TLS transportni protokol

Naloge TLS transportnega protokola pri pošiljanju:

  • prevzame sporočilo od zgornjega aplikativnega sloja ali od enega kontrolnih slojev TLS protokola in ga razdeli na kose po 16 k-oktetov,
  • podatkovne pakete stisne (opcijsko),
  • izračuna in na koncu doda zaščitno MAC polje,
  • dobljene pakete šifrira in preda nižje ležečemu transportnemu sloju.

Naloge TLS transportnega protokola pri sprejemanju:

  • od transportnega sloja prejme paket in ga odšifrira,
  • nad podatki izračuna MAC vrednost in jo primerja s sprejeto na koncu paketa,
  • podatkovne pakete razširi (opcijsko),
  • pakete sestavi in jih preda zgornjemu aplikativnemu ali kontrolnemu TLS sloju.

Vsebina TLS paketa

upoštevano pri izračunu MAC
tip
1 oktet		 verzija
2 okteta		 dolžina
2 okteta		 podatki
do 18 oktetov		 MAC+polnilo+dolžina_polnila
do 276 oktetov
šifrirano

Polje tip določa vrsto TLS protokola:

  • vrednost 20: protokol sprememba šifriranja,
  • vrednost 21: alarmirni protokol,
  • vrednost 22: usklajevalni protokol,
  • vrednost 23: podatki aplikativnega sloja.

Le v primeru uporabe blokovnega šifrirnega algoritma, je na koncu paketa dodano polnilo. Namen polnila je, da je dolžina paketa enaka večkratniku šifrirnega bloka in za težjo ugotovljivost velikosti šifrirnega bloka in šifrirnega postopka.

Izračun zaščitnega MAC polja

Zaščitno MAC polje izračunamo kot: 

MAC = HMAC_hash(MAC_ključ + zap_št + prva_štiri_polja_TLS_paketa)

kjer "+" pomeni združevanje nizov.

MAC_ključ ključ izračunan iz varnostnih parametrov dogovorjenih z usklajevalnim protokolom. Klient in strežnik uporabljata različen ključ za tvorjenje zaščitnega MAC polja. zap_št zaporedna številka paketa. Paketi so oštevilčeni, da je mogoče odkriti vsako izgubo ali vrivanje dodatnega paketa. Številka paketa ni nikjer eksplicitno zapisana v paketu. Klient in strežnik morata šteti pakete in po preračunu MAC vrednosti se mora ta ujemati z vrednostjo v zaščitnem MAC polju. Po vsakem usklajevalnem postopku se pričnejo paketi šteti ponovno od nič. HMAC_hash zaščitni algoritem dogovorjen v usklajevalnem protokolu. Trenutno sta v protokolu predvideni dve možnosti: MD5 in SHA-1.

Zaščitno MAC polje se izračuna pred šifriranjem [CRYPT str 366]. Šifrira se celotni blok vključno z zaščitnim MAC poljem.

Šifriranje

TLS protokol uporablja simetričen šifrirni postopek za šifriranje podatkov, blokovni ali pretočni. Uporablja različen šifrirni ključ za vsako smer podatkov, zato morata klient in strežnik poznati vsak po dva šifrirna ključa. Ker se pri blokovnem, kot npr. RC2 ali DES, šifriranju uporablja CBC verižno šifriranje [CRYPT str. 228], morata poznati tudi dva začetna inicializacijska vektorja.

Določitev funkcije za psevdo generiranje naključnih nizov – PRF()

Najprej določimo iteracijsko razširitveno funkcijo: 

P_hash(ključ, seme) = HMAC_hash(ključ, A(1) + seme) + HMAC_hash(ključ, A(2) + seme)
+ HMAC_hash(ključ, A(3) + seme) + ...

kjer je funkcija A() določena kot: 

A(0) = seme 

A(i) = HMAC_hash(ključ, A(i-1))

Potrebno je toliko iteracij, da dobimo potrebno količino izhodnih podatkov – HMACMD5 : 16 oktetov/iteracijo, HMACSHA-1 : 20 oktetov na interacijo.

Izhodni niz iz razširitvene funkcije razpolovimo na S1 in S2. Če je število oktetov liho, podvojimo zadnji oktet niza S1 kot prvi oktet niza S2.

Na koncu določimo funkcijo PRF() kot XOR kombinacijo dveh nizov: 

PRF(ključ, oznaka, seme) = P_MD5(S1, oznaka + seme) XOR P_SHA-1(S2, oznaka + seme)

Glavni ključ

Obe strani izračunata glavni ključ po formuli: 

glavni_ključ = PRF(pomožni_ključ, »master secret«, klientov_naključni_niz + strežnikov_naključni_niz)
  • glavni ključ: je vedno dolg 48 oktetov. Po izračunu glavnega ključa morata obe strani izbrisati pomožni ključ.
  • pomožni ključ: tvori klient pri usklajevalnem sporočilu »klientova izmenjava ključa« in asimetrično šifriranega pošlje strežniku.
  • klientovnaključniniz: psevdo naključni niz, ki ga tvori klient v klientovem pozdravnem sporočilu.
  • strežnikovnaključniniz: psevdo naključni niz, ki ga tvori strežnik v strežnikovem pozdravnem sporočilu.

Ostali parametri

TLS transportni protokol uporabi varnostne parametre dogovorjene z usklajevalnim protokolom za tvorjenje naslednjih parametrov:

  • klientov MAC ključ,
  • strežnikov MAC ključ,
  • klientov simetrični šifrirni ključ,
  • strežnikov simetrični šifrirni ključ,
  • klientov inicializacijski vektor IV (samo za blokovni šifrirani postopek),
  • strežnikov inicializacijski vektor IV (samo za blokovni šifrirni postopek).

Postopek generiranja parametrov se precej razlikuje glede na izvozne omejitve šifrirnih postopkov. Iz varnostnih parametrov dogovorjenih v usklajevalnem postopku tvorimo podatkovni niz: 

blok = PRF(glavni_ključ, »key expansion«, strežnikov_naključni_niz + klientov_naključni_niz)

Uporabiti je treba toliko iteracij, da dobimo zadostno dolžino niza za dogovorjen šifrirni postopek. Izhodni niz se potem razseka po vrsti na zgoraj naštete parametre (klientov in strežnikov MAC ključ, klientov in strežnikov simetrični šifrirni ključ, klientov in strežnikov inicializacijski vektror IV (v kolikor gre za blokovni šifrirni postopek). Končni ostanek niza se zavrže.

Če je v uporabi izvozni šifrirni postopek, se vsi parametri nadalje še nekoliko obdelajo.

Dobljene vrednosti parametrov so končne vrednosti ključev za šifriranje aplikativnih podatkov.

Specifikacije protokolov

TLS protokol sestavljajo štiri vrste protokolov:

  • TLS transportni protokol,
  • protokol »sprememba šifriranja«,
  • alarmirni protokol,
  • usklajevalni protokol.

Protokol »sprememba šifriranja«

sprememba šifriranja = 1
1 oktet

Protokol »sprememba šifriranja« se uporablja za obveščanje nasprotne strani o spremembi strategije šifriranja.

Protokol »sprememba šifriranja« je samostojno sporočilo dolgo natanko en oktet z vsebino 1, ki je tudi stisnjeno in šifrirano, vendar z uporabo do tega trenutka veljavnimi parametri in ne z na novo dogovorjenimi.

Sporočilo pošljeta oba. To je indikator, s katerim klient in strežnik drug drugega obvestita, da bodo od tega trenutka naprej vsa sporočila šifrirana na novo dogovorjen način.

Pred tem sporočilom se morata klient in strežnik z usklajevalnim protokolom dogovoriti o novih varnostnih parametrih.

Nepričakovan sprejem brez dogovora o novih varnostnih parametrih sproži usodno napako »nepričakovano sporočilo«.

V primeru nove komunikacije po shranjeni seji si strani izmenjata to sporočilo po začetnih pozdravnih sporočilih.

Alarmirni protokol

alarmna stopnja
1 oktet		 opis
1 oktet

Alarmirni protokol je namenjen obveščanju nasprotne strani o napakah in drugih pomembnih dogodkih. Obravnava napak pri TLS protokolu je zelo enostavna. Stran, ki odkrije napako, pošlje alarmirno sporočilo s specifikacijo napake nasprotni strani.

Kot vsa sporočila je tudi alarmnirno sporočilo stisnjeno in šifrirano.

Alarmirno sporočilo je sestavljeno iz dveh polj po en oktet. Prvo polje označuje alarmno stopnjo in je lahko:

  • vrednost 1: opozorilo;
  • vrednost 2: usodna napaka.

Po usodni napaki obe strani takoj končata povezavo. Ostale povezave te seje se lahko nadaljujejo, toda seja se invalidira. V tem primeru se seja ne shrani in se ne more več uporabiti za vzpostavljanje novih povezav. Po zaključku seje sta obe strani dolžni izbrisati vse parametre, ki so bili uporabljeni pri taki seji.

Drugo polje označuje tip napake ali dogodka:

  • vrednost 0 - zaključek povezave
    To sporočilo ne označuje napake, ampak obvešča nasprotno stran o končanju povezave. Obe strani morata biti obveščeni o koncu povezave. Tako onemogočimo vrsto napada »truncation attack«, ko bi napadalec lahko »odrezal« sejo, tako da bi regularno zaključil TCP povezavo in to ne bi bilo ugotovljivo.
    Katerakoli stran lahko kadarkoli zaključi povezavo. Podatki sprejeti po zaključku povezave se zavržejo. Nasprotna stran mora poslati enako sporočilo o zaključku povezave, vendar za dejanski zaključek ni potrebno čakati na potrditev sprejema tega sporočila poslanega z druge strani.

Po zaključku seje se ta shrani za morebitno naslednjo povezavo, vendar samo v primeru, če je bila trenutna povezava pravilno zaključena z alarmno stopnjo 1 (opozorilo) in opisom 0 (zaključek povezave).

Ostale vrednosti pomenijo sporočilo o napaki:

  • vrednost 10 - nepričakovano sporočilo
    Sprejet je bil nepričakovan tip sporočila. To je vedno usodna napaka in mora brez obravnave končati povezavo.
  • vrednost 20 - napačna MAC vrednost
    Sprejeto sporočilo je imelo nepravilno MAC vrednost. To je vedno usodna napaka.
  • vrednost 21 - neuspešno odšifriranje
    Zapis je napačno odšifriran. Dolžina ni večkratnik šifrirnega bloka ali polnilo na koncu zapisa je napačno. To je vedno usodna napaka.
  • vrednost 22 - predolg zapis
    Sprejeti zapis je daljši od 18 k-oktetov ali odšifriran zapis je daljši od 17 k-oktetov. To je vedno usodna napaka.
  • vrednost 30 - napaka pri razširjanju
    Razširitvena funkcija je zaznala nepravilnost v vhodnih podatkih ali razširjeni niz je predolg. To je vedno usodna napaka.
  • vrednost 40 - napaka pri usklajevanju
    Komunicirajoči strani se nista mogli dogovoriti o rabi skupnih varnostnih parametrov. To je vedno usodna napaka.
  • vrednost 42 - pokvarjen certifikat
    Sprejeti certifikat je pokvarjen, vsebovan podpis ni pravilen.
  • vrednost 43 - neustrezen tip certifikata
  • vrednost 44 - preklican certifikat
  • vrednost 45 - pretečen certifikat
    Veljavnost certifikatu je potekla ali certifikat trenutno ni veljaven.
  • vrednost 46 - nepoznan certifikat
    Ostale napake v zvezi s certifikatom.
  • vrednost 47 - neustrezen parameter
    Vrednost polja pri dogovarjanju o varnostnih parametrih ni ustrezna. To je vedno usodna napaka.
  • vrednost 48 - nepoznan izdajatelj
    Sprejeta je bila pravilna veriga certifikatov, vendar izdajateljev certifikat ni poznan. To je vedno usodna napaka.
  • vrednost 49 - dostop zavrnjen
    Sprejeti certifikat je bil ustrezen, vendar po kontroli dostopa pošiljatelj noče nadaljevati z usklajevalnim postopkom. To je vedno usodna napaka.
  • vrednost 50 - dekodirna napaka
    Sporočila ni bilo mogoče odkodirati zaradi neustrezne vrednosti nekaterih polj ali nepravilne dolžine sporočila. To je vedno usodna napaka.
  • vrednost 51 - napaka pri odšifriranju
    Usklajevanje je spodletelo zaradi napake pri preverjanju podpisa, odšifriranja ključa ali preverjanja zaključnega sporočila.
  • vrednost 60 - izvozna omejitev
    Usklajevanje ni v skladu z izvozno omejitvijo šifrirnih postopkov. To je vedno usodna napaka.
  • vrednost 70 - verzija protokola
    Klientova ponujena verzija protokola ni ustrezna. Npr., če zaradi varnostnih razlogov ne dovolimo uporabe stare verzije protokola. To je vedno usodna napaka.
  • vrednost 71 - nezadostna varnost
    Signalizirano namesto napake pri usklajevanju (40), kadar strežnik zahteva bolj varne šifrirne postopke, kot jih je ponudil klient. To je vedno usodna napaka.
  • vrednost 80 - interna napaka
    Interna napaka, ki ni neposredno povezana s pravilnostjo protokola, npr. nezadostna količina pomnilnika. To je vedno usodna napaka.
  • vrednost 90 - uporabnikov preklic
    Med usklajevalnim postopkom je bila povezava preklicana. Slediti mora sporočilo zaključek povezave (0). To je ponavadi opozorilo.
  • vrednost 100 - ponovno usklajevanje ni primerno
    To sporočilo pošlje klient na zahtevo po usklajevanju ali strežnik na klientovo pozdravno sporočilo. Slediti bi moral ponoven usklajevalni postopek. Če nasprotna stran tega ne želi, pošlje to sporočilo. Od pobudnika ponovnega usklajevanja je potem odvisno, ali bo dovolil nadaljevati povezavo. To je vedno opozorilo.

Pri napakah, kjer alarmna stopnja ni navedena, je ta lahko odvisna od implementacije. Če je alarmna stopnja opozorilo, je od implementacije odvisno, kakšna bo obravnava napake.

Usklajevalni protokol

tip usklajevalnega sporočila
1 oktet		 dolžina
3 oktete		 vsebina
do 16 M-oktetov

Tipi usklajevalnih sporočil:

  • ponovno usklajevanje,
  • klientovo pozdravno sporočilo,
  • strežnikovo pozdravno sporočilo,
  • certifikat,
  • izmenjava ključa,
  • zahteva certifikata,
  • strežnikov konec pozdrava,
  • certifikatsko preverjanje,
  • zaključno sporočilo.

Usklajevalni protokol služi dogovoru o varnostnih parametrih in medsebojnemu overjanju komunicirajočih strani.

Z usklajevalnim protokolom se stani dogovorita o:

  • verziji TLS (SSL) protokola,
  • izbiri šifrirnega algoritma,
  • medsebojnem overjanju.
    Overjanje je opcijsko. Običajno se overja samo strežnik. Klient se overja samo v primeru, če preko povezave potekajo zaupne transakcije, kjer klient aktivno sodeluje (npr. bančne transakcije). O tem odloča strežnik. Protokol ne predpisuje overjanja in možne so tudi popolnoma anonimne zveze. uporabi tehnike asimetričnega šifriranja za tvorjenje in izmenjavo ključev za simetrično šifriranje.

Opis poteka popolnega usklajevalnega postopka

Popolni usklajevalni postopek se uporabi pri kreiranju nove seje ali ob sprožitvi zahteve po spremembi varnostnih parametrov s strani klienta ali strežnika.

faza I – klient

  • klient pošlje pozdravno sporočilo.

faza II – strežnik

  • strežnik odgovori s strežnikovim pozdravnim sporočilom.
    Izmenjava pozdravnih sporočil vzpostavi sledeče atribute povezave:
    • verzijo TLS (SSL) protokola,
    • identifikator seje,
    • izbiro varnostnih parametrov,
    • metodo stiskanja,
    • izmenjavo dveh generiranih psevdo–naključnih nizov.
  • strežnikov cerifikat (opcijsko).
    Če je iz izbranih šifrirnih algoritmov potrebno overjanje strežnika, potem strežnik pošlje svoj certifikat.
  • strežnikova izmenjava ključev (opcijsko).
    Če overjanje strežnika ni potrebno in strežnik nima certifikata, ali če je strežniški certifikat primeren samo za podpisovanje (overjanje) in ne za šifriranje, potem strežnik tvori par začasnih ključev in javni ključ pošlje klientu.
  • zahteva certifikata (opcijsko).
    Če je poleg overjanja strežnika zahtevano tudi overjanje klienta, strežnik pošlje sporočilo »zahteva certifikata«.
  • strežnikov konec pozdrava.

faza III – klient

  • klientov certifikat (opcijsko).
    Klient pošlje svoj certifikat samo na zahtevo strežnika.
  • klientova izmenjava ključev.
    Klient tvori in pošlje strežniku pomožni ključ iz katerega obe strani izračunata glavni ključ.
  • certifikatsko preverjanje (opcijsko).
    Klient podpiše sporočila usklajevalnega postopka.
  • sprememba šifriranja.
    Od tega trenutka naprej klient uporablja nov šifrirni postopek. To je samostojni protokol in ni del usklajevalnega protokola.
  • zaključno sporočilo.

faza IV – strežnik

  • sprememba šifriranja.
    Od tega trenutka naprej tudi strežnik uporablja nov šifrirni postopek. To je samostojni protokol in ni del usklajevalnega protokola.
  • zaključno sporočilo.
    V tem trenutku je usklajevanje končano in lahko se začne izmenjava aplikativnih podatkov.
KLIENT STREŽNIK
I.
klientovo pozdravno sporočilo
II.
strežnikovo pozdravno sporočilo
strežnikov certifikat (opc.)
strežnikova izmenjava ključa (opc.)
zahteva certifikata (opc.)
strežnikov konec pozdrava
III.
klientov certifikat (opc.)
klientova izmenjava ključa
certifikatsko preverjanje (opc.)
[sprememba šifriranja]
zaključno sporočilo
IV.
[sprememba šifriranja]
zaključno sporočilo
V.
izmenjava aplikativnih podatkov		 V.
izmenjava aplikativnih podatkov

Opis poteka poenostavljenega usklajevalnega postopka

Poenostavljeni usklajevalni postopek se uporabi, kadar klient in strežnik vzpostavljata povezavo v obstoječi shranjeni ali aktivni seji.

faza I – klient

  • klient pošlje pozdravno sporočilo.

faza II – strežnik

  • strežnik odgovori s strežnikovim pozdravnim sporočilom.
    Izmenjava pozdravnih sporočil vzpostavi sledeče atribute povezave:
    • verzija TLS (SSL) protokola mora ustrezati obstoječi seji,
    • identifikator že obstoječe seje,
    • varnostni parametri morajo ustrezati obstoječi seji,
    • metoda stiskanja mora ustrezati obstoječi seji.
  • sprememba šifriranja.
    Od tega trenutka naprej strežnik zamenja šifrirni postopek, ki ustreza obstoječi seji. To je samostojni protokol in ni del usklajevalnega protokola.
  • zaključno sporočilo.

faza III – klient

  • sprememba šifriranja.
    Od tega trenutka naprej tudi klient zamenja šifrirni postopek, ki ustreza obstoječi seji. To je samostojni protokol in ni del usklajevalnega protokola.
  • zaključno sporočilo.
    V tem trenutku je skrajšano usklajevanje končano in lahko se začne izmenjava aplikativnih podatkov.
KLIENT STREŽNIK
I.
klientovo pozdravno sporočilo
II.
strežnikovo pozdravno sporočilo
[sprememba šifriranja]
zaključno sporočilo
III.
[sprememba šifriranja]
zaključno sporočilo
IV.
izmenjava aplikativnih podatkov		 IV.
izmenjava aplikativnih podatkov

Sporočila usklajevalnega protokola

S pozdravnimi sporočili si klient in strežnik izmenjata možne vrednosti parametrov, ki jih podpirata. Med pozdravna sporočila štejemo: sporočilo »zahteva po usklajevanju«, klientovo in strežnikovo pozdravno sporočilo.

Sporočilo »zahteva po usklajevanju«

Sporočilo »zahteva po usklajevanju« lahko pošlje strežnik kadarkoli, če želi zamenjavo varnostnih parametrov. Klient mora ob tem sporočilu pričeti usklajevalni proces z pozdravnim sporočilom. Če je usklajevanje že v teku, sporočilo klient prezre. Če klient ne želi ponovnega usklajevanja, sporočilo prezre ali pošlje napako »ponovno usklajevanje ni primerno« (100). Od implementacije strežnika je odvisna reakcija. Možno je nadaljevanje ali prekinitev povezave.

Klientovo pozdravno sporočilo

To je prvo sporočilo, ki ga pošlje klient pri vzpostavljanju povezave. Lahko ga pošlje tudi kasneje, če želi ponoviti usklajevalni postopek zaradi spremembe varnostnih parametrov ali kot odgovor na strežnikovo zahtevo po usklajevanju.

verzija
2 okteta		 random
32 oktetov		 ID seje
32 oktetov		 šifrirni postopki
2-65535 oktetov		 postopki stiskanja
1-255 oktetov
  • verzija;
    Ponujena verzija TLS (SSL) protokola, s katero želi komunicirati klient. Polje je dolgo dva okteta za številko verzije in podverzije – npr. 3 in 1 pri TLS V1.0.
  • random;
    Psevdo naključni niz, ki ga tvori klient. Uporabi se kasneje pri tvorjenju ključev.
  • id_seje;
    Identifikator seje. Če vzpostavljamo novo sejo, mora biti prazno. Če hočemo uporabiti obstoječo sejo, mora vsebovati prejšnji identifikator.
  • šifrirni_postopki;
    Seznam postopkov šifriranja in podpisovanja, ki jih podpira klient, v želenem prioritetnem vrstnem redu. Vsak postopek je označen z dvema oktetoma. Možnosti so:
varnostni parametri povezave vsebina polja
TLS_NULL_WITH_NULL_NULL 0x00,0x00
TLS_RSA_WITH_NULL_MD5 0x00,0x01
TLS_RSA_WITH_NULL_SHA 0x00,0x02
TLS_RSA_EXPORT_WITH_RC4_40_MD5 0x00,0x03
TLS_RSA_WITH_RC4_128_MD5 0x00,0x04
TLS_RSA_WITH_RC4_128_SHA 0x00,0x05
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 0x00,0x06
TLS_RSA_WITH_IDEA_CBC_SHA 0x00,0x07
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 0x00,0x08
TLS_RSA_WITH_DES_CBC_SHA 0x00,0x09
TLS_RSA_WITH_3DES_EDE_CBC_SHA 0x00,0x0A
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 0x00,0x0B
TLS_DH_DSS_WITH_DES_CBC_SHA 0x00,0x0C
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA 0x00,0x0D
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 0x00,0x0E
TLS_DH_RSA_WITH_DES_CBC_SHA 0x00,0x0F
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 0x00,0x10
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 0x00,0x11
TLS_DHE_DSS_WITH_DES_CBC_SHA 0x00,0x12
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0x00,0x13
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 0x00,0x14
TLS_DHE_RSA_WITH_DES_CBC_SHA 0x00,0x15
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0x00,0x16
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 0x00,0x17
TLS_DH_anon_WITH_RC4_128_MD5 0x00,0x18
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 0x00,0x19
TLS_DH_anon_WITH_DES_CBC_SHA 0x00,0x1A
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 0x00,0x1B
  • postopki stiskanja;
    Seznam metod stiskanja, ki jih podpira klient v želenem prioritetnem vrstnem redu. Posebna je metoda z vrednostjo 0, kar pomeni brez stiskanja.

Strežnikovo pozdravno sporočilo

Pošlje strežnik kot odgovor na klientovo pozdravno sporočilo.

verzija
2 okteta		 random
32 oktetov		 id_seje
32 oktetov		 šifrirni postopek
2 okteta		 postopek stiskanja
1 oktet
  • verzija;
    Verzija TLS (SSL) protokola, s katero se strežnik strinja. Lahko je enaka ali nižja od zahtevane s strani klienta.
  • random;
    Psevdo naključni niz, ki ga tvori strežnik. Uporabi se kasneje pri tvorjenju ključev.
  • id_seje;
    Identifikator seje. V primeru nove seje jo strežnik tvori in ji dodeli nov naključni niz kot identifikator. V tem sporočilu identifikator sporoči klientu. Če se strežnik strinja z nadaljevanjem obstoječe seje, pusti v tem polju identifikator, ki ga je predlagal klient. Če strežnik tvori sejo, ki je po zaključku v nobenem primeru ne bo možno nadaljevati, strežnik pusti to polje prazno.
  • šifrirni_postopek;
    Šifrirni postopek, ki ga strežnik izbere iz klientovega seznama. Pri uporabi shranjene seje mora ustrezati shranjeni seji.
  • postopek stiskanja;
    Postopek stiskanja, ki ga strežnik izbere iz klientovega seznama. Pri uporabi shranjene seje mora ustrezati shranjeni seji.

Strežnikov certifikat

Če se mora strežnik overiti, kar je razvidno iz polja šifrirni_postopek v pozdravnem sporočilu, potem strežnik takoj po strežnikovem pozdravnem sporočilu pošlje svoj certifikat skupaj z nadrejenimi certifikati izdajateljev. Certifikat mora biti ustrezen za izbrano šifriranje in overjanje. Ponavadi je X.509v3 certifikat.

Strežnikova izmenjava ključa

Če strežnik nima certifikata ali ta ni primeren za ustrezno šifriranje, potem strežnik tvori par začasnih ključev za asimetrično šifriranje.

Zahteva certifikata

Na sporočilo »zahteva certifikata« overjenega strežnika mora svoj certifikat v naslednjem koraku poslati tudi klient. V zahtevi strežnik določi vrsto certifikata in sprejemljive izdajatelje.

Anonimni strežnik ne more zahtevati klientovega certifikata. To sproži usodno napako pri usklajevanju (40).

Strežnikov konec pozdrava

Strežnik zaključi svojo stran usklajevalnega postopka s sporočilom »strežnikov konec pozdrava«. Pred klientovim nadaljevanjem mora klient najprej preveriti ustreznost strežnikovih parametrov in certifikatov.

Klientov certifikat

To je prvo sporočilo, ki ga pošlje klient po zaključku strežnikovega usklajevalnega postopka. Pošlje se, če ga je zahteval strežnik s sporočilom »zahteva certifikata«. Pošiljanje klientovega certifikata je po strukturi popolnoma enako kot pošiljanje strežnikovega certifikata pred tem. Če klient nima certifikata, pošlje to sporočilo prazno. V tem primeru je od strežnika odvisno, ali bo dovolil nadaljevati usklajevalni postopek in povezavo.

Klientova izmenjava ključa

Struktura sporočila je odvisna od asimetričnega šifrirnega postopka določenega s pozdravnimi sporočili.

Primer, če gre za RSA algoritem:

  • klient tvori psevdo naključni pomožni ključ dolžine 48 oktetov, ga šifrira s sprejetim strežnikovim certifikatom ali strežnikovim začasnim javnim ključem. Pomožni ključ se uporabi kasneje pri tvorjenju glavnega ključa.

Certifikatsko preverjanje

S tem sporočilom klient potrdi – podpiše ves usklajevalni promet do tega sporočila. Sporočilo certifikatsko preverjanje pošlje klient samo v primeru, če je predhodno poslal svoj certifikat, ki je ustrezen za podpisovanje.

Vsebina sporočila je sestavljena iz kombinacije MD5 in SHA-1 algoritmov nad celotnim usklajevalnim prometom do vključno sporočila pred tem in podpisano s klientovim zasebnim ključem. To sporočilo »certifikatsko preverjanje« ni vključeno v izračun.

Zaključno sporočilo

Zaključno sporočilo je vedno poslano takoj po protokolu »sprememba šifriranja«. »Sprememba šifriranja« je sicer samostojni protokol in ne sodi med sporočila usklajevalnega protokola. Kljub temu se protokol »sprememba šifriranja« uporablja med usklajevalnimi sporočili.

Zaključno sporočilo je prvo, ki je šifrirano z novo dogovorjenimi varnostnimi parametri. Obe strani morata preveriti vsebino zaključnega sporočila sprejetega od druge strani. Če je vse v redu, se lahko začne aplikativni promet.

Sporočilo je sestavljeno kot kombinacija MD5 in SHA-1 algoritmov nad šifrirnim ključem in vsemi sporočili usklajevalnega postopka.

vsebina_sporočila = PRF(šifrirni ključ, končni_znakovni_niz, MD5(vsa_usklajevalna_sporočila) + SHA-1(vsa_usklajevalna_sporočila))

  • končni_znakovni_niz;
    znakovni niz »client finished« ali »server finished«, odvisno od pošiljatelja.

Pomanjkljivosti

Protokol TLS je sicer dobro zasnovan, vsake toliko pa se kljub temu še pokažejo pomanjkljivosti:

  • napake v implementacijah.
    Te so najbolj pogoste. Redno je treba spremljati obvestila o napakah v implementaciji in ustrezno dograjevati programe.
  • prešibki ključi v ameriških produktih zaradi ameriških izvoznih omejitev.
    Do januarja 2000 so bili simetrični ključi omejeni na 40 bitov in asimetrični na 512 bitov. Zdaj so te omejitve delno odpravljene, vendar je dobro preveriti, kakšne ključe podpira programska oprema, ki jo nameravamo uporabljati.
  • občutek lažne varnosti.
    TLS protokol zaščiti zgolj povezavo med dvema sistemoma, podatki na njima pa niso šifrirani. Za njuno varnost pred vdori in za zaščito datotek na postajah mora biti dodatno poskrbljeno.
  • lažno predstavljanje, lažni certifikati.
    Ko se povezujemo preko Interneta, imamo na začetku povezave s strežnikom možnost preveriti njegovo digitalno potrdilo. Kdo ga je izdal in komu? Kaj, če je bilo vmes preklicano, ali je veljavnost potekla?

Sorodne tehnologije

Poleg TLS protokola obstajajo še druge tehnologije za zagotavljanje zaupnosti pri komuniciranju preko nevarnih omrežij. Nekatere od teh so:

  • WTLS protokol.
    Obstaja tudi različica protokola TLS. To je WTLS namenjen za mobilne kliente.
  • S-http protokol.
    To je varnostna nadgradnja običajnega http protokola. Zagotavlja zaupnost v spletu. Poglavitna razlika med s-http in TLS protokolom je v tem, da s-http protokol ne vzpostavlja seje. S-http protokol šifrira vsako sporočilo posebej.
    S-HTTP protokol je razvila organizacija Enterprise Integration Technologies (EIT).
  • IPsec protokol
    IPsec (IP Security) je standardiziran (IETF) in zelo dodelan protokol za varno komuniciranje. Z razliko od zgoraj naštetih deluje na nižjem, omrežnem IP nivoju. Podpira dve vrsti delovanja:
    • transportni, kjer se šifrira samo vsebina posameznih paketov;
    • tunelski, kjer se vzpostavljajo komunikacijski tuneli, skozi katere poteka ves omrežni promet.
      Prednost pred TLS je zelo dodelan mehanizem izmenjave ključev. Časovna veljavnost posameznih ključev je natančno predpisana, za periodično izmenjavo skrbijo dodatni protokoli. Uporaba IPsec je za vse storitve popolnoma transparentna in uporabniku ni potrebno skrbeti za šifriranje pri uporabi posameznih ali novih aplikacij. Omogoča tudi povezovanje celih omrežij (VPN – virtual private network) in ne le povezave klient – strežnik.
      Pomanjkljivost pred TLS in zaradi tega tudi manjši obseg uporabe je v tem, da za komuniciranje potrebujemo vnaprej pripravljeno infrastrukturo: tunele, ustrezno nastavljene usmerjevalnike, usklajene začetne ključe ali certifikate.
      Ves promet je šifriran na omrežnem nivoju, zato vsebina vsebovanih aplikativnih protokolov ni vidna. To je prednost z varnostnega vidika. Slabost pa je, ker omrežni elementi ne morejo različno obravnavati prometa glede na aplikativno naravo (QoS – kvaliteta storitev).
  • SSH storitev in protokol
    SSH protokol je bil razvit v podjetju SSH Communications. Prvenstveno je bil namenjen za varne interaktivne prijave na oddaljene sisteme (zamenjava za storitev telnet) in za izmenjavo datotek na različicah UNIX operacijskih sistemov.
    SSH je možno uporabiti tudi v tunelskem načinu in tako povezati dva sistema ali omrežji. Potem deluje precej podobno kot zgoraj opisani IPsec protokol. SSH obstaja za vse aktualne operacijske sisteme.
  • PPTP z MPPE in MPPC
    PPTP (Point to Point Tunneling Protokol) z MPPE (Microsoft Point to Point Encription) in MPPC (Microsoft Point to Point Compression) je tunelski protokol, ki je bil razvit pod okriljem korporacije Microsoft. Namenjen je varnemu tunelskemu povezovanju oddaljenih klientov v omrežje. Protokol je standardiziran:
  • PGP
    PGP (Pretty Good Privacy) je en najstarejših postopkov za šifriranje, ki ga je razvil Philip Zimmerman. Delovanje temelji na uporabi asimentričnih šifrirnih postopkov. Največ se uporablja za šifriranje in podpisovanje datotek in sporočil elektronske pošte.
    PGP še ni podpiral infrastrukture javnih ključev (PKI), ki se je razvila kasneje. Zato je glavna pomanjkljivost PGP v zaupanju javnim ključem.

Viri