Jos olet joskus selaillut HTTPS-URL-osoitteita selaimen kautta, olet kokenut SSL-kättelyn. Vaikka et ehkä huomaa sitä, selain ja verkkosivusto luovat HTTPS-yhteyden käyttämällä yksisuuntaista SSL-kättelyä.
S SSL-kättelyn päätarkoitus on tarjota yksityisyys ja tietojen eheys palvelimen ja asiakkaan välisessä viestinnässä. Kättelyn aikana palvelin ja asiakas vaihtavat tärkeitä tietoja, joita tarvitaan suojatun yhteyden luomiseksi.
Kahdentyyppisiä SSL-kättelyjä kuvataan yksisuuntaiseksi SSL:ksi ja kaksisuuntaiseksi SSL:ksi (Mutual SSL). Näiden kahden erona on se, että yksisuuntaisessa SSL:ssä vain asiakas vahvistaa palvelimen henkilöllisyyden, kun taas kaksisuuntaisessa SSL:ssä sekä palvelin että asiakas vahvistavat toistensa henkilöllisyyden. Kun selataan HTTPS-sivustoa, käytetään yleensä yksisuuntaista SSL:ää, jossa vain selain (asiakas) vahvistaa verkkosivuston (palvelimen) henkilöllisyyden. Kaksisuuntaista SSL:ää käytetään useimmiten palvelimelta palvelimelle tapahtuvassa viestinnässä, jossa molempien osapuolten on varmennettava toistensa henkilöllisyys.
S SSL-kättelyn aikana palvelin ja asiakas noudattavat seuraavia vaiheita.
1. Client Hello
Asiakas lähettää tiedot, joita palvelin tarvitsee aloittaakseen HTTPS-yhteyden.
Yllä olevasta lokista näemme, että client hello TLS v1.2:lla. Tällä asiakas ilmoittaa palvelimelle, että sillä on tuki TLS-versioille 1.2 ja sitä pienemmille. Luettelo salakirjoituksista, joita asiakas tukee, voidaan myös nähdä yllä olevasta lokista. Palvelin valitsee tästä luettelosta tukemansa salauspaketin. Jos luettelossa on salakirjoitussarjoja, joita palvelin ei tunnista, tue tai halua käyttää, palvelin jättää kyseiset salakirjoitussarjat huomiotta. Jos yhtään tuettua salakirjoitussarjaa ei löydy, palvelin lähettää epäonnistumishälytyksen ja sulkee yhteyden.
2. Server Hello
Palvelin vastaa takaisin Client Hello -kohdasta valitsemallaan konfiguraatiolla sekä tiedoillaan kättelyn jatkamiseksi. Server Hello on seuraava.
Server valitsee TLS-version sen mukaan, kumpi on alempi asiakkaan Client Hello -viestissä ehdottamasta ja kumpi on korkein palvelimen tukema. Palvelin lähettää myös takaisin salauspaketin, jonka se on valinnut asiakkaan esittämästä salauspakettiluettelosta.
Palvelin lähettää Server Hello -viestin mukana myös palvelimen varmenteen varmenneketjulla varustettuna. Varmenteiden ketju tarkistetaan asiakkaan luottamussäilössä olevien varmenteiden perusteella.
3. Palvelimen avaintenvaihtoviesti
Palvelin lähettää asiakkaalle tämän viestin, joka sisältää tarvittavat tiedot, jotta asiakas voi luoda esipääsalaisuuden. Tätä viestiä ei lähetetä, jos käytetään RSA-avaintenvaihtoalgoritmia (tästä lisää myöhemmin) tai muita avaintenvaihtoalgoritmeja, jotka eivät vaadi palvelimelta tietoja pre-master-salaisuuden luomiseksi.
Elliptic Curve Diffie Hellman(ECDH) -avaintenvaihdossa asiakkaalle lähetetään seuraavat tiedot palvelimen ECDH-avaimen julkisesta avaimesta.
4. Varmennepyyntö
Tässä kohdassa yksisuuntainen SSL poikkeaa kaksisuuntaisesta SSL:stä. Yksisuuntaisessa SSL:ssä asiakkaan aitoutta ei vahvisteta. Siksi tämä vaihe jätetään pois yksisuuntaisessa SSL-kättelyssä.
Tässä vaiheessa palvelin lähettää asiakkaalta varmennepyynnön, jossa ilmoitetaan palvelimen tukema varmenteen tyyppi, varmenteen allekirjoitusalgoritmit ja varmenneviranomaiset. Voi olla tilanteita, joissa varmenteiden myöntäjien luettelo voi olla tyhjä. Tällaisissa tilanteissa asiakas voi valita, lähettääkö hän asiakkaan varmenteen vai välttääkö hän sen lähettämisen (riippuu asiakkaan toteutuksesta)
Viimeiseksi palvelin lähettää Server Hello Done -viestin, joka ilmaisee Server Hello -toiminnon päättymisen. Tämän viestin lähettämisen jälkeen palvelin odottaa asiakkaan vastausta.
5. Asiakkaan varmenne
Asiakas esittää palvelimelle varmenneketjunsa. Varmenteen on oltava sopiva neuvotellun salakirjoitussarjan avaintenvaihtoalgoritmille ja mahdollisille neuvotelluille laajennuksille.
6. Client Key Exchange Message
Tämän viestin asiakkaan on lähetettävä Client Certificate -viestin jälkeen. Jos asiakasvarmentetta ei esitetä (yksisuuntaisessa SSL:ssä), asiakasavainten vaihtoviesti on lähetettävä sen jälkeen, kun asiakas on vastaanottanut ServerHelloDone-viestin.
Kuten kaikki tiedämme, HTTPS-yhteydessä palvelimen ja asiakkaan välillä siirrettävät tiedot salataan. Tähän tarkoitukseen käytetään symmetristä salausta, koska sen laskentakustannukset ovat paljon pienemmät kuin epäsymmetrisen salauksen. Symmetrisen salauksen käyttäminen edellyttää, että molemmilla osapuolilla on yhteinen avain. Tämän viestin tarkoituksena on luoda tämä yhteinen avain kyseisen asiakkaan ja palvelimen välille paljastamatta sitä ulkopuoliselle.
TLS v1.2 -spekseissä on kuvattu kaksi asiakkaan avaintenvaihtomenetelmää. Ne ovat RSA ja Diffie-Hellman.
Jos avaintenvaihtoalgoritmina käytetään RSA:ta, asiakas luo 48 tavun suuruisen pre-master-salaisuuden. Asiakas salaa pre-master-salaisuuden varmenteen julkisella avaimella ja lähettää sen palvelimelle. Vain palvelimella on vastaava yksityinen avain, jolla se voi purkaa salauksen ja saada asiakkaan luoman esisalasalaisuuden.
Jos käytetään Diffie-Hellmania, Diffie-Hellman-parametrit lähetetään, jotta sekä asiakas että palvelin voivat luoda saman esisalasalaisuuden.
Sen jälkeen molemmat osapuolet luovat pääsalaisuuden käyttäen esisalasalaisuutta, ja pääsalaisuuden avulla luodaan symmetrinen avain istuntotiedon salausta varten.
7. Finished
Todennuksen onnistumisen ja pre-master-salaisuuksien/master-salaisuuksien luomisen jälkeen sekä asiakas että palvelin lähettävät change cipher spec -viestin, jossa ilmoitetaan, että loput viestinnästä salataan.
Finished-viesti seuraa välittömästi change cipher spec -viestiä. Tämä on ensimmäinen viesti, joka salataan neuvotelluilla algoritmeilla. Sovellustiedot siirretään vasta sen jälkeen, kun molemmat osapuolet ovat lähettäneet finished-viestin ja varmistaneet viestin sisällön.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/