Comments 43
Кто собирает curl под macos? Очевидно что если проблема в libssl значит она затрагивает не только curl но и другие приложения.
Я не знаю про какую версию идет речь, но быстрый поиск мана в интернете показывает вот что:
--cacert <file>
...
(iOS and macOS only) If curl is built against Secure Transport, then this option is supported for backward compatibility with other SSL engines, but it should not be set. If the option is not set, then curl uses the certificates in the system and user Keychain to verify the peer, which is the preferred method of verifying the peer's certificate chain.
Последний абзац. На мой взгляд, тут ясно написано, что при определенных условиях cacert не должна использоваться. Ну т.е. да, определенные претензии тут могут быть - но скорее к документации, потому что непонятно/неполно описано поведение.
Как я понял, претензия автора на самом деле заключается не в провокационном заголовке поста, а в том, что яблочная реализация не поддерживает функциональность избирательного доверия, и это, с точки зрения автора, является дырой в безопасности.
Хотя вопрос очень спорный – если пользователь установил центр сертификации доверенным в системе, то у этого центра всяко будут различные пути, так сказать, пролоббировать своё мнение.
То что такое поведение curl, ну скажем, нехорошее - я скорее согласен. Я бы предпочел иметь возможность выбрать сертификаты удостоверяющего центра сам, когда захочу. Для конкретного сайта. Очевидный вариант - сертификаты Минцифры я бы предпочел иметь отключаемыми, без вариантов.
Но цитата из ман выше показывает на мой взгляд, что отличия как раз документированы (хотя и не очень четко). Так что автору оригинала просто следовало бы ман прочитать, и найти/собрать другую реализацию, тем более что ее долго искать не придется.
Если вы хотите иметь сертификаты Минцифры отключаемыми, то их не надо делать доверенными в системе, а надо передавать в конкретный вызов curl, что, как я понял статью, вполне возможно.
Ну да. Но это curl так позволяет - какой-то другой софт может пользоваться системным хранилищем, и тогда отключить все что лежит в нем, уже не получится (и на curl это повлияет в том числе). И мне такое поведение тоже не нравится.
Я понимаю Ваш ход мысли, но согласитесь, что, если некто является доверенным удостоверяющим центром в системе, то в принципе он может всё, в том числе и, допустим, модифицировать систему по своему усмотрению, устанавливая свои обновления под видом яблочных. Поэтому, потерявши голову, по волосам не плачут. Я хочу сказать, что фактически дыры в безопасности тут нет, а есть только вопрос удобства некоторых отладочных операций.
Ну я бы чуть иначе к этому подходил. Доверенный центр сертификации - это в сущности лишь чей-то корневой сертификат. Например, выпущенный вашей же компанией. И их очевидно в системе много, даже не считая того, что у моей компании скажем этих УЦ штуки четыре минимум.
Сам он ничего не может (в том смысле, что он пассивный, это не код, а данные), но он используется при установлении соединения с кем-то, в том числе и с репозиториями обновлений.
Т.е. "устанавливая свои обновления под видом яблочных" - ну да, может быть и такое, но устанавливать будет кто-то типа homebrew, и при этом у него будет такой же выбор как у curl - пользоваться системным набором сертификатов доверенных УЦ, или же использовать для установки обновлений свой набор сертификатов, который у него лежит отдельно. То есть, вопрос опасности того, что мы доверяем каким-то сертификатам в частности состоит и в том, что определенный важный софт не умеет работать с хранилищами сертификатов, отличными от системного.
Автор оригинала - это автор curl. И строчка в мане скорее всего появилась после изложенных событий (лень проверять).
У вас пример некорректный. Скажем, для взаимодействия со сбербанком я бы как раз хотел сертификаты минцифры и никакие другие (вспоминаем Symantec и прочих любителей выпускать поддельные сертификаты для "плохих" доменов). А вот это уже на яблоках не получится.
В том то и дело что центр содержит сертификаты, которые в том числе не пользователь установил...
Вопрос вызывает не сломанный функционал - это однозначно проблема. Проблема глубже - почему пользователь может хотеть не доверять центру, очевидно те кто наполняют его несут за это ответственность, но она выходит далеко за техническую область.
Да, эта проблема называется параноя и лечится соответствующими врачами. Потому что суть "не доверять корневому хранилищу сертификатов в системе, которое в силу своей функции должно быть априори доверенным" где-то на уровне "а вдруг сертификат в памяти подменят" или "где гарантии что из исходников собралось то, что в исходниках, а не файл с руткитом".
Ну, Thawte помнится выпустила фальшивые сертификаты для google.com, за что в последствии огребла от гугла, который пообещал выпилить все серты thawte из хрома и огнелиса. Но вы не гугл.
И что? Какой из этого вывод? Удалять все корневые серты из системы, а то вдруг кто-то из них окажется скомпроментирован с вероятностью один на триллион?
Я потому и говорю, что это параноя, которую лечить надо.
Нет, ну зачем удалять.
Глобально (мечты, мечты) должна быть возможность сертификации центров сертификации под TLD. Типа чтобы было прописано, скажем, для доменов .ru и .рф, что сертификаты Минцифры ок, а многократно замеченные в подлогах symantec и comodo не ок. А если они хотят быть ок, то пусть пляшут под нашу дудку. И в обратную сторону, никакие другие зоны минцифру не принимают (ну может Пу с Лу договорятся, и будет приниматься в .by)
На среднем уровне есть certificate pinning, когда конкретный домен говорит, что у меня вот сертификат от комодо, а с letsencrypt не лезьте, это фейк.
Ну и на базовом должна быть возможность в конкретном приложении прибить гвоздями конкретный сертификат и/или цепочку доверия, вплоть до самоподписа. Именно это делает обсуждаемая опция curl'a, и именно это сломало яблоко.
Да, давно напрашивается. Сертификатами в доменной зоне должен рулить тот же кто рулит доменной зоной. Глобальные центры сертификации не нужны. Автоматизируется полностью, бесшовный переход на такое возможен, пользователи ничего не заметят.
Можно даже еще дальше обобщить. Есть у тебя домен, значит можешь сделать свой центр сертификации и выдавать сертификаты на любые его поддомены со сроком сертификатов в пределах срока докуда у тебя домен оплачен. Третий уровень уже не нужен скорее всего, но если что можно и глубже.
Оно так себе работало и уже удалено из всех основных браузеров. Надо перепридумать.
Базовая всегда работавшая фича которую непонятно зачем сломали.
Лицензия curl, вроде, не запрещает создание форков с тем же именем. Формально у Apple всё в порядке. Это форк с изменённым поведением.
Хм. Интересно проверить доки curl на Маке, может, там поведение прописано... UPD Нынче на Хабре минусят за любопытство. А ведь если оно прописано в доках, то получается ещё более интересный прецедент о правах, лицензиях, отурытом ПО и т. д.
На Маке прописано, что эту опцию вообще не следует использовать. В точности как процитировано здесь.
Деюре, безусловно, всё верно. Но хорошим тоном является делать публичные форки с новым именем, чтоб не плодить вопросы "а какую вариацию одноименной утилиты я сейчас запущу?"
tldr: Apple thinks it is fine. I do not.
When this command line option is used with curl on macOS, the version shipped by Apple
Установить версию из brew и пожать плечами или написать статю и сообщить всему миру, что ты борешься с корпорацией зла v2.0. TLDR: Даниель встал на путь борьбы.
Это автор curl. И ему не нравится что Эпл тихо! сломала функционал.
Curl and libcurl are true Open Source/Free Software and meet all definitions as such. It means that you are free to modify and redistribute all contents of the curl distributed archives. You may also freely use curl and libcurl in your commercial projects.
https://curl.se/docs/copyright.html
Где здесь про то, что нравится или нет Даниелю? Или что нужно делать громко или тихо?
Где здесь про ...
Вот здесь:
Except as contained in this notice, the name of a copyright holder shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization of
the copyright holder.
Эплам нужно было curl назвать другим именем. В общем-то это логично - эплы могли вообще поломать весь функционал и правильнее это делать под своим именем.
Если поведение опции не задокументировано полностью - это однозначно плохо, но в целом, лично я именно такого поведения и ожидал бы. Потому что, очевидно, подкладывать какой-то свой файл имеет смысл, когда ты хочешь, чтобы некий сайт с кастомным сертификатом прошёл валидацию, а не чтобы отвалились все остальные из хранилища ОС.
Или нет. Ты хочешь сходить на свой заранее известный сайт которому ты точно доверяешь. А на любой сайт из интернета не хочешь. Логично доверять только сертификатам которые ты сам выбрал, а не всем подряд. Банковские приложеньки должны примерно так работать
Давно пользуюсь такой версией curl
brew update && brew info curl
If you need to have curl first in your PATH, run:
echo 'export PATH="/usr/local/opt/curl/bin:$PATH"' >> ~/.zshrc
brew list curl
Wow, Apple is definitely wrong on this. That means of you can’t script a cert-pinned app on MacOS. I do that all the time for intranet apps that use our corporate PKI.
Комментарий оттуда.
Встроенная в Windows версия curl с поддержкой schannel точно так же использует встроенное хранилище сертов операционки.
curl на MacOS тоже использует. Но когда ему сказано использовать только свои сертификаты, то он этой опции и следует, а не лезет в систему.
Мне интересно, это перевод такой косой или все читают по диагонали? Я в английском оригинале всё понял.
В переводе вот так, с сохранением авторского форматирования:
Когда этот параметр командной строки используется с curl в macOS, версия, поставляемая Apple, видимо, откатывается назад и проверяет хранилище системного центра сертификации на случай, если предоставленный набор сертификатов центра сертификации не пройдет проверку. Вторичная проверка, о которой не просили, не документирована и, откровенно говоря, становится полной неожиданностью. Таким образом, когда пользователь запускает проверку с использованием Curl и обрезанного, выделенного файла сертификата центра сертификации, она не завершится неудачно, если в системном хранилище центра сертификации содержится сертификат, который сервер сможет проверить!
Но когда ему сказано использовать только свои сертификаты, то он этой опции и следует, а не лезет в систему.
На маке как раз как я понял проблема в том что не следует этой опции, и в систему лезет.
Поведение Curl на macOS отличается от документированного. Apple считает, что это нормально