Постквантовое будущее для Let's Encrypt



Let's Encrypt стремится к созданию устойчивой к постквантовым технологиям инфраструктуры открытых ключей (PKI) для веб-сети. Мы планируем использовать сертификаты на основе дерева Меркла («MTC»), новый подход, который добавляет постквантовую аутентификацию в веб-среду без ущерба для скорости и надежности, благодаря которым TLS стал универсальным протоколом.

В этом посте речь пойдёт об этих планах и о том, почему мы считаем, что MTC (многоканальные телекоммуникационные центры) заслуживают внимания как ключ к постквантовому будущему.

Проблема становится все более актуальной.
В течение последних нескольких лет дискуссия о постквантовой криптографии сводилась к обсуждению шифрования. Логика была проста: злоумышленник, который сегодня записывает зашифрованный трафик, может расшифровать его через несколько лет, когда квантовые компьютеры смогут взломать лежащую в его основе математику. Аутентификация, часть TLS, которая подтверждает, что сервер действительно тот, за кого себя выдает, была менее актуальной проблемой. Квантовому компьютеру необходимо подделывать подпись в реальном времени, а не задним числом, поэтому угрозы аутентификации зависят от существования криптографически значимого квантового компьютера (CRQC).

Этот комфорт постепенно ослабевает. В Соединенных Штатах пакет CNSA 2.0 Агентства национальной безопасности США с 2022 года направляет системы национальной безопасности на внедрение постквантовых алгоритмов в период с 2030 по 2035 год, а проект руководства NIST по переходу предусматривает отказ от RSA-2048 и P-256 после 2030 года и запрет их использования после 2035 года. Дорожная карта Европейского союза нацелена на системы высокого риска к концу 2030 года и на масштабную миграцию к 2035 году. Эти требования не являются прямыми обязательствами для общедоступной инфраструктуры открытых веб-сетей (PKI), но они устанавливают временные рамки на конец десятилетия, к которым уже стремятся поставщики, библиотеки и организации по стандартизации, на которые она опирается.
www.nsa.gov/Cybersecurity/Post-Quantum-Cybersecurity-Resources/
nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

В этом году сроки еще больше сократились. Google объявил о миграции своих сервисов к 2029 году, сославшись на ужесточение оценок потенциального появления CRQC. Cloudflare последовал его примеру, подтвердив аналогичное обязательство. Кроме того, Go 1.27 добавляет в стандартную библиотеку ML-DSA, стандартизированную NIST схему постквантовой подписи, что свидетельствует о том, что постквантовые подписи становятся практичной инфраструктурой.
blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/
blog.cloudflare.com/post-quantum-roadmap/
go.dev/doc/go1.27

Проблема постквантовой аутентификации больше не актуальна для экосистемы Web PKI, и ее следует откладывать. Ключи с длительным сроком службы (корневые центры сертификации, ключи подписи кода, системы идентификации) представляют собой особенно ценные объекты, а для широкого внедрения новых технологий требуются годы, поэтому работу необходимо начинать как можно раньше.

Уникальные особенности веб-PKI
Веб-инфраструктура открытых ключей (PKI) — одно из самых сложных мест для развертывания постквантовых подписей. Причина в её масштабе.

ML-DSA-44, одна из самых компактных схем постквантовой подписи, стандартизированных NIST, имеет подпись длиной примерно 2420 байт. Алгоритмы, используемые сегодня в Web PKI, значительно меньше. Подписи RSA-2048 занимают 256 байт, а подписи ECDSA-P256 — 64 байта. Открытые ключи также больше: 1312 байт для ML-DSA-44, 256 байт для RSA-2048 и 64 байта для ECDSA-P256. Типичное рукопожатие Web PKI сегодня включает пять подписей и два открытых ключа. Замена их на эквиваленты ML-DSA приведет к тому, что одно рукопожатие TLS превысит 10 килобайт. Исследования Cloudflare показали, что при таком масштабе значительная часть TLS-соединений в реальных сетях выходит из строя, а остальные замедляются.

blog.cloudflare.com/another-look-at-pq-signatures/

Увеличение длины рукопожатия повлияет на все TLS-соединения, а не только на те, которые могут завершиться неудачей. Это приведет к ограничению пропускной способности, замедлению соединения и ухудшению пользовательского опыта — и все это в обмен на защиту от угрозы, которая еще не материализовалась. Включение этой функции по умолчанию — это слишком высокая цена, а именно настройки по умолчанию обеспечивают реальный уровень безопасности в масштабах веб-приложений.

Сертификаты дерева Меркла
За последний год появилась новая технология, называемая сертификатами дерева Меркла («MTC»), и мы считаем, что это перспективный путь развития постквантовой инфраструктуры открытых ключей для веб-технологий.

Вместо того чтобы выдавать сертификаты по одному и подписывать каждый из них индивидуально, центр сертификации MTC выдает сертификаты партиями, при этом одна подпись охватывает всю партию. Браузеры получают актуальную информацию об этих подписях партии (называемых «ориентирами») отдельно от рукопожатия TLS.

В типичном случае весь путь аутентификации при рукопожатии MTC состоит из одной подписи, одного открытого ключа и одного подтверждения включения. Это меньше, чем рукопожатие Web PKI, даже несмотря на то, что MTC используют постквантовые алгоритмы. Другой случай — это «автономная» форма. Она использует немного более длинные рукопожатия в качестве резервного варианта, когда контрольная точка клиента устарела.


MTC — это не только оптимизация размера. Поскольку каждый сертификат является частью опубликованного дерева Меркла, прозрачность становится свойством самого процесса выдачи. Современная экосистема прозрачности сертификатов создается постфактум: сертификаты выдаются центрами сертификации, затем регистрируются отдельно, а дополнительные подписи добавляются в процесс установления соединения TLS для подтверждения этой регистрации. В случае с MTC сертификат не может существовать вне дерева Меркла. Прозрачность сертификатов встроена в него.

Для нас это не совсем новая область. Let's Encrypt использует журналы прозрачности сертификатов с 2019 года. Эти журналы представляют собой деревья Меркла с возможностью добавления данных, ту же самую базовую структуру данных, на которой построены MTC, и которую мы используем в производственной среде в больших масштабах уже много лет.
letsencrypt.org/docs/ct-logs/

Cloudflare и Chrome уже проводят экспериментальную проверку возможности использования MTC на реальном интернет-трафике. Рабочая группа PLANTS IETF работает над стандартизацией этого подхода. Chrome объявил, что MTC являются предпочтительным способом добавления постквантовых сертификатов в публичный интернет.
blog.cloudflare.com/bootstrap-mtc/
datatracker.ietf.org/wg/plants/about/

Наши планы
Мы планируем поддерживать сертификаты на основе дерева Меркла как перспективное направление для постквантовой веб-инфраструктуры открытых ключей (PKI). Мы рассчитываем создать тестовую среду для выдачи сертификатов Меркла к концу 2026 года, а готовую к использованию в производственной среде — к 2027 году.

Это непростая задача. Выпуск MTC в масштабах Let's Encrypt требует существенных изменений во всей нашей инфраструктуре: в нашей системе выпуска, в протоколе ACME, который наши подписчики используют для получения сертификатов, в инструментах отзыва и эксплуатации, а также в инфраструктуре журналов прозрачности, которую включают в себя MTC. Мы участвуем в рабочих группах IETF PLANTS и ACME по мере формирования стандартов.

Наряду с работой над MTC, мы отслеживаем стандарты для подписей ML-DSA в X.509 RFC 9881 и TLS draft-ietf-tls-mldsa а также работу в экосистеме, от которой это зависит, например, добавление ML-DSA в стандартную библиотеку Go. Переход веб-PKI к постквантовой безопасности требует, чтобы все это появилось в браузерах, библиотеках и клиентах ACME, независимо от того, будут ли в конечном итоге предоставлены сертификаты MTC или сертификаты X.509, подписанные ML-DSA.
www.rfc-editor.org/rfc/rfc9881
datatracker.ietf.org/doc/draft-ietf-tls-mldsa/

Что это значит, если вы используете Let's Encrypt?
Сегодня ничего не меняется. Ваши текущие сертификаты Let's Encrypt будут по-прежнему выдаваться и продлеваться точно так же, как и всегда. Когда появятся постквантовые сертификаты от Let's Encrypt, они будут предоставляться так же, как и всегда: бесплатно, автоматически и доступны любому пользователю с клиентом ACME.

Переход займет время. Стандарты все еще находятся в стадии доработки, базовые программы еще определяют свои требования, и инженерные работы должны быть интегрированы в более широкую экосистему (браузеры, библиотеки, клиенты ACME), прежде чем все это будет иметь значение в масштабах всей системы. Мы будем держать сообщество в курсе по мере продвижения работы и уточнения сроков.

Если вы используете ACME-клиент или управляете конвейером выдачи сертификатов на основе ACME, сейчас самое время начать отслеживать работу рабочей группы PLANTS и обсуждения в списке рассылки mtcs@chromium.org Некоторые из грядущих изменений потребуют поддержки на стороне клиента, и экосистема выиграет от клиентов, готовых к поддержке на стороне выпуска сертификатов.

Замечание о более широком постквантовом переходе
Для всего интернет-сообщества: постквантовое шифрование — более актуальная проблема, поскольку любое TLS-соединение без постквантового обмена ключами потенциально может быть использовано для последующей расшифровки. Если вы используете серверы, убедитесь, что они поддерживают гибридный постквантовый обмен ключами (X25519MLKEM768). Основные браузеры и операционные системы уже поддерживают его, и включение этой функции на сервере — одно из самых эффективных действий, которые вы можете предпринять в этом году.

В заключение
С 2013 года мы создаём инфраструктуру для общедоступного интернета, исходя из принципа, что безопасность должна быть доступна каждому, автоматически и бесплатно. Квантово-цифровой переход — это смена поколений в том, как эта безопасность работает «под капотом».

Скоро всё починим!



Коротко о ситуации:
Один из дата-центров (nLighten) внезапно, без предупреждения, отключил оборудование MIRhosting в Нидерландах и Германии. Сами ребята из MIRhosting в шоке — такие резкие движения без переходного периода они считают абсолютно неприемлемыми, особенно потому, что под раздачу попали их клиенты (то есть мы с вами).

Что сейчас происходит?
MIRhosting уже нанял юристов, выясняет детали и ищет альтернативные площадки. Их главные задачи прямо сейчас:
  • вернуть доступ к серверам, где это возможно;
  • сохранить всё наше оборудование и данные в целости;
  • быстро найти новую «прописку» для мощностей;
  • держать нас в курсе конкретных шагов.

Наше мнение:
Ситуация, конечно, неприятная, но не смертельная. Мы уже на связи с MIRhosting и будем продавливать самые быстрые решения. Как только появится конкретика по каждому серверу — с кем переезжаем, куда и когда — сразу напишем лично каждому пострадавшему клиенту.

Главное, что хотим сказать:
Мы на вашей стороне, разбираемся и точно найдём выход. Держим руку на пульсе, лишних драматичных писем слать не будем, только факты и готовые варианты решения.

Спасибо за терпение и доверие. Скоро всё починим!

https://ruweb.net

Локации NL и DE готовятся к переезду в другой датацентр



На данный момент нет большого количества новостей.
Готовимся к переезду в другой датацентр. Краткая история: поставщика услуг преследует новостной фон, из-за которого датацентр решил в одностороннем порядке ограничить доступ к оборудованию. Насколько видим, несколько других хостинг-провайдеров также столкнулись с этим.
Для всех услуг будет добавлена компенсация как только запустим все услуги.
Затрагивает только NL и DE. Другие локации не относятся к поставщику.

We don’t have a lot of news here yet.
Preparing for a migration to another data center. Brief background: the service provider is dealing with negative press coverage, due to which the data center decided to unilaterally restrict access to the equipment. As we can some other hosting providers are also dealing with the same issue.
Compensation will be added to all services as soon as we start all services in both regions.
Affects only NL and DE regions. Other locations are not related to the datacenter services provider.

Технические работы в нескольких локациях



В связи с прекращением деятельности нашего апстрим-провайдера в ряде европейских локаций, мы вынуждены провести миграцию ваших VPS на временные площадки:

Работы затронут следующие страны: Бельгия, Греция, Ирландия, Латвия, Северная Македония, Хорватия. — VPS из данных стран будут временно мигрированы в другую локацию.

В период с сегодняшнего дня по пятницу включительно в этих локациях возможны временные сбои в работе VPS, а также кратковременная недоступность серверов в связи с процессом миграции.

Прямо сейчас пожалуйста создайте резервные копии (бекапы) всех важных данных на ваших VPS. А также сохраните копии в надёжном месте (другой сервер, локальный диск, облачное хранилище).

Мы прилагаем все усилия, чтобы минимизировать время простоя и сохранить ваши данные в полной безопасности. Все работы будут выполнены с максимальной осторожностью.

Благодарим за понимание и доверие.

С уважением,
Команда 4vps.su

Недоступность серверов на локации Франкфурт



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

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

На текущий момент мы готовы предложить вам один из следующих вариантов:
  • Выдача нового сервера на другом доступном узле с новым IP-адресом.
  • Восстановление сервера из доступного резервного бэкапа, если такой бэкап имеется, также на новом узле и с новым IP-адресом.
Обратите внимание, что старый IP-адрес в текущей ситуации может быть недоступен, поэтому при переносе или выдаче нового сервера потребуется обновить DNS-записи, настройки домена или подключения, если они были привязаны к старому IP.

Мы понимаем, что данная ситуация может доставить неудобства, и приносим извинения за возникшие сложности. Наша команда работает над тем, чтобы как можно быстрее предоставить рабочее решение каждому затронутому клиенту.

Пожалуйста, сообщите нам в тикетах, какой вариант для вас предпочтителен:
  • выдать новый сервер;
  • восстановить сервер из доступного бэкапа при его наличии.

hosting-vds.com

Новые символы в домене .РФ



Теперь зарегистрировать сайт или почту можно на родном языке — без транслита и искажений.

В зону.РФ добавлены буквы абазинского, адыгейского, алтайского, башкирского, бурятского, ингушского, кабардино-черкесского, калмыцкого, коми, марийского, осетинского, татарского, тувинского, удмуртского, хакасского, чеченского, чувашского и якутского языков.

А также 26 новых кириллических символов. Меньше барьеров, больше родного языка в интернете.

firstvds.ru/services/domain_names

Список символов, допустимых в составе доменного имени в домене.РФ
U+002D HYPHEN-MINUS -
U+0030 DIGIT ZERO 0
U+0031 DIGIT ONE 1
U+0032 DIGIT TWO 2
U+0033 DIGIT THREE 3
U+0034 DIGIT FOUR 4
U+0035 DIGIT FIVE 5
U+0036 DIGIT SIX 6
U+0037 DIGIT SEVEN 7
U+0038 DIGIT EIGHT 8
U+0039 DIGIT NINE 9
U+0430 CYRILLIC SMALL LETTER A а
U+0431 CYRILLIC SMALL LETTER BE б
U+0432 CYRILLIC SMALL LETTER VE в
U+0433 CYRILLIC SMALL LETTER GHE г
U+0434 CYRILLIC SMALL LETTER DE д
U+0435 CYRILLIC SMALL LETTER IE е
U+0451 CYRILLIC SMALL LETTER IO ё
U+0436 CYRILLIC SMALL LETTER ZHE ж
U+0437 CYRILLIC SMALL LETTER ZE з
U+0438 CYRILLIC SMALL LETTER I и
U+0439 CYRILLIC SMALL LETTER SHORT I й
U+043A CYRILLIC SMALL LETTER KA к
U+043B CYRILLIC SMALL LETTER EL л
U+043C CYRILLIC SMALL LETTER EM м
U+043D CYRILLIC SMALL LETTER EN н
U+043E CYRILLIC SMALL LETTER O о
U+043F CYRILLIC SMALL LETTER PE п
U+0440 CYRILLIC SMALL LETTER ER р
U+0441 CYRILLIC SMALL LETTER ES с
U+0442 CYRILLIC SMALL LETTER TE т
U+0443 CYRILLIC SMALL LETTER U у
U+0444 CYRILLIC SMALL LETTER EF ф
U+0445 CYRILLIC SMALL LETTER HA х
U+0446 CYRILLIC SMALL LETTER TSE ц
U+0447 CYRILLIC SMALL LETTER CHE ч
U+0448 CYRILLIC SMALL LETTER SHA ш
U+0449 CYRILLIC SMALL LETTER SHCHA щ
U+044A CYRILLIC SMALL LETTER HARD SIGN ъ
U+044B CYRILLIC SMALL LETTER YERU ы
U+044C CYRILLIC SMALL LETTER SOFT SIGN ь
U+044D CYRILLIC SMALL LETTER E э
U+044E CYRILLIC SMALL LETTER YU ю
U+044F CYRILLIC SMALL LETTER YA я
U+0456 OLD CYRILLIC I і
U+0458 CYRILLIC SMALL LETTER YE ј
U+0493 CYRILLIC SMALL LETTER GHE WITH STROKE ғ
U+0495 CYRILLIC SMALL LETTER GHE WITH MIDDLE HOOK ҕ
U+0497 CYRILLIC SMALL LETTER ZHE WITH DESCENDER җ
U+0499 CYRILLIC SMALL LETTER ZE WITH DESCENDER ҙ
U+04A1 CYRILLIC SMALL LETTER BASHKIR KA ҡ
U+04A3 CYRILLIC SMALL LETTER EN WITH DESCENDER ң
U+04A5 CYRILLIC SMALL LIGATURE EN GHE ҥ
U+04AB CYRILLIC SMALL LETTER ES WITH DESCENDER ҫ
U+04AF CYRILLIC SMALL LETTER STRAIGHT U ү
U+04BB CYRILLIC SMALL LETTER SHA һ
U+04CF CYRILLIC SMALL LETTER PALOCHKA ӏ
U+04D1 CYRILLIC SMALL LETTER A WITH BREVE ӑ
U+04D5 CYRILLIC SMALL LIGATURE A IE ӕ
U+04D7 CYRILLIC SMALL LETTER IE WITH BREVE ӗ
U+04D9 CYRILLIC SMALL LETTER SCHWA ә
U+04DD CYRILLIC SMALL LETTER ZHE WITH DIAERESIS ӝ
U+04DF CYRILLIC SMALL LETTER ZE WITH DIAERESIS ӟ
U+04E5 CYRILLIC SMALL LETTER I WITH DIAERESIS ӥ
U+04E7 CYRILLIC SMALL LETTER O WITH DIAERESIS ӧ
U+04E9 CYRILLIC SMALL LETTER BARRED O ө
U+04F1 CYRILLIC SMALL LETTER U WITH DIAERESIS ӱ
U+04F3 CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE ӳ
U+04F5 CYRILLIC SMALL LETTER CHE WITH DIAERESIS ӵ
U+04F9 CYRILLIC SMALL LETTER YERU WITH DIAERESIS ӹ

Обновление дизайна личного кабинета ISPserver





Мы обновили интерфейс личного кабинета на проекте ISPserver.ru. В его основе — современная дизайн-система, которая уже используется в продуктах ISPsystem и продолжает активно развиваться.

Новый интерфейс стал более удобным и понятным: переработаны ключевые элементы, улучшена навигация, обновлены формы и списки, ускорен доступ к основным действиям. Особое внимание уделено пользовательским сценариям — работать с услугами, платежами и настройками стало проще и быстрее.

Обновление затронуло не только внешний вид, но и общий пользовательский опыт. Интерфейс стал более консистентным, логичным и адаптированным под реальные задачи пользователей. Работа над развитием личного кабинета продолжается — впереди новые улучшения и функциональные обновления.

ispserver.ru

Все о идентификации через Госуслуги (ЕСИА) с 1 сентября 2026 года



Начиная с 1 сентября 2026 года обязательным условием для управления доменами в зонах .ru,.рф и .su станет подтверждение личности через портал «Госуслуги». Эта норма закреплена в Федеральном законе от 29.12.2025 № 569-ФЗ.

Что будет недоступно без подтверждённой (не упрощённой) учётной записи на «Госуслугах»?
  • Регистрация новых доменов в указанных зонах.
  • Продление срока действия уже имеющихся доменов.
  • Смена администратора (фактического владельца) доменов.
  • Перевод доменов к другому регистратору.

Важные нюансы:
  • Требование распространяется на всех: новых и действующих администраторов, физических лиц, индивидуальных предпринимателей и компании.
  • Детали процедуры пропишут в новых Правилах регистрации доменных имён (документ находится на утверждении).
У нас появится возможность идентификации через ЕСИА на нашем сайте ориентировочно к сентябрю 2026 года — мы внедряем эту функцию и будем держать вас в курсе на данной странице.
На данный момент регистраторы не имеют доступа к ЕСИА. Ожидаем готовность системы к 1 сентября.

Что делать прямо сейчас?
Приведите все контактные данные, указанные при регистрации домена, в полное соответствие с вашими актуальными документами (паспорт, адрес, телефон, электронная почта и т.д.). Это необходимо, чтобы позже ваша учётная запись на «Госуслугах» успешно сопоставилась с анкетой домена.
Если данные устарели (меняли паспорт, адрес регистрации, телефон, электронная почту, наименование юрлица и т.п.) — обязательно создайте заявку в техническую поддержку на их обновление.

Отдельно для иностранцев:
Иностранные граждане должны создать учётную запись на «Госуслугах»
www.gosuslugi.ru/help/faq/login/0006
Иностранным юридическим лицам необходимо будет открыть официальное представительство в России и также пройти подтверждение аккаунта на «Госуслугах»
www.gosuslugi.ru/help/faq/company_profile/100405

ru-tld.ru
my.ru-tld.ru/manager/

Данные клиентов не пострадали, все они сохранены в полном объеме





Проблемы с доступностью части серверов, данные клиентов не пострадали, все они сохранены в полном объеме, но решение проблемы может затянуться на несколько дней т.к. зависит от третьей стороны.