Ostatnie lata „https” to TLS w wersji 1.2. Niestety nie jest on za szybki, a co gorsza okazało się, że nie spełnia swojej pierwotnej funkcji – bezpieczeństwa. I tak przez 10 lat istnienia TLSv1.2 mogliśmy słyszeć o takich podatnościach jak FREAK, Heartbleed, Poodle, ROBOT czy SLOTH.
Mimo wszystko sporo firm dopiero w 2018 roku przesiadło się na TLS w wersji 1.2 (GitLab, ZendDesk, Office365).
Ale nie o tym dzisiaj. W połowie 2018 roku został sprecyzowany jego następca – TLSv1.3 (chociaż powinien nazywać sie TLSv2.0). TLS 1.3 jest o wiele bezpieczniejszy od poprzednika, a do tego szybszy. Usunięto bardzo wiele przestarzałych lub po prostu potencjalnie niebezpiecznych mechanizmów (np. md5, sha-1, des/3des, aes-cbc), a dodano wiele kombinacji opartych o sha256/aes128 oraz skrócono proces „uścisku dłoni”.
nginx i TLS 1.3
Aby zacząć „przygodę” z TLS 1.3 na serwerze musimy posiadać OpenSSL 1.1.1 (np. Debian 10, Ubuntu 18.10, FreeBSD 12.0 lub ze źródeł), od strony Klienta obsługę taką dostarcza obecnie Chrome 70, Opera 57 i Firefox 63 (niestety Safari nie obsługuje – aktualny status wdrożeń).
Jako miłośnik kompilacji przedstawię szybki sposób od strony serwera (przedstawione wersje poniżej są najświeższe, jeśli to możliwe powinniśmy sprawdzić sumy kontrolne paczek po pobraniu):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
$ wget https://www.openssl.org/source/openssl-1.1.1a.tar.gz $ tar -xvf openssl-1.1.1a.tar.gz $ cd openssl-1.1.1a/ $ ./config $ make $ cd .. $ wget https://nginx.org/download/nginx-1.15.8.tar.gz $ tar -xvf nginx-1.15.8.tar.gz $ cd nginx-1.15.8 $ ./configure \ --sbin-path=/usr/local/sbin \ --with-pcre-jit \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --without-mail_pop3_module \ --without-mail_imap_module \ --without-mail_smtp_module \ --with-openssl=../../openssl-1.1.1a \ --with-openssl-opt='enable-ec_nistp_64_gcc_128 enable-tls1_3' $ make # make install |
Gdy mamy obsługę TLS 1.3 na serwerze pozostaje tylko odpowiednio zmienić konfigurację samego serwera WWW (nginx). Ze względu, że nie wszystkie przeglądarki wspierają TLSv1.3 powinniśmy pozostawić nadal obsługę TLSv1.2. Natomiast włącznie 0-RTT (Zero Round Trip Time Resumption) powoduje spory wzrost wydajności i szybkości połaczenia (więcej informacji w CloudFare) w przypadku TLSv1.3:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
server { listen 443 http2 ssl; ssl_certificate /etc/ssl/my_cert.pem; ssl_certificate_key /etc/ssl/my_key.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_early_data on; #enable 0-RTT (TLS 1.3) location / { proxy_pass http://my_backend; proxy_set_header Early-Data $ssl_early_data; } } |
Jak widziecie wystarczy dodać TLSv1.3 na liście obsługiwanych protokołów, oraz dodatkowo można włączyć obsługę 0-RTT. Reszta tak naprawdę zależy od Waszego szczególnego przypadku (np. proxy_pass).
DNS CAA
Gdybyście sprawdzali po tych zmianach poprawność działania nowych ustawień przez SSL Labs, zauważycie, że pojawiła się tam nowa pozycja DNS CAA, jest to opcja która chroni przed niepowołanym wystawieniem certyfikatu dla domeny. Dlaczego? Nie wiem czy wiecie, ale certyfikat dla Twojej domeny może wysyawić dowolny ośrodek CA, tak naprawdę bez pytania Ciebie o zdanie. Mechanizm DNS CAA wprowadza dodatkową weryfikację przez przeglądarki czy certyfikat, którym posługuje się strona jest faktycznie na białej liście przypisanym do domeny na poziomie jej strefy DNS.
Jeśli korzystacie z certyfikatów Let’s Encrypt wystarczy dodać poniżą linijkę w strefie swojej domeny:
|
1 |
@ CAA 128 issue "letsencrypt.org" |
I to wszystko. Miłych testów.