(no subject)
Mar. 22nd, 2013 03:57 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cat_muciusЧто-то никто, кроме 
yigal-s, над вопросом про сертификаты думать не захотел. :-)
Ладно, просто так расскажу. Интересны они вот чем: один из них настоящий. Другой - поддельный. А подпись у них одинакова.
Краткая напоминалка, как это всё работает: сертификат – это электронный документ, удостоверящий в сети кого-то или что-то: вебсайт, компьютер, юзера, адрес мейла. Для того, чтобы этому документу кто-то доверял, надо, чтобы он был подписан каким-то гарантом, к которому доверие уже есть. Такими гарантами выступают фирмы вроде VeriSign и Comodo, которые этим и занимаются – продают сертификаты. Называют их CA (certification authorities).
Как работает электронная подпись? Берётся этот самый документ и прогоняется через хэш-функцию. У хэш-функции же есть две особенности:
• Для каждого значения на входе она должна выдать уникальное значение на выходе. В идеале, не должно быть двух разных наборов данных, для которых функция выдаст одинаковый хэш. Ситуация, когда такое всё же происходит, называется collision и говорит о том, что функция плоха.
• Из хэша на выходе не должно быть возможно узнать, что было скормлено функции на входе.
Авторы схемы защиты вируса Gauss использовали вторую особенность – здесь же нас интересует первая.
Итак, берётся сертификат и вычисляется его хэш. После чего CA, что подписывает сертификат (скажем, VeriSign), шифрует его своим секретным ключом. Результат шифрования – это и есть электронная подпись, которая прилагается к сертификату. Тот же, кто хочет подпись проверить (скажем, браузер) делает вот что: а.) в свою очередь вычисляет хэш по тем же данным, б.) расшифровывает подпись открытым ключом того, кто её зашифровал и с.) сравнивает результат. Если в сертификате или подписи был изменён хотя бы один бит, то сравнение проваливается и значит, подпись поддельная и доверять ей нельзя.
Нетрудно заметить, что если у двух сертификатов будет одинаковый хэш, то и результат шифрования тайным ключом удостоверителя выйдет одинаков. Если я могу взять сертификат, удостоверяющий сайт https://mail.google.com, и составить свой с таким же именем и таким же хэшем, то мне совершенно необязательно знать секретный ключ фирмы VeriSign, подписавшей сертификат Гугля – я могу просто скопировать подпись из сертификата Гугля и пришпандорить к своему. После чего построить липовый сайт, выдающий себя за https://mail.google.com и перехватывать пароли. Именно поэтому требования не повторяющихся значений на выходе хэш-функции настолько важно: уникальный хэш = уникальная подпись.
Амбула:
Так вот, в 2008-м группа из семи исследователей именно этого и добилась – сумела сгенерировать пару сертификатов так, чтобы хэш у них вышел одинаков. После чего подсунула один из них на подпись к одному из CA – фирме Equifax / GeoTrust. Поскольку критериям CA сертификат вполне удолетворял (несмотря на указанное в нём имя сайта i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org), то GeoTrust его автоматически подмахнула за малую мзду. После чего остался последний ход: подпись просто взяли и приставили ко второму сертификату, который GeoTrust не подписала бы ни в жисть. А не подписала бы потому, что второй был выписан не на какой-то там вебсайт, настоящий или липовый – а на дочерний CA, который автоматом наследует весь капитал доверия, которым располагает GeoTrust. То есть хозяева поддельного сертификата получили прекрасную возможность выписывать в свою очередь любые другие сертификаты, которым бы браузеры доверяли автоматически.
Выгорело дело, кстати, потому, что GeoTrust полагалась на хэш-функцию по нынешним временам слабую – MD5. Первую полноценную коллизию в MD5 нашли ещё в 2004-м, но от того, чтобы просто найти два каких-то куска информации с одинаковым хэшем и до того, чтобы подобрать таким образом два куска _нужной_ информации – дистанция огромного размера, и великолепная семёрка её преодолела. Всякие смачные детали, вроде вычислений на кластере из двухста игровых консолей, можете почитать здесь, а я поговорю о последствиях.
Что могло бы выйти:
Последствий особых не было, разве что все СA бросились срочно менять MD5 на более стойкий алгоритм – SHA1. Но не было лишь потому, что авторы работы, из социальной ответственности, постарались собственные результаты всячески обезвредить. Во-первых, отказались разгласить ключ, с помощью которого могли бы выписывать дочерние сертификаты. Во-вторых, свой липовый сертификат предусмотрительно создали дохлым с рожденья – со сроком жизни всего-то в август 2004-ого. И в третьих, просто не опубликовали некоторые секретные тонкости своей технологии.
Ну а если бы они решили пуститься во все тяжкие? У, тут последствия могли быть жирные. Корневым сертификатам Equifax / GeoTrust доверяют подавляющее большинство компьютеров в мире (и твой собственный, дорогой читатель – не веришь, запусти certmgr.msc и полюбуйся на список в "Trusted Root Certification Authorities"), они поставляются вместе с операционными системами и браузерами, такими, как Firefox. Это значит, что дочернему – липовому – CA они доверяли бы точно так же. А это открывает большие возможности:
• Можно выписать сертификат на абсолютно любой сайт – хоть на https://www.facebook.com/, хоть на https://www.paypal.com. После чего с помощью MitM-атаки или фишинга красть пароли, личную информацию, коммерческие секреты, просто деньги. Причём совершенно неважно, что Пайпалу сертификат выписал не GeoTrust, а вовсе даже VeriSign, и без всякого MD5.
• Можно подписывать какой-нибудь malware. Сегодня туча програм подписывается каким-нибудь CA, чтобы юзер не боялся запускать их на своей машине. Windows при попытке поставить програмку без подписи уже и предупреждение выкатывает... Так вот, берём любого троянского коня, любой spyware, и снабжаем его подписью – создано Microsoft. После чего хошь – ботнет строй, хошь – пароли кради, ну и бабло, опять же.
• Можно перехватывать шифрованные каналы IPsec / VPN, можно ловить пароли от копроративных WiFi-сеток.
• Можно тот же malware рассылать подписанными / шифрованными мэйлами, чтобы спаморезки пропускали и юзеры ловились, а то и проводить сложные мошеннические схемы с фальшивыми документами, но это скорее экзотика.
В общем, нехило оторваться можно. Причём в любую из этих ловушек не то что обычный юзер, но и админ-параноик вденется в полный рост. Что, кто-то помнит наизусть, какой CA выписал сертификат его банку?
Контрмеры:
Хорошо, допустим, какие-то атаки бы удались – но потом началось бы расследование и на свет божий выплыло бы существование липового CA. Насколько эффективно можно было бы свести возможность повторных атак на нет?
Вообще-то, не особенно. Основной способ борьбы с сертификатами, попавшими не в те руки, это “чёрные списки”, называемые CRL (certificate revocation list). Каждый CA публикует такой список, куда вносит сертификаты, которым призывает больше не доверять. В теории, браузеры или любые иные программы, желающие проверить сертификат, должны прочесть свежий CRL от того CA, что подписал сертификат и убедиться, что его серийного номера нет в списке.
То есть GeoTrust могли бы взять серийник нашего липового сертификата и забить его в свой список (вот он, кстати - http://crl.geotrust.com/crls/globalca1.crl).
Проблема в том, что способ этот очень ограничен:
1.) Как браузер вообще узнаёт, где искать CRL? Ответ: URL к нему публикуется прямо в том же сертификате, который браузер и хочет проверить. Бредово? В общем да: основано это на предположении, что подделать сертификат нельзя, и призвано для защиты от иных сценариев (утечка ассоциированного с сертификатом секретного ключа, в основном).
Ну а наш поддельный сертификат адреса CRL вообще не содержит, и привет. И ни один браузер по этому поводу не заверещит, потому как ситуация эта нормальна: нет требования, чтобы любой сертификат непременно содержал линк к CRL. И даже если бы такое требование было, обойти его было бы легко: достаточно поставить неработающий линк, или работающий, но на битый CRL, или даже вполне целый, с отменной подписью законнейшего CA, только ... устаревший. Браузеры не склонны портить user experience предупреждающими воплями лишь потому, что не удалось прочесть самый свежий CRL, да ещё и не первый в цепочке.
2.) Тем не менее, есть способы, которыми CRL может дойти до потенциальных жертв:
a. Допустим, браузер открыл сайт, защищёный легальным сертификатом от того же Equifax, в ходе проверки скачал CRL и закэшировал его. Тогда, покамест CRL хранится в кэше, попытки подсунуть фальшак провалятся.
Проблема в том, что это чисто вероятностная штука.
b. Иные механизмы, такие, как Windows Update. После того, как иранский хакер смог заполучить сертификаты к набору разных важный сайтов два года назад, этот способ и использовался: вместе с заплатками к операционке на компьютер спускался CRL c номерами забаненных сертификатов и сами эти сертификаты.
Проблема в том, что далеко не все компы получают регулярно обновления.
3.) Не все браузеры вообще удосуживаются проверять CRL, поскольку это замедляет загрузку страниц – нужно дополнительно побегать по линкам и проверить подписи.
4.) Наконец, есть сценарии, когда проверить CRL просто невозможно. Например, когда сертификат используется для защиты доступа в сетку WiFi. Как клиенту убедиться, что сертификат не отозван, когда у него и IP-адреса ещё даже нет?
В общем, вполне можно ожидать, что даже месяцы и годы спустя обнаружения первых атак процентов этак 20-30 компьютеров в мире принимали бы липовые сертификаты за милую душу.
Вот какая неприятность может произойти всего-то из того, что хэш-функция для двух input’ов выдала один output. :-)
Выводы:
1. Всякий, имеющий дело с сертификатами с MD5 – да отряхнёт их прах с рук своих.
2. Да и на SHA1 лучше не полагаться. Если его завтра вот так ломанут, это будет ОЙ! – потому как почти все сертификаты подписываются с SHA1RSA.
3. Сисадмин, помни, что иерархия доверия – вообще-то, необходимое зло, призванное решать проблему scalability, а не нечто прекрасное само по себе. Если есть возможность установить точечное доверие к конечному сертификату, а не полагаться на цепочку подписей – стоит это делать.
4. Доверять стопроцентно одной лишь технологии никогда не стоит. Защищать передачу юзерского пароля одним лишь SSL – плохая идея, лучше использовать дополнительную схему типа digest / NTLM / Kerberos, даже если обмен идёт по шифрованному каналу.
5. Нужен способ проверки CRL-ей и цепочек доверия сверху вниз, от корневого CA, а не наоборот. Логичный кандидат для этого, кстати, есть – DNSSEC.
6. PKI чрезмерно полагается на предположение, что подделать подпись нельзя, и должен быть передизайнен с дополнительными защитами.
yigal-s, над вопросом про сертификаты думать не захотел. :-)Ладно, просто так расскажу. Интересны они вот чем: один из них настоящий. Другой - поддельный. А подпись у них одинакова.
Краткая напоминалка, как это всё работает: сертификат – это электронный документ, удостоверящий в сети кого-то или что-то: вебсайт, компьютер, юзера, адрес мейла. Для того, чтобы этому документу кто-то доверял, надо, чтобы он был подписан каким-то гарантом, к которому доверие уже есть. Такими гарантами выступают фирмы вроде VeriSign и Comodo, которые этим и занимаются – продают сертификаты. Называют их CA (certification authorities).
Как работает электронная подпись? Берётся этот самый документ и прогоняется через хэш-функцию. У хэш-функции же есть две особенности:
• Для каждого значения на входе она должна выдать уникальное значение на выходе. В идеале, не должно быть двух разных наборов данных, для которых функция выдаст одинаковый хэш. Ситуация, когда такое всё же происходит, называется collision и говорит о том, что функция плоха.
• Из хэша на выходе не должно быть возможно узнать, что было скормлено функции на входе.
Авторы схемы защиты вируса Gauss использовали вторую особенность – здесь же нас интересует первая.
Итак, берётся сертификат и вычисляется его хэш. После чего CA, что подписывает сертификат (скажем, VeriSign), шифрует его своим секретным ключом. Результат шифрования – это и есть электронная подпись, которая прилагается к сертификату. Тот же, кто хочет подпись проверить (скажем, браузер) делает вот что: а.) в свою очередь вычисляет хэш по тем же данным, б.) расшифровывает подпись открытым ключом того, кто её зашифровал и с.) сравнивает результат. Если в сертификате или подписи был изменён хотя бы один бит, то сравнение проваливается и значит, подпись поддельная и доверять ей нельзя.
Нетрудно заметить, что если у двух сертификатов будет одинаковый хэш, то и результат шифрования тайным ключом удостоверителя выйдет одинаков. Если я могу взять сертификат, удостоверяющий сайт https://mail.google.com, и составить свой с таким же именем и таким же хэшем, то мне совершенно необязательно знать секретный ключ фирмы VeriSign, подписавшей сертификат Гугля – я могу просто скопировать подпись из сертификата Гугля и пришпандорить к своему. После чего построить липовый сайт, выдающий себя за https://mail.google.com и перехватывать пароли. Именно поэтому требования не повторяющихся значений на выходе хэш-функции настолько важно: уникальный хэш = уникальная подпись.
Амбула:
Так вот, в 2008-м группа из семи исследователей именно этого и добилась – сумела сгенерировать пару сертификатов так, чтобы хэш у них вышел одинаков. После чего подсунула один из них на подпись к одному из CA – фирме Equifax / GeoTrust. Поскольку критериям CA сертификат вполне удолетворял (несмотря на указанное в нём имя сайта i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org), то GeoTrust его автоматически подмахнула за малую мзду. После чего остался последний ход: подпись просто взяли и приставили ко второму сертификату, который GeoTrust не подписала бы ни в жисть. А не подписала бы потому, что второй был выписан не на какой-то там вебсайт, настоящий или липовый – а на дочерний CA, который автоматом наследует весь капитал доверия, которым располагает GeoTrust. То есть хозяева поддельного сертификата получили прекрасную возможность выписывать в свою очередь любые другие сертификаты, которым бы браузеры доверяли автоматически.
Выгорело дело, кстати, потому, что GeoTrust полагалась на хэш-функцию по нынешним временам слабую – MD5. Первую полноценную коллизию в MD5 нашли ещё в 2004-м, но от того, чтобы просто найти два каких-то куска информации с одинаковым хэшем и до того, чтобы подобрать таким образом два куска _нужной_ информации – дистанция огромного размера, и великолепная семёрка её преодолела. Всякие смачные детали, вроде вычислений на кластере из двухста игровых консолей, можете почитать здесь, а я поговорю о последствиях.
Что могло бы выйти:
Последствий особых не было, разве что все СA бросились срочно менять MD5 на более стойкий алгоритм – SHA1. Но не было лишь потому, что авторы работы, из социальной ответственности, постарались собственные результаты всячески обезвредить. Во-первых, отказались разгласить ключ, с помощью которого могли бы выписывать дочерние сертификаты. Во-вторых, свой липовый сертификат предусмотрительно создали дохлым с рожденья – со сроком жизни всего-то в август 2004-ого. И в третьих, просто не опубликовали некоторые секретные тонкости своей технологии.
Ну а если бы они решили пуститься во все тяжкие? У, тут последствия могли быть жирные. Корневым сертификатам Equifax / GeoTrust доверяют подавляющее большинство компьютеров в мире (и твой собственный, дорогой читатель – не веришь, запусти certmgr.msc и полюбуйся на список в "Trusted Root Certification Authorities"), они поставляются вместе с операционными системами и браузерами, такими, как Firefox. Это значит, что дочернему – липовому – CA они доверяли бы точно так же. А это открывает большие возможности:
• Можно выписать сертификат на абсолютно любой сайт – хоть на https://www.facebook.com/, хоть на https://www.paypal.com. После чего с помощью MitM-атаки или фишинга красть пароли, личную информацию, коммерческие секреты, просто деньги. Причём совершенно неважно, что Пайпалу сертификат выписал не GeoTrust, а вовсе даже VeriSign, и без всякого MD5.
• Можно подписывать какой-нибудь malware. Сегодня туча програм подписывается каким-нибудь CA, чтобы юзер не боялся запускать их на своей машине. Windows при попытке поставить програмку без подписи уже и предупреждение выкатывает... Так вот, берём любого троянского коня, любой spyware, и снабжаем его подписью – создано Microsoft. После чего хошь – ботнет строй, хошь – пароли кради, ну и бабло, опять же.
• Можно перехватывать шифрованные каналы IPsec / VPN, можно ловить пароли от копроративных WiFi-сеток.
• Можно тот же malware рассылать подписанными / шифрованными мэйлами, чтобы спаморезки пропускали и юзеры ловились, а то и проводить сложные мошеннические схемы с фальшивыми документами, но это скорее экзотика.
В общем, нехило оторваться можно. Причём в любую из этих ловушек не то что обычный юзер, но и админ-параноик вденется в полный рост. Что, кто-то помнит наизусть, какой CA выписал сертификат его банку?
Контрмеры:
Хорошо, допустим, какие-то атаки бы удались – но потом началось бы расследование и на свет божий выплыло бы существование липового CA. Насколько эффективно можно было бы свести возможность повторных атак на нет?
Вообще-то, не особенно. Основной способ борьбы с сертификатами, попавшими не в те руки, это “чёрные списки”, называемые CRL (certificate revocation list). Каждый CA публикует такой список, куда вносит сертификаты, которым призывает больше не доверять. В теории, браузеры или любые иные программы, желающие проверить сертификат, должны прочесть свежий CRL от того CA, что подписал сертификат и убедиться, что его серийного номера нет в списке.
То есть GeoTrust могли бы взять серийник нашего липового сертификата и забить его в свой список (вот он, кстати - http://crl.geotrust.com/crls/globalca1.crl).
Проблема в том, что способ этот очень ограничен:
1.) Как браузер вообще узнаёт, где искать CRL? Ответ: URL к нему публикуется прямо в том же сертификате, который браузер и хочет проверить. Бредово? В общем да: основано это на предположении, что подделать сертификат нельзя, и призвано для защиты от иных сценариев (утечка ассоциированного с сертификатом секретного ключа, в основном).
Ну а наш поддельный сертификат адреса CRL вообще не содержит, и привет. И ни один браузер по этому поводу не заверещит, потому как ситуация эта нормальна: нет требования, чтобы любой сертификат непременно содержал линк к CRL. И даже если бы такое требование было, обойти его было бы легко: достаточно поставить неработающий линк, или работающий, но на битый CRL, или даже вполне целый, с отменной подписью законнейшего CA, только ... устаревший. Браузеры не склонны портить user experience предупреждающими воплями лишь потому, что не удалось прочесть самый свежий CRL, да ещё и не первый в цепочке.
2.) Тем не менее, есть способы, которыми CRL может дойти до потенциальных жертв:
a. Допустим, браузер открыл сайт, защищёный легальным сертификатом от того же Equifax, в ходе проверки скачал CRL и закэшировал его. Тогда, покамест CRL хранится в кэше, попытки подсунуть фальшак провалятся.
Проблема в том, что это чисто вероятностная штука.
b. Иные механизмы, такие, как Windows Update. После того, как иранский хакер смог заполучить сертификаты к набору разных важный сайтов два года назад, этот способ и использовался: вместе с заплатками к операционке на компьютер спускался CRL c номерами забаненных сертификатов и сами эти сертификаты.
Проблема в том, что далеко не все компы получают регулярно обновления.
3.) Не все браузеры вообще удосуживаются проверять CRL, поскольку это замедляет загрузку страниц – нужно дополнительно побегать по линкам и проверить подписи.
4.) Наконец, есть сценарии, когда проверить CRL просто невозможно. Например, когда сертификат используется для защиты доступа в сетку WiFi. Как клиенту убедиться, что сертификат не отозван, когда у него и IP-адреса ещё даже нет?
В общем, вполне можно ожидать, что даже месяцы и годы спустя обнаружения первых атак процентов этак 20-30 компьютеров в мире принимали бы липовые сертификаты за милую душу.
Вот какая неприятность может произойти всего-то из того, что хэш-функция для двух input’ов выдала один output. :-)
Выводы:
1. Всякий, имеющий дело с сертификатами с MD5 – да отряхнёт их прах с рук своих.
2. Да и на SHA1 лучше не полагаться. Если его завтра вот так ломанут, это будет ОЙ! – потому как почти все сертификаты подписываются с SHA1RSA.
3. Сисадмин, помни, что иерархия доверия – вообще-то, необходимое зло, призванное решать проблему scalability, а не нечто прекрасное само по себе. Если есть возможность установить точечное доверие к конечному сертификату, а не полагаться на цепочку подписей – стоит это делать.
4. Доверять стопроцентно одной лишь технологии никогда не стоит. Защищать передачу юзерского пароля одним лишь SSL – плохая идея, лучше использовать дополнительную схему типа digest / NTLM / Kerberos, даже если обмен идёт по шифрованному каналу.
5. Нужен способ проверки CRL-ей и цепочек доверия сверху вниз, от корневого CA, а не наоборот. Логичный кандидат для этого, кстати, есть – DNSSEC.
6. PKI чрезмерно полагается на предположение, что подделать подпись нельзя, и должен быть передизайнен с дополнительными защитами.
