SSL с сертификатом и без
Речь идет именно по теме данного форума, т.е. по практической безопасности.
Вопрос по использованию SSL, например, через SSH-канал.
Обычно используют два варианта – с использованием заранее сгенерированного сертификата, выложенного на удаленный сервер, и без него.
Первый вариант вроде как сильнее, потому что невозможна MITM.
Но с другой стороны, если сертификат своевременно не менять (что часто так и бывает), то возникает теоретическая опасность его взлома (подбора).
Второй вариант явно слабее, т.к. подвержен MITM, но с другой стороны имеется свое преимущество: ключи меняются в каждом сеансе, т.е. очень часто, и их подбор в каждом сеансе затруднителен.
Отсюда вопрос: какой вариант использования практически безопаснее?
Или разновидность того же вопроса: как долго нужно не менять сертификат, чтобы безопасность канала связи с ним упала до уровня обычного сеансового, без сертификата?
PS. Не нашел из 100 тем по SSL подходящую для моего вопроса, поэтому сорри, открыл новую.
В SSL — пока не взломают сервер и не украдут сертификат. Хотя после этого и смена сертификата не поможет — если сервер кем-то взломан и недоверяем.
Честно говоря, вопрос не совсем понятен. SSH и SSL — разные вещи, в SSH м.б. пароль и ключ, а не сертификат. Может в последних версиях там чего-то и скрестили между ними, не в курсе.
Извиняюсь – я явно запутался в терминологии, хотя нижеописанные процедуры неоднократно тупо выполнял, не задумываясь о сути :)
В-общем, все что написано мною выше, можно зачеркнуть и забыть, а я начну сначала.
Итак, есть удаленный Linux-сервер, на который можно входить по SSH двумя способами:
– по паролю;
– с помощью ключей, сгенерированных по статье SSH: аутентификация с использованием открытого ключа[link1]
Почему управление с помощью этих ключей счтается более стойким (взломостойким), чем по паролю?
Пароли крайне редко содержат хотя бы 128 бит энтропии, их подбор — достаточно распространённая практика. Подбор ключа, напротив, бесперспективен, для получения доступа противнику потребуется, во-первых, скомпрометировать хранящуюся у Вас закрытую часть ключа и, во-вторых, подобрать к ней пароль (если ключ зашифрован).
Так а если я использую програмку pwgen и использую пароли длиной не менее 32 символов, включая буквы, цифры, знаки – и что, все равно слабее ключа?
Нет, это адекватная мера, в пароле такой длины, использующем все печатные ASCII-символы, что-то порядка 200 бит энтропии.
Иными словами, стойкость с паролем с такими характеристиками примерно равна стойкости при использовании ключей?
(кстати, с какими характеристиками они – ключи, должны быть в этом случае?)
И получается, можно спокойно пользоваться системой "мощных" паролей, не заморачиваясь генерацией ключей?
Аутентификация по ключам – надежнее паролей. А ключ с надежным паролем – еще надежнее. А если еще и менять их иногда через ssh-keygen -p – еще надежнее)
А нет ли каких нибудь других подвохов, снижающих практическую стойкость такого "парольного" канала SSH, несмотря на то, что стойкость его пароля сопоставима со стойкостью ключей?
Чем, конкретно? Хотелось бы числовых доказательств (например, как привел SATva).
Понятно, но хотелось бы остановиться в разумных границах (а не рекордов криптостойкости).
При чем тут цифры? Аутентификация по паролю, который если не сбрутить, то можно увести кейлоггером, подсмотреть и тд. Или же по ключу и паролю? Что надежнее? Как ты скомпрометируешь свой ключ? Его невозможно украсть, даже если взломан сервер, вся криптомагия заключается в том, что ключ не передается на сервер при авторизации, а клиент "доказывает" серверу, что владеет ключом.
UPD. Ну и это, fail2ban поставь, если решишь все-таки обойтись только паролями.
В поиске истины не доверяю эмоциям. Цифры намного надежнее.
А fail2ban да, стоит изначально, но не в нем суть – см. строку выше.
Есть. Можно порыться в этом[link2] треде и обратить внимание на другое обсуждение с этим[link3] комментарием. Деталей не помню, но если рассматривать компрометацию сервера и MTIM, в ряде случаев ключ предпочтительнее, потому что при парольной аутентификации может утечь пароль. Ещё при аутентификации по ключу шифрование всегда идёт случайно выработанным сеансовым ключом, а вот как оно при аутентификации по паролю — надо смотреть.
Рессу не слушай, он здесь за местного шута: часть советов полезные, часть вредные, часть бесполезные, и ещё часть плохо сформулированные. Разбирать внимательно, что он написал, и где там правда, а где ложь — смысла нет, проще просто игнорировать.
Можно сгенерировать один и тот же закрытый ключ и заверять им свою аутентификацию на разных серверах. Если один из серверов взломают, то ваш закрытый ключ (и пароль для его локальной расшифровки) от этого сам по себе никак не будет скомпрометирован и вы можете продолжать его использовать на других серверах. Т.е. безопасность на других серверах от взлома одного из них не пострадает, если вам только не нужна ещё и псевдонимность между ними, то тогда пострадает только псевдонимность.
А теперь представьте, что вы не используете ключ, но по ошибке ввели пароль от одного сервера на другой сервер, а он оказался взломанным и собирает все пароли, которыми на него пытаются зайти. Не говоря уже про случай использования одного пароля на разные сервера.
Ключом вы подписываете только сеансовый рэндом, ранее подписанный сервером, для подтверждения своей аутентификации. В отличие от пароля, закрытая часть ключа не утекает на сервер, он получает от вас только подпись сеансовых параметров.
Кроме того, на один логин можно повесить несколько ключей, дать кому то временный доступ от имени другого пользователя, а затем убрать его ключ. Или для какого-то ключа выполнять определённую команду при входе, команды прописываются прямо в ssh/authorized_keys. Больше опций при желании.
Получается, куда ни кинь – всюду ключ надежнее.
Спасибо всем большое за столь понятные и убедительные разъяснения!
Пожалуйста, приходите ещё.
Кстати, когда создаётся аккаунт для использования с SSH-ключом, обычного пароля (например, для локального входа) у него может вообще не быть.