HTTPS na parkovanych domenach

Jiz dlouhodobe internet smeruje k pouzivani HTTPS a ja tak postupne prichazim o ruzne zdroje dat 🙂 Jak u proxy tak DN dochazi k tomu ze u HTTPS requestu nevidim URI pozadavku, tedy nedokazu rozlisit jestli domena ma nejaky realny traffic na domena.tld/nejaky_post ci domena.tld/ nebo nejaky roboticky traffic ve smyslu domena.tld/api/script.php nebo JS domena.tld/neco.js. Tlaci se i na zavadeni DNS over HTTPS (DoH) ktere je integrovane v novych verzich prohlizecu, kde Chrome vyuziva svoje a Firefox DNS od Cloudflare, cimz by mel postupne klesat traffic i u Public DNS a clovek tak postupne prijde i o tyto data.

HTTPS? WTF?

Dale pak clovek cte jak se tlaci na funkcnost webu pres HTTPS a je uz jedno jestli ma nejaky formulare ci nema, jak se i na Google meni odkazy postupne na HTTPS, atd … proste je to novy trend kteremu se neda vyhnout.

V Listopadu 2019 kdy me jela proxy ve velkym (jeste tehdy na 10Gbit/s pripojeni nez jsem ji musel docasne zrusit) mela prumerny denni pocet requestu kolem 270 milionu. 170 milionu pozadavku bylo pres HTTPS!!! To je vice nez 60%! Aktualne mam na proxy (znovuspusteno v pulce Brezna) necely 1M pozadavku denne, z toho cca 50% pres HTTPS. 

V tom pripade si pak rikam – sakra, vzdyt uz dneska vic jak pulka trafficu jde po HTTPS, jak to je teda u parkingu domen ? Je fakt, ze ja na svym parkovacim serveru HTTPS nepodporuju kvuli nutnosti generovat certifikaty, ale co parkovaci splecnosti ? Nedalo mi to, a podival jsem se tomu na zoubek.

Jak vubec funguje muj parking ?

Mam vlastni DNS server (napsany v Go langu) ktery zvlada ohromny mnozstvi dotazu za vterinu (desitky/stovky tisic) a odpovida na jakykoliv dotaz uplne stejne, a to:

gransy@Gransy-Macbook ~ % dig @ns.parktons.com domena.tld

; <<>> DiG 9.10.6 <<>> @ns.parktons.com domena.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6089
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;domena.tld.			IN	A

;; ANSWER SECTION:
domena.tld.		3600	IN	A	45.76.35.138
domena.tld.		3600	IN	A	95.179.243.224
domena.tld.		3600	IN	A	45.76.79.236

;; AUTHORITY SECTION:
domena.tld.		3600	IN	NS	ns.parktons.com.
domena.tld.		3600	IN	NS	ns2.parktons.com.

;; Query time: 40 msec
;; SERVER: 199.247.26.153#53(199.247.26.153)
;; WHEN: Wed Apr 15 01:22:22 CEST 2020
;; MSG SIZE  rcvd: 123

Vraci me tedy tri ruzne A zaznamy, kam rozkladam provoz jako takovy. Dale pak obsahuje definice pro ww2.domena.tld (Bodis), ww62.domena.tld (ParkingCrew), ww92.domena.tld (Skenzo).

Jakmile traffic (HTTP) dorazi na jeden z vyse uvedenych serveru, jsou vytazeny veskery potrebny udaje pro zalogovani do Elasticu (ulozeno primo JSON requestem over HTTPS), odmitnuti robotu, vyhodnoceni jaky parking pouzit na zaklade predchozich zkusenosti (data v MySQL) a naservirovani potrebneho obsahu, tzn. v pripade JS volani serviruju window.location=“ redirect v pripade normalniho requestu pak klasicky HTTP redirect, prave na jednu z domen: ww2.domena.tld, ww62.domena.tld, nebo ww92.domena.tld. Cely webserver je taktez napsany v GoLangu a vyuziva Redis jako cache pro MySQL dotazy na parking, nebot zpracovava tisice requestu za vterinu a to by bylo pro MySQL znicujici.

Jak je z popisu videt, chybi mi tam prave sotisfikovane zpracovani HTTPS pozadavku – nebot nemam validni certifikat. Resil jsem to dlouhodobe servirovanim nejakyho defaultniho, kdy pak navstevnik musel hodit vyjimku ze souhlasi s navstevou, coz 99% lidi neudelalo, proto jsem tuto moznost zrusil a takovy traffic rovnou odmital (nedoslo tedy ke spojeni).

Jak funguji parkovaci spolecnosti s HTTPS ?

Po kontrole celeho meho reseni jsem si rikal – jak to vlastne resi parkovaci spolecnosti ? Trebas bych mohl stejne – tak se na to podivame.

1, Bodis

gransy@Gransy-Macbook ~ % curl -I https://ww2.keznews.com
curl: (7) Failed to connect to ww2.keznews.com port 443: Operation timed out

2, ParkingCrew

gransy@Gransy-Macbook ~ % curl -I https://ww62.keznews.com
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ww62.keznews.com:443

3, Skenzo

gransy@Gransy-Macbook ~ % curl -I https://ww92.keznews.com
curl: (7) Failed to connect to ww92.keznews.com port 443: Connection refused

Zoufaly, zoufaly, zoufaly …. Bodis nejhorsi – tam ten pozadavek vytimeoutuje … ParkingCrew i Skenzo natvrdo spojeni odmitaji, proste na HTTPS portu neposlouchaji. Takze takovy zmateny navstevnik co se misto sveho ocekavaneho webu nedostane ani na parking ale rovnou na chybu v prohlizeci odchazi okamzite pryc!

Nahozeni HTTPS?

Lze pochybovat o smyslu nahozeni HTTPS na parkingu ? Z vyse uvedenych duvodu asi moc ne – ale otazka – jak se to projevi realne na trafficu, penezich ? Ma to opravdu smysl ? Uvidime …

Z technickyho hlediska vyuziju neskutecnou vyhodu certifikatu Let’sEncrypt a nastroje acme.sh Nejprve jsem si nahodil HTTPS pro mou testovaci domenu, a ve webserveru jsem naprogramoval aby si certifikaty bral z urcene slozky (struktura LE). Zapnul jsem i logovani chyb ktere certifikaty nemuze najit, abych tak zjistil ktere domeny maji HTTPS traffic, nebot casto parkuju domeny o kterych vubec nic nevim, a tedy nemohu generovat certifikaty predem. Taktez jsem upravil webserver tak, aby bylo jedno na ktery z nich dojde pozadavek na autorizaci a byl spravne naservirovan „challenge“ soubor z mista kde byl generovan. To je v praxi udelane tak, ze si odchytavam pozadavek na challenge a ten serviruju na postranni webserver (NGINX) ktery potrebny data poskytuje. Diky tomu nemusim resit na kterem serveru LE certifikat generuji, resp na ktery LE autorita se bude dotazovat, protoze odpoved dostane vzdy.

2020/04/04 12:37:36 http: TLS handshake error from 185.148.xx.xx:58897: open /users/ssl/EPO2016/fullchain.cer: no such file or directory
2020/04/04 12:37:36 http: TLS handshake error from 196.1.xx.xx:60191: open /users/ssl/HQ-ENS/fullchain.cer: no such file or directory
2020/04/04 12:37:36 http: TLS handshake error from 178.128.xx.xx:48768: open /users/ssl/pofescorts.pro/fullchain.cer: no such file or directory
2020/04/04 12:37:36 http: TLS handshake error from 178.16.xx.xx:53858: open /users/ssl/rpmq.scrdairy.com/fullchain.cer: no such file or directory
2020/04/04 12:37:36 http: TLS handshake error from 95.78.xx.xx:55895: open /users/ssl/screenz.info/fullchain.cer: no such file or directory
2020/04/04 12:37:36 http: TLS handshake error from 178.16.xx.xx:53859: open /users/ssl/rpmq.scrdairy.com/fullchain.cer: no such file or directory
2020/04/04 12:37:37 http: TLS handshake error from 176.59.xx.xx:62376: open /users/ssl/screenz.info/fullchain.cer: no such file or directory
2020/04/04 12:37:37 http: TLS handshake error from 83.39.xx.xx:49840: open /users/ssl/googlest.ru/fullchain.cer: no such file or directory
2020/04/04 12:37:37 http: TLS handshake error from 88.99.xx.xx:39652: open /users/ssl/ffs.social/fullchain.cer: no such file or directory

Z logu je patrne, ze je potreba vygenerovat certifikaty pro ffs.social, googlest.ru, screenz.info, rpmq.scrdairy.com, pofescorts.pro a dva nesmysly ktere budu ignorovat. Napsal jsem si tedy jednoduchy script, ktery mi log projede, a za pomoci Acme vygeneruje potrebne certifikaty. S okamzitou platnosti pak zacali fungovat vsechny HTTPS requesty na konkretni domeny.

A jak se takovy traffic nasledne zmenil ?

Mam tu dve testovaci domeny z nedavne doby:

Domenu sacaronavirus.co.za registrovanou 10.4.2020, kde:

• 10.4.2020 – 24 requests (100% HTTP)
• 11.4.2020 – 36 requests (100% HTTP)
• 12.4.2020 – 44 requests (100% HTTP)
• 13.4.2020 – 236 requests (25% HTTP, 75% HTTPS) – den vygenerovani certifikatu
• 14.4.2020 – 468 requests (16% HTTP, 84% HTTPS) – plnych 24h s funkcnim certifikatem

Domenu wcedportal.co.za registrovanou taktez 10.4.2020, kde:

• 10.4.2020 – 10 requests (100% HTTP)
• 11.4.2020 – 8 requets (100% HTTP)
• 12.4.2020 – 7 requests (100% HTTP)
• 13.4.2020 – 46 requests (65% HTTP, 35% HTTPS) – den vygenerovani certifikatu
• 14.4.2020 – 109 requests (65% HTTP, 35% HTTPS) – plnych 24h s funkcnim certifikatem

U te druhe domeny je docela zajimave, ze nastal s nasazenim certifikatu i vyssi traffic pres HTTP – nebo se muze jednat o anomalii, nicmene diky HTTPS je jednoznacne narust.

Ma to cely smysl ?

Melo nasazeni HTTPS nejaky smysl, krom toho ze musi webserver zpracovavat vice pozadavku ? Dle me jednoznacne ano. U HTTPS je mnohem vyssi pomer realnych uzivatelu vuci robotum a jinymu shit trafficu, tedy na parking se pak dostane o dost vice navstevniku. Zaroven tim obchazim limity parkingu, protoze byt prvotni request zpracuju po HTTPS, na parking presmeruju jiz po HTTP, cimz docilim toho ze navstevnik se nikde po ceste neztrati.

Co se tyce financnich zisku, nemam zatim uplne relevantni data, protoze u svych hlavnich domen jsem delal vice zmen najednou jiz pred 14ti dny, a tak nevim cemu mam prirovnat konkretni rusty, a u vyse uvedenych dvou domen nemam k dnesnimu dni (15.4 – 2h rano) jeste parkovaci data ze vsech parkingu za predchozich par dni. Nicmene:

• sacaronavirus.co.za
  
• wcedportal.co.za
  

Data jsou z API reportu, takze tam nejsou neauditovany data, nicmene je videt narust v trafficu i prokliku, muzem doufat ze se to projevi i finance, ale pokud se podivam primo na parkovaci spolecnosti, tak to vychazi dobre:

Zde jsou screenshoty z jednotlivych parkingu pro obe dve domeny:

• ParkingCrew:
  
  
• Bodis:
  
  
• Skenzo:
  
  

Udaje s hvezdickou jsou jeste v procesu auditu, mohou se tedy zvysit, ci snizit, nebo nektere (ParkingCrew) jeste nejsou vubec nacteny. Nicmene shrnu-li to, tak u techto dvou domen aktivace HTTPS mela efekt ve vysledku: 0.14$ za 3 dny vs. 1,51$ za den a pul!