Опубликован релиз OpenSSH 10.0, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Основные...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63042
>его удаление позволит стимулировать прекращение поддержкиКакое они право имеют "стимулировать" (формировать экосистему)? Монопольное. Как Гугл и Cloudflare имеют полное право скоту навязывать. Так и эти. Помните об этом.
> Какое они право имеют "стимулировать" (формировать экосистему)?Наверное потому что они ее и создают?
Тот кто делает, тот и решает. А потpe6ляди могут только жрать с лопаты.
>позволит стимулировать прекращение поддержки DSA в других реализациях SSH и криптографических библиотекахОни уже пытаются навязывать другим проектам, к которым отношения не имеют.
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Что это вообще значит? Они пилят свой SSH сервер и больше не хотят поддерживать DSA. Остальные вольны делать что им заблагорассудится.
Читать не умеешь? Они гордо используют своё доминирующее положение для навязывания и не скрывают этого.
Я тоже использую свое доминирующее положение, когда ребенку говорю уроки делать и чего теперь? С чего снежинки 2005 года рождения вдруг считают, что это плохо?
Они не являются папа-мамами для других SSL/TLS-проектов, в отличие от тебя. А так, это уже попахивает претензиями на монополизацию области деятельности.
Любое устаревшее и угрожающее ИБ стоит выкидывать, если алгоритм/метод/протокол потерял свою актуальность с точки зрения ИБ, то ему место на помойке/музее истории. Свободу творчества такой подход никак не ограничивает, а вот разным несознательным криминальным элементам создает проблемы.
> Читать не умеешь? Они гордо используют своё доминирующее положение для навязывания и не скрывают этого.Как они могут НАВЯЗАТЬ другим ОТСУТСТВИЕ DSA? Тео лично вломится в дом к каждому поддерживающему DSA и обоссыт его?
Очень просто. Все, кто OpenSSH используют, дропнут (просто потому что OpenSSH дропнул, а бодаться с властями - себе дороже) - и тебе придётся.
> Очень просто. Все, кто OpenSSH используют, дропнут (просто потому что OpenSSH дропнул,
> а бодаться с властями - себе дороже) - и тебе придётся.Зачем? Если где-то есть требования по списку алгоритмов, делаешь compile-time опцию для включения-выключения. В том же OpenSSH это есть.
А кто-то запретил навязывать или что? Надо сидеть в уголочке, ковырять землю и скромненько бормотать, что будешь поддерживать то, что не хочешь? Вот сам так и делай)
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Что мешает авторам других проектов запилить и поддерживать свой патчсет для поддержки DSA в OpenSSH?
Попробую угададать - если за десять лет они не осилили добавить в свой "другой проект" каких-либо алгоритмов, кроме DSA, то им даже и думать нечего о правке кода OpenSSH.
ну так не ставь. используй другие проекты или пиши свои
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Не-не-не, это другое проекты к ним не имеют никакого отношения))
И вот эти самые "другие проекты" могли бы или запилить свой ssh или форкнуть имеющийся - код же открыт! Но у них лапки)) Поэтому будут пользоваться тем что дают.Вообще уже стали немного напрягать местные "особенные", которые начинают что-то требовать от опенсорса. "Пачиму вы дропаете кор2duo???", "Вы абязаны поддерживать иксы!!111" и так далее.
Ребята, попуститесь! Вам никто ничего не должен. Или сами делайте, или прикройте варежку.
Так скот на то и скот что сам не докумекает. А разумных людей стимулировать не нужно, они от небезопасного неэффективного и древнего говна первые съезжают.
Помнится, был один чел не из OpenSSH, вроде гордо носивший бирку работника Google, который выложил из себя "SSH 3.0". Этот гений, который даже RFC до первых двух параграфов не прочитал и элементарные тесты не сделал, с какого-то перепугу начал заявлять, что SSH прибит гвоздями к TCP (это не правда, ssh работает на любых двух 8-битных пайпах, транспорт хоть флешка может быть), и прибил гвоздями "SSH 3.0" к QUIC.Суть басни - идите хотя бы почитайте стандарт протокола, прежде чем позорится. Вы можете согласовать аутентификацию хоть стрибогом и шифровать кузнечиком - протокол этого вообще никак не запрещает. Хотят ли челы из OpenSSH эти (и другие подозрительные или устарелые) алгоритмы у себя в проекте? Как видно, не очень. Код под открытой лицензией ISC. Захочешь - вернёшь обратно, заодно пропатчишь под новые версии.
>По сравнению с алгоритмом Диффи — Хеллмана на базе эллиптических кривыхНо есть нюанс - они не считаются настолько же безопасными, насколько работа с теорией чисел. Но Национальная Безопасность (тм) в некоторых государствах считается uber alles. И ради неё могут на каких угодно разработчиков, живущих там, давление оказать.
> Но есть нюанс - они не считаются настолько же безопасными, насколько работа с теорией чисел.Простейший квартовый компьютер может взломать биткоин за неделю.
Суперкомпьютер будет взламывать это временем зарождения миллионов галактик.
>квартовыйЭто же сколько кварт надо выпить, чтобы достичь нужного эффекта!
Сказал аноним знакомый с биткойном из новостей. Не позорьтесь.
Кто вам такое сказал?
В огороде бузина.Эллиптические кривые это и есть теория чисел.
Странно... А мне говорили, что алгебраическая геометрия...
Версия для линукса бодро докладывает, что она уже р2
ssh -V
OpenSSH_10.0p2
А почему mlkem768x25519-sha256 а не sntrup761x25519-sha512?sntrup761x25519 же лучше будет, или я не прав?
Чем лучше? ML-KEM шире распространён.
С точки зрения безопасности что лучше?
https://blog.cr.yp.to/20231023-clumping.html
Толково. Спасибо.
Кому нужен DSA (как и мне для виртуалок с древними системами) - в Putty всё на месте.
В клиенте они тоже dsa выпилили? То есть на какое-нибудь hp StorageWorks зайти -- гульден? От спасибочки!
Гм. Обычно везде, где есть dsa есть и rsa жи, ни? Причем, afaik dsa нигде, кроме fips'овских железок для всякого us goverment дефолтом не был...
Что мешает держать в отдельной папочке клиент версии 9.9?
Запустить клиент нужной версии в 2025 году совершенно не решаемая задача, конечно.
> задействован гибридный алгоритм обмена ключами "mlkem768x25519-sha256", стойкий к подбору на квантовом компьютереИ видимо не стойкий на обычном :)
> По сравнению с алгоритмом Диффи — Хеллмана на базе эллиптических кривых удалённая реализация медленнее и требует дополнительных вычислительных ресурсов при идентичном уровне безопасности.Вот только к элиптике есть вопросы.
> По умолчанию выставлен список приоритетов при выборе шифров: Chacha20/Poly1305, AES-GCM (128/256) и AES-CTR (128/192/256).Глупое умолчание.
AES-NI есть много где в железе а чачи нигде нет.
Более того это по сути единственный в мире чисто поточный шифр (не считая RC4 отправленного на пенсию).
> В sshd добавлена опция "--with-linux-memlock-onfault" для закрепления sshd в памяти (запрета вытеснения в раздел подкачки).Хорошо но на фре это делается банальным
sshd_oomprotect="ALL"
в rc.conf, который там внутри дёргает /usr/bin/protect для указанного PID.
Я так кучу важных сервисов на системе сделал неубиваемыми.
Хотя нет. Сделали банальный лок страниц памяти.
> Вот только к элиптике есть вопросы.Можно поподробнее?
https://kiwibyrd.org/2016/10/07/1610/Из забавных совпадений тут то, что p-256 теперь форсит везде гугол для ECDH.
Это тот кивибирд, который на 3дньюз несколько лет назад писал всякую антинаучную дичь, типа про "древне-китайские бронзовые ПРОЗРАЧНЫЕ зеркала, которые ОПРОВЕРГАЮТ СОВРЕМЕННУЮ НАУКУ"? И вы приводите его статью десятилетней давности для чего? Над вами недостаточно часто смеются?
Да автора бывает заносит.
Но в данном случае речь идёт об объективно наблюдаемых фактах:1. АНБ перестало форсить переход на элиптику своих госов. Можно интерпретировать это как: нет смысла напрягатся, скоро вместо элиптики будет что то лучше, квантово стойкое потому сплошная экономия.
2. Элиптику форсят в разных местах. Те если до 2015-18 года элиптика вполне существовала но всем было пофиг то сейчас её прямо форсят, это видно даже в этой новости.
Тот же гугол форсит именно p-256 для ECDH которую по словам кивибёрда даже NIST выкинул.3. RSA вполне надёжен, все претензии к нему только в производительности, и надо сказать что его юзали ещё в древние времена на древнем железе. А применительно к ssh (где conn rate низкий) так вообще пофиг.
> типа про "древне-китайские бронзовые ПРОЗРАЧНЫЕ зеркалаПрозрачный аллюминий же изобрели, может и до бронзы дело дойдёт :)
А касательно зеркал - так вероятно прозрачная бронза заменяла стекло.
Но из "статьи" по ссылке можно сделать вывод (точнее, автор сам его делает в конце), что "у кого надо" есть алгоритмы, которые _наверное_ могут взломать ECC без всяких квантовых компьютеров. Т.е. отказ АНБ от внедрения ECC обусловлен тем, что АНБ считает ECC небезопасным _прямо сейчас_. И, видимо, именно этим киви и пытается объяснить форс перехода к "постквантовым" алгоритмам. Но он слишком увлекается, украшая свою статью переплетениями словесных узоров и делая её похожей на индейские шёлковые ковры - настоящее произведение искусства, удивительные изделия, которые поражают воображение каждого, кто их увидит и вызывают в памяти полузабытые слова из старинных восточных сказок, услышанных от родителей ещё в детстве. Короче, я задолбался читать его поток сознания.Также из статьи видно очевидное преимущество ECC: "256-битные операции ECC эквивалентны работе с модулем длиной 3072 бита в RSA". Для меня это вполне нормальное объяснение форса этих алгоритмов везде. Шифрование теперь даже в лампочках есть, удобно, когда оно не требует больших мощностей.
>Да автора бывает заносит.
Его не заносит, он откровенно лжёт. Я уже не помню всю статью про эти зеркала, но он привёл "немагическое" объяснение этого эффекта, но потом всё равно жирно намекнул на то, что не всё так однозначно. Это был не первый раз, когда он нёс подобную дичь, но мне этот момент запомнился именно этим внезапным поворотом - он дал разумное объяснение эффекта, но тут же написал, что "это всё неправда" не приводя никаких внятных доказательств или аргументов. Собственно, после этого я перестал его читать.
Хорошо, давайте по другому.Если АНБ сказало своим госам сидеть на попе ровно с RSA, то зачем нам бегать с ECDSA/ED25519?
В остальном видно как остальных форсят в ECDSA/ED25519, так же как форсили DUAL_EC_RNG и некоторые другие алгоритмы.
Допустим для гугла есть разумные экономические обоснования форсить крипту вообще и форсить ECC даже если оно дырявое.
Но я не вижу смысла в ECC вообще для себя лично. Притом что я убил где то пол года на написание С кода ECDSA/GOST лично для себя. Впрочем то для чего я писал код - там то вполне норм ибо ценность заметно ниже цены взлома.Те лично я бы рассматривал ECC сейчас как вычислительно дешманскую крипту для которой потенциально есть средства раскрытия, но средства эти дорогие и палить их по мелочам не будут.
Для личного применения RSA с длинным ключём вполне ок, там где не предполагается частых вычислений. Вот SSH самое оно.
На вебсайт надо сильно думать: я тут на домашний выкатил RSA 16384 так потом когда сканер-проверяльщик ssl натравил видно было что nginx по пол ядра отжирают :)
Смотри, я могу объяснить "непонятную торопливость" "инстанций" не прибегая к сиономарсианам: инстанции знают, что если они начнут сегодня, то внедрение новых технологий станет более-менее массовым как раз к тому моменту, как квантовый компьютер можно будет купить на алиэкспресс.
Смотри, у меня RSA 16384, я могу ещё долго сидеть и смотреть на крах биткойна и прочих применений элиптики :)
Это если нам про квантовые - врали. А если нет?Я вот _лично_ пытаюсь справляться с проблемами по мере их появления, заранее - только если на 146% точно предсказал где\что\как(\кто :)
Что бы там ни врали - мне с RSA 16384 без разницы, ничего не меняется :)
Как бе это сказать ... мне и с 4К (а вне работы - да и даже с 2К) - так же :)Любители играют до победы! Профессионалы - до свистка.(С)
Дадут свисток на 16К - будет и 16К ... и премия за безопасТностЕ :))))
А где вы ключ такого размера храните? На всяких security key оно вродь не лезет.
При попытке использовать для commit signing скорее всего проблемы будут - тот же gitlab пишет, что из-за go specific implementation максимальный размер 8мб.
Предполагаю, что и еще где-нибудь споткнуться можно - и вот нахрена?
p-256 классифицирован DJB как небезопасный: https://safecurves.cr.yp.to/#:~:text=The%20following�...
DJB тот ещё фрукт: везде бегал и орал про ужасный ECDSA только потому что там тайминг атаки неустранимы, чтобы пропеарить свой 25519.Да и список далеко не полный, там и от ниста не всё и от браинпула, и госта нет.
> И видимо не стойкий на обычном :)Кажеться, они совмещают "на всякий случай". Там логика типа, алгоритм новый, хз как он, так что сделаем и так и сяк, и если взломают, то хоть старый уровень останется.
Если бы не стойкий на обычном, то на обычном ломали бы квантовую часть, а на квантовом обычную. Ну в таком плане.
> Глупое умолчание.
Слыхал, в имплементации gcm что-то там не шифровалось, типа метаданных каких-то или что-то такого плана.
> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon.
http://kb.ictbanking.net/article.php?id=691
Также, раньше на мобилках было плохо с аппаратной поддержкой.
https://blog.cloudflare.com/do-the-chacha-better-mobile-perf.../Ну и кто-то говрит, что он чуть безопастнее типа:
https://www.reddit.com/r/cybersecurity/comments/gxso79/chach.../
>Ну и кто-то говрит, что он чуть безопастнее типа:
>https://www.reddit.com/r/cybersecurity/comments/gxso79/chach.../Еще более авторитетно получится, когда на Реддите будут ссылаться на анонимусов с Опеннета.
> Кажеться, они совмещают "на всякий случай".На всякий случай квантовых с нужным кубитом ещё нет, даже для банальных ECDSA на 96, 128 бит которые задепрекейтили ещё лет 15 назад.
А для аналогов с RSA ещё очень долго не будет хватать кубитов.
> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data.Да и пофиг.
> Также, раньше на мобилках было плохо с аппаратной поддержкой.А мне и не надо чтобы ко мне с мобилок ходили и гоняли джигабайты трайфика :)
Для мобилок гугл чачу форсил, чтобы ютуп смотреть приватно.В остальном же я вполне себе монтирую через sshfs диски и гоняю относительно много трафика поэтому для меня разница между AES и чачей будет заметна.
С мобилки же если и сижу в ссш - то это терминал, где хоть тормозным гостом можно шифровать - ничего не изменится.
> Ну и кто-то говрит, что он чуть безопастнее типаПусть говорят, мне AES-256 хватает.
>> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use.
> Да и пофигНифига себе "пофиг". Размер пакета в сообщении SSH, если что, относится к незашифрованным реальным данным. Размер дополнительного рандомного паддинга идёт ещё одним байтом. Зная размер плейнтекста, можно, например, угадать, чем конкретно вы сейчас занимаетесь/ печатая что-то у себя в консоли и смотря что консоль возвращает обратно. Поэтому размер плейна тоже должен шифроваться. Странно, что GCM этого не делает, ибо протокол обязует размер пакета добивать до минимума размера блока шифрования, чтобы можно было зашифровать вообще всё, включая длину плейнтекста.
Как видишь это почему то никого не волнует.
Я вижу то, что никто даже конфиг ssh (клиента) не трогает, чтобы себе жизнь упростить всякими hostkeyalias и match, не говоря уже о том, что никто не трогает дефолтный sshd_config. А если никто этого не делает, значит по дефолту у всех и так чача и ed25519.
> Странно, что GCM этого не делает, ибо протокол обязует размер пакета добивать до минимума размера блока шифрования, чтобы можно было зашифровать вообще всё, включая длину плейнтекста.Это не GCM должен делать, написано ведь "because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use".
GCM это режим блочного шифрования, и там "обязует размер пакета добивать до минимума размера блока шифрования" это относится к самому алгоритму блочного шифрования, который не будет ничего шифровать меньше необходимого размера блока данных.
И конечно же любая метаинфа связанная с плейнтекстом также должна быть конфиденциальна.
Новость не новая, мб исправили.> Это не GCM должен делать, написано ведь
Да, но для нас, как для пользователей, этого можно грубо списать как: алгоритм не реализован в ssh, а за вычетом его остается aes-ctr и чача.
> На всякий случай квантовых с нужным кубитом ещё нет, даже для банальных ECDSAЭто понятно. Тут речь о будущем... Хах, хотя, какое тут будущее))
И есть слухи, что некоторые государства сохраняют шифрованные данные с целью расшифровать, если будут найдены уязвимости в определенных алгоритмах или грубая сила позволит.
> С мобилки же если и сижу в ссш - то это терминал, где хоть тормозным гостом можно шифровать - ничего не изменится.
Ну это ваш случай. У меня в одном заведении фаервол с белым список по доменам, так что использую ssh как forward proxy, как раз с мобилки.
> Это понятно. Тут речь о будущем... Хах, хотя, какое тут будущее))Гибрид
> есть слухиhttps://en.m.wikipedia.org/wiki/Utah_Data_Center
https://en.m.wikipedia.org/wiki/SORM
>И видимоНет.
>Вот только к элиптике есть вопросы.
Задавать их вы, конечно, не будете, потому слабо понимаете, о чём говорите.
>а чачи нигде нет.
Есть даже в смартфонах.
> Задавать их вы, конечно, не будете, потому слабо понимаете, о чём говорите.Ээээ...вообще то вы это пишете одному из немногих авторов собственной имплементации ECDSA+GOST на C на этой планете. И когда я писал свою - остальных реализаций было штук 5, в основном по криптолибам.
Те она полностью на С, начиная со своей реализации длинных чисел и операций над ними, продолжая математикой над кривыми и заканчивая собственно применением этого всего для криптографии.
Не буду спорить, я математическую часть/суть не понимаю и только имплементировал алгоритмы.
Однако заявлять что я совсем не разбираюсь в теме слишком высокомерно с вашей стороны.
> Есть даже в смартфонах.Где где!?
Речь про железо вообще то.
А так то это и на счётах+бумаге можно посчитать и сказать что даже в каменном веке могли в чачу.
Если вы такой спец по реализации, где ВАШ список вопросов к эллиптике? Основанный на математике, а не на теории заговоров.
В прошлом, там же где и ECDSA и 25519 и прочая элиптика.
Накодить что-то по чужим алгоритмам и разрабатывать эти алгоритмы — большая разница.> Не буду спорить, я математическую часть/суть не понимаю и только имплементировал алгоритмы.
> Однако заявлять что я совсем не разбираюсь в теме слишком высокомерно с вашей стороны.Высокомерно — это с твоей стороны делать вид, что ты разбираешься в чём-то кроме кодинга на С.
Как они задолбали удалять старые алгоритмы, особенно из клиента. Ну не добавить в старые железки новые алгоритмы, никак. Putty в этом плане намного лояльнее, но его применение ограничено, конечно.
Да оспыдя. Пока это обновление до LTS'а доползет - те железки уж сдохнуть успеют. А если и останется 2,5 штуки, умеющие в dsa, но не умеющие в rsa - то какой-нибудь dropbear вроде не отбирают пока...
1. держать в отдельной папке старую версию с нужным протоколом.
2. в пакетманагере прибить гвоздями нужную старую версию для всей системы.
> в пакетманагере прибить гвоздями нужную старую версию для всей системыИ вручную накладывать бэкпорт патчи с заплатками CVE
а там, куда без DSA не зайти, всё типа до сих пор получает обновления или там даже вручную не наложить, так что норм?
> Putty в этом плане намного лояльнееЭто клиент, а не сервер. Клиентам, как раз важно поддерживать бесконечно любое легаси.
PS: и вам в винду уже давно Microsoft завезла нормальный SSH клиент и терминал, вам для SSH, PuTTY не нужен, вы просто используете его по энерции, потому что кто-то когда-то так вам сказал работать
PS2: если вам нужна поддержка легаси на SSH сервере, то с помощью Docker вы всегда можете поднять SSH сервер любой версии не ломая свою систему, но Docker это же не для вас, да?
>с помощью Docker вы всегда можете поднять SSH сервер любой версии не ломая свою систему, но Docker это же не для вас, да?С незакрытыми уязвимостями, но безопасность это же не для вас, да?
> С незакрытыми уязвимостями, но безопасность это же не для вас, да?причём тут уязвимости? речь об избежании прдолинга с бекпортами и прочими трюками, лишь бы не осваивать контейнеры
Ну а снизить риск от уязвимостей можно разными средствами, включая PoLP, MAC, DAC и т.п.
> В ssh-keygen добавлена поддержка токенов FIDO, не возвращающих данные аттестации, таких как WinHello.Гм. Оно ж с 8.9 в 10ке работает - ssh-keygen -t ecdsa-sk и нерезидентный ключик зашифрованный TPM'ом с аутентификацией по морде\пальцу\чему-изволите вот прям из коробки. Еще помнится смеялись про "тот неловкий момент, когда под windows SSH работает лучше, чем под онтопик", в котором это делалось традиционно через пляж-гамак-лыжи-pkcs11...
Ну и как оно, при использовании StrictHostKeyChecking=no по-прежнему добавляет никак не проверенные ключи в known_hosts?
Так не пользуйтесь "no". Какие проблемы? Там "ask" по-умолчанию.
> Так не пользуйтесь "no". Какие проблемы? Там "ask" по-умолчанию.У меня комп для тестов, у которого при каждом ребуте новый ключ, ради чего мне там ask делать? Чтоб потом удалять его?
Вы зачем эту опцию используете? Почитайте в манпейдже про HostkeyAlias, если вам нужно подключаться к одной и той же тачке разными способами. Вместо хоста в known_hosts будет сохранятся этот самый альяс, и никаких предупреждений о новом хосте / сменившемся на 192.168.0.2 ключе вы не увидете больше никогда.
> Вы зачем эту опцию используете? Почитайте в манпейдже про HostkeyAlias, если вамОпция интересная, но не мой случай, у меня тестовая машина загружается каждый раз с новыми ключами и при выключении удаляется.
Опция поможет только если бы я на разные хосты через один IP:port ходил.
Доктор! Если я делаю "вот так!" - мне больно!
... а вы "вот так!" - не делайте :)
То есть Вы отключаете проверку ключей, и ужасно возмущены тем, что ключи после этого не проверяются? Никаких противоречий не замечаете?
Нет, я возмущён тем, что непроверенный ключ сохраняется туда же, куда и проверенные. Неужели из предыдущих сообщений это никак не читается?
Совершенно никак и не читается, а со стороны выглядит именно так, как я описал. А в вашем случае - установите для этого хоста отдельный known_hosts, опцией UserKnownHostsFile. И там уж выбирайте хоть /dev/null.А то поведение, что вы описали, является ожидаемым, и никак не является ошибкой.
Ожидать что ключи разного качества проверки валятся в одну кучу? Я простите трезвым за комп сажусь, а не после двух литров пива, чтоб такое "ожидать".Как раз наоборот, если после такого подключения попытаться на тот же хост зайти уже с ВКЛЮЧЕННОЙ проверкой ключа, при текущем состоянии софта произойдёт вход, считая что тот ключ, который уже сохранился КАК БЫ УЖЕ ПРОВЕРЕН (хотя никто его не проверял), что точно не является ожидаемым. И тут даже никаких бла-бла-бла про ожидаемое-неожидаемое не нужно - софтине сказали проверить ключ, а она этого не сделала.
Впрочем, вы похоже просто не понимаете о чём речь (так же как и не смогли понять смысл предыдущих сообщений) - потому что судя по всему рассуждаете на уровне тестировщика, а проблема архитектурная.