[Към каталога на техническите бележки]
Техническа бележка: Лоша HTTPS/SSL практика на Унинет
Публикувана на: 9 септември 2008 г.
Съдържание:
Тази бележка има за цел да запознае обучаваните в направление "Мрежи и комуникации" на УИЦ на Софийския Университет "Св. Климент Охридски", с лошата SSL практика на сдружение Унинет. Целта е студентите, чието обучение е свързано със системна администрация, да получат примери за лоша практика при администриране на HTTPS протоколни сървъри, за да могат да я избягват в бъдещата си работа.
Често в дизайна на някои страници, се използва автоматично преминаване от HTTP към HTTPS протокол, без клиента да извършва подобен избор. В разглеждания случай има точно такъв подход. Всички заявки за http://www.uninet.bg се пренасочват към https://www.uninet.bg. Пренасочването има за цел да се премине към защитен режим на комуникация, без да се налага клиентът да избира такъв.
Администраторът на сървъра, който предоставя SSL услугата, използва X.509 сертификат за хост, който е непроверяем като валидност в наличните браузъри на фондация Mozilla (дефакто стандарт при използване на HTTPS). Нито в Mozilla Firefox, нито в Seamonkey е наличен удостоверителски сертификат, с който да се извърши проверка на валидността на сертификата издаден за www.uninet.bg.
За да се направи все пак анализ на проблема, е изтеглен подавания от сървъра сертификат, чрез използване на инструментариума на OpenSSL:
$ openssl s_client -connect www.uninet.bg:https > dump.asc
След това се извлича подробна информация за подавания от сървъра сертификат:
$ openssl x509 -text -noout -in dump.asc
В информационните полета, като издател е посочен субекта "Secure Business Services CA". Разширенията на X.509 сертификата указват URI на сертификатите, използвани от този удостоверител (виж информацията в секция "Authority Information Access"):
http://crt.securebusinessservices.com/SecureBusinessServicesCA_2.crt
http://crt2.securebusinessservices.com/SecureBusinessServicesCA_2.crt
За да се извърши проверка на валидността на сертификата спрямо посочените в URI записите X.509 удостоверителски сертификати, единия от тях се изтегля в директория за експеримента и след това се използва при извършване на SSL сесията:
$ wget http://crt.securebusinessservices.com/SecureBusinessServicesCA_2.crt $ openssl s_client -connect www.uninet.bg:https -CAfile SecureBusinessServicesCA_2.crt
Ако валидацията е минала успешно, при извълнение на втория команден ред, в края на изхода, ще се съдържа реда:
Verify return code: 0 (ok)
След анализ чрез други бразузъри бе установено, че единствено браузъра Internet Explorer може да валидира сертификат за хоста www.uninet.bg.
На основа на горните наблюдения и констатации може да се направи извода, че сдружение Унинет използва изключително лоша административна практика за управление на своите HTTPS базирани услуги. Лошата практика се състои в използването на сертификат за хост, който е издаден от удостоверител, чиито сертификат фигурира в сертификатното хранилище на само един браузър. Това не би било пробем, ако нямаше автоматично превключване към SSL режим и в не-SSL версията на страницата не бе указано от къде да се изтегли копие от X.509 сертификата на удостоверителя (друг въпрос е дали потребителя ще се довери на подобна препратка към удостоверител). Администраторът издал сертификата не е направил една от най-елементарните проверки - дали издадения сертификат се валидира от по-разпространените браузъри. От там следва още по-лошата практика, при която клиента се насочва автоматично към SSL достъпна страница с непроверяем сертификат и това предизвиква появата на съобщения за грешки и недостъпност на страницата.
Когато една организация, каквато е Унинет, има претенции да бъде регистър на домейн от първо ниво, тя трябва да покаже добра практика на услугите. Копирането в случая на идеята на Register.BG за пренасочване на заявки от не-SSL към SSL сесия е извършено доста зле технически.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]