Открыть список
Как стать автором
Обновить

Комментарии 31

Да это же целая дипломная работа!
мда, обмельчали дипломники. Это максимум реферат. Даже на курсовик не наберется.
И впрямь. Наверное изменилась цепочка но сертификат не был повторно сгенерирован. Автор пишет что у него генерация происходит ночью по крону, так что завтра наверное станет валидным снова :)
Так а зачем тогда такая подпись если она «то валидная, то нет»? Пользователь забьет на это быстро и поставит галочку «доверять всем».
А если такая чехарда случится с сертификатами того же paypal.com, то фишинговым сайтам аля paypa1.com будет существенно легче вызвать доверие — их сертификат будет таким же «не валидным» как и оригинальный :)
Имхо максисмум как вспомогательная технология, когда валидность можно однозначно проверить другим путем. Ну или может допилят, чтобы оно цепочку учитывала и фишеров не пропускало…
Я ошибся с предположением об изменившейся цепочке. Адам сказал, что в данный момент тестирует что-то и поэтому сертификат недействительный.

зачем тогда такая подпись если она «то валидная, то нет»?


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

Откровенно говоря я сам не до конца понимаю как работает этот «stapled certificate» и чтение RFC не добавляет понимания.

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

И добавление «тем клиентам, которые не поддерживают» — а что в таком случае мешает заспуфить 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 от корневой зоны.
Для того, чтобы научить утилиту dig проверять подпись, необходимо создать отправную точку в цепочке доверия, создав файл с ключом корневой зоны

Клиент содержит в себе этот ключ и может проверить всю встроенную цепочку. Так как хеши нижних зон (DS записи) подписываются ключем верхних — то «поддельную» цепочку просто нельзя сделать — нет приватного ключа верхней зоны. Т.е. подделать paypal.com, к примеру, будет нельзя, так как нет приватного ключа com зоны для подписи DS записи для paypal.com и клиент сразу увидит несоответствие. Да и сам домен подписывается приватным ключем SSL, поэтому «слить» цепочку с оригинального домена и подставить в свой сертификат не получится.

Таким образом валидность домена из сертификата однозначно подтверждается через «root CA» зашитого в клиенте (в случае если он не может получить его из резолвера) и проверкой подписи конечного домена самим сертификатом.

По поводу фишинга автор тоже говорит что да, есть такое дело :) И нужно использовать нормальные сертификаты для подтверждения «правового статутса».
Ну то что браузеру известен ключ корневой зоны — это очевидно, иначе бы он вообще не смог верифицировать сертификат.
Да, конечно. Меня смущала еще подпись домена SSL ключем, но после того как я понял где оно потом используется — все встало на свои места.

Ну и область использования пока только «крупные локальные сети использующие Chrome» как очертил автор :)

Ушел читать RFC, чтобы знать на что теперь обращать внимания кроме «валидного» сертификата…
Нет, фишинговый сайт в этом случае не будет вызвать доверия, впрочем, как и оригинальный. Криво, но в этом есть положительные моменты по сравнению со схемой без защиты. Потому что если уж запись валидна, то мы будет уверены, что все в порядке. Если не валидна, то может подождать обновления. Но в любом случае у нас будет явный индикатор показывающий степень доверия в текущий момент.
> С помощью DNSSEC можно самостоятельно подписать SSL-сертификат который будет «валидным» в браузере.

Очень привлекательная опция. Это позволит в будущем (не знаю, насколько далеком) отказаться от SSL-провайдеров. Плюс тогда никто, не попадя, не сможет выписать сертификат для моего домена через левый CA.

Но возникает два вопроса:

1) Как это будет вязаться с продажей сертификатов: например, тот же Verisign, немалая часть бизнеса которого построена на SSL-сертификатах, будет давать возможность выписать свои валидные сертификаты через DNSSEC.

2) Если домен будет использовать свой сертификат, авторизованный через DNSSEC, то надежность этого подхода очень сильна привязана к администратору зоны: к Verisign (для ".") и нижестоящему (опять же Verisign для ".com" и ".net").
>Это позволит в будущем (не знаю, насколько далеком) отказаться от SSL-провайдеров
>Плюс тогда никто, не попадя, не сможет выписать сертификат для моего домена через левый CA.

С одной стороны это верно. Но с другой сертификационный центр, выдающий сертификат? проводит, хотя бы минимальную проверку сайта. Например откровенно фишинговому сайту типа paypa1.com, сертификат вероятнее всего не выдадут. Кроме того, при выдаче сертификата класса 3, сертификационный центр проводить углубленную проверку конторы, вплоть до посещения офиса. А при возможности подписать сертификат самостоятельно, любой фишинговый сайт получит валидный сертификат. Так что не так всё однозначно.

> Например откровенно фишинговому сайту типа paypa1.com
Тогда должна быть опция, доверять ли самоподписанным через DNSSEC сертификатам.

> Как это будет вязаться с продажей сертификатов: например, тот же Verisign,…
Но я не нахожу ответ на этот вопрос. С одной стороны в протоколе есть возможность поставить свой сертификат, с другой у SSL-провайдеров будут отбирать кусок рынка.
Зелёный, может, и не выдадут. А простой часто выдаётся автоматически на основе единственной проверки на то, что домен действительно принадлежит заявителю.
Отличная статья.
Кстати говоря, в российских реалиях в ряде случаев будет использоваться DNSSEC с ГОСТ-овой криптографией. На эту тему имеется RFC www.rfc-editor.org/rfc/rfc5933.txt, разработанное специалистами фирмы Криптоком и продукт МагПро DNS, созданный на базе OpenSSL и bind/Unbound.

Самое печальное, тендер вроде бы Минкомсвязи на DNSSEC-кизацию РФ по ГОСТам они проиграли:(. У нас в стране недостаточно сделать стандарт и его же реализовать, чтобы гос-во вас заметило.
А кто выиграл тендер?
Если я правильно ошибаюсь, то Р-Альфа. Но не уверен на 100%.
К сожалению ГОСТ для подписания tld не подходит. Отсутствие NSEC3 делает его совершенно неконкуретноспособным в этом качестве. А простой NSEC открывает широчайшие возможности для киберсквоттинга.
НЛО прилетело и опубликовало эту надпись здесь
Очень интересно. Но как вы видите практическую реализацию? Если альтернативную схему DNS можно еще представить, то альтернативу IP я не могу вообразить.
НЛО прилетело и опубликовало эту надпись здесь
Ну как я понял, это ведь ваша концепция. Я давно мечтаю о p2p интернете, только чтобы прямо в браузере без тормознутых TOR-ов и фринетов с i2p на джаве. Концепция фринета интересная, но ждать пока контент размажется по всем клиентам — неудобно. На клиентской стороне не должно устанавливаться ничего сложнее плагина для браузера. Вполне допустимы какие-то опорные ноды как в TOR-сети, клиенты соединяются другом с другом при помощи DHT.

Короче, я бы поучаствовал.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В ответе запись DS содержит слепок ключа, которым подписывается зона «com.»

Разве в DS не хранятся исключительно отпечатки KSK (а не ZSK), ошибаюсь?
Я испугался, когда пришло письмо из статьи 2012 года.
Извините, вот такой я некромант. :-)
7 лет не интересовался вопросом — и вот пригодилось.
Честно говоря началось все с того, что unbound почему-то не резолвит vmware.com со словами servfail. По тексту ошибки и тому факту что зона vmware.com подписана, логично предположить что ошибка валидации (но это не точно). Вот и разбираемся понемногу.

А на Хабре всего две с половиной толковых статьи про DNSSEC, и это одна из них.

Кстати есть очень доходчивый материал здесь.
Попробую сам себе ответить
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 домена без каких-либо изменений родительской зоны.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.