1 заметка с тегом

https

HTTPS (аббр. от англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443. Протокол был разработан компанией Netscape Communications для браузера Netscape Navigator в 1994 году.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак и атак типа man-in-the-middle, при условии, что будут использоваться шифрующие средства и сертификат сервера проверен и ему доверяют.

По умолчанию HTTPS URL использует 443 TCP-порт (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат открытого и закрытого ключа для этого веб-сервера. В TLS используется как асимметричная схема шифрования (для выработки общего секретного ключа), так и симметричная (для обмена данными, зашифрованными общим ключом). Сертификат открытого ключа подтверждает принадлежность данного открытого ключа владельцу сайта. Сертификат открытого ключа и сам открытый ключ посылаются клиенту при установлении соединения; закрытый ключ используется для расшифровки сообщений от клиента[6].

Существует возможность создать такой сертификат, не обращаясь в ЦС. Подписываются такие сертификаты этим же сертификатом и называются самоподписанными (self-signed). Без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) такое использование HTTPS подвержено атаке man-in-the-middle.

Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизованным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля.

В HTTPS для шифрования используется длина ключа 40, 56, 128 или 256 бит. Некоторые старые версии браузеров используют длину ключа 40 бит (пример тому — IE версий до 4.0), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит, с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации.

Настройка DoH в Mikrotik

Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

Теперь нужно провести небольшую артподготовку, а именно скачать и импортировать список корневых сертификатов. Делается это двумя командами:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

 Нет комментариев   4 мес   Cloudflare   DNS   DoH   Google   https   Mikrotik   VPN