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