Сигурна електронна поща с Mozilla Thunderbird и X.509 сертификати

Версия 1.0.1, 26 октомври 2008

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Адрес за кореспонденция: vesso AT vesselin.org

Първоизточник: http://www.vesselin.org

Лиценз на документа: CC Attribution-ShareAlike

 

 

Съдържание:

  1. Инсталиране и актуализация на Mozilla Thunderbird

    1.1. Инсталиране на Mozilla Thunderbird

    1.2. Актуализация на Mozilla Thunderbird

  2. Конфигурационни профили в Mozilla Thunderbird и използването им

  3. Сертификатно хранилище на Mozilla Thunderbird и работа с него

    3.1. Меню за управление на сертификатното хранилище и асоциираните към него модули и устройства

    3.2. Файлова организация на сертификатното хранилище

    3.3. Задаване или смяна на паролата за защита на частните ключове в сертификатното хранилище

    3.4. Заключване на сертификатното хранилище за достъп до частните ключове

    3.5. Отключване на сертификатното хранилище за достъп до частните ключове

    3.6. Добавяне на потребителски X.509 сертификат и прилежащия му частен ключ в сертификатното хранилище, чрез PKCS#12 форматен файл

    3.7. Добавяне на удостоверителски X.509 сертификат в сертификатното хранилище

    3.8. Добавяне на кореспондентски X.509 сертификат в сертификатното хранилище

    3.9. Изтриване на потребителски X.509 сертификат и прилежащия му частен ключ от сертификатното хранилище

    3.10. Изтриване на удостоверителски сертификат от сертификатното хранилище

    3.11. Изтриване на кореспондентски X.509 сертификат от сертификатното хранилище

    3.12. Създаване на PKCS#12 копие от въведените в сертификатното хранилище персонални X.509 сертификати и прилежащите им частни ключове

  4. Електронно подписване и криптиране на съдържанието на писма в Mozilla Thunderbird

    4.1. Общи принципи на електронното подписване и криптирането на съдържанието на електронната поща

    4.2. Асоцииране на клиентски X.509 сертификат към IMAP профил в Mozilla Thunderbird

    4.3. Електронно подписване на съдържанието на писмо в Mozilla Thunderbird

    4.4. Електронно подписване и последващо криптиране на съдържанието на писмо в Mozilla Thunderbird

    4.5. Проверка на електронен подпис и декриптиране на съдържанието на писмо в Mozilla Thunderbird

  5. Проверка на текущата валидност на използваните X.509 сертификати в Mozilla Thunderbird

    5.1. Механизми за проверка на текущата валидност на X.509 сертификатите

    5.2. Използване на списъци с отменени сертификати (CRL)

    5.2.1. Обща информация за списъците с отменени сертификати (CRL)

    5.2.2. Намиране на адреса на файл съдържащ CRL

    5.2.3. Меню за управление на CRL в сертификатното хранилище на Mozilla Thunderbird

    5.2.4. Добавяне на CRL в сертификатното хранилище на Mozilla Thunderbird и първоначално задаване на параметрите на актуализацията му

    5.2.5. Промяна на параметрите за актуализация на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

    5.2.6. Ръчно извършване на актуализация на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

    5.2.7. Премахване на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

    5.3. Проверка на валидността на X.509 сертификат в реално време чрез използване на OCSP

    5.3.1. Обща информация за OCSP и използването му

    5.3.2. Настройки на OCPS клиента на Mozilla Thunderbird

    5.4. CRL срещу OCSP

  6. Използване на TLSv1/SSLv3 в Mozilla Thunderbird за криптиране на комуникационните канали и удостоверяване пред пощенски или директорийни услуги

    6.1. Особености на използването на TLSv1 и SSLv3

    6.2. Особености на сертификатното удостоверяване на Mozilla Thunderbird пред TLSv1/SSLv3 базирани услуги

    6.3. Настройки на Mozilla Thunderbird за работа с TLSv1/SSLv3 базирани услуги

    6.3.1. Настройки за работа с IMAP

    6.3.2. Настройки за работа с SMTP

    6.3.3. Настройки за работа с LDAP базирани адресни книги

 

1. Инсталиране и актуализация на Mozilla Thunderbird

 

1.1. Инсталиране на Mozilla Thunderbird

Инсталирането на Mozilla Thunderbird трябва да става само и единствено от дистрибутивното пакетно хранилище. В дистрибуцията Red Hat Enterprise Linux (съответно CentOS и Fedora), името на дистрибутивния пакет е thunderbird. Не се препоръчва изтеглянето и използването на бинарния инсталатор от страницата на проекта, освен в краен случай.

Преди да се пристъпи към инсталация на пакета thunderbird, следва да се провери дали той не присъства вече в системата. Проверката може да стане директно чрез инструмента rpm, извикан от непривилигирован потребител:

$ rpm -q thunderbird

Ако пакетът е наличен, горния команден ред ще върне като резултат освен името на пакета и неговата дистрибутивна версия, например:

thunderbird-2.0.0.16-1.el5

Ако се установи, че пакета не е инсталиран, той трябва да се инсталира или чрез пакетния мениджър или чрез използването на Red Hat Network (последното е в сила, ако използваната дистрибуция е Red Hat Enterprise Linux). Ходът на инсталиране зависи от това какъв инструмент за управление на пакети се използва в конкретната дистрибуция. Red Hat Enterprise Linux 4 използва инструмента up2date. В този случай инсталирането може да стане в команден ред с права на root и изглежда така:

# up2date thunderbird

Конкретно за Red Hat Enterprise Linux 4 друг удобен начин е инсталиране на thunderbird през профила на системата в Red Hat Network.

Когато thunderbird трябва да се инсталира върху дистрибуции от типа на Red Hat Enterprise Linux 5, CentOS 4 и 5 или Fedora, може да се използа пакетния мениджър yum, с права на root:

# yum install thunderbird

Специално за случая на Red Hat Enterprise Linux 5 инсталацията може да бъде извършена през профила на системата в Red Hat Network.

 

 

1.2. Актуализация на Mozilla Thunderbird

Пощенският клиент Mozilla Thunderbird е обект на интензивен анализ от гледна точка на работоспособността и сигурността му. Подобен систематичен анализ понякога води от откриване на проблеми, които се класифицират по важност и най-критичните от тях се поправят във възможно най-кратък срок. Поправените версии на пакета thunderbird в Red Hat Enterprise Linux, CentOS и Fedora са негови актуализации. Тези актуализации въпреки, че запазват текущата мажорна версия на пакета, представляват по същество нов и прекомпилиран пакет. Строго препоръчително е те да бъдат инсталирани в системата навреме (колкото се може по-бързо след появата им в дистрибутивните пакетни хранилиша). Използването на неактуализиран пощенски клиент Mozilla Thunderbird е опасно!

Всички дистрибуции, които касае тази документация, имат свои механизми за актуализация на пакетите. Освен това съществуват и два вида актуализация - периодична и инцидентна. При периодичната актуалзация някакъв системен процес, на определен интервал от време, проверява пакетните хранилища на дистрибуцията и изтегля и инсталира всички актуализирани пакети. Инцидентната актуализация обикновено се извършва ръчно от оператора на системата, когато той прецени, че трябва да я извърши.

Съществуват различни мнения коя от посочените актуализации следва да се използва. Red Hat Enterprise Linux и CentOS са консервативни дистрибуции, за които се предлагат само и единствено актуализации на пакетите, които са необходими за гарантиране на работоспособността и сигурността. Периодичната актуализация на пакети в системи базирани на тези дистрибуции е честно добра практика. Пакетите с актуализираните версии са така изготвени, че да не предизвикват смущения и проблеми след инсталиране. Fedora обаче е платформа за разработки и внедрявания на нови пакети и функционалности и няма стабилността на Red Hat Enterprise Linux, съответно CentOS. Следователно не се препоръчва извършването на автоматична актуализация във Fedora!

Ако все пак се налага извършването на инцидентна актуализация, то ето примери как се извършва тя в система базирана на Red Hat Enterprise Linux 4:

# up2date -u thunderbird

и в системи базирани на Red Hat Enterprise Linux 5, CentOS 4 и 5, и Fedora:

# yum update thunderbird

Red Hat Enterprise Linux 4 и 5 използват Red Hat Network и извършват периодични актуализации, ако това е указано в профила на конкретната система там. Периодичното запитване от страна на системата към Red Hat Network за налични задачи за изпълнение, се извършва чрез услугата yum-updatesd след съответни настройки във файла /etc/yum/yum-updatesd.conf. Автоматичната пакетна актуализация на системата обаче, се извършва само, ако профила на системата е отключен за автоматични актуализации и това следва да се има предвид. По подразбиране всички профили на системи в Red Hat Network са отключени за автоматични актуализации. Ако профилът обаче е заключен, следва от списъка с актуализации, налични за профила, да се отбележи изрично актуализирането на thunderbird. По този начин, подадено като конкретна задача за актуализация, обновяването на системата ще се извърши като задача за rhnsd, независимо от флага за заключване в профила.

Един оптимален набор настройки във файла /etc/yum/yum-updatesd.conf, които могат да се използват от yum-updatesd, са следните:

# how often to check for new updates (in seconds)
run_interval = 3600
# how often to allow checking on request (in seconds)
updaterefresh = 600

# how to send notifications (valid: dbus, email, syslog)
emit_via = dbus
# should we listen via dbus to give out update information/check for
# new updates 
dbus_listener = yes

# automatically install updates
do_update = yes
# automatically download updates
do_download = no
# automatically download deps of updates
do_download_deps = no

В CentOS 4 и 5 автоматичните актуализации се извършват на базата само на съответните настройки на yum-updatesd в /etc/yum/yum-updatesd.conf.

 

 

2. Конфигурационни профили в Mozilla Thunderbird и използването им

Понякога изискването да се работи с различни X.509 сертификати асоциирани към един и същи електронен пощенски адрес на потребител, създава известни неудобства. За да се преодолеят те, се използват т.нар. "конфигуационни профили". Конфигурационните профили в Mozilla Thunderbird позволяват пощенският клиент да работи с набор от различни конфигурации (в това число и тези свързани със сигурната електронна поща). Изборът на профил се прави при стартирането на клиента.

Най-често използването на профили при решението за сигурна поща се налага, когато:

Ако са извършвани допълнителни настройки по профилите, се използва подразбиращия се такъв с име "default" и при стартирането си пощенския клиент чете настройките в него, без да въвежда потребителя в диалогово меню за избор на профил. За да се активира стартовото меню за избор на конфигурационен профил, се извършват следните действия.

Отваря се терминал и пощенския клиент се стартира от команден ред така:

$ thunderbird -P

След изпълнението на този команден ред се появява прозореца:

 

Меню за избор на профил с един наличен профил

 

Причината, поради която това меню не се появява всеки път, в който се стартира Mozilla Thunderbird е, че е маркирана опцията "Don't ask at startup". Нейното размаркиране позволява при всяко стартиране на пощенския клиент потребителя да избира работен профил, без да му се налага да използва терминал и команен ред, като в примера по-горе. По принцип малко потребители използват повече от един профил и за това въпросната опция е маркирана по подразбиране.

Създаването на нов профил става чрез натискане на бутона "Create Profile":

 

Прозорец с разяснения относно профилите

 

Натискането на бутона "Next" позволява да се направи избор на името на профила и директория, в която той ще бъде запазен:

 

Избор на име на профил и директория за съхранение на профила

 

За примера е създаден профил с име "secure", съхраняем в директория /home/users/vlk/.thunderbird/a3kpopph.secure. По подразбиране всички профили се създават в поддиректории на директорията ${HOME}/.thunderbird, но ако трябва да се избере друга директория за съхранение на профила, се използва бутона "Choose Folder". След натискане на бутона "Finish" става връщане в прозореца за избор на профил, а в списъка ще е избираем и последно създадения:

 

Нов профил в списъка с профили

 

Доколкото профила "secure" е новосъздаден, при натискане на бутона "Start Thunderbird" ще се влезе в диалогово меню за изграждане на конфигурацията му. След задаването на многопрофилност по горната схема, при всяко стартиране на Mozilla Thunderbird, първо ще бъде изведено менюто за избор на конфигурационен профил.

Ако трябва да се изключи менюто за избор на профил и да се работи по подразбиране с някой от профилите, трябва да се маркира "Don't ask at startup". По този начин при всяко следващо стартиране на Mozilla Thunderbird, ще се работи с последния избран конфигурационен профил.

 

 

3. Сертификатно хранилище на Mozilla Thunderbird и работа с него

 

3.1. Меню за управление на сертификатното хранилище и асоциираните към него модули и устройства

Всеки конфигурационен профил в Mozilla Thunderbird, притежава свое автономно сертификатно хранилище. За да се достъпи менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, следва да се стартира пощенския клиент и да се избере конфигурационен профил. От лентата с менюта в главния прозорец на клиента се избират последователно "Edit" » "Preferences":

 

Влизане в прозореца на менюто 'Preferences'

 

Правилното изпълнение на описаното по-горе действие води до отваряне на прозорец, в който се избира секция "Advanced", а в нея подсекция "Certificates":

 

Меню за управление на сертификатното хранилище

 

Именно подсекцията "Certificates" се явява главното меню за управление на сертификатното хранилище и асоциираните към него модули и устройства. В нея има четири бутона: "View Certificates", "Revocation Lists", "Verification" и "Security Devices". Всеки от тях управлява съответно подменю, както следва:

 

3.2. Файлова организация на сертификатното хранилище

Сертификатното хранилище на всеки от конфигурационните профили на Mozilla Thunderbird е съставен от три файла:

cert8.db
key3.db
secmod.db

Тези файлове не бива да бъдат редактирани директно и следва да бъдат предпазвани от копиране или изтриване. Структурата и предназначението на тези файлове са описани в документацията към проекта "Network Security Services (NSS)" на фондация Mozilla.

Ако все пак се налага редакция на хранилището без помощта на Mozilla Thunderbird, тя може да се извърши чрез инструментариума от пакета "NSS Security Tools".

 

3.3. Задаване или смяна на паролата за защита на частните ключове в сертификатното хранилище

Когато в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, заедно с даден X.509 сертификати, бъде въведен частния му ключ, последния трябва да бъде защитен с парола. Тази защита е необходима, за да не може частния ключ да бъде откопиран от злонамерен потребител или софтуер. Откопирането на частния ключ е равносилно на възможност за безпроблемно фалшифициране на електронния подпис на титуляра на X.509 сертификата. За да не се усложнява процедурата, всички частни ключове в сертификатното хранилище са защитени с една парола. Тя не е зададена по подразбиране, а следва да се зададе от потребителя на съответния конфигурационен профил. Ако не бъде въведената парола за защита на частните ключове, всяко поставяне на частен ключ в хранилището е рисковано, защото ключа ще е свободно читаем от всеки с достъп за прочит на файловете на сертификатното хранилище.

Извиква се менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства и в него се натиска бутона "Security Devices". Следва отваряне на прозореца за управление на криптографските модули и устройства:

 

Прозорец за управление на криптографските модули

 

От списъка с поддържани устройства (в лявата част на прозореца), се избира "Software Security Device":

 

Управление на 'Software Security Device'

 

За да се въведе първоначална парола или за да се смени стара такава, се натиска бутона "Change Password" в дясната лента с бутони. Следва появата на прозорец за въвеждане на старата парола и задаването на новата:

 

Бланка за смяна на паролата за защита на ключовете в сертификатното хранилище

 

Ако до момента е нямало въведена парола, т.е. такава трябва да се въведе за първи път, в полето "Current password" стои надписа "(not set)". При смяна на паролата, в "Current password" няма надпис "(not set)" и в това поле се въвежда старата парола. И в двата случая новата парола се въвежда двукратно (втория път за потвърждение) в полетата срещу "New password" и "New password (again)":

 

Задаване на парола за защита на частните ключове в хранилището за сертификати

 

За удобство и като показател за неразкриваемостта на паролата, е въведен измервател на здравината на паролата, който се намира под полетата за въвеждане на паролата ("Password quality meter"). Добре е нивото му да е над половината от възможното, в противен случай паролата за защита на сертификатното хранилище е уязвима.

Ако паролата за защита на частните ключове бъде забравена, това означава, че те няма да могат да бъдат използвани за подписване и декриптиране! Затова от ключово значение е тази парола да се помни или съхранява записана на безопасно място.

 

 

3.4. Заключване на сертификатното хранилище за достъп до частните ключове

Mozilla Thunderbird има следната особеност от гледна точка на достъпа до частните ключове в сертификатното хранилище. Ако е зададена парола за защита на частните ключове, то достъпа до тях в сертификатното хранилище е забранен по подразбиране (налична е защита с парола). В рамките на текущата сесия на пощенския клиент, при извършване на първата операция (подписване или декриптиране), изискваща достъп до частен ключ от сертификатното хранилище, се появява прозорец с текстово поле от вида:

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

в който потребителя трябва да въведе паролата за достъп. След като паролата бъде въведена вярно и сертификатното хранилище бъде отключено, тя се пази в паметта на компютъра докато не бъде затворен пощенския клиент. Това може да създаде опасност от разкриване на частните ключове. Съществува механизъм, чрез който може да бъде заключено хранилището за достъп до частните ключове след като преди това е било отключено, без при това да се налага да се спира пощенския клиент. За целта се отваря прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, натиска се бутона "Security Devices" и се отваря прозореца за управление на модулите и устройствата:

 

Прозорец за управление на защитата на сертификатното хранилище

 

От списъка с модули и устройства се избира "Software Security Device". След избора в дясната рамка са появява описанието на софтуерния сертификатен модул и успоредно с това в списъка на бутоните в дясната част на прозореца, се активира (свободен за натискане) бутона "Log Out":

 

Прозорец за управление на защитата на сертификатното хранилище: отключено сертификатно хранилище

 

След натискането на бутона "Log Out", паролата за защита на частните ключове в сертификатното хранилище се изтрива от паметта. Ако в последствие се налага достъп до ключовете, ще бъде изведен прозореца за въвеждане на паролата. Друг ефект от натискане на бутона "Log Out" е активирането на "Log In" (виж следващата секция).

 

 

3.5. Отключване на сертификатното хранилище за достъп до частните ключове

Макар и рядко, може да възникне следния проблем. Пощенският клиент Mozilla Thunderbird е стартиран, но все още не е извършена операция, изискваща достъп до частните ключове в сертификатното хранилище. Това означава, че не е била въвеждана паролата за отключване на достъпа до частните ключове, която се въвежда при първото заявяване на достъп до тях в рамките на текущата потребителска сесия. Как да се отключи хранилището за достъпа до частните ключове, без да се налага да се извършва някаква операция, при която те да бъдат използвани?

Съществува лесен и бърз начин за отключване на достъпа до частните ключове в хранилището, без да се налага да се извършва операция с тяхно участие. За целта се влиза в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства. В него се натиска бутона "Security Devices" и се отваря прозореца за управление на модулите и устройствата:

 

Прозорец за управление на защитата на сертификатното хранилище

 

От списъка с модули и устройства се избира "Software Security Device". След изпълнение на това действие, в дясната рамка са появява описанието на софтуерния сертификатен модул и успоредно с това в списъка на бутоните в дясната част на прозореца, се активира (свободен за натискане) бутона "Log In".

 

Меню за управление на защитата на сертификатното хранилище: софтуерен сертификатен модул

 

Натискането на този бутон води до отваряне на прозореца за въвеждането на паролата за защита на частните ключове в сертификатното хранилище:

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

След успешното й въвеждане, достъпа до частните ключове е разрешен, а паролата се съхранява в паметта, докато не бъде спрян пощенския клиент Mozilla Thunderbird или не бъде заключено сертификатното хранилище.

 

 

3.6. Добавяне на потребителски X.509 сертификат и прилежащия му частен ключ в сертификатното хранилище, чрез PKCS#12 форматен файл

За да може да бъде извършвано електронно подписване и декриптиране на получена криптирана кореспонденция, е нужно използването на частни ключове (електронното подписване е процес на криптиране на съдържанието с частния ключ и декриптиране с публичния, а криптирането на информацията става с публичния, а декриптирането й с частния ключ). Когато даден потребител на сигурна пощенска услуга трябва да подписва електронно писма или да декриптира писмата изпратени до него, той следва да има инсталиран в сертификатното хранилище персонален потребителски X.509 сертификат и прилежащ частен ключ.

Добавянето на потребителски X.509 сертификат и прилежащия му частен ключ в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, става чрез прочита им от PKCS#12 форматиран файлов контейнер. Нужно е да се отбележи, че описанието по-долу касае единствено и само добавяне на сертификата и прилежащия му ключ към файловата структура на сертификатното хранилище. Примерът не е преносим за случая на използване на "smart" карти, защото в този случай и сертификата и ключа се намират в картата, а не в сертификатното хранилище на Mozilla Thunderbird!

Строго препоръчително е преди да се добави сертификат с прилежащия му ключ към сертификатното хранилище на съответния профил, да се зададе парола за защита на ключа.

За да се извърши добавянето, се стартира пощенския клиент и се избира съответния конфигурационен профил. След това се влиза в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства и се натиска бутона "View Certificates" и в новия прозорец се избира секция "Your Certificates". Ако се извършва първото подобно добавяне на потребителски сертификат и ключа му за дадения профил, списъка със сертификати ще бъде празен:

 

Прозорец със списък на потребителски X.509 сертификати, чиито частни ключове също са инсталирани в сертификатното хранилище

 

а в противен случай ще се вижда списъка с имената на добавените сертификати. Файлът с PKCS#12 контейнера се избира с използването на файловия мениджър, който се отваря след натискане на бутона "Import":

 

Избор на файла съдържащ PKCS#12 контейнера

 

След като файла с контейнера бъде избран и се натисне бутона "Open", ще се наложи въвеждане на паролата за защита на частните ключове в сертификатното хранилище (ако тя не е била вече въведена в текущата сесия на пощенския клиент):

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

а след правилното й въвеждане, ще бъде изискано и въвеждането на тази за защита на частния ключ във файловата PKCS#12 структура:

 

Прозорец за въвеждане на паролата за защита на частните ключове в PKCS#12 контейнера

 

и ако то бъде успешно, ще се изведе съобщение за добавяне на потребителския X.509 сертификат и прилежащия му частен ключ към сертификатното хранилище:

 

Съобщение за успешното добавяне на сертификата в хранилището на профила

 

Най-накрая информацията за въведения сертификат ще се появи в секцията "Your Certificates":

 

Изглед на добавения потребителски X.509 сертификат в списъка със сертификати

 

 

3.7. Добавяне на удостоверителски X.509 сертификат в сертификатното хранилище

Удостоверителските сертификати имат за цел да покажат дали на даден потребителски сертификат е гласувано доверие от страна на издателя му, за което той претендира. Доверието гласувано на даден потребителски сертификат, се уставновява само чрез копие от сертификата на удостоверителя му. Удостоверителските сертификати се добавят в сертификатното хранилище по два начина: чрез файл, който ги съдържа или чрез сертификатната верига на добавен потребителски X.509 сертификат от PKCS#12 контейнер. Последното означава, че даден удостоверителски сертификат може да бъде добавен в сертификатното хранилище при прибавянето на потребителски X.509 сертификат и прилежащия му частен ключ. Това е възможно, защото обикновено PKCS#12 контейнерите на потребителските сертификати съдържат цялата удостоверителна верига - от удостоверителския сертификат до потребителския.

Локалното сертификатно хранилище съхранява два типа сертификати: вградени и добавени. Вградените удостоверителски сертификати са вградени в изходния код на библиотеката /usr/lib/libnssckbi.so, която е част от RPM пакета nss. Това е набор от най-използваните в света удостоверителски сертификати. Добавените удостоверителски сертификати са тези, които са прибавени като съдържание в сертификатното файлово хранилище на конфигурационния профил. Ако се използва "smart" карта, е възможно в хранилището с удостоверителски сертификати да са достъпни и такива, намиращи се в самата карта, но те не могат да се разглеждат нито като вградени (не са част от системна библиотека), нито добавени (не са част от съдържанието във файловата структура на сертификатното хранилище), а като част от външно хранилище с временен достъп (до изваждането на картата от четеца).

Прибавянето на удостоверителски сертификат от файл става само, ако файла има съответния формат (PKCS#11). Обикновено такъв файл има разширение *.crt, *.pem или *.der и се изтегля от файловия сървър на съответния доставчик на удостоверителни услуги, след което се запазва върху локалната файлова система.

За да се инсталира удостоверителски сертификат от съдържащия го файл, се влиза в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, натиска се бутона "View Certificates" и в новоотворения прозорец се избира секция "Authorities":

 

Общ изглед на хранилището на удостоверителски сертификати

 

След това се натиска бутона "Import" и чрез файловия мениджър се избира файла съдържащ сертификата на удостоверителя, който трябва да се добави:

 

Избор на файл съдържащ удостоверителския сертификат

 

Натискането на бутона "Open" завършва добавянето на удостоверителския сертификат в сертификатното хранилище, а най-накрая се извежда и меню за гласуване на доверие на сертификата:

 

Меню за задаване на ниво на доверие на удостоверителския сертификат

 

Всеки удостоверителски сертификат, който бива въведен в сертификатното хранилище, трябва да има гласувано доверие по един от трите възможни критерия (нива), показани по-горе, в противен случай той е неизползваем. За проверката на гласувано на потребителски сертифкати доверие, е достатъчно да се избере "This certificate can identify mail users", но ако ще се установява гласувано доверие на сървърски сертификат, то трябва да се избере и "This certificate can identify web sites". Най-често, за да няма проблеми, се избират и двете споменати до тук нива:

 

Указано ниво на доверие на удостоверителски сертификат

 

След натискане на бутона "OK", сертификатът може да бъде намерен по име в списъка с удостоверителски сертификати:

 

Добавен удостоверителски сертификат в сертификатното хранилище

 

В списъка се вижда ясно, че този добавен сертификат е част от сертификатното хранилище на профила - "Software Security Device", за разлика от вградените удостоверителски сертификати, за които е указана принаджленост към библиотеката на пакета nss - "Builtin Object Token" (виж втората колона в списъка).

Ако удостоверителски сертификат е попаднал в сертификатното хранилище чрез PKCS#12 структурата на въведен потребителски X.509 сертификат, той няма да има никакво ниво на доверие и следователно е неизползваем. За да може да се използва, трябва да му бъде гласувано ниво на доверие, по схемата описана по-горе. За да може тя да бъде приложена, сертификата се избира от списъка по име и след това се натиска бутона "Edit".

 

 

3.8. Добавяне на кореспондентски X.509 сертификат в сертификатното хранилище

За да може да бъде проверена валидността на електронния подпис върху получено писмо или да бъде криптирано съдържание за изпращане до даден кореспондент, следва в сертификатното хранилище да е налично копие от неговия X.509 сертификат. За да може да бъде добавен кореспондентски X.509 сертификат, той трябва да бъде валиден. Това означава, че не бива да е с изтекъл срок на валидност, нито да е отменен, а освен това в сертификатното хранилище трябва да е наличен удостоверителския му сертификат. Съществуват два начина за добавяне на кореспондентски X.509 сертификат в сертификатното хранилище на даден конфигурационен профил в Mozilla Thunderbird.

Първият начин е чрез автоматично поставяне, което се реализира в случаите, в които кореспондента изпрати електронно подписано писмо и то бъде прочетено от пощенския клиент в съответния конфигурационен профил. Съгласно модела за сигурна поща "PEM", всяко електронно подписано писмо следва да носи в себе си освен електронния подпис и копие от X.509 сертификата на изпращача, а така също и сертификатната верига за проверка на валидността на сертификата.

Вторият начин е, X.509 сертификата на даден кореспондент да се поставя ръчно в сертификатното хранилище на конфигурационния профил, чрез прочит на файл, който го съдържа. Този файл следва да има разширение *.crt или *.pem. Съдържанието му се добавя към сертификатното хранилище в специална секция "Other People's", до която се стига след като се отвори прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, и натискане на бутона "View Certificates":

 

Хранилище за сертификати на кореспонденти

 

Ако в тази секция има вече добавени сертификати на кореспонденти, те ще бъдат изведени като списък. Следва натискането на бутона "Import" и избиране на файла върху локалната файлова система, който съдържа сертификата на кореспондента:

 

Избор на файл съдържащ кореспондентски сертификат

 

Ако файлът бъде прочетен и наистина съдържа кореспондентски X.509 сертификат, съдържанието му ще бъде добавено в сертификатното хранилище на съответния конфигурационен профил:

 

Кореспондентски сертификат в сертификатното хранилище

 

В случай, че кореспондетският сертификат не може да бъде валидиран по някаква причина, той няма да бъде добавен успешно в сертификатното хранилище и ще бъде изведено съобщението:

 

Съобщение указващо на липсата на валидност на добавяния кореспондентски сертификат

 

 

3.9. Изтриване на потребителски X.509 сертификат и прилежащия му частен ключ от сертификатното хранилище

Изтриването на един потребителски X.509 сертификат и прилежащия му частен ключ от сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, се налага в следните случаи:

Процесът на изтриване започва с влизане в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, и продължава с натискане на бутона "View Certificates", а в отворения прозорец се избира секцията "Your Certificates":

 

Изглед на добавения потребителски X.509 сертификат в списъка със сертификати

 

След това се маркира (по име) чрез еднократно натискане с десния бутон на мишката сертификата, който ще бъде изтрит:

 

Маркиране на сертификат за изтриване

 

и се натиска бутона "Delete". Това довежда до диалогово меню за потвърждаване на изтриването:

 

Меню за потвърждаване на изтриването на сертификата

 

Ако в рамките на текущата сесия на пощенския клиент, не е била въведена паролата за защита на частните ключове в сертификатното хранилище, сега тя ще бъде изискана:

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

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

Нужно е да се отбележи, че изтриването на потребителския X.509 сертиифкат и прилежащия към него частен ключ, не води до изтриване на удостоверителските сертификати, които евентуално са били добавени в сертификатното хранилище при въвеждането на PKCS#12 структурата на потребителския сертификат.

 

 

3.10. Изтриване на удостоверителски сертификат от сертификатното хранилище

Изтриването на удостоверителски X.509 сертификат от сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, се налага сравнително рядко, най-често поради една от следните причини:

За да се изтрие избрания удостоверителски сертификат, се влиза в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, натиска се бутона "View Certificates" и в отворения прозорец се избира секцията "Authorities":

 

Общ изглед на хранилището на удостоверителски сертификати

 

В нея се намира и маркира сертификата, който ще бъде изтрит:

 

Добавен удостоверителски сертификат в сертификатното хранилище

 

и се натиска бутона "Delete". След натискането му ще се изведе диалогово меню:

 

Диалогово меню за потвърждаване на изтриването на удостоверителския сертификат

 

в което трябва чрез натискане на бутона "OK" да бъде потвърдено изтриването на сертификата.

Тук е мястото да се опише една особеност. Няма никакви пречки от сертификатното хранилище да бъде изтрит вграден удостоверителски сертификат. Това не означава, че ще бъде модифицирана системната библиотека /usr/lib/libnssckbi.so от пакета nss. При изтриването на вграден сертификат, този сертификат всъщност не се изтрива, а се добавя в сертификатното хранилище на профила, като му се задават специални флагове така, че да не бъде читаем от пощенския клиент. За съжаление "връщането" на изтрития по този начин сертификат в списъка с вградени удостоверителски сертификати, няма как да се извърши само с инструментариума на Mozilla Thunderbird. За да се "върне" той там е нужно използването на инструмента certutil, чрез който този сертификат да бъде изтрит от хранилището на съответния профил, където е бил поставен при извършеното от Mozilla Thunderbird изтриване.

 

 

3.11. Изтриване на кореспондентски X.509 сертификат от сертификатното хранилище

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

За да се изтрие кореспондентски X.509 сертификат от сертификатното хранилище на текущия конфигурационен профил на Mozilla Thunderbird, трябва да се отвори прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, в него да се натисне "View Certificates" и в новоотворения прозорец да се избере секцията "Other People's":

 

Кореспондентски сертификат в сертификатното хранилище

 

Сертификатът, който трябва да бъде изтрит, се маркира в списъка с кореспондентски сертификати (еднократно натискане с десния бутон на мишката върху него):

 

Маркиран кореспондентски сертификат

 

и след това се натиска бутона "Delete", при което ще се появи диалогово меню за потвърждение на операцията по изтриването:

 

Диалогово меню за изтриване на кореспондентски сертификат

 

След натискане на бутона "OK", сертификатът ще бъде премахнат от сертификатното хранилище на текущия конфигурационен профил.

 

 

3.12. Създаване на PKCS#12 копие от въведените в сертификатното хранилище персонални X.509 сертификати и прилежащите им частни ключове

В някои случаи се налага създаване на копие на всички въведени в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, потребителски X.509 сертификати и прилежащите им частни ключове. Най-често това се прави, ако се налага да се мигрира профила или да се направи нов профил съдържащ въпросните сертификати и ключове. Създаденото ново копие се запазва във файл с PKCS#12 структура - същата, с която става внасянето на сертификатите и ключовете в сертификатното хранилище.

За да се направи копие на даден потребителски X.509 сертификат и прилежащия му частен ключ, се влиза в прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, натиска се бутона "View Certificates" и в отворения прозорец се избира секцията "Your Certificates". Там се маркира сертификата, който заедно с прилежащия му частен ключ, ще бъдат експортирани в PKCS#12 формат:

 

Маркиране на потребителски X.509 сертификат

 

След това, чрез натискане на бутона "Import", следва да се избере файл върху локалната файлова система, в който да бъде запазена експортираната PKCS#12 структурата:

 

Указване на име на файл за запазване на PKCS#12 структурата и път до него

 

Ако в рамките на текущата сесия не е била въвеждана паролата за защита на частните ключове в сертификатното хранилище, ще се появи прозорец за въвеждането й (в противен случай няма как частните ключове да се извлекат от хранилището и да се включат във формираната PKCS#12 структура):

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

След като паролата бъде въведена коректно, ще се отвори прозорец за задаване на парола за защита на частните ключове в новосъздадената PKCS#12 структура:

 

Въвеждане на парола за защита на PKCS#12 структурата

 

Паролата следва да се въведе двукратно, като бъде подбрана така, че индикатора за здравината й ("Password quality meter"), да се запълни над половината. След правилното й въвеждане следва записване на PKCS#12 структурата в зададения за целта файл. При успешен запис, ще бъде изведено съобщението:

 

Съобщение за успешно копиране на сертификата и прилежащия му частен ключ

 

Ако трябва да се направи копие на всички въведени сертификати и ключове, на първата стъпка в горното описание, следва вместо бутона "Backup", да се натисне "Backup All".

Важна особеност на така изградената PKCS#12 структура е, че в нея освен потребителския X.509 сертификат и прилежащия частен ключ, се съдържа и удостоверителския му сертификат (или удостоверителската верига, когато има такава).

 

 

4. Електронно подписване и криптиране на съдържанието на писма в Mozilla Thunderbird

 

4.1. Общи принципи на електронното подписване и криптирането на съдържанието на електронната поща

Целта на поставянето на електронен подпис върху писмо, е да удостовери самоличността на подателя (съставителя) пред получателя или пред други заинтересовани лица и организации, а също така и да даде възможност да се провери дали изпратеното съдържание не е променяно (злонамерено или не) при преноса му. За целта получателят или заинтересованите лица и организации, следва да разполагат с копие от X.509 сертификата на изпращача извършил подписването, с който да проверят валидността на електронния подпис върху съдържанието на писмото. Криптиране на съдържанието се извършва тогава, когато следва да се предотврати нежелания му прочит от неоторизирани за целта лица и организации. Криптирането защитава съдържанието от неоторизиран прочит, както при преноса му през Интернет, така и при последващото му съхранение в пощенската кутия на получателя. Само последния, с използване на частния си ключ, може да декриптира съдържанието на писмото.

Доколкото всеки, притежаващ копие от X.509 сертификата на получателя, може да му изпрати криптирано писмо, то криптирането не удостоверява по никакъв начин подателя (особеност на криптографската система с публичен ключ). Ако подателят следва да се удостовери пред получателя като изпращач на съдържанието, той трябва първо да извърши електронен подпис върху него и чак след това да го криптира и изпрати. По този начин само получателя може да удостовери самоличността на подателя, защото в общия случай само първият може да декриптира електронно подписаното съдържание и да провери валидността на подписа. Разбира се, за проверката на електронния подпис ще се изисква и копие от X.509 сертификата на подателя.

От гледна точка на електронното подписване и криптирането, всяко електронно писмо може да се разглежда като съставено от две части: (i) неподписваема и некриптируема и (ii) подписваема и криптируема:

 

Илюстрация на отделните части на писмото, относно подписването и криптирането

 

Оцветяване на подписваемата и криптируема част на писмото - подписваема и криптируема част на писмото

Оцветяване на неподписваемата и некриптируемата част на писмото - неподписваема и некриптируема част на писмото

 

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

Неподписваемата и некриптируема част на писмото обхваща неговата заглавна част и полета в нея. Тя включва и полето със заглавието ("Subject"). Това означава, че ако се изпраща криптирано съдържание на някого, то следва в полето със заглавието да няма информация, която да е важна или да свързва по някакъв начин криптираното съдържание. Например, много често се допуска фатална потребителска грешка, която се състои в това, че в полето на заглавието се поставя информация, която описва съдържанието, например "Договор за продажба" или "Банков трансфер по сметка номер ...".

Нужно е да се отбележи, че криптирането на едно писмо не скрива получателя му. Също така, трябва да се има предвид, че електронното подписване не удостоверява датата и часа на съставяне и изпращане на писмото. Ако следва да се удостовери датата и часа на съставяне на писмото, следва да се използва удостоверение за време ("Time Stamping"). Издаването на удостоверение за време на дадено съдържание няма да бъде описвано тук, доколкото не касае работата с Mozilla Thunderbird.

 

 

4.2. Асоцииране на клиентски X.509 сертификат към IMAP профил в Mozilla Thunderbird

За да може чрез въведен в сертификатното хранилище на съответния конфигурационен профил X.509 сертификат и прилежащия му частен ключ, да се извършва електронно подписване на изходящите електронни писма, съответно криптирането им, следва да се направи асоциация към изграден в пощенския клиент IMAP профил.

Асоциацията се извършва в настройките на IMAP профила, а сертификата се избира по име от съответно меню. Най-важното, което трябва да се знае в случая е, че един сертификат може да бъде асоцииран към даден пощенски профил само, ако e-mail адреса в "Subject" полето на сертификата, съответства на адреса на IMAP кутията (например, ако IMAP профила обслужва кутията user@example.com, в "Subject" полето на сертификата трябва да се съдържа "emailAddress=user@example.com"). Това е основна постановка в стандарта за сигурна поща PEM и пощенския клиент Mozilla Thunderbird стриктно я спазва.

В описанието по настройките по-долу ще се предполага, че потребителят вече е изградил съответния IMAP профил. За да се стартира процеса на асоциация на сертификат към IMAP профила, се влиза в съдържащия го конфигурационен профил, а оттам в менюто за управление на профилите за достъп до услугите, чрез последователно избиране на "Edit" » "Account Settings":

 

Избор на менюто за настройки на imap/stmp профилите

 

В отворения прозорец за управление на профилите на използваните услуги (в това число и IMAP профилите) се избира IMAP профил за редакция:

 

Прозорец за управление на профилите на услуги

 

и в него се отваря секцията "Security":

 

Секция 'Security' в IMAP профила

 

В тази секция има две подсекции: "Digital Signing" и "Encryption". С натискането на бутона "Select" във всяка една от тях, се избира по име X.509 сертификат от изведен списък, в който се включват само тези сертификати, които могат да бъдат избрани за този IMAP профил:

 

Списък за избор на X.509 сертификат по име

 

След извършване на избора и натискане на бутона "OK", ще бъде изведено допълнително меню, в което потребителят трябва да укаже дали избрания X.509 сертификат ще се използва за криптиране/декриптиране на съдържание или не:

 

Меню за задаване на избрания за подписване X.509 сертификат и за криптиране

 

Обикновено сертификатът се използва и за криптиране така, че най-честия избор е "OK".

 

 

4.3. Електронно подписване на съдържанието на писмо в Mozilla Thunderbird

За да се извърши електронно подписване на изпращано писмо, следва преди това в хранилището на сертификати на съответния профил на Mozilla Thunerbird, да са налични валиден X.509 сертификат на изпращача и прилежащия му частен ключ. Също така, сертификата на изпращача следва да е асоцииран към текущия IMAP профил на пощенския клиент.

От лентата с менюта на главния прозорец на Mozilla Thunderbird, чрез последователния избор "File" » "New" » "Message", се отваря бланка за ново писмо:

 

Отваряне на бланка за ново писмо

 

След като в нея се попълнят адреса на получателя, полето със заглавието и се внесе съдържание в тялото на писмото (и евентуално се прикачат файлове)

 

Попълнена бланка за писмо преди подписване на съдържанието му

 

може да се пристъпи към електронно подписване на съдържанието (прикачените файлове, ако ги има, са част от съдържанието). Електронното подписване е действие, което се извършва при изпращането на писмото, а не преди това и се задава от лената с менютата, в която последователно се избира "Options" » "Security" » "Digitally Sign This Message":

 

Указание за електронно подписване на писмото при изпращане

 

След извършването на горните операции, съдържанието на писмото е готово за изпращане, ако разбира се е приключило въвеждането или редактирането на текста в него. Индикация за заявено подписване при изпращане, е иконата в долния десен ъгъл на прозореца с бланката, изобразяваща запечатан с печат плик:

 

Бланка за писмо с указано подписване при изпращане

 

По-подробна информация относно това дали писмото ще бъде електронно подписано при изпращане, може да бъде изведена, ако от лентата с менюта в бланката се изберат последователно "View" и "Message Security Info":

 

Меню за извеждане на информация относно подписването на писмото

 

Изведената информация изглежда като тази:

 

Информация за извършването на подписване при изпращането на писмото

 

Както се вижда от информацията в примера, при изпращането на писмото няма да се извърши криптиране (Encrypted: No), но ще бъде извършено подписване (Digitally signed: Yes). За излизане от прозореца с информация за подписването на писмото, се натиска бутона "OK".

Когато се натисне бутона "Send", се инициира процес на подписване на съдържанието на писмото, спрямо указанията по-горе и ако тази операция е успешна, следва изпращането му. За да може електронното подписване на съдържанието да бъде извършено, се изисква достъп до частния ключ на изпращача. Този достъп се предоставя след въвеждането на паролата за защита на частните ключове в сертификатното хранилище на текущия профил на Mozilla Thunderbird:

 

Прозорец за въвеждане на паролата за достъп до частните ключове

 

Съществува възможност всички изпращани писма от даден IMAP профил, да са електронно подписани. По принцип рядко има необходимост от това, но ако все пак такава възникне, следва да се направи съответната настройка. За целта се отваря менюто за асоцииране на сертификат към IMAP профил. При асоцииран с профила сертификат, в подсекция "Digital Sigining" се маркира опцията "Digitally sign messages (by default)":

 

Настройка за електронно подписване на всички изходящи писма

 

След натискане на бутона "OK" всички писма, изпратени през профила с тези настройки, с изпращач пощенския адрес на IMAP профила, ще бъдат подписвани електронно по подразбиране.

 

 

4.4. Електронно подписване и последващо криптиране на съдържанието на писмо в Mozilla Thunderbird

Строго препоръчително от гледна точка на сигурността е, всяко писмо, което ще бъде криптирано при изпращането му, да бъде предварително електронно подписано.

За да се извърши електронно подписване и последващо криптиране на съдържанието на писмо, трябва в хранилището на сертификати на съответния конфигурационен профил на Mozilla Thunerbird, да са налични (i) валиден X.509 сертификат на получателя, (ii) валиден X.509 сертификат на изпращача и прилежащия му частен ключ. Също така, сертификатът на изпращача следва да е асоцииран към текущия IMAP профил на пощенския клиент. Нужно е да се отбележи, че ако едно писмо ще се криптира при изпращането си, но в списъка с получатели ще има повече от един пощенски адрес, то в хранилището за сертификати на конфигурационния профил на Mozilla Thunderbird, трябва да се налични копия от X.509 сертификатите на всички един от получателите.

Криптирането на съдържанието на изпращано писмо се извършва в следната последователност. От лентата с менюта на главния прозорец на Mozilla Thunderbird, чрез последователния избор "File" » "New" » "Message", се отваря бланка за ново писмо:

 

Отваряне на бланка за ново писмо

 

След като в нея се попълнят адреса на получателя, полето със заглавието и се внесе съдържание в тялото на писмото (и евентуално се прикачат файлове)

 

Попълнена бланка за писмо преди подписването и криптирането й

 

се пристъпва към електронно подписване и криптиране на съдържанието (прикачените файлове, ако ги има, са част от съдържанието). И електронното подписване, и криптирането, са действия, които се извършват при изпращането на писмото (натискане на бутона "Send"), а не преди това. Електронното подписване на съдържанието на писмото при изпращането му се заявява, като от менютата последователно се избира "Options" » "Security" » "Digitally Sign This Message":

 

Указание за електронно подписване на писмото при изпращане

 

докато криптирането на съдържанието се заявява чрез избора "Options" » "Security" » "Encrypt This Message":

 

Указание за криптиране на писмото при изпращане

 

След горните операции, съдържанието на писмото е готово за изпращане, ако разбира се е приключило въвеждането или редактирането на съдържанието му. Индикация за заявено криптиране и подписване при изпращане, са двете икони в долния десен ъгъл на прозореца с бланката, съответно запечатан с печат плик и катинар:

 

Бланка за писмо с указано криптиране и подписване при изпращане

 

По-подробна информация относно това дали писмото ще бъде подписано и криптирано при изпращане, може да бъде изведена, ако от лентата с менюта в бланката се изберат последователно "View" и "Message Security Info":

 

Меню за извеждане на информация относно криптирането и подписването на писмото

 

Изведената информация изглежда като тази:

 

Информация за извършването на криптиране и подписване при изпращането на писмото

 

Както се вижда от информацията в примера, при изпращането на писмото ще се извърши електронно подписване (Digitally signed: Yes) и последващо криптиране (Encrypted: Yes). Сертификатът, чрез който ще се извърши криптирането, е валиден към момента (Status: Valid). За излизане от прозореца с информация за криптирането и подписването на писмото, се натиска бутона "OK".

Когато се натисне бутона "Send", се инициира процес на подписване и криптиране на съдържанието на писмото, спрямо указанията по-горе и ако тази операция е успешна, следва изпращането му. За да може да бъде извършено електронното подписване на съдържанието, се изисква достъп до частния ключ на изпращача. Този достъп се предоставя след въвеждането на паролата за защита на частните ключове в сертификатното хранилище на текущия профил на Mozilla Thunderbird:

 

Прозорец за въвеждане на паролата за достъп до частните ключове

 

Нужно е да се спомене следната особеност. Когато се криптира съдържанието на писмото при изпращане, освен за получателя, то винаги се криптира и за получателя, освен ако последното не е изрично забранено при настройките на асоциация на сертификат за криптиране към IMAP профила. Идеята на криптирането на съдържанието и със сертификата на изпращача е, писмото да може да се пази криптирано в директорията с копия на изпратените писма (обикновено това е директорията "Sent") и при нужда да може да бъде прочетено от изпращача му.

 

В Mozilla Thunderbird съществува и възможност за криптиране на всички изпращани писма по подразбиране, без изрично потребителя да го указва. За да се активира криптиране по подразбиране, следва в менюто за асоцииране на сертификат към IMAP профила да се избере опцията "Defaul encryption setting when sending messages : Required" в подсекция "Encryption":

 

Настройка за криптиране на всички изпращани писма

 

След натискане на бутона "OK" всички писма, изпратени през профила с тези настройки, с изпращач пощенския адрес на IMAP профила, ще бъдат криптирани по подразбиране. Трябва да се има предвид следното. Ако бъде избрано криптиране по подразбиране на всички изпращани писма от името на съответния пощенски адрес, асоцииран към IMAP профила, всяко изпращане на писмо до получател, чиито кореспондентски сертификат не е наличен в сертификатното хранилище, ще генерира съобщение за грешка (а писмото няма да бъде изпратено).

 

 

4.5. Проверка на електронен подпис и декриптиране на съдържанието на писмо в Mozilla Thunderbird

Проверката на електронния подпис върху получени писма или копия на изпратени такива, се извършва автоматично, при условие, че в сертификатното хранилище на съответния използван конфигурационен профил на Mozilla Thunderbird, има добавени копия на X.509 сертификатите на изпращачите. За да се декриптира съдържанието на получено или изпратено електронно писмо, следва в сертификатното хранилище да се намира частния ключ на получателя. Освен това следва да бъде въведена вярно паролата за защита му, когато това бъде изискано от пощенския клиент.

При успешна проверка на електронния подпис, извършен върху съдържанието на писмото, в лентата с информация за изпращача и получателя, ще се появи следната икона:

 

Икона указваща успешна проверка на електронния подпис

 

Ако съдържанието на писмото бъде успешно декриптирано, в лентата с менютата ще се появи икона, представляваща заключен катинар:

 

Икона указваща на успешно декриптиране

 

В случай, че съдържанието на едно писмо не може да бъде декриптирано, няма как да се извърши проверка на електронния подпис върху него. Причината е, че достъп до съдържанието може да се получи само след успешно декриптиране. Целият изглед на прозорец, съдържащ успешно декриптирано писмо с валиден електронен подпис върху съдържанието му, изглежда по следния начин:

 

Общ изглед на получено подписано и криптирано писмо

 

Ако трябва да се извлече конкретна информация за извършителя на електронния подпис и получателя на криптираното съдържание, това може да стане от лентата с менюта в прозореца, визуализиращ писмото:

 

Меню за извличане на информация относно подписването и криптирането на писмото

 

а самата информация се извежда в нов прозорец:

 

Информация за подписването и криптирането на писмото

 

Чрез натискането на бутона "View Certificate", може да бъде получена информация за сертификата на извършителя на електронен подпис върху съдържанието на писмото.

 

 

5. Проверка на текущата валидност на използваните X.509 сертификати в Mozilla Thunderbird

 

5.1. Механизми за проверка на текущата валидност на X.509 сертификатите

Валидността на всеки X.509 сертификат, е заложена като информация в мета информацията му. Тя се указва като начално и крайно време на валидност от издалия сертификата удостоверител. В периода между тези две времена, сертификатът следва да се счита за валиден. Така зададената валидност обаче има условен характер. Причината за това е, че е възможно настъпване на някакво форсмажорно обстоятелство, което да компрометира сертификата преди изтичане на срока му на валидност. В такъв случай, удостоверителят трябва да разполага с механизми, чрез които да обяви пред заинтересованите от това страни, снемане на доверие от компрометирания сертификат. Нужно е да се отбележи, че подобно снемане на доверието може да стане и за някакъв период от време. Казаното по-горе автоматично дефинира текуща или моментна валидност на сертификата, която следва да е проверяема автоматично от софтуера, използващ X.509 сертификати.

Съществуват два механизма за обявяването на един сертификат за невалиден, преди изтичане на срока му на валидност: списъци с отменени сертификати (CRL) и услуга, базирана на протокола за моментна проверка на статуса на валидност на сертификата (OCSP). И двата механизма се поддържат в Mozilla Thunderbird и използването им ще бъде описано по-долу.

 

 

5.2. Използване на списъци с отменени сертификати (CRL)

 

5.2.1. Обща информация за списъците с отменени сертификати (CRL)

Mozilla Thunderbird може да проверява моментната валидност на използваните X.509 сертификати, на основата на инсталирани локално списъци с отменени сертификати (CRL), чието съдържание би следвало да актуализира регулярно от всеки удостоверител, а когато се наложи и инцидентно (между две планирани актуализации). Съгласно идеологията на CRL, всеки удостоверител може да отменя валидността само на издадени от него сертификати. Списъкът с отменени сертификати представлява блок от данни, в който се съдържа информация за удостоверителя, списък на серийните номера на сертфикатите, от които е свалено доверие и допълнителна мета информация (напр. повод да снемане на доверие). Цялият този информационен блок, се подписва електронно с удостоверителския частен ключ и се превръща в готово за публикуване CRL съдържание. Най-често то се публикува под формата на файл, който е достъпен за свободно изтегляне в Интернет (в общия случай от интернет базиран файлов сървър на удостоверителя). По този начин всеки заинтересован от проверката на валидността на даден X.509 сертификат, би могъл регулярно да изтегля публикуваното от удостоверителя му CRL съдържание и да го използва ръчно или в някакъв софтуер. За да може обаче изтегляемият регулярно списък с отменени сертификати, да бъде използваем, трябва електронния подпис върху него да бъде валиден. Проверката за валидност на електронния подпис обикновено се извършва автоматично при всяко използване на CRL файла, с помощта на копие от удостоверителския сертификат, което задължително трябва да е налично в сертификатното хранилище на използвания софтуер. Ако валидността на електронния подпис върху CRL съдържанието не може да бъде установена, то е неизползваемо за определяне на моментната валидност на X.509 сертификати.

Всеки списък с отменени сертификати, има указани в себе си време на издаване и време на следващо издаване (последното е стойност на параметъра "Next Update" в мета информацията). Публикуваното в списъка време на следващото издаване, се чете от софтуера и на негова основа се планира следващата актуализация на CRL съдържанието. Възможно е обаче софтуера да бъде настроен така, че да не се съобразява с тази информация и да има зададен от потребителя период на актуализиране. Причината за подобно несъобразяване с времето на следващо издаване може да бъде твърде обективна. Ако удостоверителят е указал в издаден от него CRL време за следващо издаване след месец, е ясно и за неспециалист, че е твърде вероятно през този период от време, да се наложи отмяната на един и повече сертификати. Доколкото удостоверителят ще бъде принуден да актуализира своето CRL съдържание, но клиентите са планирали актуализация след месец (на основа на информацията в стар CRL), то те няма да оперират с актуална CRL информация. Това създава "дупка" и опасност за сигурността на комуникацията на клиентите и достоверността на електронно подписвания им документооборот.

В Mozilla Thunderbird, добавените списъци с отменени сертификати, стават част от сертификатното хранилище на съответния конфигурационен профил, а планирането на актуализацията им се извършва на база на потребителски настройки, както е показано по-долу.

 

 

5.2.2. Намиране на адреса на файл съдържащ CRL

Всеки удостоверител, следващ добра практика в предлаганите от него удостоверителни услуги, публикува в Интернет адреса, от който може да бъде изтеглен свободно актуалния към момента списък с отменени сертификати (CRL). На основата на този списък (след изтеглянето му), всеки заинтересован може да провери моментната валидност на издаден от удостоверителя сертификат. Най-често публикуването на адреса става на интернет страницата на удостоверителя. Успоредно с това, би следвало този адрес да се намира и в мета информацията на всеки издаден от конкретния удостоверител X.509 сертификат. По този начин сертификатът носи в себе си информция за адреса на списък с отменени сертификати, спрямо който трябва да бъде проверявана моментната му валидност. Ако удостоверителят оперира с повече от един удостоверителски сертификат или с верига от удостоверителски сертификати, в най-честия случай той трябва да поддържа CRL за всеки един тях.

Намирането на адреса на файла с CRL, публикуван на страницата на удостоверителя, е тривиална задача доколкото в повечето случаи той е ясно обозначен и лесно копируем. Ето пример, как от прозореца на браузър може да се копира в паметта адреса към файла, съдържащ CRL списъка за удостоверителския сертификат на удостоверителя "Example Personal CA":

 

Копиране в паметта на адреса към CRL файл

 

Доста по-сложна е задачата за намирането на адреса на файла с CRL съдържанието, публикуван в мета информацията на даден клиентски X.509 сертификат. Причината е, че се изискват допълнителни умения за работа със сертификати, а понякога удостоверителите не публикуват там търсения адрес. Когато все пак той е публикуван, са възможни два различни синтаксиса за указването му: IETF/PKIX или Netscape (NSS).

По-долу е даден пример за намиране на адреса на файл, съдържащ CRL и публикуван в мета информацията на клиентски X.509 сертификат, който се намира в сертификатното хранилище на конфигурационен профил на Mozilla Thunderbird. За целта се отваря прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, натиска се бутона "View Certificates" и в новоотворения прозорец за управление на сертификатното хранилище, се избира секция "Other People's". В нея се маркира (чрез еднократно натискане с десния бутон на мишката) този X.509 сертификат, от чиято мета информация ще се извлече адрес на файл, съдържащ CRL на удостоверителя на сертификата:

 

Кореспондентски сертификат в хранилището за сертификати

 

и се натиска бутона "View". В новия прозорец се избира секция "Details". Средата на тази секция съдържа подсекция "Certificate Fields", в която е представен набора с налични в сертификата информационни полета-параметри (вкл. v3 разширения). Съгласно IETF/PKIX спецификацииите, адреса на файла съдържащ CRL, се публикува като стойност на параметъра "CRL Distribution Points":

 

Преглед на мета информацията в сертификата - CRL

 

Съгласно по-старата стандартизация NSS, адреса на файла с CRL съдържание е стойност на параметъра "Netscape Certificate Revocation URL":

 

Преглед на мета информацията в сертификата - CRL в Netscape стил

 

Все по-честно в сертификатите се указва само IETF/PKIX специфичния параметър и се избягва NSS типизираното обявяване. Но и в двата показани по-горе случая на указване на адрес на CRL, маркирането на съответното поле, води до извеждане в секция "Field Value" на асоциираната към него стойност: http://ca.example.com/crls/example-staff.crl. На този адрес би следвало да се намира файла с актуалното CRL съдържание, поддържано от издателя на разглеждания сертификат.

 

 

5.2.3. Меню за управление на CRL в сертификатното хранилище на Mozilla Thunderbird

Пощенският клиент Mozilla Thunderbird разполага със сравнително добър вграден инструментариум за управление на CRL съдържания. Този инструментариум е достъпен от специално меню за управление на CRL, което е част от по-общото меню за управление на сертификатното хранилище на всеки конфигурационен профил. За да се влезе в това меню, се отваря прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, и в него се натиска бутона "Revocation Lists". Отвореният нов прозорец съдържа менюто за управление на списъците с отменени сертификати (а ако до момента такива не са прибавяни в сертификатното хранилище, най-вероятно изведения съдържащия се в менюто списък ще бъде празен):

 

Прозорец на менюто за управление на списъци с отменени сертификати (CRL)

 

 

5.2.4. Добавяне на CRL в сертификатното хранилище на Mozilla Thunderbird и първоначално задаване на параметрите на актуализацията му

Списъците с отменени сертификати в Mozilla Thunderbird, се добавят към сертификатното хранилище на използвания конфигурационен профил. Подобно на X.509 сертификатите, списъците с отменени сертификати имат срок на валидност, но той е чувствително по-кратък и е по-скоро свързан със максималния срок за издаване на нов актуализиран списък, представен като стойност на параметъра "Next Update". От друга страна, за да се поддържа високо ниво на сигурност, следва потребителят да проверява валидността на използваните от него сертификати спрямо възможно най-актуално CRL съдържание. Именно поради това, пощенския клиент разполага с механизми за ръчна или автоматична актуализация на добавените в хранилището CRL, чиято функционалност е описана по-долу.

Добавянето на CRL е действие засягащо сертификатното хранилище на конкретен конфигурационен профил. Това означава, че ако даден потребител използва повече от един конфигурационен профил на Mozilla Thunderbird, той трябва да постави необходимите за всеки профил CRL съдържания. Въпреки, че най-често един и същи набор CRL съдържания се поставя във всички профили, е възможен и случай, при който различните профили да съдържат различни списъци с отменени сертификати и имат различни настройки за актуализацията на съдържанието им.

Използването (в това число и добавянето в сертификатно хранилище) на даден CRL, е възможно само, ако в сертификатното хранилище на използвания конфигурационен профил, се намира удостоверителския сертификат на издателя на CRL съдържанието, който е и удостоверител на проверяваните за валидност X.509 сертификати. Ако това условие не е изпълнено, няма как да се провери валидността на електронния подпис върху списъка с отменени сертификати (извършен от удостоверителя), а това обезмисля използването на съдържанието му. Логиката в този случай е, че ако в конкретния конфигурационен профил, един клиентски X.509 сертификат може да бъде проверен за валидност спрямо удостоверителския му сертификат (да се провери дали сертификата е издаден от декларирания удостоверител), то няма да има проблеми при добавянето на CRL на този удостоверител в сертификатното хранилище.

Най-важният параметър, чиято стойност трябва да е известна преди прибавянето на CRL съдържанието към сертификатното хранилище, е интернет адреса на съдържащия го файл. Причината, поради която CRL се указва с адрес на съдържащия го файл в Интернет, а не с път до файл върху локалната система, е характера на последващата периодична актуализация. Ясно е, че за да се работи с актуален CRL, съдържащия го файл трябва да се изтегля периодично от файловия сървър на издалия го удостоверител. Процедурата по задаване на адреса на файла със CRL за конкретния удостоверител, се извършва в прозореца с менюто за управление на CRL в сертификатното хранилище на Mozilla Thunderbird. Ако до момента не са били извършвани добавяния на CRL съдържания в хранилището на профила, списъка в менюто бъде празен:

 

Прозорец на менюто за управление на списъци с отменени сертификати (CRL)

 

Натиска се бутона "Import" и в полето за адрес на отворения прозорец, се въвежда адреса на файла с актуалния CRL:

 

Задаване на адреса на файла съдържащ CRL

 

след което се натиска "OK". При успешно изтегляне и добавяне на съдържанието към сертификатното хранилище (индикация за това ще бъде липсата на изведени съобщения за грешка), се извежда диалогово меню, в което потребителят трябва да укаже дали иска или не извършването на автоматична актуализация на добавения списък с отменени сертификати:

 

Диалогово меню за задаване на автоматична актуализация на CRL

 

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

 

Настройки за автоматична актуализация на CRL

 

Вижда се, че зададената честота (период) на извършване на актуализация на CRL от примера, е един ден. Доколкото пощенският клиент Mozilla Thunderbird е потребителско приложение, а не резидентна услуга, точното спазване на подобна периодичност е трудно. По-скоро смисъла от задаването на такава ниска стойност е, че ако пощенския клиент е бил изключен и не е използван за работа с конфигурационния профил (в който е вложен CRL по примера от по-горе), повече от един ден, при следващото му включване ще бъде извършена актуализация. Актуализация ще бъде извършена и ако пощенският клиент използва профила непрекъснато повече от един ден. Подразбиращата се периодичност, която съблюдава пощенския клиент Mozilla Thunderbird, по отношение на CRL, е съобразена със срока за планирано публикуване на следваща CRL актуализация (стойност на параметъра "Next Update" в мета информацията на CRL съдържанието). Често периодът между две последователни планирани актуализации на CRL съдържанието, е твърде дълъг, от гледна точка на сигурността и не може да покрие възникнали преждевремено инциденти, по повод на които удостоверителя издава спешно нов CRL. Именно за да бъдат добавяни инцидентни актуализации на CRL съдържанието, възможно най-бързо след след издаванието им, в примера горе е указан най-краткия възможен (от гледна точка на софтуера) период за актуализация - 1 ден. След като настройките бъдат извършени, се натиска бутона "OK". Те могат да бъдат променени от потребителя по всяко време.

За съжаление (поне за текущата версия, за която тази документация се отнася), в Mozilla Thunderbird има един все още неотстранен проблем с визуализирането на прибавения по гореописания начин CRL, в списъка (липса на динамично опресняване). Проблемът се състои в това, че ако се е следвала процедурата до тук без прекъсвания, след завършването й ще се появи отново прозореца за управление на списъците с отменени сертификати, но в него няма да има информация за токущо прибавения:

 

Прозорец на менюто за управление на списъци с отменени сертификати (CRL)

 

За да се извърши опресняване на списъка, в който да се появи последно добавения CRL, трябва прозореца да се затвори и след това отново да се отвори по начина, описан по-горе.

 

 

5.2.5. Промяна на параметрите за актуализация на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

След като даден CRL е бил добавен в сертификатното хранилище на конфигурационен профил на Mozilla Thunderbird, е възможно да се наложи извършването на промяна на типа и честотата на актуализацията му. Промяната се извършва в прозореца с менюто за управление на CRL в сертификатното хранилище на пощенския клиент. От наличният в него списък се избира (с еднократно натискане на десния бутон на мишката) този CRL, чиито параметри за извършване на актуализация, които ще бъдат променяни:

 

Маркиране на CRL, за който ще бъдат редактирани параметрите на актуализация

 

След това се натиска бутона "Settings" и се редактират на параметрите за актуализация на списъка с отменени сертификати. Най-често извършваните промени могат да се обобщят така:

 

 

 

5.2.6. Ръчно извършване на актуализация на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

В някои случаи се налага извършване на принудителна, ръчно инициирана актуализация на определен CRL в сертификатното хранилище на конфигурационен профил на Mozilla Thunderbird. Пример за такъв случай е издаване на критична актуализация на CRL в промеждутъка от време между две последователни планирани актуализации, за която потребителя е известен по някакъв начин. За да се инициира принудителната актуализация на избран CRL, се отваря прозореца с менюто за управление на CRL в сертификатното хранилище на пощенския клиент. В списъка се маркира (с еднократно натискане на десния бутон на мишката върху него) този CRL, чието съдържание трябва да се актуализира:

 

Маркиране на CRL, за който ще бъдат редактирани параметрите на актуализация

 

и се натиска бутона "Update". След като актуализацията на съдржанието на избрания CRL завърши, ще се появи меню, подобно на това, което се появява при първоначално добавяне на съдържанието на списъка в хранилището. То има за цел да предостави на потребителя възможност за уточняване на параметрите на последващите актуализации на това CRL съдържание.

За съжаление, във всички версии на Mozilla Thunderbird, които това ръководствто обхваща, има софтуерен проблем, който се състои в това, че при извършването на ръчна актуализация на CRL, не се визуализира адреса на изтегления файл със съдържание (по-точно липсва визуализиране на стойността на полето "CRL would be imported From"):

 

Софтуерен проблем с визуализиране на адреса на CRL след ръчна актуализация

 

 

5.2.7. Премахване на добавен в сертификатното хранилище на Mozilla Thunderbird CRL

Ако поради някаква причина се налага премахването на даден списък с отменени сертификати от сертификатното хранилище на конфигурационен профил на Mozilla Thunderbird, това може да стане по следния начин. Отваря се прозореца с менюто за управление на CRL в сертификатното хранилище на пощенския клиент. В списъка се маркира (с еднократно натискане на десния бутон на мишката) този CRL, който трябва да бъде изтрит:

 

Маркиране на CRL за последващо изтриване

 

Натиска се бутона "Delete" и маркирания CRL се изтрива от сертификатното хранилище, като едновремено с това се опреснява списъка с оставащите в хранилището на конфигурационния профил списъци с отменени сертификати:

 

Опреснения списък с CRL след изтриване на маркирания

 

 

5.3. Проверка на валидността на X.509 сертификат в реално време чрез използване на OCSP

 

5.3.1. Обща информация за OCSP и използването му

OCSP е съкращение на "Online Certificate Status Protocol" - протокол за проверка на валидността на X.509 сертификати в реално време, описан в RFC2560. Идеята за извършване на проверка на валидността на сертификат в реално време чрез използване на OCPS е следната. Повечето удостоверители на X.509 сертификати, поддържат база данни с описание на валидността на издадените от тях сертификати и предоставят достъп до нея чрез OCSP сървър. OCSP клиентите запитват OCSP сървъра, като заявяват и след това получават информация за моментната валидност на издаден клиентски X.509 сертификат. Когато валидността на някои от описаните в базата сертификати бъде прекратена предсрочно, информацията за това става видима за OCSP клиентите. Ако полученият от OCSP сървъра отговор потвърждава валидността на използвания X.509 сертификат, последния може да се използва за подписване, проверка на електронен подпис, криптиране или декриптиране, ако такива операции се извършват в момента. Ако отговора получен от OCSP сървъра показва прекратена валидност на сертификата, извършваните към момента на проверката операции с негово участие, се прекратяват и се извежда съответното съобщение.

Добрата практика показва, че автоматизираната проверка на валидността на X.509 сертификати по протокола OCSP, може да се извършва коректно само, ако в мета информацията на проверявания сертификат има подписана от удостоверителя му информация за адреса на OCSP сървъра. Когато Mozilla Thunderbird работи като OCSP клиент и бъде настроен по подходящ за целта начин, той извлича адреса на OCSP сървъра от мета информацията на проверявания за валидност сертификат, и го използва за извършване на проверката за валидност. Нужно е да се отбележи една важна особеност на OCSP клиентите. Запитване по OCSP за уточняване на статуса на даден X.509 сертификат се прави само в хода на извършвани с негово участие операции (напр. проверка на електронен подпис и криптиране), а не по принцип и непрекъснато.

Доколкото OCSP е преди всичко интернет базиран протокол, то всеки OCSP клиент трябва да има връзка към Интернет, за да може да извършва проверка на валидността на X.509 сертификати. Използването на OCSP в универсалния случай, без налична връзка към Интернет е безмислено. Освен това проблеми с валидацията могат да възникнат и при налична връзка към Интернет в случаите, в които OCSP сървъра не функционира (изключен е или не обработва заявки).

 

 

5.3.2. Настройки на OCPS клиента на Mozilla Thunderbird

Всички настройки за използване на OCSP клиента на Mozilla Thunderbird са специфични за даден конфигурационен профил. За да се влезе в менюто за настройка на OCSP клиента на Mozilla Thunderbird на конкретен конфигурационен профил, се отваря прозореца с менюто за управление на сертификатното хранилище и асоциираните към него модули и устройства, и се натиска бутона "Verification". Успешното изпълнение на последната операция въвежда потребителя в менюто за настройка на OCSP клиента на Mozilla Thunderbird:

 

Ето и илюстрация на съобщение за грешка, което се извежда от Mozilla Thunderbird при проблеми с работоспособността на запитвания OCSP сървър:

 

Съобщение за грешка при проблеми с работоспособността на OCSP сървъра

 

 

5.4. CRL срещу OCSP

Често се налага да се извърши сравнение между CRL и OCSP като механизми за проверка на моментната валидност на използваните в Mozilla Thunderbird X.509 сертификати. И CRL и OCSP предлагат една и съща гледна точка върху снетото от удостоверителя доверие върху издадени от него сертификати. Но докато OCSP предлага проверка в реално време, спрямо базата от данни за сертификатите на удостоверителя, CRL предлага такава със задна дата (или най-малкото със заден час). Казаното дотук означава, че ако сигурността е приоритет No.1 при използването на X.509 сертификати в Mozilla Thunderbird, за проверката на валидността им трябва да се използва задължително OCSP. От друга страна, OCSP като протокол не може да функционира без връзка към Интернет, което го прави неподходящ при използване на конфигурационен профил на Mozilla Thunderbird в "offline" режим. Възможни са и хибридни решения, които използват едновремено CRL и OCSP.

 

 

6. Използване на TLSv1/SSLv3 в Mozilla Thunderbird за криптиране на комуникационните канали и удостоверяване пред пощенски или директорийни услуги

 

6.1. Особености на използването на TLSv1 и SSLv3

Доколкото тази документация е ръководство за потребителя, в нея няма да бъдат правени подробни разглеждания на протоколите TLSv1 и SSLv3, а само ще бъдат описани някои характерни техни особености, с които всеки потребител на сигурни пощенски услуги следва да е запознат.

TLSv1 и SSLv3 са протоколи за удостоверяване и сигурен пренос на информация по схема "клиент-сървър", на ниво приложение. Въпреки, че и двата използват практически едно и също ядро с криптографски фунции и процедури (в Mozilla Firefox това ядро е NSS), между тях има разлика на ниво протоколна инициализация.

SSLv3 отразява по-старата идеология за реализиране на сигурни услуги на приложно ниво от типа "клиент-сървър". В рамките на тази идеология "несигурната" (некриптираната) услуга работи на един порт, а "сигурната" (криптираната) на друг. По този начин за всяка услуга се дефинират два порта - един за некриптирана комуникация "клиент-сървър" и един за криптирана. Често едно и също сървърско приложение работи и на двата порта. Възможно е, макар и рядко "сигурната" услуга да се реализира с помощта на външно приложение за изграждане на SSL обвивка - SSL Wrapper (например Stunnel).

TLSv1 е в съгласие с по-новите концепции за сигурни услуги на приложно ниво от типа "клиент-сървър". В случая услугата, няма "некриптирана" и "криптирана" реализация на отделен порт. Тя използва един единствен порт (обикновено този алокиран за нея в списъците поддържани от IANA). Но протокола на договорка между клиента и сървъра е така разширен, че клиента (най-често) да може да указва на сървъра дали комуникацията между тях да бъде криптирана и удостоверена или не (пример за това е използването на инструкцията STARTTLS в разширенията към някои приложни протоколи, напр IMAP, SMTP).

Пощенският клиент Mozilla Thunderbird използва както SSLv3, така и TLSv1 за сигурни връзки до SMTP, IMAP и директорийни и др. сървъри. Дали ще се използва единия или другия протокол в случая зависи по-скоро от софтуера на сървъра. Ако сървърски софтуер, към който ще се свързва пощенския клиент, е концептуално нов, то най-вероятно поддържа TLSv1 и ако това е така, следва да се използва именно този протокол. Ако услугите се предлагат от стар като концепция сървърски софтуер, използването на протокола SSLv3 понякога е единствения избор за връзка към тях.

Както е споменато по-горе, и TLSv1 и SSLv3 включват в себе си криптографско ядро с функции и процедури, което освен за криптиране на обменяна информация между клиента и сървъра, може да се използва и за удостоверяване. При удостоверяването се използват X.509 сертификати. Освен това съществуват две принципни и взаимнодопълващи се схеми за удостоверяване между участниците в една сигурна връзка "клиент-сървър": пасивна и активна.

При пасивната схема на удостоверяване, сървърът представя пред клиента копие от своя сървърски X.509 сертификат, а клиента проверява автентичността му чрез съответния удостоверителски сертификат. След като удостоверяването на сървъра пред клиента протече успешно, се инициира криптирана връзка за комуникация между тях.

Активната схема изисква извършването на двустранно взаимно удостоверяване на сървъра пред клиента и на клиента пред сървъра. Тя е двуетапна. При първия етап се следва описаната по-горе пасивна схема, а втория етап включва удостоверяване и на клиента пред сървъра, с валиден клиентски X.509 сертификат. Само след като и двете удостоверявания протекат успешно (поне това изисква добрата практика), се дава ход на комуникацията между клиента и сървъра, съответно иницииране на криптирана връзка за обмен на данни между.

При реализирането на пощенска услуга (напр. IMAP базирана), най-често се прилага описаната по-горе пасивна схема и често това е достатъчно за осигуряване на идентификацията на пощенския сървър пред клиента и изграждане на криптиран канал, по който да се обмени потребителското име и паролата, а след това и потока електронна поща, без опасност от прихващането на тези данни при преноса им в Интернет. От друга страна пасивната схема не предпазва пощенската услуга от атака на груба сила или използване на евентуални слабости на сървърския софтуер. Това означава, че на практика всеки злонамерен потребител разполагащ с пощенски клиент, може да получи достъп до сървъра на ниво приложен протокол, макар и през криптиран канал и да проверява за валидност комбинации от потребителско име и парола, или да експлоатира слабости на сървърския софтуер. Именно затова за критично важни пощенски услуги се прилага активната схема. По този начин само потребител, разполагащ с валиден пред услугата X.509 сертификат, може да комуникира с нея на приложно ниво.

Активната схема за достъп до защитена услуга, може да се прилага в два аспекта. Първият аспект касае използването й в такива услуги, в които удостоверяването на клиента пред сървъра чрез валиден X.509 сертификат се прави само с цел получаване на достъп до приложния слой на услугата, а след това се прави удостоверяване на приложно ниво с потребителско име и парола. Вторият аспект касае такива услуги, при които клиента се удостоверява пред сървъра само с валиден X.509 сертификат, без да въвежда допълнително потребителско име и парола (например SMTP+STARTTLS). При него се изисква услугата да има специална функционалност за директна работа с информацията от сертификатите и на нейна основа да идентифицира потребителите ("Certificate Mapping")

 

 

6.2. Особености на сертификатното удостоверяване на Mozilla Thunderbird пред TLSv1/SSLv3 базирани услуги

В Mozilla Thunderbird няма конфигурационни настройки, с които пощенския клиент да бъде принуден от потребителя, да се удостовери с клиентски X.509 сертификат пред сървъра на съответната услуга. Причината за това е, че извършването на удостоверяване със сертификат пред сървъра на услугата, се договаря при SSL-"ръкостискането" между двата участника в комуникацията, и то само ако такова удостоверяване бъде изискано по инициатива на сървъра (на основа на настройки на сървърския софтуер). При уточняване на параметрите на сертификатното удостоверяване, сървърът изпраща на клиента списък с удостоверители на X.509 сертификати. Целта му е да уведоми клиента, че сертификатното удостоверяване пред сървъра, е възможно само и единствено чрез използване на X.509 сертификат, удостоверителя на който се намира в списъка. Задължително трябва да се отчете факта, че за да може един X.509 сертификат да се използва за удостоверяване, в съответното сертификатно хранилище на пощенския клиент следва да се намира и прилежащия му частен ключ (удостоверяването включва извършване и проверка на електронен подпис). Освен това, в мета информацията на сертификата трябва да има определени сертификатни разширения, които удостоверителят да е поставил при издаването на сертификата. Казаното токущо означава, че не всеки сертификат може да бъде използван за извършване на удостоверяване пред TLSv1/SSLv3 базирани услуги. За да бъде издаден X.509 сертификат, който има нужните за удостоверяване пред услуги разширения, следва заявителя да уведоми за нуждата от такива удостоверителя, преди последния да пристъпи към издаването на сертификата.

Всеки път, когато е договорено удостоверяване на клиента пред услугата на база на валиден X.509 сертификат, се извежда прозорец с данни за избрания за целта сертификат:

 

Списък за избиране на сертификат за удостоверяване пред сървър

 

Ако в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, има повече от един клиентски X.509 сертификат, отговарящ на условията поставени от сървъра (допустими удостоверители и др), потребителят може да избере (по кратко име) с кой точно от тях да извърши удостоверяването. Изборът става от падащия списък под "Choose a certificate to present as identification".

След като бъде избран подходящият за извършване на удостоверяване X.509 сертификат, се натиска бутона "OK" и ако последвалия процес на удостоверяване протече успешно и до край, пощенският клиент ще премине към съответната комуникация в рамките на услугата, която се транспортира в SSL слоя (IMAP, SMTP и др). Ако преди извършването на удостоверяване пред сървър, не е била въвеждана паролата за защита на частните ключове в сертификатното хранилище, ще се появи прозорец за въвеждането й:

 

Прозорец за въвеждане на паролата за защита на частните ключове в сертификатното хранилище

 

и удостоверяване ще бъде извършено само при вярното й въвеждане.

 

 

6.3. Настройки на Mozilla Thunderbird за работа с TLSv1/SSLv3 базирани услуги

 

6.3.1. Настройки за работа с IMAP

Mozilla Thundebird може да използва TLSv1/SSLv3 при свързване с IMAP сървър само сред изрично указване в конкретния IMAP профил. Всяка IMAP базирана пощенска кутия, описана за използване в конфигурационен профил на пощенския клиент, има свой IMAP профил. Централна част в настройките на IMAP профила е указването на пълното квалифицирано име на хост на IMAP сървъра, който обслужва кутията. Изключително важно при използването на TLSv1/SSLv3 е да се указва това име на хост, за което е издаден сървърския сертификат. Част от добрата практика на доставчиците на IMAP услуга е да обявяват своя сървър като име на хост, а не като IP адрес. Освен това не е задължително всеки IMAP сървър да поддържа TLSv1/SSLv3 и затова, преди да бъде указвана една или друга политика за използване на тези протоколи, следва да има яснота дали те се поддържат или не от страна на сървъра. Честа (и добра) практика на операторите на IMAP базирана пощенска услуга, е да публикуват информация за достъпността им през TLSv1/SSLv3.

За да се достъпват безпроблемно TLSv1/SSLv3 услуги, следва копия на удостоверителските X.509 сертификати, чрез които се проверява автоматично валидността на сертификатите на сървъра на услугата, да са налични в сертификатното хранилище на използвания за целта конфигурационен профил. Ако IMAP услугата изисква и удостоверяване на клиентите пред сървъра й чрез валиден X.509 сертификат, в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, следва да се поставят копия и на клиентските сертификати, с които ще се извършва удостоверяването.

При описанието по-долу ще се предполага, че потребителят е настроил базово своите IMAP профили, но не е активирал използването на TLSv1/SSLv3 за връзка с IMAP сървъра. Тъй като IMAP профилите са част от по-общите конфигурационни профили, които Mozilla Thunderbird поддържа, за да се редактира IMAP профил, трябва да се влезе в конфигурационния профил, който го съдържа. След успешното стартиране на пощенския клиент за работа с избрания конфигурационен профил, от лентата с менюта се избира последователно "Edit" » "Account Settings":

 

Избор на менюто за настройки на imap/stmp профилите

 

и в отворения прозорец за управление на профилите на използваните услуги (в това число и IMAP профилите):

 

Прозорец за управление на профилите на услуги

 

се избира IMAP профил за редакция (за примера user@example.com):

 

Настройки за достъп до IMAP сървъра без използване на TLSv1/SSLv3

 

След това се влиза в секцията за настройки "Server Settings" на профила. Настройките за използване на TLSv1/SSLv3 се извършват в дясната част на прозореца, в подсекция "Security Settings". По подразбиране (ако не са били извършвани други настройки), не се използва TLSv1/SSLv3 за връзка до IMAP сървъра ("Never"). Ако се налага използването на TLSv1, но потребителя не е сигурен дали този протокол се поддържа от IMAP сървъра, следва да се маркира опцията "TLS, if available":

 

Настройки за достъп до IMAP сървъра с използване на TLSv1, ако се предлага от сървърския софтуер

 

По този начин, ако TLSv1 не се поддържа от IMAP сървъра, ще се премине автоматично към свързване без използване на сертификатно удостоверяване и криптиране на комуникационния канал. Ако потребителят е сигурен, че IMAP сървъра поддържа протокола TLSv1, той може да укаже това като избере опцията "TLS":

 

Настройки за достъп до IMAP сървъра с използване на TLSv1

 

Потребителят трябва да има яснота за това, че ако направи такъв избор, но IMAP сървъра не поддържа TLSv1, няма да се реализира сесия за достъп до пощенската кутия и ще бъде изведено съобщение за грешка. Ако IMAP сървъра не използва TLSv1, но поддържа SSLv3, в настройките на подсекцията се избира "SSL":

 

Настройки за достъп до IMAP сървъра с използване на SSLv3

 

Както се вижда, ако бъде избрана работа с протокола SSLv3, порта на услугата, указан в полето "Port", се променя автоматично от 143 на 993 (TCP), което е и за очакване, като се имат предвид особеностите на SSLv3. След завършване на настройките в секция "Server Settings", се натиска бутона "OK" и промените влизат в сила. В хода на използване на услугата, ако се налага удостоверяване на клиента пред сървъра в рамките на TLSv1/SSLv3, ще се наложи да бъде извършен избор на клиентски X.509 сертификат за удостоверяване пред сървъра на услугата.

 

 

6.3.2. Настройки за работа с SMTP

SMTP използва както TLSv1, така и SSLv3 и е един от първите приложни протоколи, разширили функционалността си с използване на TLSv1.

Mozilla Thundebird може да използва TLSv1/SSLv3 при свързване със SMTP сървър само сред изрично указване в конкретния конфигурационен профил. За всеки SMTP сървър, описана за използване в конфигурационен профил на пощенския клиент, се създава конфигурация. Обикновено за профил се декларира поне един профил на SMTP сървър и след това той се асоциира към наличните IMAP профилит. Възможно е за всеки IMAP профил да се декларира различен SMTP сървър. Централна част в настройките за използване на SMTP услугата е указването на пълното квалифицирано име на хост на използвания SMTP сървър. Изключително важно при използването на TLSv1/SSLv3 е да се указва това име на хост, за което е издаден сървърския сертификат. Част от добрата практика на доставчиците на SMTP услуга е да обявяват своя сървър като име на хост, а не като IP адрес. Освен това не е задължително всеки SMTP сървър да поддържа TLSv1/SSLv3 и затова, преди да бъде указвана една или друга политика за използване на тези протоколи, следва да има яснота дали те се поддържат или не от страна на сървъра. Честа (и добра) практика на операторите на SMTP услуги, е да публикуват информация за достъпността им през TLSv1/SSLv3.

За да се достъпват безпроблемно TLSv1/SSLv3 услуги, следва копия на удостоверителските X.509 сертификати, чрез които се проверява автоматично валидността на сертификатите на сървъра на услугата, да са налични в сертификатното хранилище на използвания за целта конфигурационен профил. Ако SMTP услугата изисква и удостоверяване на клиентите пред сървъра й чрез валиден X.509 сертификат, в сертификатното хранилище на съответния конфигурационен профил на Mozilla Thunderbird, следва да се поставят копия и на клиентските сертификати, с които ще се извършва удостоверяването.

При описанието по-долу ще се предполага, че потребителят е настроил базово своите IMAP профили, декларирал е и е настроил използването на SMTP сървър за тях, но не е активирал използването на TLSv1/SSLv3 за връзката с него. Тъй като декларациите за използван SMTP сървър са част от по-общите конфигурационни профили, които Mozilla Thunderbird поддържа, за да се извърши редакция, трябва да се влезе в съответния конфигурационен профил. След успешното стартиране на пощенския клиент за работа с избрания конфигурационен профил, от лентата с менюта се избира последователно "Edit" » "Account Settings":

 

Избор на менюто за настройки на imap/stmp профилите

 

и в отворения прозорец за управление на услугите, се избира "Outgoing Server (SMTP)":

 

Конфигурационен профил за SMTP сървър

 

След това в списъка с декларирани SMTP сървъри (в лявата част на прозореца), се маркира този (еднократно натискане върху името му с десния бутон на мишката), за който ще се указва използване на TLSv1/SSLv3:

 

Избор на профил за изпозване на SMTP

 

и се натиска бутона "Edit".

Преди да се продължи с описание на възможните настройки за използване на TLSv1/SSLv3 в рамките на SMTP, следва да се опише една много важна особеност, характерна преди всичко за взаимодействието между SMTP сървърите и пощенските клиенти. SMTP сървърите често разрешават приемане на изходяща от клиентите електронна поща, на база на валиден клиентски X.509 сертификат, с който клиента се удостоверява пред сървъра. При това не се изисква последващо представяне от страна на клиента на потребителско име и парола. Възможен е обаче и друг вариант, при който след установяването на пасивна SSL сесия (клиента удостоверява сертификата на сървъра), Mozilla Thunderbird подава в криптирания канал към SMTP сървъра, валидно име и парола и на основа на успешната провека на тази комбинация за съответствие спрямо локална база от данни, сървъра решава дали да приеме изходящата електронна поща на клиента за обработка или не.

Базовите настройки за използване на SMTP сървър без криптиране на комуникацията между него и пощенския клиент и без подаване на потребителско име и парола, изглеждат така:

 

Базови настройки за използване на SMTP сървър

 

По подразбиране (ако не са били извършвани други настройки), не се използва TLSv1/SSLv3 за връзка до SMTP сървъра ("Never"). Ако се налага използването на TLSv1, но потребителя не е сигурен дали този протокол се поддържа от SMTP сървъра, следва да се маркира опцията "TLS, if available":

 

Настройки за използване на SMTP сървър, с проверка за поддържката на TLSv1 от сървърския софтуер

 

По този начин, ако TLSv1 не се поддържа от SMTP сървъра, ще се премине автоматично към свързване без използване на сертификатно удостоверяване и криптиране на комуникационния канал. Ако потребителят е сигурен, че SMTP сървъра поддържа протокола TLSv1, той може да укаже това като избере опцията "TLS":

 

Настройки за достъп до SMTP сървъра с използване на TLSv1

 

Потребителят трябва да има яснота за това, че ако направи такъв избор, но SMTP сървъра не поддържа TLSv1, няма да се реализира сесия за достъп до пощенската кутия и ще бъде изведено съобщение за грешка. Ако SMTP сървъра не използва TLSv1, но поддържа SSLv3, в настройките се маркира "SSL":

 

Настройки за достъп до SMTP сървъра с използване на SSLv3

Както се вижда, ако бъде избрана работа с протокола SSLv3, порта на услугата, указан в полето "Port", се променя автоматично от 25 на 465 (TCP), което е и за очакване, като се имат предвид особеностите на SSLv3. След завършване на настройките се натиска бутона "OK" и промените влизат в сила. В хода на използване на услугата, ако се налага удостоверяване на клиента пред сървъра в рамките на TLSv1/SSLv3, ще се наложи да бъде извършен избор на клиентски X.509 сертификат за удостоверяване пред сървъра на услугата.

 

 

6.3.3. Настройки за работа с LDAP базирани адресни книги

Функционалността на Mozilla Thunderbird за работа с адресни книги, дефинирани върху LDAP сървъри, допуска задаването на SSLv3 достъп до сървъра и удостоверяване пред услугата с помощта на клиентски X.509 сертификат. За функциониране на SSLv3 достъпа до LDAP сървъра, в сертификатното хранилище на конфигурационния профил на Mozilla Thunderbird, следва да се намират копия от удостоверителските сертификати, с които да бъдат проверявани X.509 сертификатите на LDAP сървърите, до които ще се реализира сигурна връзка. Освен това, ако ще се извършва удостоверяване на клиента пред сървъра, в сертификатното хранилище трябва да са налични съответните клиентски X.509 сертификати и прилежащите им частни ключове.

В изложението по-долу ще се предполага, че вече е конфигуриран достъп до LDAP адресна книга. За да се установи SSLv3 базирана сигурна връзка до LDAP сървъра, следва да се достъпи менюто за настройки на достъпа до адресната книга. Това става като се стартира Mozilla Thunderbird с използване на съответния конфигурационен профил и от лентата с менютата се избира последноватено "Tools" » "Address Book":

 

Извикване на адресната книга

 

В отворения прозорец се избира LDAP базираната адресна книга, за която ще бъде реализиран SSLv3 базиран достъп до LDAP сървъра й, след което се отваря менюто за настройки:

 

Редактиране на настройките за използване на LDAP адресна книга

 

и единственото, което следва да се направи в него е да се маркира опцията "Use secure connection (SSL)"

 

Указване на използване на SSL за връзка до LDAP сървъра

 

Както при всички SSLv3 базирани услуги и тук, при избора на опцията за преминаване в SSL режим, ще се смени порта за достъп до услугата (в случая от 389 на 636). За да влезе в сила настройката се натиска бутона "OK". Ако се налага удостоверяване на клиента пред сървъра в рамките на SSLv3, ще се наложи да бъде извършен избор на клиентски X.509 сертификат за удостоверяване пред сървъра на услугата.

 

Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]

Creative Commons - Признание 2.5 Valid CSS! Valid XHTML 1.0 Strict