Сообщение Re[6]: Почему ssh не использует УЦ? от 05.07.2021 13:08
Изменено 05.07.2021 13:10 vsb
Re[6]: Почему ssh не использует УЦ?
Здравствуйте, netch80, Вы писали:
vsb>>DNSSec требует клиентской конфигурации?
N>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера.
N>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет. Проверять всю криптографию должна конечная программа и никак иначе. Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
vsb>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>Просто X.509 появилась существенно раньше.
Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса.
vsb>>DNSSec требует клиентской конфигурации?
N>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера.
N>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет. Проверять всю криптографию должна конечная программа и никак иначе. Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
vsb>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>Просто X.509 появилась существенно раньше.
Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса.
Re[6]: Почему ssh не использует УЦ?
Здравствуйте, netch80, Вы писали:
vsb>>DNSSec требует клиентской конфигурации?
N>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера.
N>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет. Проверять всю криптографию должна конечная программа и никак иначе. Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
vsb>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>Просто X.509 появилась существенно раньше.
Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса. Так что определённый спрос на такой функционал точно есть. За себя могу сказать, что я бы точно предпочёл этот вариант.
vsb>>DNSSec требует клиентской конфигурации?
N>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера.
N>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет. Проверять всю криптографию должна конечная программа и никак иначе. Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
vsb>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>Просто X.509 появилась существенно раньше.
Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса. Так что определённый спрос на такой функционал точно есть. За себя могу сказать, что я бы точно предпочёл этот вариант.