В последно време в интернет пространството се води сериозна обществена дискусия дали е необходимо уеб сайтовете да бъдат пренасочвани към HTTPS. Самата миграция има своите плюсове и минуси. От едно известно време обаче въпросът не е вече “дали?”, а е по-скоро “кога?”. Затова решихме да опишем всички стъпки за преминаването към HTTPS в няколко статии. Не забравяйте, че можете да закупите SSL/TLS сертификати от Jump.BG или да използвате безплатни такива.
Предварително трябва да знаете, че преминаването към кодирана комуникация е малко по-сложен процес. Има няколко стъпки, които трябва да се направят в точно определена последователност. Времето за закупуване и издаване на сертификат е различно в зависимост от сертификата - за обикновени може да отнеме няколко часа, но за сертификати с разширена проверка (EV SSL) може да стигне до един месец. Самото време за мигрирането на даден уеб сайт към сигурна връзка може да отнеме както час-два за малки сайтове, до няколко дена или седмица за по-големи. При огромните уеб сайтове обаче процесът може да отнеме няколко месеца или дори година. Затова е важно предварително да си направите по-голям буфер във времето за горните задачи, ако имате краен срок за миграция.
Първият и най-важен въпрос, на който ще ви отговорим, е:
Защо трябва да преминете към HTTPS?
Въпреки, че отговорът на пръв поглед изглежда лесен, съществуват няколко основни причини, които са от изключителна важност за съществуването на вашия уеб сайт.
1. Сигурност
Използването на сигурна връзка (HTTPS) позволява на сървъра и на клиента да обменят безопасно данни. Реално всеки един компютър във вашата локална мрежа, рутерите, през които минава интернет трафикът и междинните сървъри могат да наблюдават целия ви трафик. Ако не използвате криптиране, тези данни може да попаднат в чужди ръце. Това включва пароли, поверителна информация, проследяване на интернет активността ви и всякаква друга информация. Тази информация може да бъде използвана срещу вас, причинявайки ви както материални, така и нематериали щети. Всичко това обаче се променя с използването на сигурна (криптирана) връзка, която гарантира, че трети страни, намиращи се по интернет трасето, няма да могат да проследят съдържанието на информацията между клиента и сървъра. Те ще могат само да определят, че е имало някакъв обмен на информация, но самото съдържание ще е известно само на тези две страни (клиент - сървър). Това е от жизненоважно значение за електронните магазини, интернет банкирането и управлението на електронни пощи. Друг подходящ пример са системите за управление на хостинг фирмите. Най-общо казано - има ли намесени пари, дебитни/кредитни карти или пароли - сигурността вече е абсолютно задължителна.
2. SEO
Повечето търсещи машини обявиха, че един от факторите за по-добро класиране е използването на HTTPS . И това не е никак странно, защото резултатите сочат, че сайтовете със сигурна връзка са малко по-стойностни от останалите:
https://twitter.com/mattcutts/status/497295150884741120
Това не означава автоматично, че самоцелното използване на HTTPS ще донесе по-добро класиране на сайта. Ако съществуват няколко уеб сайта с еднакви параметри, то тези, които използват HTTPS, ще бъдат класирани малко по-добре.
3. Доверие
Доверието в потребителите е от изключително важно значение за развитието на вашия бизнес. Ако забележите, че даден уеб сайт иска от вас финансова информация, като номера на кредитни карти, то доверието в този сайт ще бъде сринато за секунди. Самият факт, че такава важна информация ще бъде предадена по несигурна връзка, е обезпокоителен.
4. Трафик данни от други сайтове
Възможно е да има загуба на данни, ако трафикът към уеб сайта ви идва от други уеб сайтове, използващи сигурна връзка, а вашият не използва такава. В този случай в спецификациите на HTTP протокола изрично е записано, че информацията, която идва от уеб сайт със сигурна връзка не трябва да бъде предавана към уеб сайта с несигурна връзка. Така използването на статистически софтуер, като Google Analytics, ще покаже, че това посещение е “директно”, въпреки че не е. Изводът е, че информацията за препратките към вашия сайт от други сайтове не е достъпна за подобни софтуери, поне докато не го пренасочите към HTTPS.
5. Избягване на предупрежденията от браузърите
От месец януари 2017 година всички модерни браузъри показват предупредителни прозорци, уведомяващи потребителите, че данните им са предавани по несигурна връзка. Това важи само ако сайтът изисква въвеждането на пароли или финансова информация. Ето как изглежда това под Firefox и Chrome:
Тази стъпка е само част от една по-голяма инициатива, насочена към използването на по-сигурен интернет и е описана тук и тук.
6. Ускорение - HTTP/2
HTTP/2 включва много революционни нововъведения, като мултиплексиране, по-добра компресия, сървърно изпращане на файлове (push или hint) и още много други. Всичко това обаче не може да се използва, ако нямате изградена сигурна връзка. Активирането на HTTP/2 е възможно, ако уеб сайтът използва сигурна връзка.
Както сами виждате, съществуват различни причини, заради които е време да се ориентирате към HTTPS. Сега обаче ще минем към това откъде да поискате сертификат, какви са различните видове и кой е подходящ за вашия проект.
- Всеки сертификат представлява двойка ключове (числа) - личен и публичен. Информацията се кодира с личния ключ и може да се декодира само и единствено с публичния ключ. Личният ключ абсолютно никога не напуска пределите на сървъра, откъдето се изпраща информация. Към останалия свят се пуска само публичния ключ. Така всеки клиент, след като декодира информацията, получава сигурност, че е дошла точно от източника и не е променена някъде в интернет по трасето.
- Сертификатите се подписват от CA (издатели на сертификати), които удостоверяват, че сертификатът е валиден. Във всички системи има списък на официални издатели, от които може да се получават сертификати и да се считат за валидни. Тогава самият сертификат има “път” и може да се проследи от кой издател е подписан.
- Процесът на подписването на сертификат от CA се казва “изискване за подписване на сертификат” (certificate signing request), при което вие изпращате заявка към CA, съдържаща вашия публичен ключ. След това CA връща подписано съобщение със своя личен ключ (без самия ключ разбира се!), което съдържа вашия публичен ключ. При декодиране със CA устройствата виждат вашия публичен ключ и декодират данните ви успешно, защото знаят, че сертификатът ви е подписан от CA.
- Може да се използват сертификати, които не са подписани от CA. Тогава самият сертификат се именува “самоподписан” и предизвиква показване на грешка при всички компютри. Не се появява грешка, само ако сертификатът не се добави ръчно в списъка с доверените сертификати на съответния компютър или устройство. Не ви препоръчваме използването на самоподписани сертификати, освен ако не тествате HTTPS или го използвате за вътрешнофирмена комуникация.
- Всички сертификати имат дата на издаване, дата на валидност (година-две или повече) и дата, преди която да не се използва. Използването на сертификата извън определените дати предизвиква показване на грешка.
- Използването на невалидни сертификати - самоподписани, изтекли във времето или отговарящи за друг хост, не означава, че връзката ви със сървъра не е сигурна. Означава единствено, че доверието в сертификата не е доказано от издател, така че можете да продължите комуникацията с този уеб сайт, но на ваша отговорност. Можете и да откажете по-нататъшна комуникация, ако прецените, че не можете да гласувате доверие на уеб сайта
Съществуват няколко типа сертификати - сертификат за електронна поща, сертификат за подписване на приложения, сертификат за сигурна връзка и други. Днес обаче ще говорим само за сертификати за сигурна връзка.
Ако сертификатът ви е откраднат, съществува процедура за отнемане на подписването на сертификата от доставчика. Процедурата се казва “отмяна” (revoke). Това е причината да съществува опция, при която клиентът може да провери дали е валиден с отделно запитване към CA, след като вече е получил данни за сертификат. Тази операция е една форма на допълнителна защита срещу неправомерно използване на сертификатите и двойката ключове от неоторизирани лица.
Преди над 10 години за използването на сигурна връзка се изискваше да имате отделен интернет адрес (IP). Това обаче не е валидно в днешно време, защото всички сървъри и клиенти поддържат разширение SNI, което позволява на един адрес да се намират много сайтове със защитена връзка. Единствените по-големи изключения сред клиентите са Windows XP, Internet Explorer 6, както и Android 2.X, които не поддържат това разширение. Ако имате клиенти с тези операционни системи, то тогава ще трябва да изисквате от вашият хостинг отделен адрес.
Един сертификат обслужва един домейн. Сертификатът обаче може да бъде настроен да обслужва няколко други поддомейна. Пример – един сертификат може да обслужва www.jump.bg и да се добави в същия сертификат, че е валиден, ако обслужва само jump.bg. Името на тази функционалност е “алтернативни имена” и е изключиетлно важна. Може да се издаде сертификат, който да обслужва всички поддомейни от даден домейн. Например сертификатът се издава за *.jump.bg и обслужва едновременно mail.jump.bg, admin.jump.bg, help.jump.bg, blog.jump.bg и всички поддомейни под jump.bg. Името на тази функционалност е “сертификат за целия сайт” (wildcard).
Сертификатът може да бъде даже още по-сигурен, ако издателят провери фирмата, която стои зад самия сайт. Това може да бъде по адрес, телефонен номер и дори изискване на фирмената регистрация. Тези проверки удостоверяват, че зад самия сертификат действително стои фирмата, която го изисква, както и че удостоверяващият издател го е проверил преди да издаде сертификата. Тези сертификати се наричат “с разширена проверка” (extended validation - EV). При тях характерното е, че клиентът показва наличието на такъв сертификат с промяна на фона на адреса за въвеждане или с показване на фирмената регистрация. Тези сертификати се издават по-бавно и процедурата може да отнеме месец.
Всички сертификати са платени и цените им варират. Най-евтините сертификати са обикновените, след това - сертификатите за целия сайт, а най-скъпи са тези с разширена проверка. Съществуват обаче издатели, които позволяват да получите напълно безплатно валидни сертификати - Lets Encrypt и StartSSL. Първият издател се ползва с подкрепата на големи интернет фирми, като Google, Facebook, Cisco, Akamai и други. Недостатъкът е, че сертификатите имат валидност само 3 месеца (90 дена) и трябва да се подновяват по-често. Вторият издател е частна израелска фирма, която позволява безплатното издаване на сертификати за сигурна връзка след тяхна проверка. Тези имат срок от една година.
Какъв сертификат да си изберем?
Трудно е да се обобщи кой сертификат е най-правилният за вашите нуджи, но ще ви дадем няколо съвета, по които да се водите при избора.
- Ако сте голяма организация и доверието е много важно за вас - тогава единственият логичен избор за вас е EV сертификат или Wildcard EV сертификат. Такива сертификати са подходящи за държавни или финансови институции основно, но не само. Примери: ePay.bg, fibank.bg, Търговски регистър, PayPal.com. WordPress.com също използва EV сертификат.
- Ако сте голяма организация и искате да използвате един и същи сертификат на много поддомейни, като едновременно желаете да спестите от такси, подходящият избор за вас е Wildcard сертификат. Един пример е WordPress.org - сертификатът се използва на make.wordpress.org, learn.wordpress.org, developers.wordpress.org и всички останали уеб сайтове от WordPress.org. Причината е чисто икономическа. Инсталацията на един сертификат е много лесна и бърза, цената е малко по-висока от нормалните сертификати, а се инсталира на неограничен брой поддомейни.
- Ако ви трябва обикновен сертификат, например за електронен магазин, има 2 начина да го придобиете. Първият е да закупите такъв от доставчик - цените са напълно поносими и започват от около 20 лева на година, а срокът му може да бъде 1, 2 или 3 години. Удобството е, че в този случай няма да се занимавате с инсталации и настройки на сървъра и сертификата няколко години. Вторият начин е да вземете сертификат чрез някой от безплатните доставчици - LetsEncrypt или StartSSL. Безплатните сертификати по никакъв начин не отстъпват на платените в този случай. Разликата между тях е, че периодът на издаване е ограничен - LetsEncrypt има срок от 90 дена (3 месеца), StartSSL има ограничение от 1 година.
Сега вече трябва да имате по-ясна представа за това какво представляват сертификатите за HTTPS и как ще ви помогнат в развитието на проекта ви. Решихме да ви покажем как можете сами да инсталирате сертификат за HTTPS. Трябва да знаете, че процесът е малко по-сложен и се изискват технически познания, така че ако не разполагате с необходимите познания, по-добре се обърнете към фирмата, която ви поддържа сайта или към вашия хостинг доставчик.
Ние ще използваме безплатния LetsEncrypt сертификат. Този тип сертификати обаче не се издават със CSR. Организацията е разработила специфичен протокол за издаването, наречен “Автоматизирана среда за управление на сертификати” (Automated Certificate Management Environment).
1. Използване на AutoSSL
Това е най-лесният начин за получаване на сертификат. Такъв се генерира от LetsEncrypt и автоматично се инсталира на всички сайтове на сървъра. Ако уеб сайтът има друг валиден сертификат, не се издава нов, нито се променя съществуващият. Можете да проверите дали вашият хостинг доставчик използва AutoSSL или друга подобна система за автоматично генериране на сертификати с LetsEncrypt. Jump.BG поддържаме AutoSSL на повечето хостинг планове.
2. Генериране на сертификат за LetsEncrypt с помоща на https://gethttpsforfree.com
3. Проверка на сертификата
Сами виждате, че нещата са малко по-сложни и се изискват технически познания. Това е причината в добрите хостинг компании да съществуват висококвалифицирани екипи за обслужване на клиенти. Ако имате някакви въпроси за издаването или инсталацията на сертификата и нямате достатъчно опит, ви препоръчваме да поискате помощ от съответния екип. Има много издатели на сертификати и едно запитване към хостинг доставчика ви, може да спести много главоболия - както по време на издаване на сертификата, така и по време на инсталирането му. Прозесът по мигриране към HTTPS е дълъг, затова направихме още две статии. Във втора част на процеса по преминаване към HTTPS вижте подробно как да мигрирате WordPress уеб сайта си изцяло към HTTPS. В трета част описахме всеки един важен момент и стъпките, които е необходимо да бъдат направени точно след миграцията.