30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue

Käesolev blogipostitus on peatähtis läbi lugeda neil, kes tegelevad oma kodulehe vahendusel kaubandusega, kuid see on kindlasti oluline teadmiseks võtta ka teistele.

30. juunist ei luba Payment Card Industry Data Security Standard (PCI DSS) makseandmeid käsitlevate veebilehtede omanikel enam kasutada aegunud SSL/TLS turvastandardeid.

Selliste lehtede haldajad peaksid 30. juuniks veenduma, et nende HTTPS ühendused oleksid seadistatud järgmiselt:

1) SSL standardi kasutus peab olema täielikult keelatud;
2) kasutusel olev TLS protokoll peab olema vähemalt 1.1 või uuem.

Zone klientidel on hetkel seis selline:

1) SSL standardi kasutus on täielikult keelatud;
2) vaikimisi kasutusel olev TLS protokoll on 1.0 või uuem.

Rõhutan, jutt on konkreetselt SSL standardist! SSL-i terminit kasutatakse nii meil kui mujal (valesti) iseloomustamaks paljusid turvatud ühendusi, kuigi enamik neist põhineb tänapäeval juba TLS standardil.

Meie hoolsatel, turvateadlikel ja standardiga ühilduvust soovivatel klientidel on aga võimalus haldusliideses paari klikiga keelata vanemate TLS versioonide kasutamine. Selleks tuleb Virtuaalserveri haldusliideses Veebiserveri seadete alt muuta sätet “Luba aegunud TLS versioonide kasutamine”.

Võib kerkida küsimus, miks me TLS 1.0 kasutust üldiselt ära ei keela? Põhjus peitub selles, et interneti sügavustes eksisteerib veel mitu kihti internetti, üks neist on nö “asjade internet” ja teine “skriptide internet”. Need on internetikihid, millel püsib hoomamatu hulk meid ümbritsevaid protsesse ja milles iga suurem muudatus tähendab meie klientide jaoks ettearvamatuid tagajärgi.

Asjad, mis TLS 1.0 keelamisega võivad näiteks veebile ligipääsu kaotada:

* vanemad mobiiltelefonid;
* vanemad või odavamad käsiterminalid;
* vanemad või odavamad multimeediakeskused;
* vanemad operatsioonisüsteemid ja nende veebilehitsejad;
* vanemad skriptid ja programmid.

Ülevaatlikku tabelit erinevate seadmete TLS ühilduvusest üritab pakkuda muuhulgas GlobalSign.

Üks sarnane varasem iidvana protokolli toe lõpetamine on meie jaoks  näiteks lõppenud kõnega ühest logistikafirmast, mille käsiterminalid lõpetasid lennujaamas töö.

Erinevatel andmetel moodustab TLS 1.0 liiklus hetkel 5-11% kogu HTTPS-i abil turvatud ühenduste mahust.

Seetõttu oleme otsustanud, et jätame vanema TLS versiooni (TLS 1.0) kasutamise keelamise esialgu kliendi otsustada ning lükkame selle vaikimisi välja lülitamise veidi edasi, kuni teadlikkus on klientide hulgas veidi kasvanud.

Põhjus, miks PCI on otsustanud vanemate turvastandardite toetamise keelata peitub nende vanuses.

SSL (Secure Sockets Layer) on standardina olnud maha kantud juba tükk aega tagasi, kuid lühend ise elab turvatud ühendusi sümboliseeriva terminina inimeste teadvuses veel edasi. Reaalsuses lasti selle standardi viimane suurem versioon välja 1996. aastal ning aastast 2015 on selle kasutus sisuliselt keelatud (https://tools.ietf.org/html/rfc7568).

SSL-i asendas 1999. aastal standard TLS (Transport Layer Security) versiooniga 1.0 ning sellele on järgnenud versiooniuuendused 1.1 (2006 aastal) ja 1.2 (2008 aastal). 2018. aasta märtsist eksisteerib, peale pikka ja vaidlusterohket arendustööd, standardi mustandina ka TLS versioon 1.3, kuid selle laiemasse kasutusse jõudmine võtab veel veidi aega.

Mõlemad on olnud haavatavad tänu mitmetele nõrkustele, mis kandnud vahvaid nimesid nagu POODLE, BEAST, FREAK, BREACH, CRIME jt ning nende ja muude selliste aukude lappimine ei ole lihtsalt jätkusuutlik.

HTTPS kõikides Virtuaalserveri teenuspakettides

Kui Vinton Cerf ja Robert Kahn alustasid 1970-ndatel aastatel tööd interneti alustalaks saanud TCP/IP protokollistiku kallal, olid nad tõsise küsimuse ees – kas TCP/IP protokollistik peaks vaikimisi sisaldama ühenduste krüpteerimist?

Kui Vinton Cerf ja Robert Kahn alustasid 1970-ndatel aastatel tööd interneti alustalaks saanud TCP/IP protokollistiku kallal, olid nad tõsise küsimuse ees – kas TCP/IP protokollistik peaks vaikimisi sisaldama ühenduste krüpteerimist?

Peale asjaolude kaalumist olid nad sunnitud TCP/IP protokollistikku krüptograafia vaikesättena sisse ehitamisest loobuma järgmistel põhjustel:

  • võrguliikluse krüpteerimine ja dekrüpteerimine nõudis ressursse, mida toonane riistvara ei olnud võimeline pakkuma;
  • ei olnud päris selge, kuidas jaotada võrgus osalejate vahel andmeside krüpteerimiseks vajalikke võtmeid (töö avalikel võtmetel põhineva krüptograafia arendamise kallal alles käis);
  • Ameerika Ühendriikide riiklik julgeolekuagentuur (NSA) omas äärmiseid reservatsioone krüptograafia avalikesse või kommertsvõrkudesse levimise suhtes.

Krüptograafia implementeerimine andmeside protokollistiku teistes kihtides oli hiljem küll võimalik, kuid tänu Cerfi ja Kahni otsusele ei saanud sellest esialgu interneti loomulikku osa.

Tänaseks oleme olukorras, kus:

  • keerukateks krüptograafilisteks operatsioonideks võimeline riistvara on nutiseadmete näol jõudnud tavakodanike taskutesse;
  • krüptovõtmete vahetamine on tänu paljudele avaliku võtme taristutele äärmiselt lihtne;
  • just tänu NSA-le on nii laiemal avalikkusel kui ka ärimaailmal äärmiselt suur huvi krüpteeritud andmeside vastu.

Seetõttu on täiesti loomulik, et krüptograafia teeb internetis just praegu oma pöördumatut võidukäiku ning selle kasutus on muutumas kõikide infotehnoloogiliste lahenduste eelduseks.

Lausa nii jõuliselt, et Google kavatseb peale üleminekuperioodi oma Chrome veebilehitseja aadressiribal hakata HTTP ühendusi tähistama järgmiselt:

chrome_http_warning
Pildi allikas: Google Online Security Blog

HTTPS turvalisusKõike eelnevat arvesse võttes on mul hea meel kuulutada avalikult välja see, mida mitmed insaiderid on juba tähele pannud: Zone.ee Virtuaalserveri kõik teenuspaketid toetavad turvalisi HTTPS tühendusi.

Lisaks on ka Virtuaalserveri I paketi kasutajatel võimalik saada osa Let’s Encrypt initsiatiivil tasuta väljastatavatest TLS sertifikaatidest, mida kliendi soovi korral väljastatakse, seadistatakse ja uuendatakse Zone serverites automaatselt.

Aga see pole veel kõik. Tavakasutajate mõeldes tegime ülemineku krüpteerimata HTTP ühendustelt turvalisematele HTTPS ühendusele ka senisest mugavamaks. Nimelt lisasime Virtuaalserveri haldusliidesesse täienduse, mis võimaldab ühe nupuvajutusega suunata kogu HTTP veebiliikluse ümber krüpteeritud HTTPS protokollile:

Selle käigus tehakse varasematest seadetest sõltuvalt kuni kolm muudatust, mille jõustumine võtab umbes 10 minutit:

  1. tellitakse Let’s Encrypt sertifikaat (kui seda varem polnud tellitud)
  2. lisatakse serverile SSL tugi ja seadistatakse see kasutama tellitud sertifikaati (kui seda varem polnud tehtud)
  3. suunatakse kogu liiklus HTTPS peale kasutades 301 redirect’i

Kasutaja teha jääb vaid oma veebirakenduses baasurli muutmine. Kui täis-automaatne protsess riskantne tundub, siis võib mõistagi ka lisada Let’s Encrypt sertifikaadi, veenduda ca 10 minuti pärast HTTPS toimimises, teha veebirakenduses muudatused ja seejärel lisada kogu liikluse suunamise:

Kui HTTPS aktiveeritud loe lisaks: Kuidas kontrollida, kas HTTPS peale suunamine on õigesti tehtud? ja HTTPS ja HSTS ehk Strict-Transport-Security

Ja et tordil oleks ka kirss peal, siis on mul hea meel välja hõigata, et veel käesoleva kuu jooksul plaanime alustada kõikide uute Virtuaalserverite vaikimisi HTTPS ühendusega varustamist.

Zone Virtuaalserveri platvormile tellitud serverid, millele on tehniliselt võimalik HTTPS tuge lisada, saavad selle endale peagi vaikimisi kaasa ja mingit eraldi seadistamise vajadust enam ei ole.

Head küberturvalisuse kuud!

HTTPS ja HSTS ehk Strict-Transport-Security

Blogipostituses Kuidas kontrollida, kas HTTPS peale suunamine on õigesti tehtud? jäi mainimata selline HTTPS jõustamise viis nagu HSTS – osaliselt taotluslikult, sest sellega eksperimenteerides ja hiljem HTTPS toimimise eest mitte hoolt kandes võib lisaks turvalisuse tõstmisele ka endale jalga tulistada. Kõigepealt ohtudest ja kasust, siis välja lülitamisest – ja kõige lõpuks ka eriti mõjusast sisselülitamisest 🙂

Mida HSTS teeb?

HSTS ehk HTTP Strict Transport Security puhul lisatakse HTTPS-päringu vastusele päis, mis paneb brauseri etteantud aja jooksul suunama kõik HTTP ühendused ümber HTTPS peale ning rangelt keelduma saidi külastamisest, kui sertifikaat on vigane (nt aegunud).

Näiteks selline:

Strict-Transport-Security: max-age=31536000

Kuna 31536000 sekundit on 365 päeva, siis peab kasutaja brauser täpselt niikaua meeles, et mistahes bookmark või sellele veebile viitav link peab omaniku soovi kohaselt kindlasti korrektset HTTPS’i kasutama – ning kui vaja, teeb automaatselt 307 Internal Redirect’i. Ehk isegi kui lehel on js/css/pildid/vormid mingil põhjusel http:// URLiga, siis brauser pöördub nende poole garanteeritult HTTPSiga. Tulemuseks muuhulgas see, et HTTP peale ei leki päringud ega nendega (potentsiaalselt) kaasas käivad küpsised.

Brauseris toimuva 307-suunamise teeb eriti kasulikuks see, et ta mõjub ka POST-päringutele ehk kõigile “vormi-submittidele”. Tavaline .htaccess abil tehtud suunamine (vt Kuidas kontrollida, kas HTTPS peale suunamine on õigesti tehtud?) muudab need GET-päringuteks ehk teeb katki, HSTS kasutamisel toimib kõik nagu muiste:

hsts-post-upgrade

Loomulikult tuleks sellised vormid korda teha, mitte “väikse häkiga” tööle panna (ja HSTSist pole abi, kui http:// POST-päringut proovib teha Ajax), aga vanema/suurema veebi HTTPS peale kolimise teeb see omajagu turvalisemaks.

HSTS ei kaota ka vajadust seadistada veeb kasutajaid HTTP pealt HTTPS peale suunama, sest muuhulgas on selle tugi IE puhul alles versioonist 11 (vt CanIUse) ja turvakaalutlustel usaldavad brauserid seda päist ainult juhul, kui see tuleb HTTPS pealt.

Kuidas HSTS välja lülitada?

Igaks juhuks mainin enne sisselülitamise-näiteid ära, et välja lülitamiseks ei piisa päise eemaldamisest, vaid tuleb muuta selle max-age nulliks – ja see hakkab kasutajatele mõjuma alles siis, kui nad järgmist korda veebi külastama satuvad:

Strict-Transport-Security: max-age=0

Kui testimise ajal on vaja brauserile öelda, et ta HSTS’i unustaks, siis leiab brauserikohased juhised … loomulikult googeldades 🙂

Hea mõte on ka alustada lühema, nt 600 või 3600 sekundilise perioodiga – siis saab veenduda kõige toimimises ja vajadusel probleemide lahendamiseni HTTP peale naasta.

Kuidas HSTS sisse lülitada?

Lihtsaim viis on seda teha .htaccess faili abil, sobilik rida mis lisab päise ainult HTTPS päringute puhul võiks olla selline:

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Kui on soov HSTSi testida ilma kõiki kasutajaid mõjutamata, võib päise seada ka PHPs – näiteks selline hsts-on-off.php:

<?php

$max_age = ! isset( $_GET['off'] ) ? 600 : 0;

header( "Strict-Transport-Security: max-age=$max_age" );
echo "HSTS max-age set to $max_age";

Muud seaded?

“Aga see pole veel kõik” – lisaks on võimalik sätestada, et reegel rakendub ka kõigile alamdomeenidele (oled kindel, et kõik dev./uus./staging. saidid on HTTPS peal, nüüd ja tulevikus?):

Strict-Transport-Security: max-age=31536000; includeSubDomains

 

Samuti saab lubada oma domeeni eelistuse kirja panemise Chrome ja teiste brauserite koodis:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Täpsemalt tuleb päise lisamise järel lugeda läbi tingimused ning täita ankeet ning jääda ootama, millal domeen nimekirja jõuab (ja seejärel järgmise brauseriversiooniga levima hakkab). Selle meetodiga jalga tulistamine saab olema eriti tõhus.

Otsides preload-nimekirjast .ee seotud domeene hakkavad silma vaid google.ee, hilti.ee, elisa.ee ja mõned ilmselt valdkondlike entusiastidega seotud nagu näiteks heh.ee – ilmselgelt ei pea olema rahvusvaheline konglomeraat, et ennast Chrome lähtekoodis jäädvustada 🙂

Mõnevõrra üllatavalt ei leia sellest nimistust nt panku või riiklikke institutsioone, huvitav kas tegu on kaalutlusega (jätmaks võimaluse operatiivsemalt muuta või kasutada turvamata ühendusi, nagu nt seb.ee avaveeb) või ei tundu oluline? Küll aga on seal huvitaval moel hulk swedbank.se alamdomeene:

hsts-preload

ps. tänu Simo Karpinile, kes HSTS teema meie FB-postituse juures tõstatas!

Kuidas kontrollida, kas HTTPS peale suunamine on õigesti tehtud?

Iga vähegi äriga seotud veeb peaks jooksma HTTPS peal – sest nii on turvalisem ja tänu HTTP/2 protokollile ka oluliselt kiirem. Tasuta Let’s Encrypt sertifikaadiga on HTTPS toe lisamine veebile äärmiselt lihtne, aga kõigi vajalike ümbersuunamiste seadistamine, otsimootorites saavutatud positsiooni säilitamine ja kasutaja jõudmine soovitud lehele vajavad läbimõeldud tegevust.

2016.a alguses testis Ahrefs blogi 10000 enimkülastatud domeeni ja jõudis järeldusele, et vaid 10% neist on HTTPS täiesti korrektselt kasutusele võtnud – probleemideks needsamad ümbersuunamised, mõne nimekuju (www-ga või ilma) mittetoimimine jms.

Kuidas kontrollida, et kõik HTTPS peale kolimisega seotu sai õigesti tehtud? Ja mida üldse kontrollida?

Katsetades Ahref’si poolt kasutatud tööriista sai aga kiiresti selgeks, et see ei tuvasta kaugeltki kõiki probleeme ja olukord on veel hullem. Mistõttu tegin nädalavahetuse-projektina oma tööriista – ja tänavapildist tuttavaid URLe sisse toksides sain kinnitust, et suuremad või väiksemad probleemid kimbutavad tihti ka korraliku IT-tagatoaga Eesti ettevõtteid.

Kontrollimist ja lahendamist vajavad teemad on sellised:

  • kõik varasemad http://  URLid peaksid suunama edasi https:// peale
  • nad peaksid seda tegema mitte ajutise ehk “302”, vaid lõpliku ehk “301” edasisuunamisega (tõsi, Google on äsja reegleid leebemaks muutnud: 301 Redirects Rules Change: What You Need to Know for SEO)
  • korrektselt peaksid toimima ja edasi suunama nii domain.ee kui www.domain.ee URLid (ning sertifikaat peaks sobima mõlemale)
  • loomulikult kehtib see ka kõigi veebi alamlehtede kohta
  • ja see peaks juhtuma ühe ümbersuunamisega, mitte nt www.domain.ee » domain.ee » https://domain.ee » https://domain.ee/et/
  • kogu lehe peal olev sisu – pildid, CSS, menüü-lingid, tekstis olevad viited teistele alamlehtedele – peaks kasutama HTTPSi (muidu ei kuvata aadressiribal rohelist tabalukku või põhjustavad klikid tarbetuid ümbersuunamisi)
  • kui on kasutusel sitemap.xml, RSS või muud lahendused – ka need peaksid toimima HTTPS pealt ja sisaldama ainult HTTPS URLe
  • lisaks peenem kraam, nagu nt veebipoe ostukorvi või kontaktivormide töölejäämine – nimelt toimivad ümbersuunamised lehe kuvamisel (GET-päringud), aga mitte andmete saatmisel serverisse (POST-päringud)

Ahjah, ja tulemust peaks saama näidata pealikule kinnituseks, et töö on hästi tehtud ja võib arvele alla kirjutada … või siis peaks pealik saama selle projekti-koosolekul kurja näoga lauale lüüa.

Siin see on: sisesta või kopeeri-kleebi mõne eelistatud kujul (www-ga või ilma) alamlehe URL oma veebist – nt www.zone.ee/blogi

Kuna see tulemus on igav ja roheline (mida ta teps mitte ei olnud esimesel katsel), siis sobib demoks paremini üks teine sait, mille omanik ilmselt eelistab selle kasutamist www-ga.

1. Esilehe ümbersuunamised

is-my-https_main

Nagu näha, käib HTTPS peale suunamine “ajutise” ehk 302 redirectiga – ning ostetud sertifikaat ei kata ilma www-ta nime (link avab SSL Labs superpõhjaliku sertifikaadi-kontrolli tööriista, mis seletab ära vea olemuse).

Kuidas parandada?

Ümbersuunamiseks saab veebimeister lisada .htaccess faili suunamise, vastavalt soovile kas eelistades WWW-ga versiooni:

# eelistame www-ga domeeninime
RewriteEngine On

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,NC,L]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

… või vastupidi, ilma:

# eelistame ILMA www-ta domeeninime
RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301,NC,L]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Sertifikaadi-vea vastu aitab ainult uue sertifikaadi tellimine – kui tellida Zonest sertifikaat kujul www.domain.ee, pannakse sinna automaatselt kirja ka domain.ee ehk see kehtib mõlemale. Let’s Encrypt sertifikaat tehakse meie puhul automaatselt kõigile vastava serveri (või alamdomeeni) nimedele, sh kõigile aliastele. Keerulisemad juhtumid vajavad personaalset lähenemist (ülaloleva näite puhul on suurel kontsernil kasutusel mitut saiti kattev sertifikaat ja sealt on lihtsalt üks nimekuju puudu).

2. Alamlehtede ümbersuunamised

Edasi tulevad alamlehe-testid, juhul kui selline URLis sisaldus:

is-my-https_subpage

Siit hakkab silma üks huvitav nüanss – nimelt pakub sait sama sisu nii …/uudised kui keele-tunnust sisaldavalt …/et/uudised lehelt, koodis olev canonical-silt palub eelistada ilma keeletunnuseta versiooni:

<link rel="canonical" href="https://www.[peidetud].ee/uudised" />

Ilmselt on neil kasutusel keerulisem ümber-suunamiste loogika kui ülalviidatud .htaccess – ning lihtsat lahendust ei saa ilma seda nägemata pakkuda.

3. Pildid, skriptid ja stiilid

Järgmiseks tulevad pildid, javascript ja stiilid:is-my-https_images

Sedapuhku on nendega kõik hästi, kuvatakse vaid tähelepanekut, et pildid võetakse eraldi alamdomeenilt. Meedia hoidmine eraldi serveris oli HTTP 1.1-ajastul mõistlik võte lehe kuvamise kiirendamiseks (veebibrauser saab luua iga saidi jaoks oma ühenduse), võttes kasutusele HTTP/2 võiks olla efektiivsem kasutada ühte serveriühendust.

Õnneks ei ole keeruline leida mõnda teist veebi, kus oleks reaalne probleem piltidega – antud puhul on tegemist WordPressiga, kus on ilmselt enne HTTPS peale viimist lisatud lehtedele pilte:

is-my-https_images2

Kuidas parandada?
  • kontrolli üle veebimootori seadistused – kas ta on ikka veendunud, et peab töötama https:// aadressi peal?
  • palu veebimeistril kontrollida, ega juhuslikult lehe kujundusteemasse mõni http:// pole sisse ununenud
  • enamus ülejäänud probleemidest on seotud sisusse lisatud piltidega – nende muutmiseks tuleb lehed käsitsi üle käia või paluda veebimeistril teha vastavas andmebaasis otsi-ja-asenda käsk
  • probleemiks võivad nt WordPressi tavakasutaja-tasemel seadistatavate teemade puhul olla ka lisatud taustapilt (vaheta välja), favicon jms – selgita välja kust probleemne element tuleb ja vaheta välja

4. Veebisisesed lingid

Ja lõpuks – kas lehel on veebi-siseseid linke, mis viitavad vanale HTTP versioonile? Kui ümbersuunamine toimib korrektselt, siis ei ole need otseselt probleemiks, küll aga peab kasutaja brauser tegema lisapäringu:

is-my-https_links

Soovitused nendega tegelemiseks on samad, mis piltide jms puhul – tegemist võib olla lehe tekstis olevate linkidega, aga üle tasub käia ka menüüd, jaluses kuvatavad teksti moodulid (lingid kasutustingimustele jms).

Täienduseks: kui oled veebi HTTPS peal korralikult käima saanud, on paras aeg lisada ka HSTS-päis ehk paluda brauseritel sellel saidil alati ainult HTTPSi kasutada ning keelduda vigase sertifikaadi puhul sisu kuvamisest: HTTPS ja HSTS ehk Strict-Transport-Security


Kui avastad probleemi, mida see tööriist ei tuvasta (või ekslikult tuvastab) – siis anna mulle teada peeter@zone.ee. Võid kirjutada ka juhul, kui vajad rohkem juhendamist probleemide kõrvaldamiseks, sest siis saab tekitada täpsema/põhjalikuma juhendi.

Chrome kuulutab äärmiselt levinud SHA-1 turvasertifikaadid soovimatuteks

TuvalisusKas vastutad veebisaidi eest, mis kasutab HTTPS ühendust? Kui nii, loe kindlasti edasi ja vasta mõttes järgmistele kontrollküsimustele:

  • Kas su sertifikaat on signeeritud SHA-1 algoritmiga?
  • Kas su sertifikaat aegub pärast 2015. aasta detsembrit?
  • Kas soovid, et Chrome kasutajad peavad su saiti turvaliseks?

Kui vastasid jaatavalt kõigile kolmele küsimusele, on aeg tegutsemiseks, sest käes on #shapokalüpsis.

Loe edasi “Chrome kuulutab äärmiselt levinud SHA-1 turvasertifikaadid soovimatuteks”