LINUX.ORG.RU

История изменений

Исправление AEP, (текущая версия) :

Нет. Даже при условии, что Let’s Encrypt играет по всем правилам. Даже если никакой удостоверяющий центр не прогибается под требования силовиков.

Нигде нет гарантии, что валидацию домена в Let’s Encrypt провел реальный владелец, а не сотрудник DNS-хостинга под нажимом силовиков.

Напоминаю: Let’s Encrypt выдает сертификат, если видит, что сгенерированный им токен оказался доступен или в виде файла, доступного для скачивания по HTTP с защищаемого домена (не наш случай), или в виде DNS TXT-записи в этом домене. Эту запись сотрудники DNS-хостера запросто могут нарисовать и таким образом получить от Let’s Encrypt на 146% валидный сертификат. В Let’s Encrypt даже не догадаются, что выдали сертификат не законному владельцу домена, а «кому надо». Затем этот сертификат ставится на подконтрольный «кому надо» сервер, подменяется A-запись, и HTTPS-запросы после расшифровки проксируются на реальный сервер. Итог - успешный MITM.

Для пользователя, защиты от этого никакой нет. Для владельца домена, формально есть запись CAA, и даже можно разрешить выпуск сертификатов только при условии, что запрос идет с конкретной учетной записи Let’s Encrypt, идентифицированной по приватному ключу регистрации. Но я не вижу, как это может работать без DNSSEC, если DNS-хостинг по факту скомпрометирован и может нарисовать любую CAA-запись вместо настоящей.

Исправление AEP, :

Нет. Даже при условии, что Let’s Encrypt играет по всем правилам. Даже если никакой удостоверяющий центр не прогибается под требования силовиков.

Нигде нет гарантии, что валидацию домена в Let’s Encrypt провел реальный владелец, а не сотрудник DNS-хостинга под нажимом силовиков.

Напоминаю: Let’s Encrypt выдает сертификат, если видит, что сгенерированный им токен оказался доступен или в виде файла, доступного для скачивания по HTTP с защищаемого домена (не наш случай), или в виде DNS TXT-записи в этом домене. Эту запись сотрудники DNS-хостера запросто могут нарисовать и таким образом получить от Let’s Encrypt на 146% валидный сертификат. В Let’s Encrypt даже не догадаются, что выдали сертификат не законному владельцу домена, а «кому надо». Затем этот сертификат ставится на подконтрольный «кому надо» сервер, подменяется A-запись, и HTTPS-запросы после расшифровки проксируются на реальный сервер. Итог - успешный MITM.

Для пользователя, защиты от этого никакой нет. Для владельца домена, формально есть запись CAA, и даже можно разрешить выпуск сертификатов только при условии, что запрос идет с конкретной учетной записи Let’s Encrypt, идентифицированной по приватному ключу регистрации. Но я не вижу, как это может работать, если DNS-хостинг по факту скомпрометирован и может нарисовать любую CAA-запись вместо настоящей.

Исправление AEP, :

Нет, даже при условии, что Let’s Encrypt играет по всем правилам.

Нигде нет гарантии, что валидацию домена в Let’s Encrypt провел реальный владелец, а не сотрудник DNS-хостинга под нажимом силовиков.

Напоминаю: Let’s Encrypt выдает сертификат, если видит, что сгенерированный им токен оказался доступен или в виде файла, доступного для скачивания по HTTP с защищаемого домена (не наш случай), или в виде DNS TXT-записи в этом домене. Эту запись сотрудники DNS-хостера запросто могут нарисовать и таким образом получить от Let’s Encrypt на 146% валидный сертификат. В Let’s Encrypt даже не догадаются, что выдали сертификат не законному владельцу домена, а «кому надо». Затем этот сертификат ставится на подконтрольный «кому надо» сервер, подменяется A-запись, и HTTPS-запросы после расшифровки проксируются на реальный сервер. Итог - успешный MITM.

Для пользователя, защиты от этого никакой нет. Для владельца домена, формально есть запись CAA, и даже можно разрешить выпуск сертификатов только при условии, что запрос идет с конкретной учетной записи Let’s Encrypt, идентифицированной по приватному ключу регистрации. Но я не вижу, как это может работать, если DNS-хостинг по факту скомпрометирован и может нарисовать любую CAA-запись вместо настоящей.

Исправление AEP, :

Нет, даже при условии, что Let’s Encrypt играет по всем правилам.

Нигде нет гарантии, что валидацию домена в Let’s Encrypt провел реальный владелец, а не сотрудник DNS-хостинга под нажимом силовиков.

Напоминаю: Let’s Encrypt выдает сертификат, если видит, что сгенерированный им токен оказался доступен или в виде файла, доступного для скачивания по HTTP с защищаемого домена (не наш случай), или в виде DNS TXT-записи в этом домене. Эту запись сотрудники DNS-хостера запросто могут нарисовать и таким образом получить на 146% валидный сертификат. Затем этот сертификат ставится на подконтрольный «кому надо» сервер, подменяется A-запись, и HTTPS-запросы после расшифровки проксируются на реальный сервер. Итог - успешный MITM.

Для пользователя, защиты от этого никакой нет. Для владельца домена, формально есть запись CAA, и даже можно разрешить выпуск сертификатов только при условии, что запрос идет с конкретной учетной записи Let’s Encrypt, идентифицированной по приватному ключу регистрации. Но я не вижу, как это может работать, если DNS-хостинг по факту скомпрометирован и может нарисовать любую CAA-запись вместо настоящей.

Исходная версия AEP, :

Нет.

Нигде нет гарантии, что валидацию домена в Let’s Encrypt провел реальный владелец, а не сотрудник DNS-хостинга под нажимом силовиков.

Напоминаю: Let’s Encrypt выдает сертификат, если видит, что сгенерированный им токен оказался доступен или в виде файла, доступного для скачивания по HTTP с защищаемого домена (не наш случай), или в виде DNS TXT-записи в этом домене. Эту запись сотрудники DNS-хостера запросто могут нарисовать и таким образом получить на 146% валидный сертификат. Затем этот сертификат ставится на подконтрольный «кому надо» сервер, подменяется A-запись, и HTTPS-запросы после расшифровки проксируются на реальный сервер. Итог - успешный MITM.

Для пользователя, защиты от этого никакой нет. Для владельца домена, формально есть запись CAA, и даже можно разрешить выпуск сертификатов только при условии, что запрос идет с конкретной учетной записи Let’s Encrypt, идентифицированной по приватному ключу регистрации. Но я не вижу, как это может работать, если DNS-хостинг по факту скомпрометирован и может нарисовать любую CAA-запись вместо настоящей.