Saturday, August 5, 2017

Authentication by client certificates as anti-interception measure

У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
- общая сложность для понимания и настройки,
- сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
- сложность с отзывом сертификатов, необходимость держать доступными точки 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 comments:

Post a Comment