Бићу опширан али зато и компликован. Сви причају о том HTTPS-у сад, SSL/TLS, Google Chrome сајтове са инпут пољима који нису иза HTTPS-а без обзира о којим се инпут пољима ради, добар је за SEO и слично – али да бацимо на папирче има ли негативних ствари око SSL/TLS-а и HTTPS-а. Ако сте техникалац и знате основе – скролујте до МАНЕ.

Прво за неупућене – шта је HTTPS? HTTPS је безбеднија верзија застарелог HTTP-а која обичан HTTP ‘замиксује’ са SSL/TLS протоколом те зашифрује саобраћај од тачке А која је твој браузер – до тачке Б која је веб сервер и теоретски свако ко се постави између тебе и веб сервера – не може али ништа да прочита више од тога – који си сајт посетио. Шта ово практично значи – кад на сајту унесете свој имејл, име, презиме, број платне картице, жалбу на женин ручак, Вучићу педеру и слично – ако саобраћај није зашифрован свако ко се постави између тебе и веб сервера имаће увид у све што си написао и моћи ће то злоупотребити ако жели – да нешто плати твојом картицом или да ти призове Информер и Пинк на врата….а између могу да се поставе – приучени хакери, скрипт кидис, интернет провајдер, сва чворишта која пакет прође од браузера до веб сервера и питај бога ко још.

Дакле – ако уносите било какве осетљиве податке било где – ако не видите у адресној линији браузера катанац и HTTPS – одустаните од куповине ОДМАХ – јер тај чија је та интернет продавница је курац од овце кад је озбиљност у питању те потражите исти производ на некој другој е-локацији.

Да ли је HTTPS у самој адресној линији браузера који видите довољан доказ да је сајт безбедан?

НЕ. Прво – да ли је сам SSL сертификат инсталиран како треба? Да би HTTPS био ‘у пуном сјају’ морају се испоштовати неки стандарди које треба да примени ћојек који одржава сервер на којем се врти сајт…а да бих објаснио где све ђаво вреба прво ћу објаснити како тече комуникација између браузера (у даљем тексту зваћемо га клијент) и веб сервера кад је SSL у питању…односно такозвани SSL handshake илити SSL руковање између клијента и сервера.

Укуцате у свој Firefox/Chrome/Opera https://kompjuteras.com – одради се иницијална комуникација преко DNS-а која тај захтев упути на сервер где се физички налази сајт и пита сам сервер – ко си ти…и пошаље му инфо на које све начине могу да размене између себе кључеве и сертификате. Овај одабере метод па му пошаље назад сертификат у којем је између осталог и домен као и доказ да су та-и-та особа или организација заиста заиста власници датог домена – али и свој јавни кључ. Браузер прочита сертификат и увери се да је везан за тај домен али онда довати неки случајни стринг зашифрује га јавним кључем сервера и прогласи за обичан симтрични кључ везан за дату сесију па га врати назад серверу – овај покуша да дешифрује тај симетрични кључ својим приватним кључем и ако успе то постаје и званични симетрични кључ везан за ту сесију (session key) и даља комуникација се одвија преко њега. Зашто симетричним а не асиметричним – јер је лакше за ресурсе и веб сервера и браузера. Иако ово делује као лудачки процес – заправо се одвија у делићима секунде и не осети се. Ако се ико постави између вас и веб сервера неће имати увид ни у странице које посећејете ни у податке које остављате, понављам – ако је све исконфигурисано како треба и наравно, ако корисник није преварен да користи други сертификат који није валидиран.

Асиметрични кључеви или ти асиметрична криптографија – је методологија шифровања помоћу два кључа – јавног и приватног при чему су оба кључа различита. Јавни кључ користи клијент да зашифрује нешто, приватни користи сервер да одшифрује то нешто што му је клијент зашифровао јавним кључем.
Симетрична енкрипција – то ти је контра од овог првог, кад су кључеви за шифровање исти и на страни сервера и на страни клијента. Рецимо – пошаљеш текст некоме на папирчету KJNjZOJ EŠPŠFJ и да при том тај неко зна да је папирче послао Цезар….било би му довољно да зна шта на папирчету пише (више о Цезаровој шифри на Википедији).

Дакле у горенаведеном handshake-у, користила се комбинација асиметричне и симетричне енкрипције.

ОК, ово је све ОК, зашто онда ‘није довољно’ безбедно?

Слабе карике су метода размене кључева, сам сертификат и његова верзија, тип и јачина енкрипције, имплементација на самом веб серверу, библиотеке које пружају криптографске сервисе веб серверу и апликацијама….али не могу сад писати над сваким од њих где је потенционални проблем – морао бих бар 2-3 дана да куцкам. Најкритичнији је део везан за размену кључева и верзију сертификата – примера ради, сајт који користи застарелу верзију OpenSSL-а….џаба му све на овом свету иако је иза HTTPS-а….јер ће малициозни корисник који се постави између опет моћи да чита шта му срцу мило – под рупом званом „The Heartbleed Bug“ која је пре 3 године одјекнула као атомска бомба у веб свету.

МАНЕ и МИТОВИ код пребацивања са HTTP на HTTPS

Прва и власницима сајтова најбитнија мана – ГУБИТАК ПОСЕТА! Откуд сад то? Ствар је у томе што старији браузери, Windows XP, старији Андроид уређаји не могу да испрате новије методе размене кључева или верзија SSL/TLS-а па са њих или није могућ приступ сајту или ће посетиоцима избацити ‘This site is unsecured’ поруку која ће их одбити од посете сајту. Дакле, сви корисници који користе Windows XP, Интернет експлорер старији од осмице, старе Андроиде и остало старо – посете њиx…а таквих застарелих корисника има и заправо је кривица на њима а не на вама – али опет, трпите ви због њихове застарелости. Пример из прве руке – кад је kompjuteras.com пребачен на HTTPS – било је изгубљено преко 20% посета. Ако имате највишу оцену на SSL-лабс тесту…у проблему сте са корисницима на старијим браузерима и ОС-овима, ако имате ниску оцену у проблему сте са безбедношћу комуникације, ако имате средњу оцену – онда нит’ вамо нит’ намо….некако не ваља како год.

Како до А+ оцене на SSL-labs тесту и на VestaCP-у – упутство овде (на латиници)

Лајк/Твит бројачи ће бити ‘највероватније’ ресетовани! Постоје неки фазони да се овај проблем заобиђе али мало људи зна за њега а мало људи и заправо и примети да се бројач ресетовао. Ја искрено нисам проверавао да ли може ово да се одради, али вероваћу људима.

Морају да се прате новости кад је SSL у питању! Зашто? HTTP није као HTTPS – он је у plaintext формату и као такав може да се чита одаклегод и какогод без да ће нешто да утиче на његову безбедност, док HTTPS-у у будућности може да се деси неки нови Heartbleed Bug – па ће се морати ‘нешто надоградити’ – што, ако сте власник сајта а нисте техникалац од вас тражи ангажман системаша, читај – додатни кеш. Ако сте на схаред хостингу ово ће највероватније да испрати системаш хостинг провајдера – а сад, да ли ће сигурно – ево не знам богами. Праћење новости није проблем јер кад се деси неки нови Heartbleed сви живи ће дрвити само о томе, нема да бринете…

Нема вируса, нема хакерских упада, сајт држе озбиљни људи или компаније – мало сутра! То што неко има SSL сертификат и све је иза HTTPS-а никако не гарантује да се на самом сајту не налази малициозни код, вирус или икаква заштита од вируса и ичега. То само значи да нико не може (још увек званично, за незванично нисам сигуран) да снифује комуникацију између вас и веб сервера. Сам сертификат и његова валидација зависе од типа купљеног сертификата – неки продавци скупљих сертификата нуде и дневно скенирање сајта у потрази за малициозним софтвером или кодом. Доменски валидирани сертификати, као што им име говори су ту само да потврде да је домен валидиран и да су ваши контакт подаци везани за њега – а сад, да ли је озбиљна фирма иза тог сајта питање је. Можете имати и бесплатан LetsEncrypt сертификат и дићи сајт на којем ћете варати купце или купца – дакле комуникације ће бити безбедна и ту је све ОК али постоји могућност да вам стигне цепаница уместо Acer лаптопа, дакле сем самог катанца у адресној линији морате да испратите ипак и репутацију самог продавца. Примера ради, на ФБ у последње време све пришти од сајтова који нуде на продају коришћене лаптопове у одличном стању, при чему рецимо лаптоп који би полован коштао 400€ – код њих кошта фазон 90…све је иза HTTPS-а, SSL-лабс им дао оцену А+…а уствари преварантски сајт.

Миграција сајта на HTTPS – иако се рекламира као једноставна…ономе ко није технички поткован може бити убица или додатни трошак за неког системаша. Срећа је па има упутстава на нету како се ради миграција. У случају Компјутераш ИТ блога, миграција је одрађена помоћу interconnect/it алата за replace url-ова у бази и неколико измена по фајловима Вордпреса.