The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером
Для предотвращения получения TLS-сертификатов третьими лицами, которые в ходе
MITM-атаки могут контролировать трафик сервера, рекомендовано использовать
DNS-запись CAA, через которую можно указать какой именно удостоверяющий центр и
какая именно учётная запись в этом удостоверяющем центре авторизированы на
выдачу сертификата для домена.

CAA поддерживается в Let's Encrypt и не позволяет запросить сертификат,
используя другой ACME-ключ. Для включения привязки в DNS-зону следует добавить:

для привязки домена example.com к удостоверяющему центру letsencrypt.org:

   example.com. IN CAA 0 issue "letsencrypt.org"

для дополнительно привязки к учётной записи acme-v02.api.letsencrypt.org/acme/acct/1234567890

   example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

DNS-сервер должен быть размещён на отдельном сервере, не подверженном
MITM-атаке. Для дополнительной защиты от подмены DNS необходимо использовать
протокол DNSSEC, который помешает атакующим подменить  DNS-ответы с записью CAA.

Дополнительно рекомендовано через Tor или внешние хосты наладить автоматический
мониторинг  отсутствия подмены сертификатов, и подключиться к сервисам
мониторинга CT-логов (Certificate Transparency, отражают выданные
удостоверяющими центрами сертификаты) или вручную отслеживать появление
незапрошенных сертификатов в CT-логах (https://crt.sh/). Также  рекомендовано
выбирать размещённых в разных странах операторов хостинга, регистрации домена,
DNS и удостоверяющих центров.
 
Ключи: mitm, tls, dns, crypt, acme, letsencrypt / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Аноним (1), 13:33, 21/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гдето в заголовке стоит добавить что речь о получении tls серта сервером.

    Для клиента задача решается чуть по другому:
    https://www.linux.org.ru/forum/admin/15104732?cid=15113619
    https://www.linux.org.ru/forum/admin/15104732?cid=15113671

     
     
  • 2.2, Аноним (2), 15:37, 21/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там просто сверяют эталонный список корневых сертификатов со списком, установленным у клиента. Это не поможет в ситуации как с jabber.ru (https://www.opennet.me/59965 ), когда валидный сертификат был получен владельцем сервера в  Let's Encrypt и MITM-атакующий тоже получил фиктивный сертификат через Let's Encrypt, на время переправив трафик к себе. Раньше помогал pinning сертификатов, но его убрали из браузеров и он был актуален для долгожвивущих сертификатов, а на тех, что на 3 месяца выдаются.
     
     
  • 3.3, fyjybv (?), 16:34, 21/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >привязка DNS к учётной записи letsencrypt

    может быть поможет

     
  • 3.23, Пряник (?), 14:22, 26/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    HPKP ещё от компрометации центра сертов защищает.
     

  • 1.4, Аноним (4), 22:17, 21/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    И все равно все сводится к ЦА. Могут проверить, а могут и выпустить для особого случая непроверенный сертификат.
    Еще в нулевые сертификаты за это критиковались, но публичные случаи были достаточно редки, а после джаббера думаю очевидно что современная инфраструктура не отражает современных потребностей (у ssl есть и другие проблемы с конфидициальностью) и все должно быть перестроено на сквозное шифрование (вероятно в течение десятилетий) и децентрализованный веб.
     
     
  • 2.11, Аноним (11), 12:42, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это палево, выписать сертификат если у вас есть политика САА и атакующий не имеет валидного ключа.
    тут фигня в том что.. для того чтобы выписать сертификат, его надо сначала записать в СТ.. если не записать в СТ то браузер его (сертификат выписанный публичным ЦА, но не имеющем записи в СТ) отвергнет. тоесть владелец имеет возможность спалить факт выписки неустановленного сертификата, если контролирует появления своих сертификатов в СТ.

    Когда у того же ЛЕ выяснилось, что они проверяли не каждый раз САА а только раз в неделю, они поменяли политику и отозвали всё что небыло проверено по САА непосредственно в момент выписки.

    Это кстати то, почему сертификат минцифры - зло.. СТ подписей нет, (его не в списке публичных ЦА соотв браузер регистраций в СТ не требует, этакий корпоративный СА) и хрен владелец сайта узнает, что ему понавыписывали поддельных сертификатов.

     
  • 2.21, fi (ok), 09:38, 25/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > перестроено на сквозное шифрование

    вы попутали, это две разные задачи.

     

  • 1.5, OpenEcho (?), 13:54, 22/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

    Вот оно бы все хорошо, но проблема то в том, что нынче модно все "облаках" где в большинстве случаев то самый "/acme/acct/1234567890" находится вместе с приватным ключом от аккаунта на том же виртуальном хосте, ну для удобства, чтоб там по dehydrated, lego, certbot... все обновлялось автоматом по крону и если учесть что хост может видеть гостей в облаках, то что хостеру мешает "заглянуть" одним глазком на ключик от аккаунта?  И вся секьюрность сыпится как карточный домик.

    Вот это вот ^^^ ключевой момент, чтоб работало как написано, надо генерировать сертификаты не на серваках, а через DNS с отдельной, выделенной только для,  админской тачки и деплоить уже потом выданные сертификаты на серваки

     
     
  • 2.26, Tron is Whistling (?), 09:46, 29/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "На облаках" вы можете генерировать хоть у себя на коленке - "заглянувший" внутрь хоста вася всё равно получит приватный ключ вашего сертификата вместе с сертификатом, и даже выписывать поддельный серт не надо.

    И ничего вообще от этого не спасёт. Кроме отказа от "облачка" собственной инфраструктуры. Там другие проблемы с безопасностью, но конкретно этой - нет. Ну или принять этот риск как возможное неизбежное зло и учитывать.

     

  • 1.6, OpenEcho (?), 14:15, 22/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ко всему тому, что написанно в статье + выполненно условие описанное выше мной, не плохо бы еще и перестраховаться и кронить переодически то что ниже

    '''
    <pre>
        #!/bin/sh

        domain='супер.дуппер.tld'
        last_issued_date='2023-11-09T02:21:15'  # хозяином

        rc=$(
          curl "https://crt.sh/?q=${domain}&output=json" 2>/dev/null |
          jq --arg d ${last_issued_date} 'map(select(.entry_timestamp | . > $d + "z"))'
        )

        if [ "${rc}" != '[]' ]; then
          echo 'КАРАУЛ !!!'
        fi
    </pre>
    '''

    P.S.
    На этом сайте когда нибудь можно уже <code></code>  или безобидный <xmp></xmp>?

     
     
  • 2.24, ivan_erohin (?), 08:27, 29/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > На этом сайте когда нибудь можно уже <code></code> или безобидный <xmp></xmp>?

    1) и так все понятно.
    2) все равно переделывать. например запрос на crt.sh слать (и ответ получать)
    по двум разным каналам. т-щ майор идущее через открытый интернет РФ подделает,
    а херр гауптман из BND - нет. или наоборот.

     

  • 1.7, OpenEcho (?), 14:28, 22/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею и не сидят на бабках мордакниги и добросовестно все сливают в СТ ;)
     
     
  • 2.13, Аноним (11), 12:55, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот
    > ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею
    > и не сидят на бабках мордакниги и добросовестно все сливают в
    > СТ ;)

    А им деваться некуда... веб браузеры не возьмут сертификат без записи из СТ..

     
     
  • 3.15, OpenEcho (?), 13:24, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот
    >> ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею
    >> и не сидят на бабках мордакниги и добросовестно все сливают в
    >> СТ ;)
    > А им деваться некуда... веб браузеры не возьмут сертификат без записи из
    > СТ..

    А с каких это пор браузеры стали в СТ заглядывать? Вы с OCSP не перепутали?

     
     
  • 4.16, Аноним (11), 16:42, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот как раз в ОCSP они перестали почти все заглядывать уже давно А в сам СТ им ... большой текст свёрнут, показать
     
     
  • 5.18, OpenEcho (?), 18:19, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А в сам СТ им заглядывать нет нужны

    Т.е. просто верить на слово СА тому что они подписали?

    > В самом браузере зашит список публичных СТ и их подписи, соотв он проверит, что подписи тут валидны

    А здесь мы верим браузерам...

     
     
  • 6.29, Аноним (29), 20:50, 07/11/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А здесь мы верим браузерам...

    А ещё ядру ОС, библиотекам, компиляторам, авторам ЯП, а то и вовсе центральным процессорам, модулям памяти и даже сетевым картам. Боюсь выход только один: направить оптоволокно прямо в глаз и считывать сигналы напрямую. Уж фотоны-то точно не подведут!

     
     
  • 7.30, OpenEcho (?), 13:47, 08/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> А здесь мы верим браузерам...
    > А ещё ядру ОС, библиотекам, компиляторам, авторам ЯП, а то и вовсе
    > центральным процессорам, модулям памяти и даже сетевым картам. Боюсь выход только
    > один: направить оптоволокно прямо в глаз и считывать сигналы напрямую. Уж
    > фотоны-то точно не подведут!

    "Сильно" сказал...

    Только мы здесь говорили конкретно о сертификатах.
    Все что ты перечислили, - возможно перепроверить, а вот сертификаты это такая штука которая связанна с понятием криптография, которая для того и сделана чтобы что-то скрыть - НАДЕЖНО

     
     
  • 8.32, Аноним (29), 21:41, 08/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт о... текст свёрнут, показать
     
     
  • 9.33, OpenEcho (?), 00:00, 09/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я не знаю, осталась или нет одна очень интересная лаборатория в России, в которы... текст свёрнут, показать
     
  • 7.31, OpenEcho (?), 21:16, 08/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Прям во время, специально для вас постарались:

    https://www.theregister.com/2023/11/08/europe_eidas_browser/

     

  • 1.8, OpenEcho (?), 14:35, 22/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > и подключиться к сервисам мониторинга CT-логов (Certificate Transparency, отражают выданные удостоверяющими центрами сертификаты)

    Может кто-нибудь гарантировать, что то самый СТ, как бы случайно, (ну "ошибочки" они же у всех бывают, правда? Особенно преднамеренные) вдруг пропустит выданный "кому-то" серт (по большому блату/просьбе) ?

     
     
  • 2.12, Аноним (11), 12:53, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Может кто-нибудь гарантировать, что то самый СТ, как бы случайно, (ну "ошибочки"
    > они же у всех бывают, правда? Особенно преднамеренные) вдруг пропустит выданный
    > "кому-то" серт (по большому блату/просьбе) ?

    при выписке сертификата в нём должно появиться не менее 2-х записей из двух баз СТ. соотв. сначала серт регистрируется в СТ а потом подписывается (для этого там есть такая штука как пресертификат, который и регистрируется в СТ) и только потом отдаётся клиенту. Веб браузер сертификат без инфы от СТ должен отвергнуть.
    Кроме того многие регистраторы, включая ЛЕ, в СТ сливают и сам выписанный сертификат (а не только пресертификат) если же сам сертификат туда не попадает, его туда временами заливает ктото еще. В общем появление пресертификата достаточно, чтобы было понятно, что сертификат выписан.

     
     
  • 3.14, OpenEcho (?), 13:20, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > при выписке сертификата в нём должно появиться не менее 2-х записей из
    > двух баз СТ.

    И оба, три СТ... находятся под чей юрисдикцией?
    Если вам ну очень убедительно скажут, - поставить фильтр отсекающий выдачу "нужным людям", вы ведь точно откажетесь, правда?

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

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

     
     
  • 4.17, Аноним (11), 16:58, 24/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >> при выписке сертификата в нём должно появиться не менее 2-х записей из
    >> двух баз СТ.
    > И оба, три СТ... находятся под чей юрисдикцией?
    > Если вам ну очень убедительно скажут, - поставить фильтр отсекающий выдачу "нужным
    > людям", вы ведь точно откажетесь, правда?

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

    И да, ЦТ это  не та постгресовая базка, которую покажут по https://crt.sh/?Identity=%25.opennet.ru. Это агрегатор, по разным ЦТ для удобства.. Можно мониторить все СТ самостоятельно, список есть, он публичен. (оно немного не быстро, т.к. там реально надо перпелопатить все миллиарды записей) но если этим заниматься постоянно, то т.к. блокчейн, то не надо там каждый раз вычитывать с начала времён, а можно продолжать с ранее законченного места. В общем я это делаю для себя по своим доменам.

    и уж точно ни РФ ни ФРГ спецслужбы там не смогли бы ни на что повлиять... если там есть дыры в математике, или процедуре, то доступны они только одной стране. Ну и как бы не факт они там есть.. Скорее дыры есть в алгоритмах шифрования, которые позволяют им читать что им надо безо всей этой вот мишуры.. и ключ под сертификат им скорее всего не нужен, сам трафик, который представляет интерес шифруется же не им. Это всё для установления связи и проверки, что попали туда изначально.

     
     
  • 5.19, OpenEcho (?), 00:02, 25/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ну там, типа, блокчейн база..

    Тот самый блокчэин, который можно модефицировать имея более 50% котроля.

    А сами СТ: Apple, Google, Sectigo, Censys, Cloudflare, digicert, facebook...
    sorry, - но волки, заботящиеся о баранах

    Или там есть кто то из Индии, Китая, России, Казахстана с более чем 50% контроля над блок чэин?

     

  • 1.9, OpenEcho (?), 15:08, 22/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кстати, для копи-пастеров, бит 128 вместо 0 в САА записи - более полезен

    Правильно:
    <code>
        example.com. IN CAA 128 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
    </code>

    Для не верующих - RTFM: https://letsencrypt.org/docs/caa/

     
  • 1.20, VecH (ok), 04:56, 25/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В каком формате данные вколачивать на dns.he.net ?
    Что не вставлял, пишет что invalid
     
     
  • 2.25, ivan_erohin (?), 08:32, 29/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > В каком формате данные вколачивать на dns.he.net ?
    > Что не вставлял, пишет что invalid

    BIND 9.18.19-1 - все работает. обратитесь в техподдержку электро хурриканов.

     

  • 1.22, придурок (?), 21:06, 25/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    браузер заверещит же чё тут защищаться то
     
     
  • 2.35, Аноним (35), 13:17, 16/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Серт же действительный. Вы про кейс jabber.ru таки почитайте сначала.
     

  • 1.27, Tron is Whistling (?), 09:50, 29/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как вы понимаете, всё это - honor-based, и никаких гарантий, что некий CA (даже тот, что обычно CAA хонорит) не выпишет серт из-за сбоя с проверкой этого самого CAA - нет.
     
     
  • 2.28, Tron is Whistling (?), 09:51, 29/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Надёжнее использовать stapling, потому что там хотя бы тысячиглаз, то есть браузеров, большинство из которых таки проверяют для себя любимого лично. Но и это не панацея.
     

  • 1.34, НоуНэйм (?), 15:32, 12/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Защититься от этого - элементарно и просто.
    самовыпущенный сертификат.
     
     
  • 2.36, Аноним (35), 13:45, 16/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это да, но вот потом вам надо будет, чтобы юзеры проверяли, что этот сертификат самовыпустил именно ты, а не васян-хацкер или тащмайор. Вручную через какой-то условно доверенный канал.
     

  • 1.37, Аноним (-), 17:08, 17/11/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какой шикарный костыль. Потом окажется что DNS тоже можно подменять, понадобится еще DNSSEC какой-нибудь кривущий и что там еще.

    В общем этажерка https/tls начинает предсказуемо разваливаться прямо в воздухе.

     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру