WordPressi viimine HTTPS peale

WordPressi veebi viimine HTTPS peale on lihtne – vaja on tellida Let’s Encrypt sertifikaat, muuta aadressis http:// ümber https://-iks ning asendada olemasolevates postitustes olevad pildi- ja sisulingid (selleks leiab abi pluginast).

Mõnel puhul võib http:// olla ka teemasse kirjutatud – siis ei jää muud üle, kui tuleb need kohad teema-failidest üles otsida ja asendada https://-iga (kui pole varem teema muutmisega tegelenud, siis tasub selleks punktiks küsida veebimeistri abi).

  1. Telli serverile Let’s Encrypt sertifikaat –  Minu Zone » Halda » Veebiserver » Let’s Encrypt, valida tuleb vaid vastav server (või alamdomeen). Sertifikaat väljastatakse nii www-ga kui ilma aadressile, samuti kõigile olemasolevatele aliastele. Kui sertifikaadi väljastamine ei õnnestu, on tõenäoliselt mingi probleem veebiserveri seadistustega, kirjuta info@zone.ee ja küsi julgelt abi.
  2. HTTPS toe käivitumine võtab kuni 10 minutit, võta üks kohv/tee/vesi.
  3. Sisene turvaliselt haldusliidesesse https://[firmanimi.eu]/wp-admin
  4. Muuda Sätted » Üldine saidi aadressis http:// ümber https:// -iks
  5. Paigalda ja lülita sisse Velvet Blues Update URLs plugin, seejärel mine Tööriistad » Update URLs ning sisesta Old URL lahtrisse oma veebi aadress http:// -ga ja New URL lahtrisse https:// -ga. Märgi kõik lahtrid peale GUID ja käivita asendus. Seejärel võid plugina deaktiveerida ja kustutada.
  6. Vaata veebis ringi – kas kõigi lehtede puhul on aadressiribal lisaks https://-ile näha ka “Secure”? Kui jah, siis õnnitlen!
    Kui ei, siis on teemas (või mõnes vanas pluginas) viidatud piltidele, fontidele, CSS-ile, või JavaScriptile kasutades http://-d. Selle kordategemiseks on vaja muuta vastavaid faile, seega tuleks leida üles oma veebimeister – aga tegevus on näha ka videos (ei ole väga keeruline, aga kui pole varem teemafaile puutunud küsi parem abi).
  7. Kui kõik lõplikult korras võiks minna veelkorda Minu Zone » Halda » Veebiserver ning Seadete või Alamdomeenide all klõpsata nuppu “Suuna kogu liiklus HTTPS peale” – nii saavad kõik URLid korraliku 301-ümbersuunamise.

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.

Let’s Encrypt nüüd “government grade” ka Eestis

Mullu septembris alustas Let’s Encrypt oma visiooni “Krüptime kogu veebiliikluse!” teostamist, Zone liitus beetaga detsembris – ja alates 12. aprillist on tegemist juba “päris asjaga”: Let’s Encrypt Leaving Beta, New Sponsors.

Kuna meie kaudu tellitud ja kehtivatest sertifikaatidest on tänase seisuga ca 20% Let’s Encrypt omad oli ka meil viimane aeg menüüst “beeta”-märkus maha võtta.

Täiendav tõuge selleks tuli otse ministeeriumist:

mkm-letsencrypt

Olgu lisatud, et tänu Let’s Encrypt-ile käib ka MKM’i IT-l HTTPS toe lisamine nende serverites olevatele saitidele ilma pikema jututa – muuseas poetatud vihje, et üks sait näeks rohelise tabalukuga kenam välja, sai lõunaks vastuse “Vajalikud HTTPS-i sertifikaadid genereeritud [ja paigaldatud]”. Tavapäraselt oleks hakatud kaaluma kas ikka on väga vaja, kas eelarves on raha ning koguma kooskõlastusi. Respekt ja tervitused kaasvõitlejatele!

Zone virtuaalserverite puhul saab Let’s Encrypt serdi tellida ja serverile lisada nii:

Nagu näha on ilma HTTPS toeta ehk Pakett I kasutava virtuaalserveri puhul Let’s Encrypt tellimise lehel ka nupp “Värskenda teenuspaketti” mis võimaldab ühe klikiga teha upgrade Pakett II peale – see annab muideks ka 2x rohkem paralleeltööühikuid ehk maakeeles “protsessori jõudu”. Tõsi, paketivahetuseks peab olema sisse loginud serveri omaniku ZoneID või sellega seotud identiteediga (delegeerimisest ei piisa).

Igaks juhuks ka pikem selgitus koos sellega, mida tuleks näiteks WordPressi ja Magento puhul muuta liikluse suunamiseks HTTPS peale.