C, PHP, VB, .NET

Досега силно препоръчвахме употребата на SSL, но не дадохме конкретна информация как точно ще бъде защитена нашата комуникация с него. SSL e съкращение на „Secure Socket Layer“ и се използва изключително широко при криптиране на мрежови трафик. Най-често се използва при world wide web за криптиране на HTTP, но вече много често може да бъде видян и при други протоколи, като FTP, SMTP, NNTP, POP3, IMAP и т.н.

1. История: SSL започва своето развитие с версия 1.0, разработена от Netscape през 1993. Тя никога не излиза за публичен достъп, тъй като още в процеса на разработка са открити множество пробиви в сигурността.

През 1994г. се появява втората версия SSL 2.0. За нещастие много бързо са открити редица пробиви в сигурността, като:
– Слаби кодове за автентикация;
– Методи за насочване на двете страни да използват по-слаб алгоритъм за криптиране;
– Липса на защита по време на „договарянето“;
– Множество други атаки.

През 1995г. Microsoft правят опит за внедряване на тяхна алтернатива – PCT. Не придобива широка популярност, но все още съществува като стандарт.

През 1996г. отново Netscape изваждат най-популярният и най-широко използван досега стандарт SSL 3.0. В момента почти всички уеб сървъри, подържащи https криптиран канал за комуникация, поддържат SSL 3.0.

През 1999г. излиза TLS (Transport Layer Security) – още известен като SSL 3.1. Това всъщност е обединение на SSL и PCT (тоест може да работи и с двата стандарта). Този протокол добавя и подобрения в сигурността над SSL 3.0, но те засега са само препоръчителни, тъй като TLS е напълно съвместим със „стари“ клиенти, използващи SSL 3.0.

2. Принцип на действие: Вече обяснихме проблема с подслушването на трафик. Всяка една мрежа е застрашена от злонамерени хора, целящи да откраднат информация. И така – как SSL решава този проблем?

SSL основно се базира на идеята за криптиране чрез публичен и частен ключ. В началото, при установяването на връзката, двете страни на комуникацията си разменят своите „сертификати“. Те съдържат в себе си публичните ключове и допълнителна информация, за която ще говорим по-долу. При по-нататъшна комуникация всяка от страните изпраща информацията си кодирана чрез публичния ключ на другата страна. Информацията, кодирана с такъв публичен ключ, може да бъде декодирана единствено използвайки съответветващия му частен ключ. Тъй като частните ключове остават невидими за подслушващия трафика, то той не може да дешифрира тази информация.

За нещастие самият процес на криптиране не е единствения проблем, с който се сблъскваме в реално време. Чрез криптография ние наистина сме изолирали подслушващите трафика, но не сме решили проблема с „подменящите“ трафика (т.е. когато стои „човек по средата“ на комуникацията – пред клиента се представя за сървър, а пред сървъра за клиент). Тези атаки биха били успешни, ако няма начин за удостоверяване на автентичността на сертификата (атакуващият просто предава своя публичен ключ и на двете страни и използва своя частен за дешифриране на целия трафик):

Клиент <–> Атакуващ <–> Сървър

Очевидна е нуждата от удостоверение за автентичност на сертификат. SSL се справя с този проблем, като сертификата се подписва чрез т.нар. „CA“ (съкратено от Certificate Authority). Всеки сертификат се издава за даден уебсайт (на строго определен статичен IP адрес) от някоя трета страна, наречена CA. В публичният интернет това са организации като Verisign, Comodo, Geotrust, Globalsign и др. При локални мрежи това може да е централният сървър или компютъра на системия администратор. CA одобрява сертификатът на сървъра, като специално указват за кой hostname е издаден. Ето например сертификата на Google:

Ако сървър се опита да предложи сертификат, който не е подписан, ще бъде изведена грешка в браузъра на клиента. Той обаче все пак има възможност да продължи на своя отговорност. Ето един пример:

Публичните сертификати от Verisign, Comodo, и т.н. сравнително скъпа услуга. Обикновено малките уеб сайтове, предлагащи безплатни услуги (както например моят cphpvb.net) не могат да си позволят закупуването на такъв сертификат (света все пак се върти от бизнеса). Браузърът на клиента ще приеме за валиден само сертификат, който е верифициран от един от т.нар. root сертификати (тези на големите CA). Ако ние сами издадем сертификат за себе си (подписваме собствения си сертификат с наше собствено CA), ще е нужно да накараме всичките си клиенти да вкарат нашия CA сертификат като „trusted“ в своя браузър. В Интернет среда това е нереалистично. За локалните мрежи обаче това е честа практика. Използвайки domain controller можем лесно да накараме клиентите да приемат нашия сертификат за един от т.нар. „root“ сертификати.

3. Проблеми с SSL:

а) Понижаването на версия: Преди няколко години беше често явление сървъра да поддържа едновременно SSL 3.0 и SSL 2.0, с цел да донесе обратна съвместимост с по-стари браузъри. Това веднага можем да приемем като пробив в сигурността, тъй като атакуващият може да накара двете страни да се „споразумеят“ да използват по-старата версия. След това, подслушвайки трафика им, той ще може да използва уязвимостите в по-стария протокол.

б) Отново с цел обратна съвместимост се срещат сървъри, които поддържат слабо криптиране (56 или по-малко битове). Такова криптиране с днешната техника може да бъде дешифрирано с brute force атака за няколко дни. При използването на 128 или по-високо ниво можем все още да се чувстваме сравнително спокойни.

в) Използването на ненадеждни hash алгоритми е един също възможен проблем. Тъй като md5 и ssh1 са достатъчно популярни стандарти, вие можете да изключите всички по-малко надеждни алгоритми за вашия сървър.

г) Пренасочване към некриптиран канал, ако „споразумението“ между страните пропадне – това е най-често срещания проблем, който на практика обезсмисля всякаква защита. Ако една услуга трябва да бъде криптирана, то никога не я пускайте през некриптиран канал!

д) Всеки сертификат има срок на валидност. По предтекст, че има минимален период от време за който можем да приемем, че една brute force атака би намерила нашия частен ключ, големите CA ни взимат парите за подновяване на двойката публичен/частен ключ. Това всъщност е един доста реален аргумент – би било хубаво да подменяме сертификатите си колкото се може по-често. Изтеклите сертификати довеждат до съобщения за грешки, много подобни на тези на напълно невалидните сертификати. По този начин клиентите започват да свикват с тях и няма да обърнат внимание ако съобщението за грешка се смени (атакуващият е застанал по средата). Подновявайте сертификатите си!

е) Уязвимост при машината на клиента може да доведе до презаписване на неговия публичен/частен ключ или добавянето на невалиден root CA в браузъра му. Тук протокола SSL е безсилен, а и не би трябвало да му влиза в работата да следи за чужди грешки.

ж) Вече споменахме за проблемите при прехвърляне на session ID през некриптиран канал. Надяваме се, че ги помните. SSL няма да ви помогне при наличие на session fixation или session hijacking.

и) Всеки пробив в сигурността, при който частен ключ бъде видян от чужда машина, е фатален.

й) Възможно е използването на статистически методи за намиране на често срещани думи при прехвърлянето на информация. Такъв е например низа „GET / HTTP/1.0“, предаван от клиент към сървър. Очевидно е, че той ще бъде прехвърлян всеки път криптиран по един и същи начин. Прихващайки тази информация атакуващият е улеснен в опитите си с brute force атака, тъй като вече знае какъв резултат трябва да очаква при дешифриране на дадения низ. Засега SSL и TLS не решават този проблем.

В разгледаният вариант за комуникация може би сте забелязали, че само една от страните на комуникацията е защитена от CA – това е сървърът. При тази комуникация сертификатът на клиента не се автентикира за достоверност. Възможна е естествено и комуникация между две валидиращи се взаимно страни (обикновено това е комуникация между два сървъра).

4. Процедура за регистриране на SSL сертификат:

За да регистрирате SSL сертификат е нужно първо да генерирате CSR (certificate signing request). Той включва следните данни:
– Common Name: hostname, за който искате сертификат;
– Organisation: име на вашата фирма (сертификатите се предполага, че се използва от фирми);
– Organisation Unit: отдел на вашата фирма, например „support“, „marketing“, …;
– City: град, в който е регистрирана вашата фирма;
– Region: щат или област, в която е регистрирана фирмата;
– Country: държава;
– E-mail: адрес за връзка с вашата фирма.

Самият CSR се изпраща в криптиран вид към CA. Допълнително трябва да представите и информация за типа на вашия сървър, например apache mod_ssl, openssl, internet information server, и т.н. В замяна вие ще получите три файла – ca.crt, domain.crt и domain.key. Двата crt файла са съответно публичния ключ на CA и вашият собствен публичен ключ. Файлът завършващ с разширение key е вашият частен ключ (който трябва да бъде пазен със всички възможни средства). Следвайте инструкциите на сървъра, който използвате за да настроите вашия SSL сертификат.

5. Passphrase:

Passphrase е нещо като парола, защитаваща вашия частен ключ, така че той да не може да бъде използван ако бъде откраднат (eдин вид криптиране на частния ключ). Ползата от използването на passphrase е спорна, защото повечето хора приемат, че ако някой успее да пробие вашата система дотам, че да открадне частния ключ, то той би имал достъп и до процеса на web сървъра. Тъй като web сървъра трябва да „знае“ passphrase, тъй като той използва частния ключ, то атакуващия тъй или иначе има достъп до желаната информация. Въпреки това считаме, че passphrase е ценно допълнение към защитата на системата. За съжаление има един голям недостатък, поради който почти никъде не е добил популярност – при всяко стартиране/рестартиране на сървъра вие трябва да въвеждате тази парола. Затова passphrase се използва само със системи, които са под постоянно наблюдение.

Задача: Националният осигурителен институт към момента (Декември 2008) не криптира данните при проверка на здравно осигурителен статус по ЕГН (healthinsurance.nssi.bg). Потърсете други представителни български институции, при които се предава конфиденциална информация и е възможно подслушването на трафик.