SSL - Secure Sockets Layer
Last updated
Last updated
SSL ili Secure Sockets Layer je protokol koji omogucava sigurnu komunikaciju te predstavlja unaprijedjenje TCP protokola na nacin da uvodi povjerljivost, integritet podataka, autentifikaciju servera i autentifikaciju klijenta. SSL se koristi za bezbijednost saobracaja koji se odvija preko HTTP protkola. Kako je SSL obezbjedjen od strane TCP protkola moze ga koristiti svaka aplikacija koja koristi, odnosno izvrsava se preko TCP protokola. SSL nudi jednostavan API sa soketima koji je slican API-ju koji nudi TCP protokol. Kada neka aplikacija hoce da koristi SSL ukljucuje se SSL klase i biblioteke. SSL se tehnicki nalazi u aplikacionom sloju ali iz perspektive programera to je transportni protokol koji koji pruza TCP usluge obogacene uslugama bezbjednosti. Na sljedecoj slici mozete vidjeti gdje se SSL nalazi unutar OSI modela.
Prilikom klijent server komunikacije preko SSL protokola komunikacija se odvija na sljedeci nacin:
Klijent salje spisak kriptografskih algoritama koje podrzava, zajedno sa klijentovim jednokratnim brojem
Server is tog spiska bira jedan simetrican kriptografski algoritam (npr: AES) i jedan algoritam javnih kljuceva (npr: RSA) i jedan MAC algoritam. Server nakon toga vraca klijentu svoj izbor, zajedno sa svojim jednokratnim brojem i certifikatom.
Klijent provjerava certifikat, izvlaci serverov javni kljuc, pravi PMS (PreMaster Secret) i kriptuje ga javnim kljucem servera. Nakon toga klijent salje serveru svoj izbor, zajedno sa svojim jednokratnim brojem i kriptovanom PMS.
Istom funkcijom za pripremu kljuce, klijent i server svako za sebe izracunava MS (Master Secret) na osnovu PMS i jednokratnih brojeva. Zatim se MS dijeli na dva kljuca za sifrovanje i dva MAC kljuca. Sve buduce poruke izmedju servera i klijenta ce biti sifrovane i autentifikovane pomoca MAC kljuca.
Klijent salje posebnu MAC poruku serveru, koja se koristi za potvrdu integriteta podataka.
Server salje klijentu posebnu MAC poruku, koja se koristi za potvrdu integriteta podataka.
Na sljedecoj slici je prikazano kako izgleda SSL TLS handshake.
*Slika preuzeta sa stranice An overview of the SSL or TLS handshake
Preduslov za sigurnu komunikaciju je da "vjerujete" da public key kriptografija i potpisivanje digitalnim potpisom rade kako treba. To znaci da su "vjerujete" sljedecim principima:
Svaka poruka enkriptovana Serverovim javnim kljucem moze biti dekriptovana samo od strane Serverovog privatnog kljuca
Bilo ko sa pristupom Serverovom javnom kljucu moze verifikovati da je poruka (signature) mogla biti kreirana samo od strane nekoga ko ima pristup Serverovom privatnom kljucu.
Na sljedecoj slici mozete vidjeti pojednostavljeni prikaz HTTPS komunikacije.
Certificate Authority CA je entitet koji pohranjuje, potpisuje i izdaje digitalne certifikate. Kako bi mogli utvrditi da je server onaj za kojeg se predstavlja neophodan nam je Certificate Authority kako bi potvrdio njegov identitet. U primjeru sa slike iznad smo imali certifikat koji je potpisan od strane Google CA koji je potvrdio da je server koji salje poruku zaista server na kojem se nalazi web stranica sa domenskim imenom moja-web-stranica.com. Google CA se smatra Certified Authoritijem kojem mozemo vjerovati na interentu. Kao i bilo koji drugi CA, Google CA ima svoj par kljuceva. Jedan javni kljuc koji se koristi za potpisivanje certifikata, a drugi privatni kljuc koji se koristi za dekripciju poruka. Ako zelimo da nas web server koristi HTTPS vezu neophodno je da kreira svoj par kljuceva i da ga registruje kod CA. CA ce potpisati javni kljuc i vratiti nam certifikat koji mozemo koristiti za potvrdu identiteta servera. Proces registracije kljuca kod CA se zove Certificate Signing Request (CSR) i prikazan je na slici ispod.
Zahvaljujuci tome sto je Certificate Authority potpisao kljuceve koje server koristi, moze da se sprijeci Man in the Middle Attack gdje bi neka druga stranica / server mogao da se pretvara da je moja-web-stranica.com
Na sljedecem linku mozete vidjeti listu Certified Authoritija kojima vjeruje Chrome browser.
Ponekad nije neophodno da imate SSL certifikat potpisan od strane poznatog Certified Authoritija. Uzmimo za prijmjer da imate development okruzenje gdje zelite da enkriptujete svu komunikaciju. Potrebno je da kreirate par privatnog i javnog kljuca i nakon toga da kreirate CRS koji ce biti potpisan od strane vaseg vlastitog CA. Vlastiti CA kreirate na nacin da ste kreirali par kljuceva koji ce poptpisati kljuceve kreirane od strane servera u development okruzenju. Kako se radi o vasem vlastitom CA, tom certifikatu nece biti vjerovano ali kako se radi o development okruzenju vi mozete reci vasoj aplikaciji da vjeruje CA koji je koristen za potpisivanje certifikata.
Chain of trust (lanac povjerenja) u kontekstu SSL certifikata odnosi se na proces provjere valjanosti certifikata kako bi se osigurala sigurna veza izmedju browsera/klijenta i web servera. Lanac povjerenja sastoji se od niza certifikata koji se proteže od SSL certifikata krajnjeg korisnika do root certifikata, preko jednog ili više intermediate certifikata.
Evo kako lanac povjerenja funkcionise za SSL certifikate:
Root certifikat: Na vrhu lanca povjerenja je root certifikat, koji izdaje Certificate Authority (CA). Root certifikati su ugradjeni u web preglednike i operativne sisteme kao dio njihove liste pouzdanih certifikata.
Intermediate certifikat(i): Root CA izdaje intermediate certifikate, koji služe kao posrednici između root CA i krajnjih korisnika (SSL certifikata). Intermediate CA moze izdati SSL certifikate direktno krajnjim korisnicima ili drugim intermediate CAs, stvarajući lanac medjuposrednickih certifikata.
SSL certifikat: Na kraju lanca povjerenja je SSL certifikat koji je izdan od strane Intermediate CA. SSL certifikat se koristi za autentifikaciju web servera i šifriranje komunikacije izmedju browser i servera.
Kada browser/klijent pokusava uspostaviti SSL/TLS vezu s web serverom, server salje svoj SSL certifikat, zajedno s potrebnim intermediate certifikatima. Browser provjerava lanac povjerenja na sljedeci nacin:
Provjera valjanosti SSL certifikata: Preglednik provjerava je li SSL certifikat važeći (npr. nije istekao) i potpisan od strane poznatog intermediate CA.
Provjera intermediate certifikata: Browser provjerava je li intermediate certifikat vazeci i potpisan od strane poznatog root CA ili drugog intermediate CA.
Provjera root certifikata: Browser uporedjuje root certifikat s onima iz svoje liste pouzdanih certifikata. Ako se root certifikat podudara s jednim od unaprijed instaliranih certifikata, lanac povjerenja smatra se ispravnim.
Ako je lanac povjerenja ispravan, browser uspostavlja sifriranu vezu sa serverom koristeći SSL/TLS protokol. Ako lanac povjerenja nije ispravan, browser prikazuje upozorenje o sigurnosti, obavjestavajuci korisnika o potencijalnom problemu sa certifikatom ili sigurnoscu veze.
Postoji nekoliko razloga zašto su intermediate certifikati važni:
Dodatna sigurnost: Koristenje intermediate certifikata pomaze u zastiti root CA (Certificate Authority) tako što se privatni kljuc root CA može drzati offline i na sigurnom mjestu. Ako bi privatni ključ root CA bio kompromitiran, to bi ugrozilo cijelu hijerarhiju povjerenja. Držanjem root CA offline, smanjuje se rizik od kompromitacije.
Fleksibilnost i organizacija: Intermediate certifikati omogucuju CA da organiziraju izdavanje certifikata po razlicitim kategorijama i namjenama. Npr, jedan intermediate CA moze biti zaduzen za izdavanje certifikata za e-trgovinu, dok drugi može biti zaduzen za izdavanje certifikata za bankarstvo. Ovo omogucuje bolju organizaciju i upravljanje certifikatima.
Smanjenje rizika: U slucaju da neki intermediate CA bude kompromitiran, posljedice su manje katastrofalne nego kad bi root CA bio kompromitiran. Ako je kompromitiran samo jedan intermediate CA, moze se povuci i zamijeniti, a ostatak PKI infrastrukture ostaje netaknut.
Skalabilnost: Koristenjem intermediate certifikata, CA može prosiriti svoju infrastrukturu kako bi podržao rast i razvoj poslovanja, bez potrebe za izmjenom root CA.
Ukratko, intermediate certifikati dodaju dodatni sloj sigurnosti u hijerarhiju povjerenja, omogućavaju bolju organizaciju i upravljanje certifikatima, te pruzaju veću skalabilnost i fleksibilnost PKI infrastrukture. Neki od najpoznatijih root CA koji izdaju intermediate certifikate su DigiCert, Symantec, GoDaddy, Let's Encrypt, Comodo, GlobalSign, Thawte, i Entrust.
Leaf certifikati, takodjer poznat kao end-entity certificate ili krajnji korisnicki certifikati, su SSL certifikati koji se koriste za autentifikaciju web servera i šifriranje komunikacije između web browsera i servera. Leaf certifikati se izdaju od strane intermediate CA, a ne od strane root CA. Leaf certifikati su najcesce SSL certifikati koji se koriste za HTTPS web stranice. U hijerarhiji povjerenja, leaf certifikat je izdan od strane intermediate CA ili u nekim slučajevima direktno od root CA. Kada web browser pokusava uspostaviti SSL/TLS vezu s web serverom, server salje svoj leaf certifikat i potrebne intermediate certifikate browseru kako bi se provjerila autenticnost certifikata kroz lanac povjerenja.
Leaf certifikati sadrze sljedece informacije:
Informacije o vlasniku: Ime, organizacija, adresa i druge informacije o vlasniku certifikata.
Javni kljuc: Javni kljuc koji se koristi za sifriranje podataka u SSL/TLS komunikaciji.
CA informacije: Informacije o autoritetu za certificiranje koji je izdao certifikat (root CA ili intermediate CA).
Vrijeme vazenja: Period vazenja certifikata, nakon kojeg certifikat vise nije valjan i treba ga obnoviti.
Digitalni potpis: Digitalni potpis koji potvrduje autenticnost certifikata. U kontekstu PKI (Public Key Infrastructure), leaf certifikati su najniži u hijerarhiji povjerenja, ali igraju ključnu ulogu u šifriranju i autentifikaciji internetskog prometa.
U sljedecem primjeru cemo pokazati na koji nacin mozemo konfigurisati SSL Let's Encrypt certifikat na EC2 Amazon Linux 3 serveru koristeci Nginx web server. Za ovaj primjer cemo koristiti web aplikaciju i znanje koje smo stekli u tokom Week-5 predavanja iz serije predavanja odrzanih tokom DevOps Mentorship Programa. To podrazumijeva da imamo EC2 instancu sa Amazon Linux 3 operativnim sistemom, Nginx web serverom i web aplikaciju koja je dostupna po HTTP protokolu na portu 80 koristeci nasu javnu IP adresu.
Kreirali smo Route 53 DNS zapis http://ssl.awsbosnia.com/ i usmerili ga na nasu Public IP adresu nase EC2 instance na kojoj se nalazi nasa aplikacija.
Za kreiranje Lets Encrypt certifikata iskorisiti cemo certbot alat. Certbot je alat koji nam omogucava da automatski generisemo i instaliramo SSL certifikat. Na Amazon Linux Ami 3 cert bot cemo instalirati koristeci pip alat.
Output komande sudo certbot certonly --nginx:
Vidimo da su nasli ccertifikati na sljedecoj lokaciji:
Kako bi NGINX mogao da primi HTTPS zahtijeve neophodno je da azuriramo NGINX konfiguraciju.
Nakon sto smo napravili backup upisujemo novi konfiguracijski fajl node-app.conf:
Restartujemo NGINX web server:
Nakon toga vidimo da mozemo pristupiti nasoj web aplikaciji preko sigurne HTTPS veze koristeci domensko imehttps://<domensko-ime.com>/.
Dokumentacija za importovanje certifikata u AWS Certificate Manager se nalazi na Importing certificates into AWS Certificate Manager.
OpenSSL je open source alat (github repo | dokumentacija) koji se moze korisiti za upravljanje kljucevima i certifikatima, potpisivanje digiralnih potpisa i provjeru autenticnosti certifikata.
