Безопасная-безопасная оболочка

Возможно, вы слышали, что криптоаналитики могут расшифровать SSH по крайней мере иногда. Если нет, то прочитайте последнюю партию документов Сноудена о SSH и прочих технологиях шифрования. Эта статья всё ещё будет здесь, когда вы закончите с ними. Моя цель с этим постом здесь, чтобы вы знали о том, что они делают и как ваши SSH сессии могут стать безопаснее.

puffy

TL;DR (Много букв): переходите к части "Практика".

Читая документы, у вас может создаться предположение, что заинтересованные лица могут 1) расшифровывать слабую криптографию и 2) воровать ключи. Давайте сосредоточимся на слабой криптографии. SSH поддерживает различные алгоритмы обмена ключами, шифры и коды аутентификации сообщений. Сервер и клиент выбирают набор алгоритмов, поддерживаемых обоими, а затем продолжают обмен ключами. Некоторые из поддерживаемых алгоритмов не столь безопасны и должны быть отключены полностью. Это навредит совместимости с другими SSH серверами, но всё равно почти все использует современные версии OpenSSH. К счастью, использование атаки на понижение поддерживаемых алгоритмов (downgrade attack) не представляется возможным, так как поддерживаемые алгоритмы включены в процесс обмена ключами. Если человек в посередине (Man-In-The-Middle) изменяет списки, то сервер и клиент будут вычислять разные ключи.

Теория:

Обмен ключами

Есть два основных способа сделать обмен ключами: алгоритм Диффи-Хеллмана и алгоритм Диффи-Хеллмана с использованием эллиптических кривых. Оба обеспечивают совершенную прямую секретность, которая очень осложняет жизнь заинтересованным лицам, потому что они не могут использовать пассивный сбор и восстановление ключей позже. Сервер и клиент будет в конечном итоге с общим секретом в конце, пассивные подслушивающие элементы не будут знать секрет. После того, как у нас есть общий секрет, мы должны получить криптографический ключ от функции формирования ключа. В случае SSH, это хэш-функция. Коллизии хеш-функции для SSH уже были доказаны.

OpenSSH поддерживает 8 алгоритмов обмена ключами:

  1. curve25519-sha256: ECDH over Curve25519 with SHA2
  2. diffie-hellman-group1-sha1: 1024 bit DH with SHA1
  3. diffie-hellman-group14-sha1: 2048 bit DH with SHA1
  4. diffie-hellman-group-exchange-sha1: Custom DH with SHA1
  5. diffie-hellman-group-exchange-sha256: Custom DH with SHA2
  6. ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
  7. ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
  8. ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2

Тут нам стоит принять во внимание три вещи:

  • Выбор кривой для ECDH: Это устраняет 6-8 потому что кривые NIST сосут. Через них может утечь секрет через атаки по времени (timing side channels) и ввод вне кривой (off-curve input). Также, NIST считается вредным.
  • Размер DH модулей: Это устраняет 2, потому что заинтересованные лица имеют суперкомпьютеры и, возможно, неизвестные атаки. DH 1024 bit не считается безопасным в настоящее время.
  • Безопасность хеш-функции: Это устраняет 2-4, потому что SHA1 сломан. Лучше не ждать очередной аттаки, которая позволит вычислить коллизию на смартфоне за 10 минут, а не пользоваться SHA1.

В итоге мы остались с 1 и 5 алгоритмами. 1 лучше из-за того что Curve25519 признана безопасной, не имеет статичных параметров в реализации OpenSSH и в целом быстрее. Можно использовать 5 алгоритм для совместимости с WinSCP и прочими.

Аутентификация сервера

Сервер доказывает свою идентичность клиенту подписывая ключ получающийся после обмена ключами.
Есть 4 алгоритма обмена публичными ключами:

  1. DSA with SHA1
  2. ECDSA with SHA256, SHA384 or SHA512 depending on key size
  3. Ed22519 with SHA512
  4. RSA with SHA1

DSA ключи должны быть строго 1024 бит так что отлючим их.
Номер 2 включает в себя сосущий NIST и тоже должен быть отключен.
Другим важным недостатком DSA и ECDSA является то, что они используют случайные номера для каждой подписи. Если случайные номера не обладали лучшей энтропией, то можно восстановить секретный ключ.
К счастью, RSA с использованием SHA1 не является проблемой здесь, потому что значение для подписывания на самом деле будет SHA2 хэшем. Здесь хеш-функция SHA1(SHA2(x)) почти такая же по безопасности как и SHA2 (меньше бит конечно, но нет лучших атак).
Это также отключит сломаный протокол v1 который вы никогда не должны использовать.

Симметричные шифры

Симметричные шифры используются для шифрования данных, после того, как начальный обмен ключами и аутентификация завершена.
Здесь мы имеем довольно много алгоритмов:

  1. 3des-cbc
  2. aes128-cbc
  3. aes192-cbc
  4. aes256-cbc
  5. aes128-ctr
  6. aes192-ctr
  7. aes256-ctr
  8. aes128-gcm@openssh.com
  9. aes256-gcm@openssh.com
  10. arcfour
  11. arcfour128
  12. arcfour256
  13. blowfish-cbc
  14. cast128-cbc
  15. chacha20-poly1305@openssh.com

Мы должны принять во внимание следующее:

  • Безопасность алгоритма шифрования: Это устраняет 1 и 10-12 - так как DES и RC4 сломаны. Опять же, не нужно ждать, чтобы они стали еще слабее, лучше отключить их сейчас.
  • Размер ключа: По крайней мере 128 бит, чем больше тем лучше.
  • Размер блока: Не относится к потоковым шифрам. По крайней мере 128 бит. Это устраняет 13 и 14, потому что те имеют 64-битный размер блока.

Имитовставка (Message authentication codes)

Шифрование обеспечивает конфиденциальность, код аутентификации сообщения обеспечивает целостность. Нам нужно и то, и другое.
Если используется шифр режима AE, то MAC не используются, целостность уже есть. Если используется CTR, то нам нужен MAC, чтобы вычислить и прикрепить метку к каждому сообщению.
Есть несколько способов, чтобы объединить шифры и MAC - далеко не все из них полезны. 3 наиболее распространенные:

Encrypt-then-MAC: зашифровать сообщение, затем прикрепить MAC зашифрованного текста
MAC-then-encrypt: прикрепить MAC незашифрованного текста, затем всё зашифровать.
Encrypt-and-MAC: зашифровать сообщение, затем прикрепить MAC незашифрованного текста.

Надо использовать только Encrypt-then-MAC и точка.
Использование MAC-then-encrypt привёло к атакам на TLS, когда Encrypt-and-MAC привёло к не такому и большому количеству атак на SSH. Причина этого в том, что чем больше вы носитесь с сообщением которое передал вам атакующий, тем больше шансов что атакующий добудет информацию через сторонние каналы (side-channels). В случае Encrypt-then-MAC, MAC проверяется, и если он неправильный, отклоняется. Бум, один шаг, больше никаких атак стороннего канала по времени. В случае MAC-then-encrypt, сначала сообщение отправленное атакующим должно быть расшифровано и только тогда вы можете проверить его. Ошибка дешифрования (из-за неправильного CBC padding для примера) может занять меньше времени чем ошибка проверки. Encrypt-and-MAC также должен сначала быть расшифрован, что ведёт к тому же виду потенциальных атак по сторонним каналам. SSH по умолчанию использует этот метод.

Доступные MAC для выбора:

  1. hmac-md5
  2. hmac-md5-96
  3. hmac-ripemd160
  4. hmac-sha1
  5. hmac-sha1-96
  6. hmac-sha2-256
  7. hmac-sha2-512
  8. umac-64
  9. umac-128
  10. hmac-md5-etm@openssh.com
  11. hmac-md5-96-etm@openssh.com
  12. hmac-ripemd160-etm@openssh.com
  13. hmac-sha1-etm@openssh.com
  14. hmac-sha1-96-etm@openssh.com
  15. hmac-sha2-256-etm@openssh.com
  16. hmac-sha2-512-etm@openssh.com
  17. umac-64-etm@openssh.com
  18. umac-128-etm@openssh.com

Соображения выбора:

  • Безопасность алгоритма хеширования: нет MD5 и SHA1. Да, я знаю, что HMAC-SHA1 не нуждается в сопротивлении коллизиям, но зачем ждать? Отключите слабую криптографию сегодня.
  • Размер метки: по крайней мере 128 бит. Это устраняет ещё umac-64 и umac-64-etm.


Практика:

Клиент и Сервер:
Удаляем старые и генерируем новые, надёжные модули:

# rm /etc/ssh/moduli
# ssh-keygen -G /etc/ssh/moduli.all -b 4096
# ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
# mv /etc/ssh/moduli.safe /etc/ssh/moduli
# rm /etc/ssh/moduli.all

Клиент:

/etc/ssh/ssh_config

HashKnownHosts yes
Host github.com
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-128-etm@openssh.com,hmac-sha2-512
Host *
  ConnectTimeout 30
  KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
  MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
  Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  ServerAliveInterval 10
  ControlMaster auto
  ControlPersist yes
  ControlPath ~/.ssh/socket-%r@%h:%p

Генерируем безопасные ключи:

$ ssh-keygen -t ed25519 -o -a 100
$ ssh-keygen -t rsa -b 4096 -o -a 100

Сервер:
/etc/ssh/sshd_config

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Удаляем другие ключи и генерируем новые:

# cd /etc/ssh
# rm ssh_host_*key*
# ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
# ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Ваши скрипты могут их заново сгенерировать, если вы этого не хотите, уберите ssh-keygen команды из ваших стартовых скриптов.

Источник: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Ваша оценка: Нет Средняя оценка: 5 (6 votes)

Полезная статья, спасибо за него!)

Кстати, развитие квантовых вычислений потихоньку делает все эти алгоритмы ненадёжными. Кто знает, может в недрах спецслужб уже имеется парочка другая квантовых вычислителей?

Ваша оценка: Нет Средняя оценка: 5 (1 vote)

+1 Отличная статья, прочел с удовольствием.

dk

Ваша оценка: Нет Средняя оценка: 5 (1 vote)

Не понял, теперь и ssh нельзя доверять?

Ваша оценка: Нет Средняя оценка: 3 (2 votes)

Класс! Теперь надо мне только ssh.exe чтобы заработало!)

Ваша оценка: Нет Средняя оценка: 1 (1 vote)

Я бы кардинальнее подошел:

sudo apt-get purge windows
sudo apt-get install linux
Ваша оценка: Нет Средняя оценка: 5 (5 votes)

A PuTTY.exe для кого?

Ваша оценка: Нет

Статья интересная, но так и не понятно чем виндус хуже линукса и наоборот :)

Ваша оценка: Нет Средняя оценка: 1 (4 votes)

Внезапно, годная статья на либератуме. Автору респект.

Ваша оценка: Нет Средняя оценка: 3.3 (4 votes)
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.