Erlang/OTP 29: безпечний SSH і гібридна постквантова криптографія

Erlang/OTP 29 посилює безпечні defaults: SSH daemon більше не відкриває shell, exec і SFTP автоматично, а TLS віддає перевагу гібридному постквантовому обміну ключами x25519mlkem768. Паралельно компілятор і xref допомагають знаходити небезпечні або недокументовані виклики.

SSH daemon тепер виходить із принципу secure by default

Раніше запуск SSH daemon міг ненавмисно відкрити можливість виконання команд для автентифікованого користувача. В OTP 29 shell та exec services вимкнено за замовчуванням, так само не вмикається SFTP subsystem. Якщо система справді надає ці функції, їх потрібно оголосити явно.

Безпечна зміна може зламати автоматизацію

Внутрішні admin-панелі, release management і legacy-скрипти могли покладатися на попередню поведінку. Перед оновленням знайдіть усі виклики SSH application, перевірте options та integration tests. Не повертайте стару конфігурацію «цілим пакетом»: увімкніть лише потрібну підсистему й обмежте авторизацію.

Загальну стратегію криптографічного переходу доповнює наш матеріал про OpenSSL 3.5 і постквантові алгоритми, а ідентичність сервісів — огляд SPIFFE та SPIRE.

x25519mlkem768 стає пріоритетною TLS-групою

SSL application у типовій конфігурації віддає перевагу гібридній групі, що поєднує класичний X25519 із ML-KEM-768. Гібридний підхід потрібен для збереження звичної криптографічної гарантії навіть у разі майбутньої проблеми одного компонента. Реальна домовленість залежить від підтримки peer, проксі й TLS termination.

Постквантовий handshake треба вимірювати

Нові key shares збільшують обсяг handshake і можуть проявити проблеми в middleboxes, MTU або старих клієнтах. Перевірте успішність negotiation, час встановлення з’єднання, кількість переданих байтів і fallback. Не заявляйте про «постквантову захищеність» усього продукту лише через одну TLS-групу: сертифікати, дані at rest і життєвий цикл ключів оцінюються окремо.

Unsafe attributes формалізують ризиковані функції

OTP 29 додає атрибут -unsafe для позначення функцій, використання яких потребує особливої уваги. Компілятор за замовчуванням попереджає про виклики відомих завжди небезпечних функцій, а xref може знаходити такі виклики та функції без документації. Це корисно для security review великої кодової бази.

Попередження не слід перетворювати на шум

Спочатку зберіть baseline і класифікуйте результати: заміна API, обмежений wrapper, документоване виключення або помилковий сигнал. Якщо просто вимкнути warning у всьому проєкті, нова перевірка втратить цінність. Для monorepo варто поступово піднімати суворість на рівні застосунків.

Major-реліз містить несумісності

Команда Erlang прямо попереджає про певні incompatibilities. Перевірте release notes для ERTS, compiler, stdlib, crypto, ssl, ssh та інструментів, які використовує саме ваш проєкт. Для Elixir-систем необхідно також звірити підтримку OTP у відповідній версії Elixir і native dependencies.

План міграції кластера

1. зберіть застосунок на OTP 29 без оновлення бізнес-залежностей;
2. усуньте нові compiler та xref warnings;
3. перевірте NIF і port drivers на цільовій архітектурі;
4. протестуйте SSH, SFTP та operational tooling;
5. перевірте TLS з усіма зовнішніми peers і балансувальниками;
6. проведіть mixed-version cluster test відповідно до документації вашого release tool;
7. оновлюйте вузли поступово, контролюючи mailbox, scheduler utilization і latency;
8. збережіть перевірений rollback для release та даних.

Що контролювати після розгортання

Окрім помилок, стежте за handshake failures, TLS fallback, scheduler wall time, reductions, garbage collection і ростом mailbox. Безпекові defaults можуть зламати рідко використовуваний operational path, тому перевірте backup, restore, remote console та incident procedures до production-релізу.

Типові помилки оновлення

Небезпечно одночасно змінювати OTP, Elixir, release tool і TLS termination. Також не варто автоматично вмикати всі старі SSH services, щоб «повернути сумісність». Якщо клієнт не домовляється про hybrid key exchange, спочатку дослідіть peer та middlebox, а не вимикайте сучасну групу для всього кластера. Для NIF помилки можуть проявлятися лише під навантаженням.

Критерії завершення міграції

Усі вузли мають працювати на підтримуваній комбінації, compiler/xref findings — бути усуненими або документованими, а SSH і TLS — пройти негативні тести. Mixed-version режим не слід залишати надовго. Команда повинна довести, що може додати новий вузол, вивести старий, відновити release і отримати operational access без повернення небезпечних defaults.

Першоджерела: release notes Erlang/OTP 29.0 та офіційний огляд ключових змін.