HTTPS všade, alebo aké má výhody a nevýhody

300

Prednáška z Google I/O, ktorú mali Ilya Grigorik a Pierre Far ma inšpirovala k napísaniu tohto blogu, kde by som rád vyzdvihol výhody šifrovaného spojenia a celkového šifrovania webového obsahu protokolom TLS.

Asi ako prvá otázka sa naskytuje, prečo by sme mali používať HTTPS všade. V čom nám to pomôže, a čo nám to prinesie, a naopak, čo nás to bude stáť.https_schema

Predpokladám, že každý z vás sa už stretol s tým, že na stránke videl zelený zámoček signalizujúci pripojenie cez HTTPS. Avšak zamysleli ste sa niekedy, načo tam tento konkrétny protokol je? Prečo sa používa?

TLS je nástroj, ktorý nám dovoľuje overovať identitu servera a šifrovať spojenie so serverom. To zrejme viete. Avšak prečo to treba robiť, to už nie je tak veľmi známe. V podstate je dôvodov niekoľko.

Prečo povedať TLS áno ?

Predstavme si, že máme stránku s administráciou (v dnešnej dobe absolútna povinnosť), čiže nejaký redakčný systém. Môže byť akokoľvek bezpečne naprogramovaný, avšak ak si nedáme pozor na údaje, ktorými spravujeme túto webstránku, bude nám aj tá najlepšie naprogramovaná stránka nanič.

Naša predstava, že ak sa heslo „zaguličkuje“ a nikto nestojí za mnou, nemôže ho predsa vidieť. Čo v skutočnosti znamenajú tie guličky? Guličky sú jednoducho len maska znakov, ktoré sa pri prihlasovaní posielajú na server na spracovanie. Tieto znaky idú buď cez protokol HTTP  (nezabezpečený) alebo HTTPS (zabezpečený). Dáta, prv než sa dostanú na server, prechádzajú k modemu, ktorý ich neskôr pošle na server. A tu nastáva prvý problém.

Príklad zraniteľnosti č.1

Prídeme do zahraničia, teraz veľmi aktuálne na dovolenku. Šéf nám zavolá, že potrebuje súrne niečo zmeniť. Vytiahneme laptop pripojíme sa na prvú otvorenú wi-fi, nakoľko dátové prenosy sú v zahraničí drahé. Prihlásime sa na náš web, zmeníme obsah, odhlásime sa. A ďalej dovolenkujeme.

O pár hodín nám šéf volá s vystrašeným hlasom, že web firmy bol „hacknutý“ a boli tam uvedené nepravdivé údaje.

Čo sa stalo ?

Pri pripojení do Wi-Fi, bol na rovnakej wi-fi pripojený aj náš útočník, ktorému bežal na jeho laptope jednoduchý nástroj, ktorý odchytával komunikáciu na sieti, napríklad WireShark. Akonáhle sme odoslali dáta na server, tieto dáta šli aj k útočníkovi. Keďže sme poslali dáta cez nezabezpečený protokol HTTP útočník ich dostal ako na tácke v plaintexte. Pokiaľ by sme pristupovali na náš web cez HTTPS k tomuto scenáru by nedošlo, pretože by boli poslané kryptované dáta a útočník by nemal šancu bez súkromného kľúča tieto dáta prečítať.

Existuje aj možnosť, že stačí ak sa prihlásime na wi-fi šifrovanú napríklad WPA2, tak sú dáta tiež šifrované, ale oveľa častejšie sa dostávame do situácie, kedy sa pripájame na otvorené wi-fi siete.

Každopádne, môžete si povedať, že sa budem pripájať len na zabezpečené wi-fi a nemám problém. Chyba.

Príklad zraniteľnosti č.2

Tu sa dostávame k bodu, kedy sa útočník zahrá na našu stránku. Máme rovnakú situáciu v kaviarni, avšak tentoraz nás útočník nasmeruje na skopírovanú stránku, ktorá však nie je na našom serveri. Ako obyčajný človek to nevidíme, keďže sa zobrazí úplne alebo teda veľmi podobná stránka. Prihlásime sa a zasa máme problém.

Toto je druhý prípad kedy nás zachráni HTTPS protokol. V prípade, že útočník skopíruje náš web, a umiestni ho na svoj server, tak jeho server nedokáže overiť dáta, ktoré ste mu poslali, nakoľko nemá privátny kľúč, podľa ktorého by ste ho dešifrovali.

Čiže teraz vieme, že použitie HTTPS je veľmi dobré, avšak treba ho aj implementovať.

Serverová implementácia

TLS ako také sa implementuje ako na strane servera, tak aj vo webovej aplikácii. Čo sa týka implementácie na strane servera, do toho by som veľmi nerýpal, nakoľko to nie je môj obor, avšak dobré čítanie a v podstate dobrý návod ako nato nájdete na wikipedii.

Ja sa zameriam hlavne na implementáciu na vašej už existujúcej stránke.

Webová implementácia (Best Practices)

Ako prvé si musíme uvedomiť, že naša stránka, náš systém musí všetky linky transformovať do formátu https://example.com z formátu http://example.com. Rovnako treba nastaviť linkom atribút „rel=canonical“.

Avšak to nie je všetko. Každá stránka si načítava nejaké zdroje. Javascripty, CSS atď… tieto zdroje by mali pochádzať rovnako tak zo zabezpečených webov.

Ak na našej stránke nemáme systém, ktorý dokáže po nastavení sám upraviť URL, tak sa zameriame na korektné nastavenie ručne. Do zdrojov nemusíme natvrdo vkladať protokol, cez ktorý sa súbor bude otvárať. Zdroju stačí nastaviť relatívny protokol. Čiže príklad:

<script src=”//www.example.com/myscripts.js”></script>

Tento zápis môžeme využiť napríklad aj pri vývoji, ak aplikáciu testujeme na vývojovom serveri, ktorý nemá implementované TLS, a do produkcie ju nahodíme na server kde TLS je implementované. Protokol sa prispôsobí serverovému nastaveniu.

Avšak na stránku nám ľudia chodia bežne len tak, že napíšu „example.com“. V týchto prípadoch sú veľmi dôležité presmerovania. Vždy používame presmerovanie (301) pri zmene protokolu. Toto sa robí práve kvôli robotom Googlu a indexovaní stránok.

Správne by sme mali všetky linky zapisovať v jednom formáte, aby sme predišli presmerovaniam, ktoré môžu našu aplikáciu spomaliť, najmä ak si zoberieme, že tú aplikáciu otvárame na mobilnom zariadení (mobil/tablet). Čiže každý link by mal byť v kompletnom tvare https://www.example.com/something. V tomto prípade eliminujeme presmerovania a rovnako tak zrýchlime pageload a dátové zaťaženie.

Nesprávny zápis (vyžaduje presmerovanie):
http://example.com
http://www.example.com
https://example.com

Správny zápis:
https://www.example.com

Správny zápis je dôležitý najmä kvôli indexovacím robotom, a ľudia ho reálne ani nepostrehnú, takže výhovorka „robím web pre ľudí nie pre roboty“ u lenivých vývojárov neuspeje. 🙂

HSTS – Optimalizujeme na ešte rýchlejší web

Ďalším zlepšením čo sa týka optimalizácie nasadenia TLS priamo do aplikácie je použiť HSTS (HTTP Strict Transport Security)

Toto vylepšenie nám pomôže v tom, že do prehliadača vytvorí cache a prehliadač pri pripojení k webu vytvorí automaticky spojenie cez HTTPS, aj v prípade že zadáme HTTP. To v podstate absolútne anuluje nejaké presmerovania, ktoré nie sú z hľadiska optimalizácie žiadané, keďže sa všetko vopred správne nastaví u klienta.

Poslednou dôležitou vecou je, že treba nastaviť, aby roboty dokázali indexovať HTTPS stránky. Predstavme si, že zakážeme robotovi indexovať HTTPS, z nejakého dôvodu (neviem akého), tak nás jednoducho Google prestane indexovať. A to nikto nechce.

Pomocné nástroje

Ak chceme môžeme si pozrieť test, či sme všetko spravili správne. Ideálne je použiť Webmaster Tools od Googlu, ktorý nám pekne ukáže, či máme všetko správne. Webmaster Tools sú veľký pomocník, pri skúmaní toho, prečo sa váš web zle zobrazuje v Googli. Je to zrejme najrýchlejší debug nástroj na tento účel na internete.

Ešte by som pripomenul aj nástroj na ostestovanie vášho TLS certifikátu, v prípade, že ste ho nechali implementovať externe a chcete si to overiť, tak odporúčam navštíviť: https://www.ssllabs.com/ssltest/.

Cena za bezpečné pripojenie

K tomu čo nás to bude stáť len jednoduchá tabuľka od Googlu:

PlánCena
Jedna doména ( example.com )Od 10$/rok (nekomerčné projekty: zdarma)
Viac domén (example.com, example.co.uk…)Od 30$/rok (nekomerčné projekty: zdarma)
Wildcard (*.example.com)Od 100$/rok (nekomerčné projekty: zdarma)

V prípade, že vediete nekomerčný projekt, môžete získať certifikát aj zdarma, napríklad od firmy StartSSL.
V prípade, že publikujete open-source projekt, môžete získať certifikát zdarma od GlobalSign.

To je zrejme všetko, dúfam, že chápete prečo ten nadpis. Samozrejme šifrovať sa dajú aj iné veci ako weby, napríklad maily, instant messangeri a podobne. Avšak to je na ďalší článok.

Zdroj:

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 4 200 z vás dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

I agree to have my personal information transfered to MailChimp ( more information )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžete odhlásiť.