Certificate Wildcard SSL Gratuite

Certificate Wildcard SSL Gratuite ©

La mai puțin de doi ani de la lansare, Let’s Ecrypt a emis peste 100 de milioane de certificate gratuite, ajungându-se la un trafic criptat total de 58%.

Pentru că am mai văzut confuzii, un certificat SSL – fie că-i simplu, fie că-i extended – îți garantează doar două lucruri: 1) informațiile care pleacă de la server nu vor fi alterate când vor ajunge la tine (și invers) 2) nimeni nu poate vedea aceste informații.

Ce înseamnă asta, în termeni mai simpli? Traficul simplu, non-SSL, poate fi interceptat de către oricine se află între tine și server dar și de către oricine este în aceeași rețea cu tine, astfel încât, dacă tu vrei să te autentifici undeva, un posibil atacator – sau o persoană mai curioasă – îți va vedea atât utilizatorul cât și parola. Și ca și cum nu e suficient, traficul necriptat poate fi alterat. Adică tu vizitezi Facebook.com iar un atacator îți poate injecta JS malițios.

Ăsta este unul din motivele principale pentru care evit să mă conectez cu telefonul sau cu laptopul pe rețelele WiFi în care nu am încredere.

Până acum doi ani, un certificat SSL costa în jur de 10$/an și necesita o mulțime de pași pentru generare, instalare și actualizare. Nu scump, dar combinat cu administrarea migăloasă, era descurajant. Apoi a apărut Let’s Encrypt: certificate gratuite și automatizate. Apoi firmele de hosting au început să ofere asta și pentru găzduirea shared. Restul e istorie :)

Problema cea mai mare era că LE nu oferea certificate wildcard (e.g. *.iamntz.com). Adică pentru orice subdomeniu, este nevoie să generezi un certificat – lucru destul de greu în anumite contexte.

Bine, încă nu oferă, dar din ianuarie 2018 va avea și certificate wildcard. Aparent asta era unul dintre cele mai cerute lucruri. Cine s-ar fi gândit!

8 Comentarii

Malin a scris

@Ionuț Staicu: Sa presupunem ca esti pe shared hosting cu iamntz.com, deci ai zona de DNS activa pe serverul respectiv, asociere la IP etc. Langa tine mai sunt 50 de conturi de shared, fiecare cu treaba lui. Tu ai IP dedicat pentru SSL si pui SSL wildcard si DNS wildcard pe domeniul tau fiindca ti-e mai simplu asa.
Unul din conturile de pe server e spart la nivel de shared environment. E intr-un jail fie cu suPHP, fie cu cageFS sau alte metode si nu se poate escala peste permisiunile userului, dar serverul e scanat si se poate afla usor ce alte domenii mai sunt, care are SSL etc. Cine sparge serverul creeaza un add-on pe contul spart cu un subdomeniu de-al tau phishing.iamntz.com si pune o pagina de phishing, care are alt IP, acela al serverului shared.
Pagina de phishing merge, e legit, primeste si SSL pe ea din cauza la wildcard. Firma de hosting cand primeste raportul vede ca e domeniul tau si-ti da tie suspend, DNS-ul si SSL-ul raman active, la fel si pagina de phishing. Pana isi dau seama ce si cum dureaza ceva vreme.
Fara wildcard exista avantajul ca definesti manual ce e acoperit de SSL si ce nu, si atunci nu se poate uza SSL ca sa acorde legitimitate paginii de phishing sau whatever.
Dar se poate rezolva problema asta daca certificatul wildcard e utilizat impreuna cu HSTS.
Headerul de HSTS poate sa-ti protejeze orice subdomeniu de astfel de spoof-uri pentru ca daca apare un subdomeniu cu IP diferit nu se poate face DNS hijack si nici abuza de SSL: https://scotthelme.co.uk/hsts-polish-dns-hijacking-attack/
Despre Security Headers poti afla mai multe aici: https://securityheaders.io/?q=blog.iamntz.com&followRedirects=on; si-ti recomand sa le pui fiindca sunt utile impotriva catorva tipuri de atacuri printre care XSS. In afara de Content-Security-Policy toate sunt usor de configurat. CSP presupune sa faci whitelist pe toate elementele/hostnameurile pe care le incluzi in cod pentru a bloca incluziunea in XSS.
Eu acolo unde am anunturi, embed-uri de pe siteuri externe etc nu folosesc CSP si merg doar pe astea:

Header set X-XSS-Protection „1; mode=block”
Header set X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security „max-age=31536000; includeSubdomains”

Malin a scris

@Ionuț Staicu: Pai ba da fiindca alea poti sa le adaugi si in .htaccess cu ifmodule:

==IfModule mod_headers.c==
Header set X-XSS-Protection „1; mode=block”
Header set X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security „max-age=31536000; includeSubdomains”
==/IfModule==

P.S. Am inlocuit deschiderea si inchiderea de taguri cu 2 egaluri pentru ca anterior l-a considerat HTML si mi-a dat strip la ele.

Sorin a scris

„Tu ai IP dedicat pentru SSL si pui SSL wildcard si DNS wildcard pe domeniul tau fiindca ti-e mai simplu asa.
Cine sparge serverul creeaza un add-on pe contul spart cu un subdomeniu de-al tau phishing.iamntz.com si pune o pagina de phishing, care are alt IP, acela al serverului shared.
Pagina de phishing merge, e legit, primeste si SSL pe ea din cauza la wildcard.”

Malin, nu-mi este clar, de ce phishing.iamntz.com primeste SSL desi are alt IP decat cel dedicat ?

Malin a scris

@Sorin: Am specificat ca daca faci wildcard pe DNS si ai SSL wildcard atunci oricine face un add-on pe un alt cont de hosting, dar pe acelasi server si folosind aceleasi NS-uri cu alt IP e acoperit de SSL daca e activ wildcardul (vorbesc teoretic de cPanel). Am vazut in ultima perioada cateva spoof-uri facute asa fara SSL, dar daca activezi SSL wildcard atunci mie mi se pare logic ca avand DNS wildcard sa se poata folosi SSL-ul fara sa dea mismatch chiar daca IP-ul e altul.

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter
windows apple dropbox facebook twitter