Комментарии 31
Да это же целая дипломная работа!
И впрямь. Наверное изменилась цепочка но сертификат не был повторно сгенерирован. Автор пишет что у него генерация происходит ночью по крону, так что завтра наверное станет валидным снова :)
Так а зачем тогда такая подпись если она «то валидная, то нет»? Пользователь забьет на это быстро и поставит галочку «доверять всем».
А если такая чехарда случится с сертификатами того же paypal.com, то фишинговым сайтам аля paypa1.com будет существенно легче вызвать доверие — их сертификат будет таким же «не валидным» как и оригинальный :)
Имхо максисмум как вспомогательная технология, когда валидность можно однозначно проверить другим путем. Ну или может допилят, чтобы оно цепочку учитывала и фишеров не пропускало…
А если такая чехарда случится с сертификатами того же paypal.com, то фишинговым сайтам аля paypa1.com будет существенно легче вызвать доверие — их сертификат будет таким же «не валидным» как и оригинальный :)
Имхо максисмум как вспомогательная технология, когда валидность можно однозначно проверить другим путем. Ну или может допилят, чтобы оно цепочку учитывала и фишеров не пропускало…
Я ошибся с предположением об изменившейся цепочке. Адам сказал, что в данный момент тестирует что-то и поэтому сертификат недействительный.
Вся цепочка включается в сертификат только для того чтобы работало у тех кого системный резолвер не поддерживает DNSSEC. Иначе всю цепочку клиент может построить самостоятельно.
Откровенно говоря я сам не до конца понимаю как работает этот «stapled certificate» и чтение RFC не добавляет понимания.
И кстати, без обновления цепочки три дня у меня сертификат остается валидным.
зачем тогда такая подпись если она «то валидная, то нет»?
Вся цепочка включается в сертификат только для того чтобы работало у тех кого системный резолвер не поддерживает DNSSEC. Иначе всю цепочку клиент может построить самостоятельно.
Откровенно говоря я сам не до конца понимаю как работает этот «stapled certificate» и чтение RFC не добавляет понимания.
И кстати, без обновления цепочки три дня у меня сертификат остается валидным.
Про валидность сертификата понял. Но все равно не понял как это поможет доверять сертификату, если не опираться на что-либо еще — так как фишинг сайт будет иметь такой же валидный, с точки зрения DNSSEC, сертификат.
И добавление «тем клиентам, которые не поддерживают» — а что в таком случае мешает заспуфить DNS (ведь клиент не поддерживает DNSSEC, а значит все возможно) и перенаправить на сайт с DNSSEC SSL в котором есть «поддельная цепочка» (клиент это проверить не может) — клиент попадет на сайт, с «валидным» SSL и будет уверен что все в порядке. Это даже удобнее чем покупать корневой CA SSL, ИМХО :)
Т.е. если сам клиент не поддерживает DNSSEC изначально, то грош цена этому SSL.
А вот если клиент пришел на сайт через DNSSEC — тут он может быть уверен что итак попал на нужный сайт и проверил валидность SSL стандартным способом через CA и дополнительно проверил какой-нить extension подписанный ключем DNSSEC сайта — тогда 100% на валидном сайте (так как ключ есть только у владельца зоны).
Без последней проверки все еще будет возможно ISP перенаправить 443 порт на свой сервер (со своим валидным CA).
Но фишинг это никак не затрагивает, у них появится возможность делать валидные сертификаты… Так что вторая проверка из другого источника просто необходима.
И добавление «тем клиентам, которые не поддерживают» — а что в таком случае мешает заспуфить DNS (ведь клиент не поддерживает DNSSEC, а значит все возможно) и перенаправить на сайт с DNSSEC SSL в котором есть «поддельная цепочка» (клиент это проверить не может) — клиент попадет на сайт, с «валидным» SSL и будет уверен что все в порядке. Это даже удобнее чем покупать корневой CA SSL, ИМХО :)
Т.е. если сам клиент не поддерживает DNSSEC изначально, то грош цена этому SSL.
А вот если клиент пришел на сайт через DNSSEC — тут он может быть уверен что итак попал на нужный сайт и проверил валидность SSL стандартным способом через CA и дополнительно проверил какой-нить extension подписанный ключем DNSSEC сайта — тогда 100% на валидном сайте (так как ключ есть только у владельца зоны).
Без последней проверки все еще будет возможно ISP перенаправить 443 порт на свой сервер (со своим валидным CA).
Но фишинг это никак не затрагивает, у них появится возможность делать валидные сертификаты… Так что вторая проверка из другого источника просто необходима.
Ага, разобрался. Таки чтение RFC помогает :)
В основе DNSSEC SSL тоже лежит «root CA», просто в данном случае он называется trusted-key от корневой зоны.
Клиент содержит в себе этот ключ и может проверить всю встроенную цепочку. Так как хеши нижних зон (DS записи) подписываются ключем верхних — то «поддельную» цепочку просто нельзя сделать — нет приватного ключа верхней зоны. Т.е. подделать paypal.com, к примеру, будет нельзя, так как нет приватного ключа com зоны для подписи DS записи для paypal.com и клиент сразу увидит несоответствие. Да и сам домен подписывается приватным ключем SSL, поэтому «слить» цепочку с оригинального домена и подставить в свой сертификат не получится.
Таким образом валидность домена из сертификата однозначно подтверждается через «root CA» зашитого в клиенте (в случае если он не может получить его из резолвера) и проверкой подписи конечного домена самим сертификатом.
По поводу фишинга автор тоже говорит что да, есть такое дело :) И нужно использовать нормальные сертификаты для подтверждения «правового статутса».
В основе DNSSEC SSL тоже лежит «root CA», просто в данном случае он называется trusted-key от корневой зоны.
Для того, чтобы научить утилиту dig проверять подпись, необходимо создать отправную точку в цепочке доверия, создав файл с ключом корневой зоны
Клиент содержит в себе этот ключ и может проверить всю встроенную цепочку. Так как хеши нижних зон (DS записи) подписываются ключем верхних — то «поддельную» цепочку просто нельзя сделать — нет приватного ключа верхней зоны. Т.е. подделать paypal.com, к примеру, будет нельзя, так как нет приватного ключа com зоны для подписи DS записи для paypal.com и клиент сразу увидит несоответствие. Да и сам домен подписывается приватным ключем SSL, поэтому «слить» цепочку с оригинального домена и подставить в свой сертификат не получится.
Таким образом валидность домена из сертификата однозначно подтверждается через «root CA» зашитого в клиенте (в случае если он не может получить его из резолвера) и проверкой подписи конечного домена самим сертификатом.
По поводу фишинга автор тоже говорит что да, есть такое дело :) И нужно использовать нормальные сертификаты для подтверждения «правового статутса».
Ушел читать RFC, чтобы знать на что теперь обращать внимания кроме «валидного» сертификата…
Нет, фишинговый сайт в этом случае не будет вызвать доверия, впрочем, как и оригинальный. Криво, но в этом есть положительные моменты по сравнению со схемой без защиты. Потому что если уж запись валидна, то мы будет уверены, что все в порядке. Если не валидна, то может подождать обновления. Но в любом случае у нас будет явный индикатор показывающий степень доверия в текущий момент.
НЛО прилетело и опубликовало эту надпись здесь
>Это позволит в будущем (не знаю, насколько далеком) отказаться от SSL-провайдеров
>Плюс тогда никто, не попадя, не сможет выписать сертификат для моего домена через левый CA.
С одной стороны это верно. Но с другой сертификационный центр, выдающий сертификат? проводит, хотя бы минимальную проверку сайта. Например откровенно фишинговому сайту типа paypa1.com, сертификат вероятнее всего не выдадут. Кроме того, при выдаче сертификата класса 3, сертификационный центр проводить углубленную проверку конторы, вплоть до посещения офиса. А при возможности подписать сертификат самостоятельно, любой фишинговый сайт получит валидный сертификат. Так что не так всё однозначно.
>Плюс тогда никто, не попадя, не сможет выписать сертификат для моего домена через левый CA.
С одной стороны это верно. Но с другой сертификационный центр, выдающий сертификат? проводит, хотя бы минимальную проверку сайта. Например откровенно фишинговому сайту типа paypa1.com, сертификат вероятнее всего не выдадут. Кроме того, при выдаче сертификата класса 3, сертификационный центр проводить углубленную проверку конторы, вплоть до посещения офиса. А при возможности подписать сертификат самостоятельно, любой фишинговый сайт получит валидный сертификат. Так что не так всё однозначно.
Отличная статья.
Кстати говоря, в российских реалиях в ряде случаев будет использоваться DNSSEC с ГОСТ-овой криптографией. На эту тему имеется RFC www.rfc-editor.org/rfc/rfc5933.txt, разработанное специалистами фирмы Криптоком и продукт МагПро DNS, созданный на базе OpenSSL и bind/Unbound.
Самое печальное, тендер вроде бы Минкомсвязи на DNSSEC-кизацию РФ по ГОСТам они проиграли:(. У нас в стране недостаточно сделать стандарт и его же реализовать, чтобы гос-во вас заметило.
Кстати говоря, в российских реалиях в ряде случаев будет использоваться DNSSEC с ГОСТ-овой криптографией. На эту тему имеется RFC www.rfc-editor.org/rfc/rfc5933.txt, разработанное специалистами фирмы Криптоком и продукт МагПро DNS, созданный на базе OpenSSL и bind/Unbound.
Самое печальное, тендер вроде бы Минкомсвязи на DNSSEC-кизацию РФ по ГОСТам они проиграли:(. У нас в стране недостаточно сделать стандарт и его же реализовать, чтобы гос-во вас заметило.
смерть hosts вирусам
НЛО прилетело и опубликовало эту надпись здесь
Очень интересно. Но как вы видите практическую реализацию? Если альтернативную схему DNS можно еще представить, то альтернативу IP я не могу вообразить.
НЛО прилетело и опубликовало эту надпись здесь
Ну как я понял, это ведь ваша концепция. Я давно мечтаю о p2p интернете, только чтобы прямо в браузере без тормознутых TOR-ов и фринетов с i2p на джаве. Концепция фринета интересная, но ждать пока контент размажется по всем клиентам — неудобно. На клиентской стороне не должно устанавливаться ничего сложнее плагина для браузера. Вполне допустимы какие-то опорные ноды как в TOR-сети, клиенты соединяются другом с другом при помощи DHT.
Короче, я бы поучаствовал.
Короче, я бы поучаствовал.
В ответе запись DS содержит слепок ключа, которым подписывается зона «com.»
Разве в DS не хранятся исключительно отпечатки KSK (а не ZSK), ошибаюсь?
НЛО прилетело и опубликовало эту надпись здесь
Извините, вот такой я некромант. :-)
7 лет не интересовался вопросом — и вот пригодилось.
Честно говоря началось все с того, что unbound почему-то не резолвит vmware.com со словами servfail. По тексту ошибки и тому факту что зона vmware.com подписана, логично предположить что ошибка валидации (но это не точно). Вот и разбираемся понемногу.
А на Хабре всего две с половиной толковых статьи про DNSSEC, и это одна из них.
Кстати есть очень доходчивый материал здесь.
7 лет не интересовался вопросом — и вот пригодилось.
Честно говоря началось все с того, что unbound почему-то не резолвит vmware.com со словами servfail. По тексту ошибки и тому факту что зона vmware.com подписана, логично предположить что ошибка валидации (но это не точно). Вот и разбираемся понемногу.
А на Хабре всего две с половиной толковых статьи про DNSSEC, и это одна из них.
Кстати есть очень доходчивый материал здесь.
Попробую сам себе ответить
RFC4033 говорит нам:
То есть использование отдельных KSK и ZSK — опционально. Хотя на тип ключа все-таки отведен отдельный бит, и в текущей реализации протокола его используют.
То есть по текущей практике использования в родительской зоне в DS хранится отпечаток KSK, а в своей зоне — пачка ZSK, подписанных KSK.
Профит очевиден — регулярная ротация ZSK домена без каких-либо изменений родительской зоны.
RFC4033 говорит нам:
Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key.
То есть использование отдельных KSK и ZSK — опционально. Хотя на тип ключа все-таки отведен отдельный бит, и в текущей реализации протокола его используют.
То есть по текущей практике использования в родительской зоне в DS хранится отпечаток KSK, а в своей зоне — пачка ZSK, подписанных KSK.
Профит очевиден — регулярная ротация ZSK домена без каких-либо изменений родительской зоны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практическое применение DNSSEC