Možda niste niti svjesni činjenice kako je određene promjene uveo Google Chrome web preglednik, od inačice 58, a koje će vrlo vjerojatno i drugi slijediti.  Naime radi se o tome kako se novi Chrome striktno drži standarda RFC 2818. Ovdje se radi o novom standardu za HTTPS komunikaciju, odnosno definiciji kako se treba, odnosno mora,  koristiti TLS (Transport Layer Security ), koji je usput rečeno, naslijedio SSL (Secure Sockets Layer) protokol, kao standard za kriptiranje podataka za HTTP protokol.

Za one kojima nije jasna ova poveznica, zamislite TLS kao tunel kroz koji prolaze samo i isključivo kriptirani (zaštićeni) podaci, od i prema HTTP protokola odnosno od i prema web poslužitelju.

Dakle HTTPS u radu se oslanja na TLS tunel kroz koji se primaju i šalju kriptirani podaci, koji kada se dekriptiraju, postaju standardni (normalni) HTTP promet. Nekriptirani, odnosno nezaštićeni HTTP podaci se nikada ne šalju preko mreže, već se kriptiraju i šalju, pa ih dekriptira svatko za sebe, kako ih prima:

• HTTP(S) poslužitelj sa svoje strane
• klijent (web preglednik) sa svoje strane.

Dakle i klijent i poslužitelj zapravo komuniciraju normalnim HTTP protokolom jer se TLS komunikacija događa na jednoj razini ispod. Možemo reći to i ovako: HTTP komunikacija prolazi kroz TLS kriptirani tunel:

Klijent (HTTP)  <== ==> Klijent (TLS tj. HTTPS) <– –> Mreža (Internet) <– –>** Poslužitelj (TLS tj. HTTPS) <== ==>** Poslužitelj (HTTP)

Kako se odvija komunikacija prema HTTPS protokolu, odnosno TLS dio

1. Klijent (web preglednik) šalje „ClientHello“ poruku, koja sadrži sve potrebno za buduću komunikaciju, a između ostalog i:
   1. Listu algoritama za kriptiranje i razmjenu podataka i ključeva koje podržava (poznate pod nazivom cipher suites )
   2. Maksimalnu verziju SSL ili TLS protokola koje podržava

2. Poslužitelj odgovara sa svojom „ServerHello“ porukom, te na osnovi svoje konfiguracije odnosno postavki, odabire:

a.) Algoritam za kriptiranje i razmjenu ključeva (cipher suites) – koje dozvoljava, a klijent podržava

Ova opcija se nalazi u konfiguraciji (datoteka: ssl.conf za Apache web poslužitelj), pod parametrom: SSLCipherSuite (u njoj se navodi sve što dozvoljavamo/ne dozvoljavamo od protokola ). Pogledajte jedan primjer:

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

b.) Maksimalnu verziju SSL odnosno u novijim verzijama TLS protokola, koje dozvoljava, a klijent podržava.

3. U ovom koraku, poslužitelj dokazuje svoj identitet klijentu pomoću certifikata. Certifikat sadrži razne podatke, poput :
   1. Imena poslužitelja i domene (pr. opensource-osijek.org)
   2. Javnog ključa za asimetrično kriptiranje/dekriptiranje
   3. Digitalnog potpisa
   4. Datuma izdavanja certifikata te datuma valjanosti certifikata (pr. vrijedi do 3.8.2017)
   5. I na kraju, institucije odnosno „autoriteta“ koji je ovaj certifikat dodijelio poslužitelju
4. Klijent prima certifikat te provjerava vjerodostojnost istoga. Prvo provjerom vjerodostojnosti institucije (autoriteta) koja mu je izdala certifikat. Ovdje se radi o CA (Certificate Authority), koji ima pravo izdavati ovakve certifikate – u našem slučaju je to Let’s Encrypt, a koji je, kao i svi drugi CA, ove razine, provjeren od strane vršnih
   1. Prvo klijent (web preglednik) provjerava, da li mu se u njegovoj listi CA (a koja dolazi s instalacijom svakog web preglednika), nalazi i CA, od kojeg je došao i certifikat poslužitelja na koji se spajamo.
   2. Ako ovaj CA, nije u listi web preglednika, provjeravaju se CA-ovi koji su u toj listi te se kod njih provjerava, da li smo od nekoga od njih dobili naš certifikat. Ova lista se zapravo sastoji od dvije liste :
      1. root CA (odnosno vršne certifikacijske „institucije“)
      2. intemediate CA (odnosno svi oni niže razine, koji su naravno certificirani kod nekog od root CA).

Svako malo, vršni CA, provjeravaju certifikate CA-ova niže razine (kojima su dodjeli certifikate).

Zadnji korak je razmjena ključeva,

Prije kriptiranja kanala, prvo se moraju razmijeniti ključevi za kriptiranje, na siguran način, kako netko tko potencijalno prisluškuje komunikaciju ne bi mogao “upasti” u komunikaciju koja bi trebala biti zaštićena . Razmjena ključeva može se odraditi na dva načina – metode  1  ili 2 (dolje). Dakle pošto se klijent odlučio za algoritam i druge parametre, on ovisno o odabranom algoritmu za kriptiranje, odabire metodu razmjene ključeva:

1. Key encipherment metoda:
   1. Klijent kreira simetrični ključ
   2. Kriptira simetrični ključ sa poslužiteljevim javnim ključem. Samo ga poslužitelj može dekriptirati jer jedino on ima privatni ključ s kojim ga može dekriptirati (ovo sada  je asimetrična metoda)
2. Key agreement (sigurnija metoda)- koristi se Diffie-Hellman (DH) metoda, a koja se koristi  i kod drugih protokola – pr. SSH , ili raznih vrsta VPN konekcija. DH je opisan u RFC2631. U imenu cipher suitea, DH je označen i kao EDH (Ephemeral Diffie-Hellman) ili DHE te EECDH (Ephemeral Elliptic Curve Diffie-Hellman) . Pogledajmo i kako to radi:
   1. Klijent i poslužitelj razmjenjuju vrlo velike prim brojeve (Tzv. p i g) te rade određene računske operacije s njima te potvrđuju rezultat kao provjeru autentičnosti.
   2. Klijent šalje svoj javni DH ključ na poslužitelj
   3. Poslužitelj izračunava tajni „session“ ključ na osnovu svog privatnog ključa i koristi klijentov javni ključ za kriptiranje – te ga šalje klijentu
   4. Poslužitelj šalje svoj javni DH ključ klijentu
   5. Klijent izračunava tajni „session“ ključ na osnovu svog privatnog ključa i koristi poslužiteljev javni ključ za kriptiranje – te ga šalje poslužitelju
   6. Sada obije strane imaju ključeve pomoću kojeih se kriptira kanal za komunikaciju.

Za detalje oko procesa komunikacije, kod uspostavljanja kriptirane (HTTPS) veze, pogledajte :

https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

Vratimo se na RFC2818

Prema ovom standardu, ime računala (Hostname) definirano u certifikatu mora biti zapisano korištenjem SAN (Subject Alternative Name) unosa, a ne kako je prije bilo slučaj, korištenjem CN (Common Name) unosa.

Za one koje zanima više detalja o SAN unosu, pogledajte RFC 3280, poglavlje : 4.2.1.7

S obzirom da je naš CA (Certificate Authority) – odnosno tvrtka od koje smo dobili TLS/SSL certifikat koristio CN, a ne SAN unos za naš certifikat odlučili smo se za određene promjene.

Nakon malo istraživanja, odlučili smo se za drugi CA (Certificate Authority) – Let’s Encrypt. Let’s Encrypt je slobodan, automatiziran i otvoren CA (Certificate Authority) koji je pokrenut za javno dobro, od strane ISRG  (Internet Security Research Group).

Već nakon nekog vremena ovu organizaciju su počele sponzorirati, kako neprofitne tako i profitne male ali i velike tvrtke.

Ako pogledate listu glavnih sponzora, postati će vam jasan naš odabir:

Dodatno, ono što je vrlo važno je i kompatibilnost ovih certifikata sa svim važnijim web preglednicima:

• Mozilla Firefox >= v2.0
• Google Chrome
• Internet Explorer on Windows XP SP3 and higher
• Microsoft Edge
• Android OS >= v2.3.6
• Safari >= v4.0 on macOS
• Safari on iOS >= v3.1
• Debian Linux >= v6
• Ubuntu Linux >= v12.04
• NSS Library >= v3.11.9
• Amazon FireOS (Silk Browser)
• Cyanogen > v10
• Jolla Sailfish OS > v1.1.2.16
• Kindle > v3.4.1
• Java 7 >= 7u111
• Java 8 >= 8u101
• Blackberry >= 10.3.3

A i činjenica kako ga sada koriste i mnogi veći igrači.

Važno je znati kako je valjanost ovih certifikata 90 dana. Naravno nakon tog vremena potrebno ih je osvježiti. Let’s Encrypt, koristi  ACME protokol i pripadajuće ACME klijente, kako za kreiranje certifikata, tako i za njihovo osvježavanje.

ACME klijenata ima cijeli niz – pogledajte link.

Mi smo se odlučili za acme.sh – klijent u potpunosti napisan samo korištenjem shella (pr. bash),  bez potrebe za bilo kojim dodatnim bibliotekama ili drugim alatima ili programskim jezicima. Odluka je pala ne njega zbog jednostavnosti i činjenice kako ga koriste mnoge tvrtke u čiji odabir imamo puno povjerenje. Pogledajte listu korisnika acme.sh -> LINK.

acme.sh ažurira certfikat jednostavnim dodavanje u cron, za svaki dan. Dakle svaki dan se provjerava je li certifikat istekao, i ako je, povlači se novi, te se restarta web poslužitelj (za cca 89 dana ćemo vidjeti da li to radi automatski J ). Ovo bi trebala biti KISS metoda koja provjereno radi .

Što se instalacije i konfiguracije tiče, sve je teklo glatko, prema uputama :

https://github.com/Neilpang/acme.sh

Osnovna konfiguracija web poslužitelja

Osim standardnih dijelova za konfiguraciju SSL/TLS dijela, dio koji se odnosi na certifikate je slijedeći – govorimo o Apache web poslužitelju.

Napomena: SSLCertificateChainFile se više ne koristi već se koristi:  SSLCertificateFile.

Dakle ovako:

SSLCertificateFile /etc/httpd/ssl/fullchain.cer

Ovo je chain certifikat (fullchain.cer) koji ste dobili od Let’s Encrypta. Ovaj certifikat kako mu i naziv kaže (chain=lanac) certifikat je koji sadrži niz certifikata, počevši od root CA – onoga koji je opće „dozvolio“ rad našem – nižem odnosno intermediate CA (od kojega smo mi dobili certifikat), preko tog intermediate CA (ovdje je to Let’s Encrypt ) i sve do našeg certifikata (za našu stranicu za koju smo ga i tražili).

Slijedeća stavka je SSLCACertificateFile,  koristi se u slučajevima ako tražimo autentikaciju klijenata (mi ćemo i to uključiti),

Konfiguracija izgleda ovako:

SSLCACertificateFile /etc/httpd/ssl/ca.cer

Dakle korisitmo (ca.cer) dobiven od Let’s Encrypta.

I na kraju, naš privatni RSA ključ (private key), koji smo dobili od Let’s Encrypta. Dakle ovo je par od našeg javnog ključa (public key) – iz našeg certifikata. U našem slučaju je to datoteka : opensource-osijek.org.key

Prema tome, konfiguracija izgleda ovako:

SSLCertificateKeyFile /etc/httpd/ssl/opensource-osijek.org.key

Za one kojima još nije najbolje sjelo: simetrično i asimetrično kriptiranje

• Simetrično kriptiranje
  • S jednim (istim) ključem se radi i (en)kriptiranje i dekriptiranje. Dakle s istim ključem zaključavate sef s podacima ali i bilo tko s istim takvim ključem može otključati sef. Simetrija u nazivu je stoga što je jedan ključ i za zaključavanje (kriptiranje) i otključavanje (dekriptiranje)
• Asimetrično kriptiranje
  • Uvijek se generira (kreira) par ključeva, jedan privatni i jedan javni. Javni ključ se daje svima jer je to ključ s kojim se samo i isključivo mogu (en)kriptirati podaci. Dok se (en)kriptirani podaci samo i isključivo mogu dekriptirati s privatnim ključem. Dakle javni ključ se koristi za (en)kriptiranje a privatni za dekriptiranje podataka. Ovo znači i to, kako je za dvosmjernu komunikaciju, potrebno da svaka strana kreira sve svoje ključeve.
    • Strana A : svoj privatni ključ čuva a javni daje strani B (i bilo kome drugom)
    • Strana B : svoj privatni ključ čuva a javni daje strani A (i bilo kome drugom)
      • Prema tome kada strana A šalje podatke na stranu B, ona ih (en)kriptira s javnim ključem od strane B, koja ih potom dekriptira sa svojim privatnim ključem (B). Kada strana B šalje podatke na stranu A, ona ih (en)kriptira s javnim ključem od strane A, koja ih potom dekriptira sa svojim privatnim ključem (A).
  • Zbog toga i asimetrija u nazivu jer ne postoji jedan ključ za sve namjene, već su i ključevi i sam način rada asimetrični.

Autor: Hrvoje Horvat