1.1, AntonAlekseevich (ok), 23:51, 28/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Стоит Google отдать должное.
Убрали ещё 1 механизм из Web'а который игнорируется всеми кроме тех 375 сайтов и их пользователей.
| |
1.2, Аноним (-), 23:59, 28/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
TL;DR: нехрен админам заботиться о безопасности, CA позаботятся за них.
| |
|
2.3, Аноним (-), 00:29, 29/10/2017 [^] [^^] [^^^] [ответить]
| +12 +/– |
А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, но вы нас простите, ладно?.."
| |
|
3.5, пох (?), 00:39, 29/10/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
> А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, но
да нет, зачем же? Мы просто выдали кому надо (а не владельцу сервера) очередной летсдекриптовый сертификат - их мильярды, они каждый день обновляются, никто ничего и не заметил даже, чего вы волнуетесь?
Ключи просpала один-единственный раз одна-единственная контора, которая не должна была пройти аудит - если бы его проводили как надо, а не ради вымогательства денег. Там просто вообще не было, похоже, ни нормальных админов, ни у тех админов реальных прав остановить бардак.
Все остальные intermediate roots были выданы _сознательно_.
| |
|
2.4, пох (?), 00:36, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
гугль позаботится за них. Поскольку весь этот тяжелый бред (с прозрачным упоминанием еще одной возможности собирания бабла за воздух) с логсерверами, аудиторами и прочей неведомой хренью будет принадлежать известно кому.
Соответственно, не владельцы сайта будут решать, каким именно сертификатам доверяет браузер их посетителя.
И не посетитель - см. полезный и нужный пункт об удалении ручной привязки сертификатов - хотя она явно не может быть использована ни для чего, кроме...ну да, 100% уверенности, что сертификат не подменен, если первоначально он был получен из доверенного источника. Без всяких гуглосервисов и гуглошпионов, заметьте.
гугль продолжает старательно выполнять условия своего кредита под 0%
| |
|
3.34, Аноним (-), 00:03, 30/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> гугль позаботится за них.
Ну, вот здесь: https://www.certificate-transparency.org/what-is-ct много говорится о прозрачном, криптографически заверенном журналировании всех процессов сертификации, об открытой системе аудита и мониторинга, поддерживающей публичное наблюдение и проверку выпущенных сертификатов, распределенной системе независимых серверов журналов и т.п.
> Без всяких гуглосервисов и гуглошпионов, заметьте.
Если все будет реализовано по уму и так, как описано, и без навязчивой привязки к серверам Большого Брата, то должно быть хорошо всем.
| |
|
4.35, пох (?), 01:22, 30/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> много говорится
да-да, говорится много. Табличку "bullshit" можно поднимать после первых десятка строк.
> Если все будет реализовано по уму и так, как описано
то pkp это не заменит практически никак, ручную привязку сертификата к конкретному хосту - совсем никак.
Ваши возможности на что-то повлиять и вовсе сводятся к нулю, по обе стороны от мушки.
1. вы не можете держать свой лог-сервер - то есть, хоть обдержитесь, но CA вам никаких логов слать не будут. Доверяйте гуглю.
2. вы вряд ли сможете держать свой монитор, анализирующий логи по мере добавления - во-первых, это довольно дорогое удовольствие, во-вторых, наверняка логовладельцы захотят сделать на этом бакшиш (или просто зарейтлимитят - ну можно будет раз в день проверить, что твоему сайту еще не выдали десять сертификатов неизвестно кому, пользы от этого - ноль)
Доверяйте гуглю.
3. из набора функций аудитора вы сможете самостоятельно разьве что проверить, что сертификат есть в логе. А он конечно ж есть, чего ж нам не есть. Вот нет ли там еще парочки - непонятно ни как проверить, ни что делать с этим знанием (они может валидны).
"In most cases, the Certificate Transparency system can detect suspect certificates or CAs in a few hours instead of" immediately, as pkp did. Поправил, не благодарите.
Ну и вишенка на тортике: Others will be run as subscription services that domain owners and certificate authorities can buy into.
платите за воздух еще разок.
| |
|
5.36, Аноним (-), 03:12, 30/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, эта система пока не выглядит совершенной.
С одной стороны (https://www.certificate-transparency.org/what-is-ct):
Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.
И это выглядит хорошо: кому попало не выдаем и юзера как-то защитить пытаемся.
С другой стороны (https://datatracker.ietf.org/doc/rfc6962/?include_text=1):
7.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely instead on interested parties, such as domain owners, to monitor them and take corrective action when a misissue is detected.
Что не выглядит хорошо, ибо это есть попытка возложить функцию контроля на владельца домена.
| |
|
|
|
|
|
2.11, пох (?), 10:29, 29/10/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Всё правильно делают. Подробнее о проблемах:
"если у меня взломали сервер и, возможно, сперли все _ваши_ шифрованные данные - c pkp у меня не получается быстренько перевыпустить сертификат и сделать вид что ничего не было".
перевел, не благодари.
| |
|
3.13, Аноним (-), 14:51, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса не важнее его безопасности? тот же Линукс значительно ближе к народу, когда называет кое-кого обезъянами дрочащими на безопасность?
| |
|
4.28, пох (?), 21:28, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса
> не важнее его безопасности
ну так, казалось бы, не пользуйся pkp - доверяй CA, как все...э...заставь своих юзеров доверять CA или позаботиться о себе самим, вот, теперь правильно ;-)
но есть один ньюанс - pkp был еще одним (доступным немногим, с учетом необходимости подкладывать очень небесплатную соломку) препятствием к поголовному переходу на letsencrypt - поскольку, очевидно, бесмысленнен и опасен с короткоживущими сертификатами.
P.S. делайте ставки, господа - уберет гугль pkp из _телеметрии_ хромого, или нет.
| |
4.33, Аноним (-), 23:30, 29/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> разве людям в массе работоспособность сервиса не важнее его безопасности?
Лукавое, манипулятивное и, в ряде конкретных случаев, глупое противопоставление.
| |
|
3.19, xm (ok), 15:49, 29/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> перевел, не благодари.
Если бы только это. К примеру, недавняя история с регистрацией на стороннего человека одного из доменов NS серверов TLD .io доставила не по-деццки.
| |
|
4.29, пох (?), 21:31, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> перевел, не благодари.
> Если бы только это. К примеру, недавняя история с регистрацией на стороннего
> человека одного из доменов NS серверов TLD .io доставила не по-деццки.
ну а чего тебе не нравится? ns был зарегистрирован на несуществующий в природе хост несуществующего в природе домена. Чувак, мимокрокодил, видит, непорядок, дай, думает - зарегистрирую. Денег, между прочим, заплатил, кому следует (тем самым, кто должен бы по идее следить за бардаком) Теперь видимо чувствует себя медведем в сгоревшем автомобиле.
| |
|
|
2.18, xm (ok), 15:46, 29/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Скотт, конечно, красаучег. Но проблему со злоупотреблениями (ошибками) HPKP можно решить через внедрение механизма отзыва отпечатков. Он, собственно об этом и написал на днях.
| |
|
1.8, Аноним (-), 03:44, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> механизм Certificate Transparency,
> Google's Certificate Transparency project ...
А, ну понятно...
| |
1.9, Ilya Indigo (ok), 07:40, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Мне это механизм с самого начала не понравился.
При mitm-атаке заголовок легко подделывается.
| |
|
2.10, Аноним (-), 09:40, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
А какой механизм защищает от mitm-атак и в каких браузерах он правильно реализован?
| |
|
3.12, пох (?), 10:37, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?
механизм trusted ca, удивительное рядом? Но наше индиго-детишко недавно очаровательно описялось, обнаружив что вообще не понимает основополагающих вещей в том, как работает ssl.
pkp защищает не от обычного mitm, а от того, что сам ca неожиданно оказался не очень-то trusted - например, получил кредитец под 0% от кого надо.
как, собственно, и ручное сохранение сертификата сайта.
в обоих случаях требуется хотя бы один раз получить настоящий сертификат - например, банально до того, как 0% кредит заставят отрабатывать. Что в любом случае не может быть всеобъемлющим и продолжаться долго - ибо палевно, поэтому в общем можно доверять CA.
Вероятно, если ты создал повод предполагать, что ОНИ за тобой следят, коллекцию сертификатов надо было начинать собирать не вчера.
| |
3.15, Ilya Indigo (ok), 15:29, 29/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?
Из публичных методов, в которых каждому клиенту не придётся заранее устанавливать себе сертификат сервера перед обращением к нему, а потом и переустанавливать. если сервер его изменит, ни один из них.
Но использование KPK это лишний геморрой на пустом месте.
| |
3.20, xm (ok), 15:51, 29/10/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?
1. DNSSEC + DANE (доверие переносится на уровень регистратора домена).
2. Ни в каких.
| |
|
|
1.14, Аноним (-), 15:15, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Я один из тех, кто проср*л проект из-за этой технологии. Зарегал домен, поднял все, раскрутил, а потом решил добавить эту фигню. Шобы, значить, было еще более лучше с безопасностью. Потом полетел жесткий диск. Сайт восстановил из бэкапов, сертификат получил новый, поднял и ... никто не может зайти. Все коту под хвост.
| |
|
|
3.22, Аноним (-), 16:27, 29/10/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Вначале не бэкапил, ибо не было надобности. Если что-то случится, логичнее всего перевыпустить certificate signing request и получить новый сертификат. Более того, в случае взлома старый сертификат нужно инвалидировать и заменить. А потом ... потом было поздно.
| |
|
4.30, Аноним (-), 21:36, 29/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это хорошо?
| |
|
5.32, пох (?), 23:07, 29/10/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его
> бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это
> хорошо?
минус не мой, но объясню: потому что если у тебя физически накрылся диск - нет никакого смысла в "перегенерации сертификата" (вообще-то у нормального CA можно скачать тот же самый столько раз, сколько захочется, но закрытый ключ надо, разумеется, уберечь), надо поднять его с того же бэкапа, что всю остальную систему с минимумом лишних телодвижений. Если что - никакого секрета в нем нет, у любого заглянувшего к тебе юзера остается полная копия (можно даже извлечь ее из его браузера), без твоего закрытого ключа она бесполезна.
ломаешь ты при этом, помимо key pin'а, еще и банальное доверие тебе тех немногих умных юзеров, которые используют cert patrol или другой способ сверять сертификаты с ранее полученными их копиями, без всякого навязываемого гуглем или владельцем сайта сервиса. Поскольку они увидят, что ты менял сертификат без явных причин, и все о тебе поймут.
а бэкап без шифрования на левые дропбоксы и теряемую в автобусе флэшку не лучше и не хуже бэкапа того, что, собственно, защищает твой сертификат - юзеру в общем-то похрен, ломанули его mitm'ом из-за того, что ты упустил ключ, или просто стырили его пароль вместе со всей твоей базой.
| |
|
|
3.24, пох (?), 16:45, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Не понял, а почему ты сертификат не бекапил?
потому же, почему у него "ценный проект" (суперсекьюрный при том) на единственном жестком диске (а у меня пернатый друг и то на 3ware raid).
Чтоб сразу и волки сыты, и кобыле легче.
| |
|
2.23, пох (?), 16:43, 29/10/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Я один из тех, кто проср*л проект из-за этой технологии.
проект ты прос*л потому что ни бэкапы делать не умел, ни в технологии ничерта не разбирался, ни хотя бы хауту не прочел - на всех углах блин написано, что сигнатура должна и обязана быть не одна. Про дать денег нормальному админу, (не Илье-синюку, который не знал для чего нужны CA,но их таких есть) я уж не заикаюсь.
Но виновата, конечно же, технология, ага. Ну вот гугль о тебе и позаботился. К сожалению, и о нас тоже.
| |
|
3.25, Аноним (-), 16:56, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
Так я и не претендую. Я просто говорю, что если бы этой технологии не было, этот проект был бы жив. Ну, или я прокололся бы на чем-то другом :-)
| |
|
4.26, пох (?), 17:24, 29/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Я просто говорю, что если бы этой технологии не было, этот проект был бы жив
да не было б ssl - тоже был бы жив ;-)
причем и по сей день. Вони по поводу "сайт несекьюрен, ой, не ходите сюда" в хромом почти нет - в десктопном так вообще надо стараться, чтобы что-то там заметить. (пока, конечно, ты пароли clear-text'овой вебформой не отправляешь, но за это и в ssl-обертке убивать уже пора)
в отличии от истории с pkp, когда высовывается страшное окно с непонятными надписями и двумя кнопкам - "еще больше неведомой х..ни" и "загрузить котиков". Кнопки "продолжить" нет в принципе, пользователю незачем решать, что для него опасно, а что нет, гугль лучше знает. (мазила, если что, тоже - редкий юзер осилит удалить пин, даже если ему по буквам диктовать)
| |
|
|
|
|