Category: финансы

(no subject)

У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
- общая сложность для понимания и настройки,
- сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
- сложность с отзывом сертификатов, необходимость держать доступными точки CRL и OCSP, что может быть довольно геморройно, если у нас не общий Интернет, а изолированые сети,
- нельзя защитить часть сайта - скажем, чтобы https://hostname/public был доступен всем, а https://hostname/private требовал сертификата для опознания юзера. Точнее, этого результата можно добиться, но лишь при применении определённых хитростей.
- отсутствует нормальный logout - для того, чтобы сайт перестал тебя опознавать, надо полностью закрывать браузер (или изначально заходить в incognito-окне).

Но есть одно крутое преимущество - по сравнению с другими методами логина поверх SSL, она сильно усложняет проведение атаки man-in-the-middle, она же SSL interception. Вплоть до "вообще никак".

Подменить серверный сертификат на лету, при условии, что браузеры доверяют подменному, вполне тривиально - и есть организации, делающие это на регулярной основе: как для хороших целей (отлавливать всякую малварь), так и для менее хороших.

Способов добавить сертификат в список доверяемых есть масса, начиная с домейновых group policies и windows update, и заканчивая малварью и банальной социальной инженерией. Более того, тот же Avast antivirus делает это просто по дефолту - добавляет сертификат своего типа-CA в "Trusted Root Certification Authorities" и расшифровывает трафик.

Но когда требуется сертификат ещё и клиентский, то всё намного усложняется, посколько тогда система-перехватчик должна подменить и его тоже. А сервера куда недоверчивее в этих вопросах, чем браузеры. Им, как правило, просто указывают - сертификаты от этого CA и от этого принимать, а остальных лесом. К примеру, в FortiGate при создании PKI-юзера надо в явном виде задать и CA, которым его сертификат должен быть подписан, и что у этого сертификата должно быть в Subject. К тому же, тот может быть и вовсе самоподписанным. Тут не разгуляешься.

А подменить серверный сертификат, не подменяя клиентский, посылая его как есть - не выйдет. У сервера банально циферки не сойдутся, на чём подключению и конец.

Так что стоящая вещь, товарищи, пользуйтесь. :-)

(Это я тут с админом одной сеточки пообщался - негодовал, что не может инспектировать наш SSL-VPN. Ну, мои тебе соболезнования, приятель. :-))

(no subject)

Решил обзавестись собственным домейном 2-ого уровня - в порядке "а пусть будет". Ничего особо умного, что с ним делать, пока в голове нет, но раз появилась возможность урвать на халяву и утащить в зубах - кошачьи рефлексы диктуют урвать.

Пока завёл себе и-мейл - cat@mucius.tk - буду использовать в качестве основного личного. Сертификат к нему тоже есть (в разных форматах - 1, 2), им будет подписываться почта, с ним можно шифровать почту мне. SHA1 fingerprint для валидации - "84 46 05 12 26 d0 68 7c 94 b5 3e 1f 71 c9 b9 2f 86 01 4b e4".

http://mucius.tk - пока тупо редирект на LJ, потом может придумаю что получше.

Если кому интересно в плане "сделайсебесам": захапан домейн на dot.tk (острова Токелау, основные экономические статьи - свиноводство и DNS), хостится на cloudns.net, почтовый хостинг и всякие гугловские ништяки - на Google Apps, мэйловый сертификат - от Comodo, можно ещё и от StartSSL сертификат для сайта оторвать, если надо. Всё это без копейки денег, чем и хорошо.