Publishing Windows domain DNS to outer world

Проделал небольшой экспериментик - при установке очередного Windows-домена проинтегрировал его в общий DNS. Обычно админы такого не делают - и из нежелания, чтобы их внутренние DNS-записи мог запрашивать любой желающий, и чтобы домен-контроллеры наружу не открывать или отдельные сервера под это дело не городить.

Но поскольку сеточка тестовая, то секретность ейной внутренней структуры мне пофигу, а вот выигрыш от открытости есть: какие бы DNS-сервера не были прописаны у юзеров, каким бы методом они не подключались - по личному VPN, по site-to-site VPN, да хоть напрямую - записи будут им доступны. Поскольку вечные приколы VPN с сетевыми настройками задрали изрядно, универсальности хочется.

Что до домен-контроллеров, то открывать их во всеобщий доступ и мне не хотелось, по двум соображениям:

• Чтобы не подставлять их под DoS или ещё какую пакость,
• Чтобы не отключать на них рекурсию. Я хочу, чтобы они предоставляли внешнему миру информацию лишь о моём домене, а не о любом в мире. Можно, конечно, отключить, но тогда для машин во внутренней сети надо дополнительно что-то городить - лишнее усложнение.

Поэтому пошёл искать службу-посредник, и нашёл: BuddyNS.

Процесс простой:

1. На файерволле разрешить входящий DNS-трафик только от их IP-адресов (и исходящий на них же - для уведомлений).  Разрешить по обоим протоколам - и TCP, и UDP.
2. В настройках DNS-сервера разрешить этим адресам zone transfer, и их же внести в список, кому посылать уведомления об изменениях в зоне).
3. Указать несколько их серверов как Name Servers для конкретного домена. Этот список не имеет отношения к списку IP-адресов, вытягивающих записи из наших DC, хотя пересечения есть.
4. Указать те же сервера как ответственные за наш домен на родительском домене (или у DNS-регистратора).
5. Зарегистрироваться у BuddyNS, указать домен и внешний IP-адрес нашего DC, откуда те попытаются вытащить записи этого домена.

Пара примечаний:

• Эта контора только публикуют slave zones во внешний мир - форвардером они не работают. Если нет желания давать DC запрашивать DNS-сервера по всему миру, можно в качестве форвардеров указать адреса Гугла или OpenDNS. Понятно, не забыть про файерволл.
• Понятно также, что с доменами типа .local делать нечего. Не надо такие заводить изначально.

Israeli electronic ID bowels

Недавно мимо меня пробегало новенькое израильское удостоверение личности (теудат зеут) - уже не бумажка, а смарткарта - и я, конечно, тут же его зацапал глянуть, что на ентой смарткарте есть. Мда. После потрошения ейного сертификата могу честно сказать - построено ужасно, просто ужасно.
( Collapse )

Технические потроха:

1. Поле AIA - линк на службу проверки статуса сертификатов, OCSP:

• http://va.igcas.gov.il/ocsp/ocsp.cgi

Такой хост DNS-у просто неизвестен, и служба, соответственно, недоступна.

Время жизни CRL - три дня. Что означает, если моё удостоверение покрано, то даже если МВД отзовёт сертификат немедленно - то может пройти полных три дня, пока он перестанет приниматься сторонами, проверяющими этот CRL.

2. Поле AIA - линк на вышестоящий сертификат выглядит так:

• https://www.igcas.gov.il/cert/ilgov-res.authca-12-01.cer

Этим идиотам никто не объяснил, что использовать HTTPS для линков в AIA и CDP нельзя? Потому что может возникнуть логическая петля?

Да к тому же и линк битый.

То есть если у меня есть корневой сертификат, и мне надо проверить сертификат со смарткарты, а промежуточного у меня нет - то увы мне. Цепочку не выстроить.

Аналогичный линк с промежуточного на корневой:

• https://www.igcas.gov.il/cert/ilgov-res-authrootca-12-01.cer

Опять HTTPS, но на этот раз хотя б линк не битый. Зато сервер отдаёт сертификат с неправильным MIME-type: text/html вместо application/x-x509-ca-cert.

3. Линки на CRL - их два:
В конечном:

• http://crl.igcas.gov.il/crl/ilgov-res-authca-12-01.crl
• http://crl2.igcas.gov.il/crl/ilgov-res-authca-12-01.crl

В промежуточном:

• http://crl.igcas.gov.il/crl/ilgov-res-authrootca-12-01.crl
• http://crl2.igcas.gov.il/crl/ilgov-res-authrootca-12-01.crl

Второй в паре - битый, хост crl2.igcas.gov.il на подключения не отвечает.

4. Линки на документы с policy:
В промежуточном:

• https://cps.igcas.gov.il/cp/ilgov-res-authcert-v1.html

В корневом:

• http://cps.igcas.gov.il/cp/ilgov-res-authcert-v1.html

Как ни странно, рабочие, хотя один из них с HTTPS, причём сайт оборудован неизвестным никому сертификатом, поэтому браузер выбрасывает ошибку. Впрочем, кто её читает, эту галиматью?

5. В поле SAN значится такое:

• Principal Name=номер_ID@res.igcas.gov.il

Такой хост DNS-у неизвестен. Не то, чтобы это проблема, но жалко: можно было бы каждому сделать официальный мейлбокс или алиас.

6. Поле "Enhanced Key Usage":

• Client Authentication
• Smart Card Logon

А почему не Document Signing, к примеру? Да, шифровать ключом, у которого нет бэкапа, и впрямь не стоит - но почему не дать людям возможность документы подписывать, например?

7. Subject корневого выглядит вот так: 
    CN = Residents eID Root CA 12-01
    OU = Population and Immigration Authority
    O = Government of Israel
    C = IL
А почему бы не произвезти его от главного государственного сертификата, тем более, что такой, похоже, есть: Government of Israel Root CA G2 (правда, эти кретины отдают его мало того, что в бинарном формате, так ещё и с кривым MIME-type)? Чтобы цепочку доверия можно было легче выстроить?

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

Если кто хочет повтыкать в детали сам - припадайте. "Leaf" сертификат со смарткарты не выкладываю из соображений приватности владельца, а правительственные - на здоровье.

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. Ну, мои тебе соболезнования, приятель. :-))