Pull to refresh

Comments 56

А что там слышно про TLS без CA на базе DNSSEC?

Даже если взлетит, будет та же проблема при замене KSK-2017 на следующий. В 2017 уже переносили замену на 2018, потому что никто не был готов. И это при том, что на сегодняшний день, положа руку на сердце, DNSSEC массово не используется (по крайней мере, в не-opportunistic режиме), так что мало что могло поломаться. К следующей замене, если DNSSEC «взлетит», будет та же проблема с необновляемыми IoT-devices.

Ну на IoT нормальные люди сидят на сертификатах с PKP, то-есть с валидацией ключа без chain/CA...

Не могу уловить ход вашей мысли. Мы всё ещё говорим о IoT-телевизорах, проверяющих TLS-сертификат через TLSA-запись в DNSSEC?
Интересно, поможет ли перевести время на год назад на таких устройствах.
Тогда телевизор не примет сертификат сайта, ведь он «еще не начал действовать».
Это если у нового сертификата начальная дата не от рождества христова.
Какие-то CA выдают такие сертификаты?
Надеюсь что нет. Но для решения проблемы старых устройств, почему нет. Каких то проблем с безопасностью я от этого не вижу.
Подтвердил проблему у себя на Android 5. Обновлений от вендора нет. Решение:

  • Качаем новый сертификат c https://letsencrypt.org/certificates/,
  • конвертируем PEM → DER, чтобы понял даже Android, как-то так:
    wget -O - 'https://letsencrypt.org/certs/isrgrootx1.pem.txt' \
    | openssl x509 -in - -inform PEM -outform DER -out isrgroot.der
  • переносим полученный файл на Android-устройство;
  • на нём же: Настройки → Безопасность → Установка с SD-карты, выбираем файл с сертификатом, озаглавливаем по вкусу, добавляем в хранилище;
  • PROFIT!
Жаль, что сотни уязвимостей на пятом андроиде так легко не пофиксить :)
Тем не менее, надеюсь, решение пригодится не только пользователям пятака. )
первые два пункта для владельцев венды:
  • запустить certmgr.msc
  • открыть trusted root CA/certificates/ISRG Root X1
  • перейти на вкладку details
  • нажать кнопку copy to file
  • формат DER (расширение файла .cer)
  • ввести имя файла

А на винде зачем? По моему, сертификаты продолжают обновляться даже для Vista. Или я что-то путаю?

чтобы закинуть сертификат на планшет
У меня на планшете amazon fire hd на 5 андроиде сайт открывается файрфоксом нормально, на хроме показывает ошибку сертификата. Скопировал файлик .der в корень SD-карты и внутренной памяти, попытался установить сертификат через Security & Privacy / Credential storage / Install from SD Card, но что-то не находит его: Certificate file was not found

Upd: получилось, нужно было расширение .crt
Блин, забыл, съел у меня .der или всё-таки .crt, а перепроверять лениво. Да и комментарий уже не поправишь… х)

P. S. FF, наверно, свои сертификаты таскает.
Да, FF свои сертификаты таскает. В результате никаких проблем с шифрованием или сертификатами даже на очень старых версиях браузера и даже на Windows XP в качестве ОС — нет.

В отличии от Хрома и многих других браузеров, которые уже многие сайты открывать отказываются.
Можно вместо конвертирования, качать сразу на телефон и там же переименовать *.pem.txt в *.pem ;) По крайней мере на 6-м Андроиде — ок.
Это первое, что я попробовал. На моём девайсе не прокатило )
Главное, что выход нашёлся )

А вот начиная с 6 (или 7) такое не прокатит. Там такому корню будут доверять только приложения, настроенные доверять. Обмануть это тоже возможно, но лишь от рута, вручную или через модуль Magisk

конвертируем PEM → DER, чтобы понял даже Android

Два моих старых «дажеандроида», 4.4 и 6.0, напрочь отказались принимать в формате DER (файл серым цветом, недоступен для выбора), а в формате PEM — пожалуйста. В общем, не забываем про метод тыка.

Имеется побочный эффект — при установленном пользовательском сертификате система требует запароленную разблокировку экрана.
Когда идея приложений, таскающих с собой свой собственный CA bundle, уже не кажется забавной…

А метод, как всегда, на острие науки.
Спросил это в комментах к оригиналу на HackerNews, но не получил внятного ответа, так что спрошу и тут.

Зачем корневым сертификатам в принципе иметь ограниченный срок действия? Какую проблему это решает? Если бы они были бессрочными, какие от этого были бы другие проблемы?

На ум приходит только потенциальная компрометация приватного ключа, но если ключ утёк сейчас, а сертификат истекает через 5 лет, это в смысле безопасности всё равно никак не поможет.
Не уверен что дам правильный ответ, но самый простой: за 25 лет методы шифрования сильно уходят вперед и то, что 25 лет назад было надёжным, становится подбираемым. Поэтому сделали такое ограничение, что бы принудить всех переходить на более новые технологии. Может быть, в текущей ситуации, когда скорость развития железа упала, это станет не так актуально.
Зачем корневым сертификатам в принципе иметь ограниченный срок действия?
Да ни зачем, просто когда придумывали всю эту хрень никто об этом не думал :)

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


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


В случае асимметричной криптографии возникают и более видимые проблемы. Скажем, в схеме Эль-Гамаля, стойкость обеспечивается (предполагаемои) трудностью задачи дискретного логарифмирования — буквально, нам сложно вычислить приватный ключ по публичному. Но задача-то эта решаема, и даже вполне очевидным способом — пусть и за долгое (на данном этапе развития технологий) время. Но ограниченное. И ключевую пару дольше этого времени использовать нельзя.

Решение одно — выкинуть PKI на помойку, вместе с DAP, LDAP, X.500 и прочими миазмами энтерпрайза.

Выше четко написано — миазм энтерпрайза.

Оскорбительный эпитет — это не аргумент. Чтобы использовать его в качестве аргумента — надо сначала доказать, что "миазм энтерпрайза" — это всегда плохо, и подлежит обязательному выкидыванию.

Там все красное. Не поняли иронию, бывает.
Выкинули повсеместно возможность сказать «да я вижу что сертификат протух но мне похер» теперь имеем то что имеем.

Ну на телевизорах и прочих ИоТ этого никогда и не было, как и у сокетов которые открывают мобильные приложения… ну а на старых андроедах в браузерах оно никуда не делось.


Ну и смысла в TLS особо нет с этой кнопкой

Какой-то смысл все еще есть. Соединение остается зашифрованным, соответственно вытянуть из него данные сможет только активный MITM. И те скорее всего не полезут, если только не уверены, что на той стороне такой игнорирующий подпись клиент

если только не уверены, что на той стороне такой игнорирующий подпись клиент
Не обязательно же игнорировать подпись, можно игнорировать только дату.
Вот уже года два как выкинули. И в статье речь о том что вот скоро протухнут корневые прописанные в не очень но уже старых андроедах с броузерами уже без этой кнопки.
Об этих устройствах речь.
Более старые, думаю, отвалятся по размеру ключа в новых сертификатах.
Означает ли это что в сети отвалится много старых девайсов?
Не каждый пользователь смартфона или даже пк будет обновлять сертификаты.
Вопрос тут ещё в том, как цепочка сертификатов составляется — т.е. как создается соответсвтвие с сертификатом выпустившего/перекрестно-подписавшего CA.
Если бы везде она проверялась как в Windows, начиная с XP — по отпечатку ключа — то проблему протухания корневых сертификатов можно было бы обойти: выпускать новый сертификат с тем же ключом. Я сам такое проделывал в инфраструктуре PKI на базе чистой Windows.
Но вот за другие платформы я ничего сказать не знаю.
Так смысл ограничения срока действия сертификатов ведь именно в том, чтобы ключ сменить. Для защиты от подбора ключа всякими спецслужбами вероятного противника. Если ключ оставить тем же самым, можно сразу сертификаты с бесконечным сроком действия выпускать.
Дык, об увеличении срока действия корневого сертификата надо было думать заранее, а не подумали. Бывает.
А используются сертификаты часто там, где угрозами от спецслужб можно пренебречь. Упомянутые в статье устройства практически все относятся к этому классу. Ну, к примеру, какой ущерб будет от того, что некто сможет подсмотреть в процессе передачи на «умный» телевизор и так общедоступный поток вещания упомянутой в статье BBC?
UFO landed and left these words here

Да здравствует HTTP. Можно смотреть по user-agent: если понятно, что устройство старое, то отдать ответ по HTTP, иначе перенаправить на HTTPS.

В случае такой реализации будет возможно произвести mitm атаку. Прослушивающему будет достаточно вклиниться в запрос и подменить User-Agent

Зависит от того, что важнее: скрытность или доступность. Думаю, для медиасервисов важнее доступность. В случае надобности шифрование можно обеспечить собственной (для сервиса) парой открытого и закрытого ключа с бесконечным сроком действия.

ваш клиент умеет в https и по его user-agent это видно. он посылает запрос серверу на подключение https. но находится некий MITM который подменяет ВАШ useragent на нужный этому MITM и к серверу приходит запрос с useragent древнего девайса.
сервер думает, что ваш клиент не умеет в https и отдаёт данные по http, что может расшифровать MITM.

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

Я понимаю, что это не защитит от MITM; предложение из моего первого комментария защитит только в случае, когда попытка MITM атаки происходит после установки соединения с сервером (подразумеваю, что получив 1 раз редирект на HTTPS клиент не будет больше отправлять HTTP какое-то время) и только на устройствах, которые поддерживают HTTPS.


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

В век всеобщего HSTS не прокатит.

Это, также как и наличие HTTPS, определяется сервером, с которым связываешься

Конечно. Но оно кешируется браузером. И TTL кеша часто выставлен в дикую цифру типа 1 год. И в течении этого времени браузер HTTP даже не попробует.


Плюс есть HSTS Preload — с ним еще хуже.

Конечно, сейчас уже поздно исправлять. Это надо продумывать заранее.

Считаю, что заголовок User-Agent — вредный, его следует отменить. Нарушает приватность, подталкивает к клоакингу и показу содержимого с User-Agent только из белого списка.

С этим можно бороться на клиентской стороне. Возьмите исходники какого-нибудь открытого браузера, измените user-agent, соберите и пользуйтесь или распространяйте.

Хром уже начал — при включенном флаге chrome://flags/#freeze-user-agent в строке User-Agent упоминается Windows 10, даже при работе на Linux.
Ошибусь ли я, если скажу, что умные телевизоры и прочая редко ходят браузером по сайтам, подписанным Let's Encrypt, а все больше используют приложения Youtube, Netflix и др., сертификаты для которых подписаны (скорее всего) другими CA?
Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве.

Как программно проверить, когда протухнет корневой сертификат на Android-устройстве?

Only those users with full accounts are able to leave comments. Log in, please.