Здравствуйте, TailWind, Вы писали:

TW>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду

TW>А теперь что? Ничего не нужно? Можно получить сертификат с консоли:
TW>https://habr.com/ru/articles/667158/

TW>Для проверки нужно только разместить на своем сайте файлик с паролем
TW>Который проверяют, внимание, по http!

TW>Ведь man in middle может сделать вид, что на сайте этот файлик есть, а на самом деле, его там нет. И получить валидный сертификат на любой сайт

TW>Я прав? Это угроза безопасности всей системы https?
TW>Или я что-то не понимаю?

TW>Или есть какой-то фикс к этому?
TW>Например, каталог всех сертификатов, где можно найти дубль

Предполагается, что тот кто будет проверять сертификат знает как Lets Encrypt и ему подобные его выдают и на основании собственных политик безопасности решает доверять ему или нет. Вообще тут все построено на доверии к третьему лицу.

Здравствуйте, TailWind, Вы писали:

TW>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?

TW>Или я что-то не понимаю?

Смыслов много, это только один из них, и не самый важный.

Здравствуйте, Stanislaw K, Вы писали:

TW>>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?
TW>>Или я что-то не понимаю?
SK>Смыслов много, это только один из них, и не самый важный.

Если бы этот смысл был не самым важным для заправил индустрии, браузеры бы не закатывали такие истерики от самоподписаных сертификатов.

Мне по работе приходится иметь дело с https в локальных сетях. Глобальные сертификаты на внутренние адреса выдать невозможно, локальных центров сертификации чаще всего нет. Всех приходится заставлять прокликивать эти два экрана истерик браузеров о катастрофических нарушениях безопасности и объяснять, почему эти два экрана истерик — это на самом деле безопаснее, чем если бы мы работали по открытому http, с которым браузеры никаких истеричных экранов не показывают.

A> локальных центров сертификации чаще всего нет. Всех приходится заставлять прокликивать эти два экрана истерик браузеров о катастрофических нарушениях безопасности и объяснять, почему эти два экрана истерик — это на самом деле безопаснее, чем если бы мы работали по открытому http, с которым браузеры никаких истеричных экранов не показывают.

Странно всё это. В корп. среде обычным пользователям сертификат локального CA просто "прилетает" через доменные политики (или их аналог).
А продвинутые пользователи сами знают, что и куда прописать.

Я чаще сталкивался с кривой настройкой серверов, когда у части ресурсов доступ по https поломан.

Здравствуйте, m2user, Вы писали:

M>Странно всё это. В корп. среде обычным пользователям сертификат локального CA просто "прилетает" через доменные политики (или их аналог).

После этого хозяин домена сможет незаметно выступать в роли mitm, не?

M>А продвинутые пользователи сами знают, что и куда прописать.

и прописывать ли вообще.

Здравствуйте, aik, Вы писали:

M>>Странно всё это. В корп. среде обычным пользователям сертификат локального CA просто "прилетает" через доменные политики (или их аналог).

aik>После этого хозяин домена сможет незаметно выступать в роли mitm, не?


Если это и проблема (в локальной сети, в корпоративной среде), то она решается не техническими средствами.

M>>Странно всё это. В корп. среде обычным пользователям сертификат локального CA просто "прилетает" через доменные политики (или их аналог).

aik>После этого хозяин домена сможет незаметно выступать в роли mitm, не?

Да, но в корп. среде все данные и инфраструктура формально принадлежат работодателю. И работник обязан их использовать исключительно в рабочих целях.

Здравствуйте, m2user, Вы писали:

M>Да, но в корп. среде все данные и инфраструктура формально принадлежат работодателю. И работник обязан их использовать исключительно в рабочих целях.

Да это пожалуйста, но хотелось бы чтоб браузер как то предупреждал по-лучше, когда сертификат подменён на конторский. Сейчас это такой же замочек в файрфоксе, надо ткнуть в него чтоб прочитать что сертификат так то вообще левый.

Здравствуйте, aik, Вы писали:

M>>Да, но в корп. среде все данные и инфраструктура формально принадлежат работодателю. И работник обязан их использовать исключительно в рабочих целях.

aik>Да это пожалуйста, но хотелось бы чтоб браузер как то предупреждал по-лучше, когда сертификат подменён на конторский.

В старом firefox был addon "Certificate Patrol" https://github.com/tg-x/certpatrol

You’ll see certificate information pop up whenever you visit a new HTTPS website, including https://addons.mozilla.org for example. “New” is anything Patrol hasn’t seen and stored yet.

You are also prompted whenever a web site updates its certificate and given the opportunity to compare the two certificates side by side, line by line. See the screenshot for an example.

Even if you do not fully understand what is shown to you, you get a chance of distinguishing legitimate from suspicious changes.

Here’s a little list of things to look out for:

If the old certificate is about to expire (Validity / Expires On), it was necessary to replace it with a new one.
In most cases web sites keep using the same certification authority (Issued By) over time. Should the web site have changed its certification authority, make sure the old certificate was about to expire.
You may want to consider the most popular CAs (like maybe CAcert, Entrust, Equifax, GoDaddy, NetworkSolutions, Thawte and VeriSign.. to mention some) to be less likely to help in MITM attacks, but that is only a guess. Especially since in each country local CAs may be legitimately well established.
Comodo, GeoTrust, GlobalSign, QuoVadis, RSA WebTrust and StartCom are known to offer intermediate CA for money. Still StartCom is extremely popular with small and private web sites for its free services.
If all certificates you see are always issued by the same certification authority, you should be very suspicious. Try searching for random HTTPS sites and see if they still all appear to be signed by the same CA.
In case of doubt install the Perspectives add-on to make further checks on the credibility of a certificate. The downside of Perspectives is, you reveal who you communicate with to an external service — so better only use it when necessary.
If the web site is important to you, make a research on the name of the new CA. Make a phone call to the owner of the web site and ask them to confirm the SHA1 fingerprint shown on your screen. Ask them to send you future certification data by snail mail <i>before</i> they install it.

It is very important to understand that certificates do not make a statement about the trustworthiness of a web site, but whether that web site is indeed what you think it is. In practice you should always be very suspicious if there are problems with your electronic banking or other sites you trust for very important operations, whereas you can probably relax if a certification problem arises for a web site that you are merely intending to have a quick look at. <b>The more a web site is important to YOU, the more you should be cautious!</b> That is the most essential rule of thumb in dealing with the wild west of Internet certification today.

Здравствуйте, /aka/, Вы писали:

TW>>>Или я что-то не понимаю?
SK>>Смыслов много, это только один из них, и не самый важный.

A>Если бы этот смысл был не самым важным для заправил индустрии, браузеры бы не закатывали такие истерики от самоподписаных сертификатов.

Вопрос — кому они закатывают истерики и что они с этого имеют.
Обычным пользователям. Имеют поведенческий анализ и таргетированный показ рекламы. Обычные пользователи за это получают "защиту" от MItM внедрения посторонней рекламы.

A>Мне по работе приходится иметь дело с https в локальных сетях. Глобальные сертификаты на внутренние адреса выдать невозможно, локальных центров сертификации чаще всего нет.

Локальный CA поднимается с перекурами за день, но объективно имеет смысл лишь при централизованном администрировании локальной сети и трудозатраты оправдываются только при достаточном размере этой сети.

A>Всех приходится заставлять прокликивать эти два экрана истерик браузеров о катастрофических нарушениях безопасности и объяснять,

Есть два костыля. первый — получать *.mycompany.tld и деплоить его на локальные ресурсы. второй — split dns. на один какой-то из внешних серверов получать всю пачку switchXX.mycompany.tld db.mycompany.tld etc.. (но второй менее секурный, фактически трясешь перед третьими лицами всё нижнее бельё).

A>почему эти два экрана истерик — это на самом деле безопаснее, чем если бы мы работали по открытому http, с которым браузеры никаких истеричных экранов не показывают.

Как в локальной сети https повышает безопасность, между локальным сервером и локальным клиентом?

Здравствуйте, Stanislaw K, Вы писали:

SK> Как в локальной сети https повышает безопасность, между локальным сервером и локальным клиентом?

А что не так? Между сервером и клиентом есть какая-то среда передачи данных (провод, wifi). Среда передачи уязвима к различным атакам. Даже в рамках одного железного хоста использование TLS может иметь смысл.

Здравствуйте, Anton Batenev, Вы писали:

SK>> Как в локальной сети https повышает безопасность, между локальным сервером и локальным клиентом?

AB>А что не так? Между сервером и клиентом есть какая-то среда передачи данных (провод, wifi). Среда передачи уязвима к различным атакам.

Локальная сеть, обычно, подразумевается приватной доверенной средой.
Гостей же пускать только в физически изолированный сегмент, может быть vlan.

AB>Даже в рамках одного железного хоста использование TLS может иметь смысл.

Это уж совсем какое-то параноидально-исключительное стечение обстоятельств.

Здравствуйте, Stanislaw K, Вы писали:

SK> AB>А что не так? Между сервером и клиентом есть какая-то среда передачи данных (провод, wifi). Среда передачи уязвима к различным атакам.
SK> Локальная сеть, обычно, подразумевается приватной доверенной средой.

Логически — возможно. Но физически она никак не может быть доверенной. Разве что все провода находятся в охраняемом 24х7 периметре со всеми другими мерами обеспечения физической безопасности. Но даже в этом случае использование TLS будет одной из мер.

SK> AB>Даже в рамках одного железного хоста использование TLS может иметь смысл.
SK> Это уж совсем какое-то параноидально-исключительное стечение обстоятельств.

Например в kubernetes, когда на железной ноде запущено бог знает сколько всяких pod-ов и потенциально может появиться pod, способный слушать трафик соседей. Принцип zero trust делает использование TLS даже в рамках железной ноды вполне разумным.

Здравствуйте, Anton Batenev, Вы писали:

SK>> Локальная сеть, обычно, подразумевается приватной доверенной средой.

AB>Логически — возможно. Но физически она никак не может быть доверенной. Разве что все провода находятся в охраняемом 24х7 периметре со всеми другими мерами обеспечения физической безопасности. Но даже в этом случае использование TLS будет одной из мер.

Физическая изоляция сегментов и IPsec решают.

SK>> AB>Даже в рамках одного железного хоста использование TLS может иметь смысл.
SK>> Это уж совсем какое-то параноидально-исключительное стечение обстоятельств.

AB>Например в kubernetes, когда на железной ноде запущено бог знает сколько всяких pod-ов и потенциально может появиться pod, способный слушать трафик соседей. Принцип zero trust делает использование TLS даже в рамках железной ноды вполне разумным.

И в таком колхозе обрабатывать чувствительные данные? С сертификатом выданным третьими лицами?

Цирк.

Здравствуйте, Anton Batenev, Вы писали:

AB>Даже в рамках одного железного хоста использование TLS может иметь смысл.

Не имеет.

Здравствуйте, TailWind, Вы писали:

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

Здравствуйте, TailWind, Вы писали:

TW>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?
Нет конечно

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду
Мало ли что предполагалось, это нетехнический аспект.
По сути единственное требование — подтвердить издателю что ты владеешь именем, для которого выпускаешь сертификат. Для этого достаточно DNS\Whois или ручное размещение файла на сервере за этим именем, доступного по любому протоколу.

TW>А теперь что? Ничего не нужно? Можно получить сертификат с консоли:
TW>https://habr.com/ru/articles/667158/

TW>Ведь man in middle может сделать вид, что на сайте этот файлик есть, а на самом деле, его там нет. И получить валидный сертификат на любой сайт
Приведи пример атаки. Это же тебе надо стать между Lets Encrypt и сервером для которого выпускается сертификат, причем как-то узнать какой пароль от тебя хочет видеть Lets Encrypt, а он тебе сообщает его по HTTPS

TW>Или я что-то не понимаю?
Скорее всего

TW>Или есть какой-то фикс к этому?
Я думаю кто это придумал вовсе не идиоты и скамеры.

G>Приведи пример атаки. Это же тебе надо стать между Lets Encrypt и сервером для которого выпускается сертификат

Да, именно так

G>причем как-то узнать какой пароль от тебя хочет видеть Lets Encrypt, а он тебе сообщает его по HTTPS

Нет
Злоумышленник сделает запрос сам в Lets Encrypt, чтобы тот выдал ему сертификат
Lets Encrypt пришлёт ему пароль
Далее он имитирует сраницу http с паролем. Это же http. Тут нет ничего сложного. Если ты посередине

Здравствуйте, TailWind, Вы писали:

G>>причем как-то узнать какой пароль от тебя хочет видеть Lets Encrypt, а он тебе сообщает его по HTTPS

TW>Нет
TW>Злоумышленник сделает запрос сам в Lets Encrypt, чтобы тот выдал ему сертификат
TW>Lets Encrypt пришлёт ему пароль
Так не по http же шлет? Как ты пароль узнаешь который подсунуть будучи в середине?

TW>Далее он имитирует сраницу http с паролем. Это же http. Тут нет ничего сложного. Если ты посередине
Ага, кроме того чтобы узнать какой пароль

G>Так не по http же шлет? Как ты пароль узнаешь который подсунуть будучи в середине?

Я ссылку дал, как это делается. Я понимаю что там много текста. Но я когда прочитал, был очень удивлён
https://habr.com/ru/articles/667158/

Если коротко:
Надо скачать их утилитку и с неё послать запрос. Утилитка консольная, под винду. Запрос можно послать с любого компа
То есть в этот момент ты не man-in-middle

Здравствуйте, TailWind, Вы писали:

TW>Если коротко:
TW>Надо скачать их утилитку и с неё послать запрос. Утилитка консольная, под винду. Запрос можно послать с любого компа
Там нет инфы откуда certbot берет нужный пароль. Но есть ощущение, что там HTTPS и хрен ты его перехватишь.


TW>То есть в этот момент ты не man-in-middle
То есть нет

Я думаю придумали эту штуку люди, которые умнее тебя и меня. Наивно предполагать обратное.

G>Там нет инфы откуда certbot берет нужный пароль. Но есть ощущение, что там HTTPS и хрен ты его перехватишь.

Вы упрорно не понимаете, что не нужно перехватывать пароль

Вы сами можете подать запрос совершенно официально обратившись в Lets Encrypt
С помощью этой утилитки, которая больше никак не проверяет, вы ли владелец

Она спрашивает только: email, имена доменов. И присылает пароль. Её не надо запускать на сервере. Её можно запустить с любого компа

TW>Вы упрорно не понимаете, что не нужно перехватывать пароль

Перехватывать нужно не пароль, а владение DNS. Что делает let's encrypt — подтверждает, что вы в самом деле имеете доступ к DNS данного домена. Это их назначение и единственная функция. Если вы каким-то образом продолбали пароли вашего регистрара (или хостите ваш DNS непонятно где и непонятно как), ССЗБ.

Всё я пониял, в чём моя ошибка

Наверняка, если у сайта уже работает https, то проверять пароль он будет по https, а не по http

Тупанул, сорян )

Здравствуйте, gandjustas, Вы писали:

TW>>Далее он имитирует сраницу http с паролем. Это же http. Тут нет ничего сложного. Если ты посередине
G>Ага, кроме того чтобы узнать какой пароль

Да и посередине оказаться нелегко...

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, gandjustas, Вы писали:

TW>>>Далее он имитирует сраницу http с паролем. Это же http. Тут нет ничего сложного. Если ты посередине
G>>Ага, кроме того чтобы узнать какой пароль

Pzz>Да и посередине оказаться нелегко...

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

Здравствуйте, gandjustas, Вы писали:

Pzz>>Да и посередине оказаться нелегко...

G>Посередине межу двумя хостерами имхо почти нереально. А вот оказаться посередине между кточным юзером и сайтом — слишком легко, достаточно бесплатный вайфай в людном месте развернуть. Но перехватить код от letsencrypt тебе не поможет.

Ну вот я про то и говорю.

Здравствуйте, gandjustas, Вы писали:

G>Приведи пример атаки. Это же тебе надо стать между Lets Encrypt и сервером для которого выпускается сертификат, причем как-то узнать какой пароль от тебя хочет видеть Lets Encrypt, а он тебе сообщает его по HTTPS

ЕМНИП, плохие парни получали дубликаты ACME сертификатов раза три. Точнее — три раза это становилось известно.
Один раз точно известно что воспользовались доступом к dns. Про остальные детального разбора не было опубликовано.

Здравствуйте, Stanislaw K, Вы писали:

SK>Здравствуйте, gandjustas, Вы писали:

G>>Приведи пример атаки. Это же тебе надо стать между Lets Encrypt и сервером для которого выпускается сертификат, причем как-то узнать какой пароль от тебя хочет видеть Lets Encrypt, а он тебе сообщает его по HTTPS

SK>ЕМНИП, плохие парни получали дубликаты ACME сертификатов раза три. Точнее — три раза это становилось известно.
SK>Один раз точно известно что воспользовались доступом к dns. Про остальные детального разбора не было опубликовано.

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

Здравствуйте, gandjustas, Вы писали:


SK>> Про остальные детального разбора не было опубликовано.

G>Перехватить серты из-за ошибок конфигурации сильно проще, чем MITM атаку провернуть между двумя провайдерами.

Можно получить вместо бесплатного ACME сертификата Lets Encrypt, получить бесплатный ACME сертификат BuyPass или ZeroSSL

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду

Возможно, что другие УЦ проверяют по той же схеме как Lets Encrypt. А как ещё по простому подтвердить права на домен?

TW>Я прав? Это угроза безопасности всей системы https?
TW>Или я что-то не понимаю?

В принципе прав. Вот пример такой атаки — https://www.opennet.ru/opennews/art.shtml?num=59965

TW>Или есть какой-то фикс к этому?
TW>Например, каталог всех сертификатов, где можно найти дубль

По ссылке выше в конце приведены рецепты:
1) CAA запись в DNS (но если MITM пролез и в DNS без TLS, то тоже не поможет)
2) CT-logs — это как раз средство отслеживания дублей

Здравствуйте, TailWind, Вы писали:

TW>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?

А в чём, по-твоему, смысл TLS, https?

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду

Чтобы получить EV-сертификат, действительно, надо предоставить документы. У сайтов, которые подписаны таким сертификатом, строка URL в бровсере светится зелёненьким.

Чтобы получить обычный сертификат, достаточно продемонсрировать (электронным способом) свой контроль над доменом. Это может быть размещение специальной хрени по определенному пути HTTP-сервера на этом домене, или даже способность принимать e-mail по адресу postmaster@domain.com

TW>Ведь man in middle может сделать вид, что на сайте этот файлик есть, а на самом деле, его там нет. И получить валидный сертификат на любой сайт

А как воткнуть мужика-посерёдке между Lets Encrypt-овским сервером и проверяемым сайтом?

TW>Я прав? Это угроза безопасности всей системы https?

У меня система https не вызывает особого доверия. Уж больно много в ней организаций, имеющих право выдавать сертификаты, которым верит любой бровсер.

Здравствуйте, TailWind, Вы писали:

TW>Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?

Cмысл TLS был в том, чтобы рукопожатые люди могли на пустом месте делать деньги, раздавая сертификаты другим рукопожатым людям. В начале всё так и было. Но что-то вышло из под контроля. Я помню, как израильский StartSSL начал раздавать сертификаты дёшево и требовал только подтвердить владение доменом, в то время это было революцией. Его долго тероризировали справедливым западным правосудием и в конце додолбали до того, что им пришлось бежать в Китай. Но видимо дыру заткнуть не удалось, и сертификаты на основании одного только подтверждения владения доменом стали выдавать другие. После чего рукопожатые сделали вид, что так и задумывалось, и запустили Lets Encrypt.

Т.е. Lets Encrypt ничего не рушит, всё посыпалось до него.

А например с подписью кода такой же беды не случилось: сертификаты на код по-прежнему раздаёт узкий круг рукопожатых людей, и возможность оставить неугодных без сертификатов на код мы прочувствовали в 2022.

Здравствуйте, TailWind, Вы писали:

TW> Не рушат ли бесплатные сертификаты от Lets Encrypt весь смысл TLS, https?

* Смысл у TLS один единственный — защита от MITM. Публичные центры выдачи сертификатов к этому смыслу не имеют ровным счетом никакого отношения.
* Инфраструктура LetsEncrypt — это вопрос построения цепочки доверия, а не защиты от MITM.

Т.е. ты смешал две разных сущности в одну: TLS — сам по себе, LE — сам по себе, "взболтать, но не смешивать" и вопрос получается лишенным смысла.

Здравствуйте, TailWind, Вы писали:

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду

Документы требовали для Extended Validation, которые стоили дороже и в адресной строке обозначались зеленым замочком.
На обычные — документы не требовались, до Lets Encrypt уже существовали варианты получения бесплатных сертификатов, например, WoSign.

Здравствуйте, TailWind, Вы писали:

TW>Я так понимаю, чтобы получить сертификат ssl предполагалось, что компания владелец домена должна владельцам корневых сертификатов предоставить уставне документы, паспортные данные и прочее. То есть пройти полную проверку. По аналогии с тем как мы получаем сертификаты подписи кода под винду

Я лично считаю, что нет. То что у тебя написано придумали те кто хотят почти ничего не делать и зарабатывать огромные деньги. А всё за счёт того, что в операционные системы или браузеры заранее поставлены их корневые сертификаты. Дайте поставить свои корневые сертификаты другим в браузеры и операционные системы и подобный бизнес загнётся. Понятно, что не дадут, ведь браузеры имеют спонсоров, а операционные системы владельцев.

Что касается https, то это зашифрованный канал связи для протокола http. Причём как мы теперь знаем кто просто так, а кто-то вроде меня благодаря РосКомНадзору, есть ещё tls разных версий. Вот там и улучшается защита связи от версии к версии и что дико не нравится РосКомНадзору, который хочет осуществлять атаку посредника над любым устройством в российском сегменте сети интернета.

Кстати, пока с той стороны, то есть извне России не рубанули поддержку российских сертификатов тех же сайтов, я и не задумывался о том где лежат все эти сертификаты. А задумался я потому, что в те времена чужие сайты стали терять сертификаты и следовательно https. Не все вот так сразу сориентировались и перешли на что-то другое для https.

Firefox (десктоп)

Настройки > Приватность и Защита > [Сертификаты] - Просмотр сертификатов > Центры сертификации

Android 14 (Samsung)

Настройки > Безопасность и конфиденциальность > [Дополнительные настройки безопасности] - Другие настройки безопасности > Сертификаты безопасности

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

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

Опять же если это говорю я, то люди на рсдн начинают возникать, да кто ты такой. Недавно по рекомендации здесь же на rsdn почитал ссылку.
https://rsdn.org/forum/shareware/8925352.1
https://successfulsoftware.net/articles/

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

Засовываем
https://successfulsoftware.net/2010/10/21/app-stores-set-to-dominate-future-software-sales/
в
translate.google.com

Магазины приложений будут доминировать в продажах программного обеспечения в будущем?

После успеха магазина приложений для iPhone (более 6 миллиардов загрузок на сегодняшний день) магазины приложений становятся все более и более важной частью ландшафта программного обеспечения. Если вы пропустили, вчера Apple объявила , что App Store для Mac появится «в течение 90 дней». Вкратце:

1. Магазин приложений Mac будет тесно интегрирован с Mac OS X, включая автоматическую установку и обновление.
   
2. Будут введены ограничения на технологии, например, приложения Java не будут разрешены.
   
3. Apple оставит себе 30% от выручки от продаж.
   
4. Подписка для разработчиков за 99 долларов в год.
   
5. Разработчики по-прежнему смогут продавать свое программное обеспечение за пределами App Store.

Легко понять, почему Apple захотела это сделать:

1. Потенциально огромный новый источник дохода от продажи стороннего программного обеспечения для Mac.
   
2. Они получают еще больший контроль над взаимодействием с клиентами.

И это может иметь преимущества для пользователей Mac:

1. Более простая оплата и установка.
   
2. Отсеивание некачественных приложений и вредоносного ПО.

И потенциальные преимущества для разработчиков Mac:

1. Пользователи Mac могли бы покупать больше программного обеспечения, если бы это было проще сделать.
   
2. Один основной канал, на котором следует сосредоточить свои маркетинговые усилия.
   
3. Часть скучной инфраструктуры продажи программного обеспечения (лицензирование, корзина покупок и т. д.) может взять на себя Apple.

Но недостатки слишком очевидны:

1. Ваше приложение может быть отклонено сразу. И вы не узнаете об этом, пока не отправите его на одобрение. Apple — судья, присяжные и палач. Магазин приложений iPhone печально известен своим капризным и непрозрачным процессом одобрения.
   
2. 30% — это огромная часть дохода. Типичные платежные системы забирают 5–10% дохода. Когда новый магазин приложений каннибализирует существующие продажи (и трудно предположить, что этого не произойдет), поставщики потеряют 20–25% существующих доходов от продаж.
   
3. Новые приложения и обновления будут задерживаться на несколько дней или недель, поскольку они проходят процедуру одобрения в магазине приложений.
   
4. Единый централизованный магазин приложений, скорее всего, затруднит существование нишевых/длиннохвостовых приложений. Определенно, это то, что, похоже, происходит в магазине приложений iPhone .
   
5. Apple — помешанные на контроле и традиционно придерживаются довольно жесткого подхода к разработчикам, включая либеральное использование NDA . Магазин приложений даст им еще больше контроля.

А дальше может быть еще хуже:

1. Apple зарабатывает много денег, продавая переоцененное оборудование. Возможно, в их интересах снизить цены на программное обеспечение, чтобы продавать больше оборудования. Цена в 5 долларов считается высокой в ​​iPhone App Store.
   
2. Это может стать первым шагом на пути к тому, чтобы сделать Mac OS X закрытой системой, подобной iPhone, на которую можно устанавливать только приложения, одобренные Apple.

Думаю, они не могут слишком сильно злить разработчиков — компьютер без сторонних приложений не будет очень привлекателен для клиентов. Но мне сложно вызвать энтузиазм по поводу магазина приложений для Mac. Если он будет успешным, я могу либо остаться в магазине и отказаться от большой части свободы и поглотить существующие продажи с гораздо меньшей маржой, либо остаться в стороне и быть отрезанным от большой части рынка. Это не привлекательный выбор. Поскольку мое приложение написано на C++/Qt, а не на Objective-C/Cocoa, я даже не уверен, что оно будет иметь право на включение в магазин. Я мог бы просто отказаться от Mac OS X, но, по слухам, Microsoft также работает над своим собственным магазином приложений (несмотря на провал DigitalLocker ). Это действительно ужасающая перспектива, учитывая ужасность их процесса утверждения «Работает с Vista» (я говорю по личному опыту).

Внезапно веб-приложения стали выглядеть более интересными.

----Дэн Уиз

21 октября 2010 г. в 23:43

Я прошел процесс «Работает с Windows 7», и это было пустяком. Тест Vista был кошмаром, но, должно быть, он был для всех, потому что они сделали это намного проще с Windows 7. Я бы сказал, что преимущество для Microsoft, имеющей магазин приложений сейчас, заключается в том, что так много людей знакомы с концепцией магазина приложений благодаря iPhone, iPad и Android, что он может быть более хорошо принят, особенно с моделью развертывания ClickOnce приложений WPF и Silverlight. Что касается вашего комментария о том, что вас оторвут от «большой части рынка», если вы не продаете свое приложение в магазине Mac, у Mac по-прежнему всего около 5% доли рынка персональных компьютеров, поэтому я бы вряд ли назвал это большим, если бы вы не сравнивали его с долей Linux. Я бы согласился с этим утверждением, если бы вы строго имели в виду магазин приложений iPhone/iPad, поскольку они явно являются доминирующими доступными телефонами/планшетами.

--------Энди Брайс Автор поста

22 октября 2010 г. в 9:07 утра

>Что касается вашего комментария о том, что вас отрезают от «большой части рынка», если вы не продаете свое приложение в магазине Mac, то доля Mac на рынке персональных компьютеров по-прежнему составляет всего около 5%.

Я имел в виду большую часть рынка Mac. Кроме того, Mac вырос до почти 10% рынка настольных компьютеров.

----Кристофер Бруно

22 октября 2010 г. в 3:59 утра

Согласен, магазин приложений для Mac OS X не впечатляет. Он имеет смысл для iPhone, где такие вещи, как небольшие игры, должны быть нативными, чтобы хорошо работать. Но для настоящего компьютера большинство этих тривиальных игр можно запустить в браузере. Остаются нетривиальные приложения, которые можно распространять через Интернет так же просто, как магазин приложений. Возможно, пользователю будет немного проще/удобнее загрузить Pages или Word из магазина приложений (вместо перехода на страницу продукта). Однако, за исключением небольших тривиальных игр, я не думаю, что стоит отказываться от 30% дохода в обмен на немного более простое распространение и обработку платежей.

----Кристофер Бруно

22 октября 2010 г. в 5:42 утра

Я не думаю, что приложения Qt будут приняты:

http://www.qtcentre.org/threads/35292-Qt-Apps-banned-from-Mac-App-Store?p=163002

--------Энди Брайс Автор поста

22 октября 2010 г. в 9:08 утра

Похоже, это решение уже принято за меня.

----Рико

22 октября 2010 г. в 6:24 утра

30% от выручки по сравнению с 10%, которые взимает платежный процессор, может показаться большой суммой, но вы должны учесть еще одну вещь, которая чертовски важна, особенно для небольших компаний-разработчиков ПО и отдельных разработчиков: охват. Донести свое приложение до тысяч, потенциально миллионов людей сложно, если не невозможно для небольших магазинов (по крайней мере, предсказуемым, повторяющимся образом).

Попадание в число первых 1000 приложений, когда выйдет магазин приложений, увеличит количество посетителей и продажи (надеюсь). Проблема в том, что в долгосрочной перспективе его будет так же трудно увидеть в магазине приложений, как и в сети (или сложнее, поскольку магазин приложений более ограничителен). Сколько приложений сейчас в магазине приложений для iPhone? 300 000?

Ваша статья прекрасно подводит итоги. Я полностью согласен с вашим выводом о том, что может последовать: клиенты будут ожидать недорогого программного обеспечения не только для своего iPhone, но и для своего Mac.

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

Можно ли компенсировать более низкую цену большим объемом? Даже если можно: есть одно важное отличие между приложениями для iPhone и приложениями для Mac — запросы на поддержку.

Приложения для iPhone используются в течение коротких промежутков времени «между» другими задачами. Если что-то идет не так, пользователь перезапускает приложение. Приложения для Mac используются в течение более длительных периодов дня для выполнения работы. Если что-то не работает, пользователь, скорее всего, обращается на вашу горячую линию поддержки/по электронной почте.

Это еще один большой удар для небольших компаний-разработчиков ПО: они просто не могут справиться с огромным количеством запросов на поддержку. Модель MicroISV с меньшим количеством продаж по более высокой цене не будет работать, когда вам придется компенсировать низкую маржу более высоким объемом.

--------Энди Брайс Автор поста

22 октября 2010 г. в 9:10 утра

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

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

--------Клэй Николс

22 октября 2010 г. в 11:12 утра

Рико,

Размещение вашего приложения в App Store не делает его «видимым» для всех посетителей магазина.

В случае Энди, он показывает его только тем, кто ищет в магазине программное обеспечение для свадеб. Энди уже занимает 2-е место по запросу «программное обеспечение для рассадки на свадьбах» в Google. Дополнительные затраты? $0. Ценность? Бесценна.

Хм... Интересно, пытается ли Apple сделать комплименты общедоступными?
Я думаю, что эта стратегия не сработает в долгосрочной перспективе, потому что снижение цены на программное обеспечение (по указанным вами причинам) приведет к снижению его сложности: приложения для Mac станут такими же простыми, как Google Apps: массовые, общедоступные приложения.

Как вы думаете, кто победит в этой битве: Google или Apple?
У Google есть преимущество: их приложениями смогут пользоваться в 10 раз больше людей, и они будут бесплатными (с поддержкой рекламы).

----симы

22 октября 2010 г. в 6:49 утра

«Внезапно веб-приложения стали выглядеть интереснее». – ИМЕННО то, о чем я только что подумал. Именно.

Бинго! Лампочка загорелась.

----Ромен

22 октября 2010 г. в 7:48 утра

@sims: «Внезапно веб-приложения стали выглядеть интереснее». – ИМЕННО то, о чем я только что подумал. Именно.

Да, для приложений, которые хорошо подходят для модели подписки.
Но я сомневаюсь, что небольшие разовые платежи можно извлечь для веб-приложения. В отличие от магазина приложений/iTunes, которые делают очень простым и безболезненным для людей щелкнуть и заплатить $1-$5 за свое приложение.

----Энди Брайс Автор поста

22 октября 2010 г. в 9:49 утра

Больше отзывов разработчиков здесь:
http://www.tuaw.com/2010/10/21/developer-reactions-to-the-mac-app-store/

----Энди Брайс Автор поста

22 октября 2010 г. в 9:58 утра

Правила магазина приложений доступны здесь (я не проверял их точность):

http://pastie.org/pastes/1236378

----Чарли

22 октября 2010 г. в 1:20 дня

Еще одна причина, по которой будущее разработки приложений будет за онлайном.

Я думаю, что в краткосрочной перспективе разработчики примут эту модель, хотя я думаю, что непреднамеренные последствия, о которых вы говорите, совершенно верны. Крупные компании-разработчики программного обеспечения заплатят за дополнительный канал распространения, а компании поменьше упростят свои приложения, чтобы хеджировать риски. Со временем я ожидаю увидеть все больше и больше мелких разработчиков, переходящих на веб-приложения, где, как предсказывает Google, будет будущее вычислений (с тонким рабочим столом и всеми приложениями онлайн). Так что это может быть только краткосрочной/среднесрочной тенденцией, которая будет перекрыта более крупной тенденцией в следующем десятилетии.

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

Обратная ссылка: Будущее независимой разработки ПО | Самостоятельная независимость

----Чандра

24 октября 2010 г. в 12:01

Многие программисты Delphi ожидают появления платформы Delphi, но… похоже, это положит конец Delphi для Mac… хнык…

----Чандра

24 октября 2010 г. в 12:16

Хотел сказать «мультиплатформенный». Извините.

----Сергей Колоколкин

19 ноября 2010 г. в 17:55

Энди, поскольку у тебя уже есть приложения на основе Qt для Mac OS X, не мог бы ты попробовать и отправить одно из них в новый Mac App Store (магазин приложений для приложений Mac OS X)? Mac App Store уже открыт для отправки.

Мое приложение на основе Qt еще не закончено… Если они примут приложения на основе Qt, я не буду беспокоиться о собственной защите от копирования и автоматических обновлениях.

У меня есть приложение для iPhone, и оно обеспечивает достаточно дохода для моей семьи в течение последних 2 лет. Я бы с удовольствием добавил свое десктопное приложение в десктопный Mac App Store.

----Энди Брайс Автор поста

19 ноября 2010 г. в 18:09

Сергей,

Я жду, что произойдет, когда другие люди отправят приложения Qt в Mac App Store. ;0)

--------Сергей Колоколкин

19 ноября 2010 г. в 7:24 вечера

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

Я отправил свое приложение для iPhone вскоре после открытия магазина приложений iOS. Сначала конкуренции почти не было, и продажи были отличными, несмотря на то, что в той версии моего приложения было примерно 1/4 функциональности по сравнению с текущей версией. Эти продажи побудили меня прекратить свой контракт на программирование и работать исключительно на себя.

----симы

20 ноября 2010 г. в 6:44 утра

Думаю, меня ждет смена карьеры. Может, стану коком/матросом на большом паруснике в Средиземном море, может, ныряльщиком в мусорные контейнеры в Риме.

Сейчас не знаю.

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

Просто я не чувствую теплых чувств по поводу того, что маячит на горизонте.

[пожалуйста, извините за драматизм, если это оскорбляет – для меня это кажется реальным]

----Сергей Колоколкин

28 ноября 2010 г. в 3:58 утра

Я не вижу технических причин, по которым Apple могла бы отклонить приложение Qt, если приложение включает в себя все необходимые функции Qt внутри пакета (например, в качестве закрытого фреймворка).

Но они могут отклонять приложения Qt из-за ошибок Qt, из-за которых приложения Qt выглядят нестандартными на компьютерах Mac.

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

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

http://bugreports.qt.nokia.com/browse/QTBUG-15474
http://bugreports.qt.nokia.com/browse/QTBUG-15475

----Амрит

6 апреля 2011 г. в 10:06 утра

Я уже проверил приложение Qt в Xcode... оно работает нормально... но проблема в том, как загрузить приложение Qt в магазин приложений Mac. Опция «Сборка и архивация» отключена в моем Xcode в проекте Mac, и он не показывает ни одного устройства.
И загрузчик приложений также не работает.