А как нынче модно прозрачно MITM-ить SSL?

Хз как модно, но по описанному тобой способу помимо браузеров подсовывать придется еще в системные сертификаты, и во всякие jvm, которые часто кладут хрен на системные.

AFAIK, хром не просто положит хер на твой сертификат для gmail, но еще и стуканёт на тебя гуглу

Не только для gmail, там целый список привязанных доменов

https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_...

Кстати, если вручную добавить рутовый CA, то pinning не работает

https://www.imperialviolet.org/2011/05/04/pinning.html

There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins.

https://www.google.com/intl/en/chrome/browser/privacy/

If you attempt to connect to a Google website using a secure connection, and the browser blocks the connection due to information that indicates you are being actively attacked by someone on the network (a «man in the middle attack»), Chrome may send information about that connection to Google for the purpose of helping to determine the extent of the attack and how the attack functions.

Так были выявлены поддельные сертификаты агентства по сетевой и информационной безопасности Франции, за что последние успешно вылетели из списка доверенных промежуточных УЦ.

Это другой случай, слажали встроенные CA. Если каждому пользователю в браузер ручками добавить сертификат, проверка для него работать не будет.

Чем добавление «в браузер ручками » лучше, чем добавление вендором в OS/браузер?

Чем добавление «в браузер ручками » лучше, чем добавление вендором в OS/браузер?

Ну я выше приводил цитату - поскольку встречаются «легальные» случаи MITM вроде корпоративного прокси. Чтобы не сломать таких клиентов - сделали такой костыль.

что-то не складывается взаимопонимание

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

1.Они хранятся по-разному - например, в nss, которую используют Firefox и Chrome/Chromium встроенные рутовые сертификаты поставляются в виде разделяемой библиотеки (libnssckbi.so), пользовательские сертификаты хранятся в базе данных (Berkley DB или SQLite).

2. Браузер по-разному производит проверку цепочки сертификатов. Если в цепочке есть сертификат, добавленный пользователем, то браузер не производит дополнительных проверок, если цепочка подписана встроенным рутовым сертификатом, то включаются дополнительные проверки - сертификат проверяется в pinning листах, проверяются блеклисты промежуточных центров сертификации.

Что такое pinning list - это список соответствий доменов и сертификатов/ключей, которыми разрешается подписывать сертификат для данного домена. Например, для google.com указывается публичный ключ, которым должен быть подписан хотя бы один сертификат в цепочке. И повторю еще раз - эта проверка пропускается, если в цепочке сертификатов встретился сертификат, явно добавленный пользователем как доверенный.

А где-нибудь навскидку нету каких примеров таких сетапов? Чтобы сквид с CA связать?

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

Это утверждение основано на анализе сорцов хрома или публичной полиси гугла или это относится к сферическому браузеру вообще (а не хрому) или еще чём-то кроме описания Public key pinning на imperialviolet.org? (4-летней давности, к слову сказать)

Это утверждение основано на анализе сорцов хрома

Да. Из кода chromium/src/net/socket/ssl_client_socket_nss.cc

  // Perform pin validation if, and only if, all these conditions obtain:
  //
  // * a TransportSecurityState object is available;
  // * the server's certificate chain is valid (or suffers from only a minor
  //   error);
  // * the server's certificate chain chains up to a known root (i.e. not a
  //   user-installed trust anchor); and
  // * the build is recent (very old builds should fail open so that users
  //   have some chance to recover).
  //

Это не работает со всеми типами сертификатов. У меня есть кальмар с митмом. Все гуглевские домены пришлось пустить директом. Хотя для многих прокатило.

Это не работает со всеми типами сертификатов.

Ты о чем? Что для хромиума нельзя обойти pinning проверку? Скорее всего, ты делаешь что-то не так - судя по коду точно можно.

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

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

Кусок рабочего конфига, касающийся SSL-бампинга для Squid 3.4:

http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/squidCA.pem

sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/spool/squid3_ssldb -M 4MB

always_direct allow all
ssl_bump server-first all

Скормили пользователям корневой сертификат с прокси - гуглосервисы и прочие подобные нормально работают.

https://plus.google.com/116737397474904723219/posts/hZQEu7hANN3
Вот тебе цепочка сертификатов.
С нижним обход пининга не сработает. Сайты без пининга митмятся на ура. Проверено на практике. Плюсом сюда то, что не надо заставлять людей совать куда-то какие-то сертификаты, хотя браузер и ругается, натыкаясь на сертификат, подписанный сертификатом не являющимся корневым, или промежуточным ЦА.
С самоподписанными и одним уровнем иерархии обход пининга работает. Тоже проверено на практике. Но, требуется распространить сертификат своего самопального ЦА.
А своим мнением обо мне можешь и дальше гордиться, великий демонстратор непонятых комментариев в чужом коде.

Вот тебе цепочка сертификатов.

Что я по твоим скриншотам должен понять - для меня загадка. Ты попробуй словами объяснить - ты же великий знаток матчасти, для тебя не будет проблемы.

Плюсом сюда то, что не надо заставлять людей совать куда-то какие-то сертификаты,

Ты не можешь сделать рабочий MITM без ручного добавления сертификата на все клиенты.

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

Это называется успешным MITM ? Ты придуриваешься? Браузер показал предупреждение - MITM обнаружен.

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

Ты несколько строчек английских не можешь осилить? Мне для тебя перевести? Ты либо переходи к конкретике с предметным описанием что и как, либо иди набивай скор в другом месте.

Что за дурная привычка заливать непонятно куда и не давать прямую ссылку на изображение? Даже посмотреть что там такого особенного, нельзя.

На скриншотах цепочка с полем «основные ограничения сертификата». Там всё написано. Русским языком. Различие в этом поле как раз и влияет на то, воспримется ли цепочка как валидная. В случае если используется для mitm нижний сертификат, который «не является центром сертификации», то браузер отвергнет соединение, поскольку squid будет отдавать сертификат сайта подписанный вот таким неподходящим сертификатом.

Ты не можешь сделать рабочий MITM без ручного добавления сертификата на все клиенты.

Даже если у человека посередине сертификат промежуточного ЦА? А корневой ЦА уже есть в базе? Ты сильно ошибаешься.

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

Ты их себе лучше переведи, поскольку их не осилил именно ты.

Ты либо переходи к конкретике с предметным описанием что и как, либо иди набивай скор в другом месте.

Ты же всё-равно не поймёшь что тебе говорят.

Хм, странно, там вроде потс открыт всем подряд.
https://lh4.googleusercontent.com/-GHNjoYLzcD4/VPCIt-mLA-I/AAAAAAAACQM/nkv5ra...
Так видно? Это последняя картинка с сертификатом предназначенным для доменной валидации. С чего собственно и начался весь сыр-бор. Поскольку с таким сертификатом организовать mitm не получится. Хотя сам он валиднее некуда. Раньше не пускало на сайты с пином. Сейчас проверил — не пускает вообще никуда, хотя в сентябре прошлого года на лор я ходил по https с mitm через этот прокси огнелисом без проблем. Нужно было только подтвердить исключение безопасности в браузере.

Ты же просто валидный, судя по Comodo сертификат для домена показал. С ним у тебя только для указанного домена и значений в altnames будет сертификат валидироваться браузером.

На скриншотах цепочка с полем «основные ограничения сертификата». Там всё написано. Русским языком. Различие в этом поле как раз и влияет на то, воспримется ли цепочка как валидная.

Как работает Constraints я знаю. Понятно, что для подписи должен использоваться только сертификат, у которого в Basic Constrains прописано, что им можно подписывать другие сертификаты. Вот только какое отношение это имеет к пиннингу мне не понятно.

Даже если у человека посередине сертификат промежуточного ЦА? А корневой ЦА уже есть в базе? Ты сильно ошибаешься.

Откуда ты возьмешь приватный ключ промежуточного CA? Я про те, которые ведут к предустановленным в браузере сертификатам. Понятно, что ты можешь создать свой самопальный CA, и добавить его на все клиенты - но это как раз то, что я имел ввиду про ручное добавление сертифаката на все клиенты.

Ты же всё-равно не поймёшь что тебе говорят.

А ты попробуй. Или боишься показать свою некомпетентность?

Да, этот сертификат валидирует домен. Но на domain.tld:3128 можно же посадить mitm. Так вот если выпустить самоподписанный сертификат, со своим ЦА, то mitm на domain.tld:3128 будет прекрасно работать, надо только сертификат ЦА внедрить пользователям. В моём примере (с комодовским сертификатом) так не получится. Собственно это единственное, что я хотел здесь сказать. Что mitm не получится организовать с любым сертификатом.

С ним у тебя только для указанного домена и значений в altnames будет сертификат валидироваться браузером.

А был бы он с (например) «максимальное количество промежуточных центров классификации:0» то mitm с ним заработал, даже 0.

надо только сертификат ЦА внедрить пользователям.
Что mitm не получится организовать с любым сертификатом.

Нет если у тебя есть доступ к директории браузера пользователя, или ты так и так будешь устанавливать ему сертификат, то mitm можно сделать с любым сертификатом. Достаточно добавить его в нужном формате в файл cert_override в случае Firefox. Если у тебя физический доступ есть к машине пользователя, то можно вообще все что угодно организовать, никакой pinning и вообще ничего уже не поможет.

Как работает Constraints я знаю. Понятно, что для подписи должен использоваться только сертификат, у которого в Basic Constrains прописано, что им можно подписывать другие сертификаты.

Алилуйя! Наконец-то ты понял о чём речь.

Вот только какое отношение это имеет к пиннингу мне не понятно.

Такое, что squid сертификатом не предназначенным для подписывания вполне подписывает и в сентябре (когда я этим вопросом занимался) в файрфоксе такой бардак прокатывал. Ну ругался он на неверный самоподписанный сертификат. Но, на сайт пускал. На ЛОР. Но, ЛОР не использует пининг. А на сайтах с пинингом не прокатывало. Больше мне сказать нечего. Как это связано с пинингом уж сам решай.

Откуда ты возьмешь приватный ключ промежуточного CA?

Я ниоткуда не возьму. Насчёт третьих лиц я уже не настолько уверен. Откуда мне знать, что какой-нибудь промежуточный удостоверяющий центр не является слишком любопытным.

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

К этому процессу вообще никаких вопросов нет.

А ты попробуй. Или боишься показать свою некомпетентность?

Попробуй перечитать ещё раз вот это предложение: the server's certificate chain is valid (or suffers from only a minor error); В случае с domain validation ssl sertificate цепочка у mitm никак не может быть valid.

У меня нет физического доступа. От этого я и танцую. Если у меня доступ есть, то мне даже mitm делать не обязательно.

Такое, что squid сертификатом не предназначенным для подписывания вполне подписывает и в сентябре (когда я этим вопросом занимался) в файрфоксе такой бардак прокатывал. Ну ругался он на неверный самоподписанный сертификат. Но, на сайт пускал.

А что по твоему он совсем не должен пускать, даже если сказать да я ССЗБ и просто зашел первый раз сюда почитать, что тут да как и логиниться никуда не собираюсь? Если ты разрешишь, то конечно же пустит. Да скажу больше кое-что интересное, у меня за день когда просто серфю по несколько раз сертификаты валидные, подписанные центром меняются для одних и тех же сайтов. И даже не ясно, только это службы балуются, толи просто у разных серверов разные сертификаты валидные для одного и того же домена. Даже вот думал, уже отдельно блог для этого занести в выкладывать там подозрительные сертификаты валидные сертификаты. Сразу выкладывать на который меняет и с которого меняют. Но все лень.

Сейчас не пускает. И добавить сайт в исключения не предлагает. Есть только кнопка уйти прочь. Видимо пересмотрели реакцию на такую ошибку.
Сейчас вообще гайки закручивают с сертификатами. С sha1 only уже почти год как не выдают. Старые на новые (с sha2) бесплатно меняют независимо от срока годности. И скоро все старенькие будут считать невалидными.

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

А можешь где-нибудь выложить отловленный сертификат и полный response header сервера, ну если руки дойдут. Интересно было бы посмотреть. Это может быть просто следствием широкомасштабного обновления сертификатов.

Да такое было. Стало больше сертификатов с SHA2, но самое забавное, когда опять с SHA2 возвращаются на старый. Но я думаю, это просто старые сервера, где забыли поменять.

Такое, что squid сертификатом не предназначенным для подписывания вполне подписывает

Т.е. сделать нормальный сертификат с правом подписи ты не осилил.

и в сентябре (когда я этим вопросом занимался) в файрфоксе такой бардак прокатывал.

Он не прокатывал. Firefox тебе честно показывал ошибку, но давал возможность отстрелить себе ногу.

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

Ну и? Файрфокс все правильно делал - поскольку добавить подписывающий сертификат на клиенты ты поленился, то у него сработала pinning проверка, которая имеет очень высокий приоритет. И для этого случая файрфокс не дает стрелять себе в ногу.

Как это относится к моему высказыванию, с которым ты спорил - если добавить подписывающий сертификат (нормальные люди поставят там право подписи) в Хромиум как доверенный, то у него pinning проверка не сработает.

Я ниоткуда не возьму. Насчёт третьих лиц я уже не настолько уверен. Откуда мне знать, что какой-нибудь промежуточный удостоверяющий центр не является слишком любопытным.

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

В случае с domain validation ssl sertificate цепочка у mitm никак не может быть valid.

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

Вот первый пример (пока за время поста, первая смена), но этот пример часто вылазит. Похоже на cdn twitter, но опять как знать. Особенно зачем делать такие похожие с виду домены, как-будто я не замечу.

img это очевидно, vid наверное производное от video.
Но, действительно, зачем?

Я думал до тебя дошло. Оказалось ошибся, ты более тугой, чем предполагалось.

Т.е. сделать нормальный сертификат с правом подписи ты не осилил.

Сертификат с правом подписи на том домене не требуется. От слова «совсем». И нет никаких причин делать иначе. То, что я с этим сертификатом когда-то поэкспериментировал и сейчас здесь поделился результатами ничего не меняет. От того же слова «совсем».

Он не прокатывал. Firefox тебе честно показывал ошибку, но давал возможность отстрелить себе ногу.

Давало возможность вполне подходит под «прокатывало».

Ну и? Файрфокс все правильно делал - поскольку добавить подписывающий сертификат на клиенты ты поленился,

Дело не в лени, но это уже к обсуждению не относится.

то у него сработала pinning проверка, которая имеет очень высокий приоритет. И для этого случая файрфокс не дает стрелять себе в ногу.

То есть теперь это ты мне начал объяснять?

Как это относится к моему высказыванию, с которым ты спорил - если добавить подписывающий сертификат (нормальные люди поставят там право подписи) в Хромиум как доверенный, то у него pinning проверка не сработает.

А как нынче модно прозрачно MITM-ить SSL? (комментарий) <-- речь про это? Ну и где там я с тобой спорил? Или ответ тебе ты всегда воспринимаешь исключительно как спор? С каким типом сертификата будет фейл я показал. А за дальнейшие твои фантазии я уже не отвечаю.

Конечно может.

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

При нормальном проксировании ты генерируешь на лету (при помощи приватного ключа от сертификата с правом подписи, добавленного на все клиенты в качестве доверенного) сертификат под каждый домен.

Я прекрасно знаю, как работает squid в режиме sslbump.

Если ты используешь один сертификат под все домены,

Нет, ты меня уже совсем рассмешил, я использовал для динамической генерации доменных сертификатов в squid валидный сертификат предназначенный для domain validation без права подписи. О чём тебе уже второй день объясняю.

то ты некомпетентен и гнать тебя с работы нужно метлой.

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

Спасибо огромное! Всё работает!

imul, Vovka-Korovka спасибо за познавательную беседу.