C, PHP, VB, .NET

TLS сертификатите имат определено време на живот – обикновено от 3-4 месеца до 1 година (преди имаше и по-дълги). Един от големите проблеми, свързани със сигурността, е открадването на частния ключ за валиден сертификат – в такъв случай хакер може да създаде фалшив уебсайт и да извършва MiTM атаки. Затова много важна част от сигурността в интернет е възможността да можем да „оттегляме“ (revoke) сертификати, с което да ги направим невалидни, независимо че все още не са изтекли.

Историческото решение на проблема е с т.нар. Certificate Revocation Lists (CRLs). Това са списъци с отменени сертификати, които се публикуват регулярно от издателите им (Certificate Authorities – CA). Те са цифрово подписани и имат време на валидност, което обикновено е 24 часа. Идеята е клиента (браузъра) да изтегля актуалния CRL от даден CA, когато посещава даден уебсайт, и да проверява дали подадения от сайта сертификат присъства в списъка или не. Само ако сертификата не присъства в CRL, той може да се приеме за сигурен.

Проблемът с CRL е, че с огромното нарастване на обема на защитени с TLS сайтове, нараства много и обема на отменени сертификати. Така CRL списъците стават много големи и товарят клиентите и издателите с мрежови трафик. Исторически е правен опит за въвеждане на т.нар. протокол на онлайн проверка на статус на сертификат – Online Certificate Status Protocol (OSCP), – при който клиента прави заявка към сървър на CA само за определен домейн, а не да се тегли целия CRL, но това също се оказа непрактично, защото въпреки намаления обем на трафика, сървърите на CA се претоварват от множеството заявки на клиентите и съответно често „падат“.

Идеята на OSCP Stapling – е да разреши този проблем. При него не клиента, а сървъра се свързва с дадения CA и изтегля цифрово подписано съобщение, което гарантира, че неговия сертификат е все още валиден. Съобщението, което от своя страна си има вградено определено време на валидност, се изпраща към клиента по време на инициализацията на TLS връзката. Така няма нужда клиента да тегли актуален CRL или да прави OSCP заявки, които забавят връзката, товари мрежовия му трафик и това сървъра на CA, а може просто да се довери на полученото цифрово подписано съобщение от самия уебсайт, до който тъй или иначе е отворил връзка. OSCP сървърите на CA също са щастливи, защото заявките към тях драстично намаляват (със заявка за едно съобщение изтеглено от сървъра се обслужват много клиенти и така мрежовия трафик към тях се съкращава изключително много).

Както всяко нещо, което се е появило по-късно във времето, а не по време на първоначалния дизайн на протокола, OSCP Stapling има сериозен недостатък – не всички сървъри и не всички клиенти го поддържат. Поради тази причина той е и заобиколим. Ако хакер открадне сертификат, той може да направи сървър, който да НЕ изпраща OSCP Stapling съобщение (дори клиента да го поиска) и по този начин браузъра просто няма да го получи. Всички съвременни браузъри работят на принципа да продължат, приемайки сертификата (и проверявайки го в CRL разбира се), в случай, че сървъра не им изпрати поискано от тях OSCP Stapling съобщение. Поради тази причина на този етап OSCP stapling е улеснение за клиентите, но то не е замяна на CRL.

Понеже CRL е технология, която не се мащабира добре, в бъдеще ще се наложи тя да бъде заменена напълно и именно OSCP Stapling е най-вероятния кандидат за това. Едно възможно решение е протоколът изведнъж да стане задължителен за използване, но практиката показва, че подобни промени не се имплементират лесно и по-вероятното решение е да се потърси подход, при който промените да се въвеждат с плавен преход от старата към новата технология.

Засега едно потенциално решение е директива, която се вгражда в самия TLS сертификат, която се нарича „OSCP Must Staple“. С тази директива сертификатът указва на браузъра, че е задължително сървъра да изпрати OSCP Stapling съобщение и сертификата трябва да се приеме за невалиден, ако такова липсва. Тоест реално това би направило OSCP Stapling задължително, за сървърите които решат да го имплементират, но старата технология ще продължи да работи при всички останали. Така максималното, което могат да направят хакерите, е да използват последното валидно OSCP Stapling съобщение, но както вече беше казано, то ще е може да се използва само за определен срок, който не е дълъг. Така вече реално OSCP Stapling може да замени CRL/OSCP.

Засега само Mozilla Firefox поддържа OSCP Must Staple. Другите браузъри игнорират директивата и не се „сърдят“ ако сървъра не подаде валидно съобщение въпреки, че директивата е включена. Дали и кога ще се получи поддръжка в Chrome/Edge и другите браузъри, все още не се знае.

Включването на OSCP Stapling в Apache чрез mod_ssl е изключително лесно. Преди да го покажа, ще отбележа, че той е проектиран така, че да не прави заявки сам за обновяване на OSCP съобщението, а само при нужда. Тоест кешът не се обновява автоматично, а по време на заявка от клиент. Това потенциално може да забави отговора до този конкретен клиент, защото TLS handshake не продължава докато не се получи отговора от CA. Това не би трябвало да е проблем, защото става дума за единствена HTTP заявка – всички следващи ще се възползват от кеша. Иначе за включването на OSCP Stapling просто трябва да се добавят следните редове в конфигурационния файл (ако искате да ползвате OSCP Must Staple):

SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors on
SSLStaplingCache shmcb:/var/run/ocsp(128000)

или (ако искате да имате OSCP Stapling, но няма да имплементирате Must Staple):

SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)

Имената на променливите подсказват и тяхното значение. С SSLUseStapling инструктираме уеб сървъра, че трябва да започне да се грижи за регулярно изтегляне и обновяване на верифициращите съобщения. С SSLStaplingResponderTimeout указваме до колко секунди да се чака отговор от страна на CA за верифициране на съобщението. С SSLStaplingCache се указва къде и в какъв обем (в байтове) да се пази кеш на съобщенията, за да може веднъж верифицирано съобщение да се преизползва и за други клиенти. Стандартно OSCP Stapling съобщение е от няколко стотици байта, но не повече от 10KiB големина всяко. Ако имате множество сайтове на сървъра, би следвало и да увеличите кеша – максимум 10240*броя на сайтовете, но обикновено стига и наполовина.

А SSLStaplingReturnResponderErrors е свързано индиректно с темата за OSCP Must Staple. Принципно ако сървъра се опита да обнови OSCP съобщение и получи грешка от сървъра на CA (проблем с мрежовата връзка, временно претоварване, т.н.), тогава има три възможни теоретични варианта за действие:

• Да се информира браузъра, че е станала грешка, с което при клиента ще излезе съответното съобщение за грешка и сайта няма да се отвори;
• Да се премълчи за станалата грешка и да се изпрати към браузъра последното останало в кеша валидно съобщение (с надежда разбира се да не е изтекло – иначе показването на грешка е неизбежно);
• Да не се изпраща OSCP Stapling съобщение.

Първото е по-скоро важно при критични от гледна точка на сигурността уеб сайтове – не бихме искали да го имплементираме при стандартни, защото при проблеми на сървъра на CA ще има проблеми и при нашия уебсайт – забележете, че при него вашият сертификат си е валиден, но сайта няма да се отваря, а това не е нещо, което желаете. Второто е логичното, но за съжаление Apache mod_ssl не го поддържа. Третото е именно опцията „Off“, но при употреба на OSCP Must Staple нашия сайт отново ще спре да работи, независимо че имаме валиден сертификат – в сертификата е записано, чe трябва да има задължително валидиране, а сървъра няма да го изпрати, което ще генерира грешка в браузъра. Затова ако искаме да използваме OSCP Must Staple, на този етап (поне до Apache HTTPD версия 2.4.46, но вероятно и при по-нови) опцията по-скоро трябва да е включена – така поне потребителите ще получат някакво по-валидно изглеждащо съобщение за грешка.

При всички положения забелязахте един фундаментален проблем при mod_ssl – ако използваме Must Staple, трябва да си обновим кеша и няма връзка между нашия сървър и OSCP сървъра на CA, нашия уебсайт реално спира да работи въпреки, че сертификата ни е валиден. Това със сигурност е проблем и по-сериозни компании имплементират свои собствени „кеширащи OSCP проксита“ като потенциално решение. Именно това е най-вероятно и основната причина всички браузъри с изключение на Mozilla Firefox да не зачитат OSCP Must Staple директивата в сертификатите.

По-нов подход е да се включи OSCP Stapling чрез Apache mod_md (работи с версии 2.4.41 или по-нови), който заменя стандартната функционалност от mod_ssl и прави Apache да работи по-гъвкаво:

• С помощта на mod_watchdog, следи за валидността на stapling кеша и го обновява автоматично – така се избягва проблема със забавяне на заявка на клиент;
• Обновяването не се прави в последния момент, а се дава определено време преди последното валидно съобщение от кеша да е изтекло – това прави работата на сървъра по-малко критична за грешки от страна на сървърите на CA;
• Както вече се досетихте, работи в режима от по-горе, който описах като предпочитан (втората точка) – при грешки от страна на сървъра на CA се дава последното валидно съобщение от кеша (ако не е изтекло разбира се – иначе грешката е неизбежна);
• Записва кеша перманентно на диска и така не го губи при рестартиране на Apache HTTPD.

Mod_md обаче все още се счита за експериментален и не е добавен по подразбиране в Apache. За да го използвате, трябва да компилирате Apache със съответната конфигурационна директива:

./configure --with-apxs=<където е изтеглен модула>/bin/apxs --enable-werror

и разбира се после да бъде добавен в конфигурационния файл:

LoadModule md_module modules/mod_md.so

Накрая трябва да укажете, че ще го използвате, чрез:

MDStapling on
MDCertificateAgreement accepted

Тези директиви може да бъдат сложени както за отделен домейн (когато е сложена в неговия VirtualHost), така и глобално. С първата включваме използването на модула, а с втората изпращаме съобщение до CA, че сме приели техните Terms and Agreements (това е особеност при популярните LetsEncrypt – при други по-скоро няма значение).

П.П. Модулът mod_md има и функционалност за автоматично генериране на TLS сертификати и автоматичното им подновяване чрез Lets Encrypt. Ако не използвате някой контролен панел (например DirectAdmin), който ви дава подобна функционалност, това е може би най-лесният начин да се сдобиете с безплатно TLS криптиране за вашия уебсайт без никакви сериозни усилия. Прочетете документацията тук: https://github.com/icing/mod_md