Комментарии 56
А что там слышно про TLS без CA на базе DNSSEC?
- Качаем новый сертификат 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)
- ввести имя файла
Upd: получилось, нужно было расширение .crt
А вот начиная с 6 (или 7) такое не прокатит. Там такому корню будут доверять только приложения, настроенные доверять. Обмануть это тоже возможно, но лишь от рута, вручную или через модуль Magisk
конвертируем PEM → DER, чтобы понял даже Android
Два моих старых «дажеандроида», 4.4 и 6.0, напрочь отказались принимать в формате DER (файл серым цветом, недоступен для выбора), а в формате PEM — пожалуйста. В общем, не забываем про метод тыка.
Имеется побочный эффект — при установленном пользовательском сертификате система требует запароленную разблокировку экрана.
Зачем корневым сертификатам в принципе иметь ограниченный срок действия? Какую проблему это решает? Если бы они были бессрочными, какие от этого были бы другие проблемы?
На ум приходит только потенциальная компрометация приватного ключа, но если ключ утёк сейчас, а сертификат истекает через 5 лет, это в смысле безопасности всё равно никак не поможет.
Зачем корневым сертификатам в принципе иметь ограниченный срок действия?Да ни зачем, просто когда придумывали всю эту хрень никто об этом не думал :)
Помимо утечки приватного ключа, есть ещё соображения нагрузки на ключ. Утрированно: подписывается обычно хеш от документа, а значений хеш-функции — конечно много. Соответственно, с течением времени условная Ева будет узнавать, как подписывать всё большее и большее число хешей, и будет увеличиваться вероятность того, что в это число войдёт и хеш нужного Еве документа.
Разумеется, такая атака не очень применима на практике, но каждая операция с ключом потенциально выдаёт всё больше и больше информации о нём, и единственный способ с этим бороться — периодически менять ключ.
В случае асимметричной криптографии возникают и более видимые проблемы. Скажем, в схеме Эль-Гамаля, стойкость обеспечивается (предполагаемои) трудностью задачи дискретного логарифмирования — буквально, нам сложно вычислить приватный ключ по публичному. Но задача-то эта решаема, и даже вполне очевидным способом — пусть и за долгое (на данном этапе развития технологий) время. Но ограниченное. И ключевую пару дольше этого времени использовать нельзя.
Решение одно — выкинуть PKI на помойку, вместе с DAP, LDAP, X.500 и прочими миазмами энтерпрайза.
Ну на телевизорах и прочих ИоТ этого никогда и не было, как и у сокетов которые открывают мобильные приложения… ну а на старых андроедах в браузерах оно никуда не делось.
Ну и смысла в TLS особо нет с этой кнопкой
Какой-то смысл все еще есть. Соединение остается зашифрованным, соответственно вытянуть из него данные сможет только активный MITM. И те скорее всего не полезут, если только не уверены, что на той стороне такой игнорирующий подпись клиент
Об этих устройствах речь.
Более старые, думаю, отвалятся по размеру ключа в новых сертификатах.
Не каждый пользователь смартфона или даже пк будет обновлять сертификаты.
Если бы везде она проверялась как в Windows, начиная с XP — по отпечатку ключа — то проблему протухания корневых сертификатов можно было бы обойти: выпускать новый сертификат с тем же ключом. Я сам такое проделывал в инфраструктуре PKI на базе чистой Windows.
Но вот за другие платформы я ничего сказать не знаю.
А используются сертификаты часто там, где угрозами от спецслужб можно пренебречь. Упомянутые в статье устройства практически все относятся к этому классу. Ну, к примеру, какой ущерб будет от того, что некто сможет подсмотреть в процессе передачи на «умный» телевизор и так общедоступный поток вещания упомянутой в статье BBC?
Да здравствует HTTP. Можно смотреть по user-agent: если понятно, что устройство старое, то отдать ответ по HTTP, иначе перенаправить на HTTPS.
В случае такой реализации будет возможно произвести mitm атаку. Прослушивающему будет достаточно вклиниться в запрос и подменить User-Agent
Зависит от того, что важнее: скрытность или доступность. Думаю, для медиасервисов важнее доступность. В случае надобности шифрование можно обеспечить собственной (для сервиса) парой открытого и закрытого ключа с бесконечным сроком действия.
сервер думает, что ваш клиент не умеет в https и отдаёт данные по http, что может расшифровать MITM.
а теперь представьте, что ваш клиент это умный телевизор с какой-нибудь платной подпиской на стриминговый сервис. понятно, что есть выходы из этой ситуации и костыли (виртуальные карты, некие свои прмоежуточные устройства, etc), но это уже не реализует предложенное вами решение.
Я понимаю, что это не защитит от MITM; предложение из моего первого комментария защитит только в случае, когда попытка MITM атаки происходит после установки соединения с сервером (подразумеваю, что получив 1 раз редирект на HTTPS клиент не будет больше отправлять HTTP какое-то время) и только на устройствах, которые поддерживают HTTPS.
Вопрос стоит в том, чтобы сохранить работоспособность устройства. Если нужна безопасность, то поверх HTTP можно использовать собственное шифрование, у которого нет срока годности, можно запрещать отправлять любые ценные данные по HTTP без шифрования (платить через терминал в магазине). Но все эти способы нужно закладывать заранее, когда есть возможность перепрограммировать устройство.
В век всеобщего HSTS не прокатит.
Считаю, что заголовок User-Agent — вредный, его следует отменить. Нарушает приватность, подталкивает к клоакингу и показу содержимого с User-Agent только из белого списка.
С этим можно бороться на клиентской стороне. Возьмите исходники какого-нибудь открытого браузера, измените user-agent, соберите и пользуйтесь или распространяйте.
Корневой сертификат — сердце центра сертификации. Он буквально встроен в вашу ОС или браузер, он физически присутствует на вашем устройстве.
Как программно проверить, когда протухнет корневой сертификат на Android-устройстве?
Проблема устаревших корневых сертификатов. На очереди Let's Encrypt и умные телевизоры