articles/securing_ssh.texi

   1 @node Безопасный SSH
   2 @section Безопасный SSH
   3
   4 Данная статья -- попытка дополнить уже существующую относительно грамотную
   5 @url{https://stribika.github.io/2015/01/04/secure-secure-shell.html, Secure Secure Shell }.
   6 Но только относительно грамотную: некоторые вещи не являются правдой
   7 и поэтому часть рекомендаций не годна.
   8
   9 @strong{Несогласия}
  10
  11 Сразу же приведу список того с чем не согласен, для тех кто знаком со
  12 статьёй или её сутью:
  13
  14 @itemize
  15 @item Мало затронута тема аутентификации сервера
  16 @item
  17 DES -- сломан, но не 3DES. Если уровень безопасности в 112 бит
  18 достаточен, то его использование приемлемо (если закрыть глаза на
  19 низкую производительность)
  20 @item
  21 RC4/Arcfour имеет особенности из-за которых некоторые реализации
  22 действительно можно считать сломанными. При **правильном** использовании
  23 Arcfour обладает хорошей силой и производительностью. OpenSSH
  24 реализовал этот алгоритм правильно: отбрасывается первые 1536 байт его
  25 выхода, разные не связанные между собой ключи. При своей
  26 производительности в контексте OpenSSH можно рассматривать к
  27 применению
  28 @item
  29 С какой стати размер блока шифра должен быть хотя бы 128 бит? Это
  30 действительно позволяет реже перегенерировать ключи шифрования, но
  31 кроме этой особенности в этом размере нет ничего страшного. Кроме
  32 того, автор выкинул CAST, но оставил Blowfish, хотя у него размер
  33 блока тоже в 64 бит
  34 @item
  35 Конечно дело паранойи и недоверия, но даже скептики типа Брюса Шнайера
  36 не видят особый смысл использования 256 бит ключей против 128. В AES-е
  37 безопасность пусть и 126.5 бит, но IMHO даже этого достаточно
  38 @item
  39 Автор так не доверяет NIST-овским кривым, но к AES не имеет никакого
  40 предвзятого отношения. Для меня это странно
  41 @item
  42 Почему-то полностью исключены UMAC алгоритмы MAC. И почему размер
  43 подписи должен быть не менее 128 бит. Если алгоритм MAC использует
  44 nonce-ы (например счётчик) на входе, то нет смысла встраивать эту
  45 информацию в сам тэг и при достаточно частой смене ключей
  46 аутентификации безопасность коротких тэгов вне сомнений (а это
  47 существенная экономия трафика, ведь с каждым сообщением добавляется
  48 этот тэг). UMAC их позволяет делать и, как правило, значительно быстрее
  49 HMAC. Poly1305 это как-раз разновидность UMAC
  50 @end itemize
  51
  52 @strong{Проблема}
  53
  54 Собственно почему всё это пишется. Эдвард Сноуден раскрыл
  55 @url{https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html, документы}
  56 в которых упоминается что у спецслужб есть возможность прослушивать SSH.
  57 Как они это делают:
  58
  59 @itemize
  60 @item получают долгоживующие асимметричные ключи с серверов или у пользователей
  61 @item дешифруют слабую криптографию
  62 @end itemize
  63
  64 Под слабой криптографией подразумевается и действительно устаревшая, в
  65 которой в ходе многих лет криптоанализа нашли уязвимости, и та к которой
  66 приложили руку эти самые спецслужбы. Сноуден продемонстрировал что
  67 лазейки в алгоритмах они для себя
  68 @url{https://projectbullrun.org/dual-ec/vulnerability.html, сделали},
  69 чем и пользуются.
  70
  71 Криптография это не только чисто математическая и техническая область.
  72 Огромный вес имеет доверие, репутация, даже политика. В данной статье
  73 предлагается настроить SSH сервер и клиент так, чтобы исключить слабую
  74 недоверяемую криптографию.
  75
  76 @strong{Аутентификация сервера}
  77
  78 Первым делом после установки TCP соединения SSH необходимо убедиться что
  79 на другом конце тот самый сервер который мы и ожидаем увидеть. То бишь
  80 аутентифицировать его. К сожалению SSH не поддерживает алгоритмы
  81 одновременной аутентификации и обмена ключами, хотя существуют алгоритмы
  82 даже двустороннего аутентифицированного обмена ключами. Но это лишь
  83 вопрос деградации производительности и трафика. Существуют патчи
  84 добавляющие SRP (двусторонний аутентифицированный обмен ключами), но его
  85 нет в mainline версиях OpenSSH.
  86
  87 SSH предоставляет следующие алгоритмы:
  88
  89 @itemize
  90 @item @code{ecdsa-sha2-nistp256}
  91 @item @code{ecdsa-sha2-nistp256-cert-v01@@openssh.com}
  92 @item @code{ecdsa-sha2-nistp384}
  93 @item @code{ecdsa-sha2-nistp384-cert-v01@@openssh.com}
  94 @item @code{ecdsa-sha2-nistp521}
  95 @item @code{ecdsa-sha2-nistp521-cert-v01@@openssh.com}
  96 @item @code{ssh-dss}
  97 @item @code{ssh-dss-cert-v00@@openssh.com}
  98 @item @code{ssh-dss-cert-v01@@openssh.com}
  99 @item @code{ssh-ed25519}
 100 @item @code{ssh-ed25519-cert-v01@@openssh.com}
 101 @item @code{ssh-rsa}
 102 @item @code{ssh-rsa-cert-v00@@openssh.com}
 103 @item @code{ssh-rsa-cert-v01@@openssh.com}
 104 @end itemize
 105
 106 Итого это либо: RSA, либо DSS (вариант DSA), ECDSA (DSA на основе
 107 эллиптических кривых), Ed25519. DSS/DSA отпадают, так как стандартом
 108 определены длины ключей только размеров в 1024 бит, а этого уже
 109 недостаточно. ECDSA варианты отпадают так как используют кривые
 110 созданные NIST-ом и в них уже найдены
 111 @url{http://safecurves.cr.yp.to/, уязвимости}.
 112
 113 Ed25519 это вне всяких сомнений лучший вариант: алгоритм подписей на
 114 основе эллиптических кривых, создан Дэниелем Бернштайном (независим от
 115 госорганизаций, корпораций, великолепный математик, криптограф,
 116 программист, хакер), работает за константное время, очень быстрый код,
 117 256 бит размер ключей.
 118
 119 RSA сам по себе хуже только тем что сложнее реализовать (хотя в OpenSSH
 120 с этим проблем нет) и он во много раз медленнее и размеры подписей с
 121 публичными ключами занимают в разы больше места. Плюс никто не
 122 гарантирует что RSA ключи на сервере/клиенте будут сгенерированы
 123 достаточной длины.
 124
 125 Мои предпочтения:
 126
 127 @verbatim
 128 HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,
 129                   ssh-ed25519,
 130                   ssh-rsa-cert-v01@openssh.com,
 131                   ssh-rsa-cert-v00@openssh.com,
 132                   ssh-rsa
 133 @end verbatim
 134
 135 @strong{Обмен ключами}
 136
 137 После того как мы убедились что на другом конце тот кто нам нужен, то
 138 дальше необходимо установить (обменяться) ключи которые будут
 139 использоваться для шифрования и аутентификации сообщений. Этот этап за
 140 всё время сессии SSH может быть выполнен лишь один раз, но от него может
 141 зависеть абсолютно вся безопасность, так как не важно какой силы у вас
 142 алгоритм симметричного шифрования если ключи утекут на этапе обмена.
 143
 144 Для обмена ключами используется асимметричный алгоритм Диффи-Хеллмана:
 145 самый первый в мире, революционный, асимметричный алгоритм. OpenSSH
 146 предоставляет следующие варианты:
 147
 148 @itemize
 149 @item @code{curve25519-sha256@@libssh.org}
 150 @item @code{diffie-hellman-group-exchange-sha1}
 151 @item @code{diffie-hellman-group-exchange-sha256}
 152 @item @code{diffie-hellman-group1-sha1}
 153 @item @code{diffie-hellman-group14-sha1}
 154 @item @code{ecdh-sha2-nistp256}
 155 @item @code{ecdh-sha2-nistp384}
 156 @item @code{ecdh-sha2-nistp521}
 157 @end itemize
 158
 159 ECDH это Диффи-Хеллман на эллиптических кривых, значительно более
 160 быстрый, но опять же использует NIST-овские кривые. Исключается.
 161 @code{diffie-hellman-group1-sha1} тоже исключается так как размер модуля
 162 группы DH 1024 бита. @code{diffie-hellman-group-exchange-} позволяет
 163 варьировать размеры группы от мала до велика: конкретные значения
 164 необходимо настроить (убрать маленькие) на сервере. Ну и SHA1 лучше
 165 перестать использовать совсем.
 166
 167 Curve25519 схож с Ed25519. Обладает всеми теми же свойствами. Очень
 168 быстрый (вроде даже самый быстрый среди на практике используемых
 169 безопасных алгоритмов DH на основе эллиптических кривых), простой в
 170 коде, 256 бит размер ключей. Вне всякой конкуренции: он лучший.
 171
 172 К сожалению многие серверы не поддерживают ни curve25519, ни даже все
 173 остальные DH.
 174
 175 Мои предпочтения:
 176
 177 @verbatim
 178 KexAlgorithms curve25519-sha256@libssh.org,
 179               diffie-hellman-group-exchange-sha256,
 180               diffie-hellman-group-exchange-sha1,
 181               diffie-hellman-group14-sha1
 182 @end verbatim
 183
 184 @strong{Шифрование}
 185
 186 После того как ключи установлены, то можно уже начинать и само
 187 шифрование -- то самое что гарантирует нам конфиденциальность. В отличии
 188 от этапа аутентификации и обмена ключами: производительность в данном
 189 контексте уже играет очень существенную роль. Одно дело получить на
 190 одном ядре процессора возможность передавать данные со скоростью
 191 гигабит, а другое дело еле-еле вытягивать несколько десятков мегабит.
 192
 193 @itemize
 194 @item @code{3des-cbc}
 195 @item @code{aes128-cbc}
 196 @item @code{aes128-ctr}
 197 @item @code{aes128-gcm@@openssh.com}
 198 @item @code{aes192-cbc}
 199 @item @code{aes192-ctr}
 200 @item @code{aes256-cbc}
 201 @item @code{aes256-ctr}
 202 @item @code{aes256-gcm@@openssh.com}
 203 @item @code{arcfour}
 204 @item @code{arcfour128}
 205 @item @code{arcfour256}
 206 @item @code{blowfish-cbc}
 207 @item @code{cast128-cbc}
 208 @item @code{chacha20-poly1305@@openssh.com}
 209 @item @code{rijndael-cbc@@lysator.liu.se}
 210 @end itemize
 211
 212 3DES: усиленная версия DES алгоритма, обладающая 112 бит силой. В
 213 принципе использовать можно если такой силы достаточно, однако не
 214 рекомендуется из-за безумно медленной скоростью работы. Ну и среди всех
 215 остальных алгоритмов эти 112 бит -- наименьшая безопасность.
 216
 217 Arcfour (также известный как RC4): потоковый шифр, очень быстрый
 218 относительно многих других. Имеет много особенностей и проблем с
 219 правильным использованием. Настолько много что его рекомендуют никогда
 220 не применять. Говорить что он совсем сломан и не юзабелен я бы не стал,
 221 но рекомендовать его тоже не стоит.
 222
 223 CAST128 -- предшественник одного из финалистов конкурса AES, одобрен к
 224 использованию на государственном уровне в Канаде (читай: канадский ГОСТ).
 225 Каких-то критичных недостатков вроде не имеет, но и производительностью
 226 или чем-то другим интересным не выделяется.
 227
 228 Rijndael -- финалист конкурса AES. Честно говоря, не знаю разницы в
 229 OpenSSH между этим Rijndael и AES. Возможно это оригинальная не
 230 ослабленная AES версия алгоритма.
 231
 232 AES -- известный, популярный, полно где применяющийся алгоритм. За
 233 десятки лет имеет много криптоанализов. Может смущать что это
 234 ослабленная версия Rijndael (для повышения производительности, как
 235 официально заявляется), но многие годы анализов не выявили атак которые
 236 бы призвали его в негодность. Брюс Шнайер, Дэниель Бернштайн доверяют
 237 этому алгоритму. Хотя у него и имеются проблемы в реализациях: ключи
 238 например могут утекать через кэш процессоров современных. Да и сама
 239 реализация не такая уж простая в коде. В любом случае это очень неплохой
 240 компромисс между безопаснотью/сложностью и производительностью.
 241
 242 Blowfish -- старый, хорошо известный (проанализированный) алгоритм
 243 созданный Брюсом Шнайером. Независимость от госструктур, хорошо
 244 проанализированный, имеющий неплохую производительность. Если есть
 245 недоверие к AES, то я бы рекомендовал.
 246
 247 В AES есть три варианта: CBC, CTR, GCM. Это разные режимы шифрования. Не
 248 вдаваясь в подробности: в SSH выявлена уязвимость при которой можно
 249 получить до 32 бит открытого текста (дешифровать его то бишь).
 250 Необходимо либо обновить SSH-сервер, либо как контрмера простая: не
 251 использовать CBC режим. Сам CBC не имеет уязвимостей: это лишь в
 252 контексте SSH у него есть такой недостаток. Даже если SSH у вас свежий,
 253 то CBC всё-равно не рекомендовал бы: для его сообщений требуется
 254 дополнение (увеличение трафика) и его вычисления нельзя распараллелить.
 255 CTR (режим счётчика): можно распаралаллелить вычисления, не требует
 256 дополнения. GCM: относительно недавно введённый режим
 257 аутентифицированного шифрования (поэтому не во всех SSH-релизациях
 258 встретится) -- то есть одновременно сразу же при шифровании производится
 259 и вычисление аутентифицирующего тэга. Очень сильно подкупает то, что GCM
 260 в современных x86-процессорах имеет аппаратное ускорение. Даже без него
 261 не требует как и CTR дополнения, может быть распараллелен.
 262
 263 ChaCha20-Poly1305: опять же вне конкуренции это лучший вариант. ChaCha20
 264 алгоритм потокового шифра (более быстрый вариант Salsa20) совмещённый с
 265 Poly1305 алгоритмом аутентификации. Созданы опять же Дэниелем
 266 Бернштейном, не имеет хоть сколько-то серьёзных выявленных проблем в
 267 безопасности, очень просты в реализации (менее 100 строк кода на C),
 268 имеют фантастическую производительность: они быстрее аппаратно
 269 ускоренного AES-GCM. То есть более надёжный, более безопасный, более
 270 быстрый чем аппаратно ускоренный AES алгоритм аутентифицированного
 271 шифрования.
 272
 273 Вопрос размера ключа шифрования скорее религиозный, вопрос доверия. В
 274 принципе 128 бит достаточно. AES-128 имеет 126.5 порог безопасности. По
 275 мне так и этого достаточно. 256 бит лично я бы выбрал, если бы не сильно
 276 деградировала производительность. Кстати, ChaCha20 имеет 256 бит ключ и
 277 она даже при этом быстрее AES-128.
 278
 279 Мои предпочтения:
 280
 281 @verbatim
 282 Ciphers chacha20-poly1305@openssh.com,
 283         aes128-gcm@openssh.com,
 284         aes128-ctr,
 285         blowfish-cbc
 286 @end verbatim
 287
 288 @strong{Аутентификация сообщений}
 289
 290 Зашифрованные сообщения могут быть при передаче изменены. Изменение
 291 шифрованного текста может приводить к осознанному изменению открытого
 292 текста после дешифрации. Передавать неаутентифицированные сообщения
 293 нельзя никогда. Кроме того необходима проверка их целостности. OpenSSH
 294 предоставляет следующие алгоритмы:
 295
 296 @itemize
 297 @item @code{hmac-sha1}
 298 @item @code{hmac-sha1-96}
 299 @item @code{hmac-sha2-256}
 300 @item @code{hmac-sha2-512}
 301 @item @code{hmac-md5}
 302 @item @code{hmac-md5-96}
 303 @item @code{hmac-ripemd160}
 304 @item @code{hmac-ripemd160@@openssh.com}
 305 @item @code{umac-64@@openssh.com}
 306 @item @code{umac-128@@openssh.com}
 307 @item @code{hmac-sha1-etm@@openssh.com}
 308 @item @code{hmac-sha1-96-etm@@openssh.com}
 309 @item @code{hmac-sha2-256-etm@@openssh.com}
 310 @item @code{hmac-sha2-512-etm@@openssh.com}
 311 @item @code{hmac-md5-etm@@openssh.com}
 312 @item @code{hmac-md5-96-etm@@openssh.com}
 313 @item @code{hmac-ripemd160-etm@@openssh.com}
 314 @item @code{umac-64-etm@@openssh.com}
 315 @item @code{umac-128-etm@@openssh.com}
 316 @end itemize
 317
 318 Тут у SSH выявляется критически важный недостаток первоначальных
 319 реализаций. Подписать и зашифровать сообщение можно в разных порядках:
 320
 321 @itemize
 322 @item зашифровать, потом добавить подпись зашифрованного сообщения
 323 @item добавить подпись открытого сообщения, потом зашифровать всё это
 324 @item зашифровать, потом добавить подпись открытого сообщения
 325 @end itemize
 326
 327 Первый вариант делает IPsec, второй TLS, третий SSH. Вариант SSH
 328 категорически нельзя применять. Вариант TLS может быть атакован, что и
 329 сделали в BEAST атаке. Вариант IPsec (Encrypt-then-MAC) всегда правилен
 330 и только так и должен применяться. Половину доступных алгоритмов в
 331 OpenSSH имеют приписку etm (Encrypt-then-MAC) и только они и должны
 332 всегда использоваться. К сожалению многие SSH серверы всё ещё не
 333 обновляются и не поддерживают их.
 334
 335 Как я уже говорил в начале, короткие 64-бит тэги вполне приемлемы если
 336 правильно реализованы. Они быстрее вычисляются и меньше трафика едят.
 337
 338 UMAC появился позже HMAC-ов, но пока не имеет недостатков в безопасноти.
 339 Зато имеет преимущество в виде высокой скорости работы зачастую.
 340
 341 Остальные HMAC отличаются только используемой хэш-функцией. MD5 реально
 342 сломан, но в контексте HMAC он вполне себе годный к использованию. SHA1
 343 уже не рекомендуется, но он тоже годен. Если очень важна
 344 производительность, то конечно HMAC-MD5 будет быстрее всех. Но я бы как
 345 и автор статьи рекомендовал бы не поддерживать криптографию от которой
 346 реально надо бы избавляться. Завтра не исключено что найдут ещё более
 347 серьёзную уязвимость в MD5/SHA1 и HMAC-MD5/SHA1 которая их сразу же
 348 приведёт в негодность, а трафик уже был перехвачен и записан нехорошими
 349 людьми.
 350
 351 RIPEMD-160 создан в академических кругах, независимо от госструктур. Не
 352 имеет применимых криптоатак. Имеет 160 бит хэш, более короткий чем у
 353 SHA2, а значит экономящий трафик.
 354
 355 SHA2 уже тоже не советуется к применению. Обладает пока достаточной
 356 криптографической силой, но он гораздо более медленный чем все
 357 остальные.
 358
 359 Подчеркну что отдельный этап аутентификации сообщений, MAC, не
 360 применяется если мы уже использовали аутентифицированный режим
 361 шифрования. То есть GCM режим это уже применение аутентификации, так же
 362 как и Poly1305 это тоже чисто режим аутентификации (кстати это
 363 разновидность UMAC). Поэтому данная настройка не играет никакой роли для
 364 подобных шифров.
 365
 366 Мои предпочтения (вынужден добавлять и не @code{-etm} версии из-за кучи
 367 не обновлённых серверов):
 368
 369 @verbatim
 370 MACs umac-64-etm@openssh.com,
 371      umac-128-etm@openssh.com,
 372      hmac-ripemd160-etm@openssh.com,
 373      hmac-sha2-256-etm@openssh.com,
 374      hmac-sha2-512-etm@openssh.com,
 375      umac-64@openssh.com,
 376      umac-128@openssh.com,
 377      hmac-ripemd160,
 378      hmac-sha2-256,
 379      hmac-sha2-512
 380 @end verbatim
 381
 382 @strong{Общие рекомендации}
 383
 384 @itemize
 385 @item Используйте сильную парольную фразу для ваших клиентских ключей
 386 @item Шифруйте диск где находятся ключи сервера
 387 @item
 388 Используйте только свободного программное обеспечение, проверенные
 389 временем и криптоанализами алгоритмы шифрования и, что важнее, их
 390 реализацию
 391 @item
 392 Следите за security обновлениями
 393 @item
 394 Не добавляйте то чего можно не добавлять. Каждая лишняя строчка кода
 395 это лишний повод появиться уязвимости. Не обновляйтесь ради обновления
 396 @end itemize
 397
 398 @copyright{} Сергей Матвеев