forum.opennet.ru - "Раздел полезных советов: Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" (36)

"Раздел полезных советов: Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от auto_tips (??), 21-Окт-23, 13:33
Для предотвращения получения TLS-сертификатов третьими лицами, которые в ходе MITM-атаки могут контролировать трафик сервера, рекомендовано использовать DNS-запись CAA, через которую можно указать какой именно удостоверяющий центр и какая именно учётная запись в этом удостоверяющем центре авторизированы на выдачу сертификата для домена. CAA [[https://letsencrypt.org/docs/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 и удостоверяющих центров. URL: https://www.devever.net/~hl/xmpp-incident https://www.devever.net/~hl/acme-caa-live Обсуждается: http://www.opennet.dev/tips/info/3232.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Гдето в заголовке стоит добавить что речь о получении tls серта сервером Для кли, Аноним (1), 13:33 , 21-Окт-23, (1)

Там просто сверяют эталонный список корневых сертификатов со списком, установлен, Аноним (2), 15:37 , 21-Окт-23, (2)

может быть поможет, fyjybv (?), 16:34 , 21-Окт-23, (3) +1
HPKP ещё от компрометации центра сертов защищает , Пряник (?), 14:22 , 26-Окт-23, (23)

И все равно все сводится к ЦА Могут проверить, а могут и выпустить для особого , Аноним (4), 22:17 , 21-Окт-23, (4) +4

Это палево, выписать сертификат если у вас есть политика САА и атакующий не имее, Аноним (11), 12:42 , 24-Окт-23, (11) +2
вы попутали, это две разные задачи , fi (ok), 09:38 , 25-Окт-23, (21)

Вот оно бы все хорошо, но проблема то в том, что нынче модно все облаках где в, OpenEcho (?), 13:54 , 22-Окт-23, (5)

На облаках вы можете генерировать хоть у себя на коленке - заглянувший внутр, Tron is Whistling (?), 09:46 , 29-Окт-23, (26) +1

Ко всему тому, что написанно в статье выполненно условие описанное выше мной, , OpenEcho (?), 14:15 , 22-Окт-23, (6) +2

1 и так все понятно 2 все равно переделывать например запрос на crt sh слать , ivan_erohin (?), 08:27 , 29-Окт-23, (24)

Да, и до кучи, покрехтелки Hetzner Linode - плохие, а вот ЛетсШитКрипт - хор, OpenEcho (?), 14:28 , 22-Окт-23, (7) –1

А им деваться некуда веб браузеры не возьмут сертификат без записи из СТ , Аноним (11), 12:55 , 24-Окт-23, (13) +1

А с каких это пор браузеры стали в СТ заглядывать Вы с OCSP не перепутали , OpenEcho (?), 13:24 , 24-Окт-23, (15)

Вот как раз в ОCSP они перестали почти все заглядывать уже давно А в сам СТ им , Аноним (11), 16:42 , 24-Окт-23, (16) +1

Т е просто верить на слово СА тому что они подписали А здесь мы верим браузерам, OpenEcho (?), 18:19 , 24-Окт-23, (18)

А ещё ядру ОС, библиотекам, компиляторам, авторам ЯП, а то и вовсе центральным п, Аноним (29), 20:50 , 07-Ноя-23, (29) –1

Сильно сказал Только мы здесь говорили конкретно о сертификатах Все что ты п, OpenEcho (?), 13:47 , 08-Ноя-23, (30)

Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт о, Аноним (29), 21:41 , 08-Ноя-23, (32)

Я не знаю, осталась или нет одна очень интересная лаборатория в России, в которы, OpenEcho (?), 00:00 , 09-Ноя-23, (33)

Прям во время, специально для вас постарались https www theregister com 2023 1, OpenEcho (?), 21:16 , 08-Ноя-23, (31)

Может кто-нибудь гарантировать, что то самый СТ, как бы случайно, ну ошибочки , OpenEcho (?), 14:35 , 22-Окт-23, (8)

при выписке сертификата в нём должно появиться не менее 2-х записей из двух баз , Аноним (11), 12:53 , 24-Окт-23, (12)

И оба, три СТ находятся под чей юрисдикцией Если вам ну очень убедительно ска, OpenEcho (?), 13:20 , 24-Окт-23, (14)

ну там, типа, блокчейн база есть некоторые сложности, математического порядка,, Аноним (11), 16:58 , 24-Окт-23, (17)

Тот самый блокчэин, который можно модефицировать имея более 50 котроля А сами , OpenEcho (?), 00:02 , 25-Окт-23, (19)

Кстати, для копи-пастеров, бит 128 вместо 0 в САА записи - более полезенПравильн, OpenEcho (?), 15:08 , 22-Окт-23, (9) +1
В каком формате данные вколачивать на dns he net Что не вставлял, пишет что inv, VecH (ok), 04:56 , 25-Окт-23, (20)

BIND 9 18 19-1 - все работает обратитесь в техподдержку электро хурриканов , ivan_erohin (?), 08:32 , 29-Окт-23, (25)

браузер заверещит же чё тут защищаться то, придурок (?), 21:06 , 25-Окт-23, (22)

Нет Серт же действительный Вы про кейс jabber ru таки почитайте сначала , Аноним (35), 13:17 , 16-Ноя-23, (35)

Как вы понимаете, всё это - honor-based, и никаких гарантий, что некий CA даже , Tron is Whistling (?), 09:50 , 29-Окт-23, (27)

Надёжнее использовать stapling, потому что там хотя бы тысячиглаз, то есть брауз, Tron is Whistling (?), 09:51 , 29-Окт-23, (28)

Защититься от этого - элементарно и просто самовыпущенный сертификат , НоуНэйм (?), 15:32 , 12-Ноя-23, (34)

Это да, но вот потом вам надо будет, чтобы юзеры проверяли, что этот сертификат , Аноним (35), 13:45 , 16-Ноя-23, (36)

Какой шикарный костыль Потом окажется что DNS тоже можно подменять, понадобится, Аноним (-), 17:08 , 17-Ноя-23, (37)

Сообщения [Сортировка по времени | RSS]

1. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (1), 21-Окт-23, 13:33

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

Ответить | Правка | Наверх | Cообщить модератору

2. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (2), 21-Окт-23, 15:37

Там просто сверяют эталонный список корневых сертификатов со списком, установленным у клиента. Это не поможет в ситуации как с jabber.ru (https://www.opennet.dev/59965 ), когда валидный сертификат был получен владельцем сервера в  Let's Encrypt и MITM-атакующий тоже получил фиктивный сертификат через Let's Encrypt, на время переправив трафик к себе. Раньше помогал pinning сертификатов, но его убрали из браузеров и он был актуален для долгожвивущих сертификатов, а на тех, что на 3 месяца выдаются.

Ответить | Правка | Наверх | Cообщить модератору

3. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +1 +/–

Сообщение от fyjybv (?), 21-Окт-23, 16:34

>привязка DNS к учётной записи letsencrypt
может быть поможет

Ответить | Правка | Наверх | Cообщить модератору

23. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Пряник (?), 26-Окт-23, 14:22

HPKP ещё от компрометации центра сертов защищает.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +4 +/–

Сообщение от Аноним (4), 21-Окт-23, 22:17

И все равно все сводится к ЦА. Могут проверить, а могут и выпустить для особого случая непроверенный сертификат.
Еще в нулевые сертификаты за это критиковались, но публичные случаи были достаточно редки, а после джаббера думаю очевидно что современная инфраструктура не отражает современных потребностей (у ssl есть и другие проблемы с конфидициальностью) и все должно быть перестроено на сквозное шифрование (вероятно в течение десятилетий) и децентрализованный веб.

Ответить | Правка | Наверх | Cообщить модератору

11. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +2 +/–

Сообщение от Аноним (11), 24-Окт-23, 12:42

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

Ответить | Правка | Наверх | Cообщить модератору

21. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от fi (ok), 25-Окт-23, 09:38

> перестроено на сквозное шифрование
вы попутали, это две разные задачи.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 22-Окт-23, 13:54

> 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 с отдельной, выделенной только для,  админской тачки и деплоить уже потом выданные сертификаты на серваки

Ответить | Правка | Наверх | Cообщить модератору

26. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +1 +/–

Сообщение от Tron is Whistling (?), 29-Окт-23, 09:46

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

Ответить | Правка | Наверх | Cообщить модератору

6. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +2 +/–

Сообщение от OpenEcho (?), 22-Окт-23, 14:15

Ко всему тому, что написанно в статье + выполненно условие описанное выше мной, не плохо бы еще и перестраховаться и кронить переодически то что ниже
```
<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>?

Ответить | Правка | Наверх | Cообщить модератору

24. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от ivan_erohin (?), 29-Окт-23, 08:27

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

Ответить | Правка | Наверх | Cообщить модератору

7. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" –1 +/–

Сообщение от OpenEcho (?), 22-Окт-23, 14:28

Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею и не сидят на бабках мордакниги и добросовестно все сливают в СТ ;)

Ответить | Правка | Наверх | Cообщить модератору

13. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +1 +/–

Сообщение от Аноним (11), 24-Окт-23, 12:55

> Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот
> ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею
> и не сидят на бабках мордакниги и добросовестно все сливают в
> СТ ;)
А им деваться некуда... веб браузеры не возьмут сертификат без записи из СТ..

Ответить | Правка | Наверх | Cообщить модератору

15. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 24-Окт-23, 13:24

>> Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот
>> ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею
>> и не сидят на бабках мордакниги и добросовестно все сливают в
>> СТ ;)
> А им деваться некуда... веб браузеры не возьмут сертификат без записи из
> СТ..
А с каких это пор браузеры стали в СТ заглядывать? Вы с OCSP не перепутали?

Ответить | Правка | Наверх | Cообщить модератору

16. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +1 +/–

Сообщение от Аноним (11), 24-Окт-23, 16:42

Вот как раз в ОCSP они перестали почти все заглядывать уже давно. А в сам СТ им заглядывать нет нужны, всё что нужно, есть в сертификате, который сервер любезно сообщает сам.
openssl s_client -showcerts -connect opennet.ru:443 < /dev/null | openssl x509 -text
...
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : B7:3E:FB:24:DF:9C:4D:BA:75:F2:39:C5:BA:58:F4:6C:
                                5D:FC:42:CF:7A:9F:35:C4:9E:1D:09:81:25:ED:B4:99
                    Timestamp : Sep  8 20:02:31.632 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:29:D5:65:98:8D:F5:BE:5E:80:72:58:68:
                                51:89:EE:CF:94:9E:BE:AB:95:C6:90:B1:58:34:11:B0:
                                32:55:76:59:02:20:6F:75:88:3A:18:D4:72:3F:C9:E2:
                                CB:53:E8:26:6F:EF:E7:53:57:C8:E2:64:CD:ED:12:7F:
                                71:30:9B:82:5A:E2
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 7A:32:8C:54:D8:B7:2D:B6:20:EA:38:E0:52:1E:E9:84:
                                16:70:32:13:85:4D:3B:D2:2B:C1:3A:57:A3:52:EB:52
                    Timestamp : Sep  8 20:02:31.647 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:3F:9D:B2:BA:07:7D:0C:02:95:AC:D5:58:
                                79:4B:74:A0:F1:EA:AE:2E:DE:D6:3D:48:8E:CE:4F:47:
                                8A:C7:BD:20:02:21:00:B4:1A:01:2D:80:E8:AB:82:4E:
                                54:D0:C1:7C:6F:46:18:8A:02:B7:64:B7:55:4A:32:60:
                                A6:C5:E7:42:F3:A4:3C
...
тоже самое в уже декодированном виде можно посмотреть во вкладке security в нетворк мониторе хрома
Certificate Transparency
SCT    Let's Encrypt 'Oak2023' log (Embedded in certificate, Verified)
SCT    Cloudflare 'Nimbus2023' Log (Embedded in certificate, Verified)
В самом браузере зашит список публичных СТ и их подписи, соотв он проверит, что подписи тут валидны.. Есть и второй способ, когда веб сервер сам сливает сертификат в СТ и добавляет информацию о СТ с подписями в ответе вместе с сертификатом, на случай если информации о СТ нет в самом сертификате, но сейчас публичные СА таких не выдают, а те что были выданы ранее, те давно протухли.

Ответить | Правка | Наверх | Cообщить модератору

18. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 24-Окт-23, 18:19

> А в сам СТ им заглядывать нет нужны
Т.е. просто верить на слово СА тому что они подписали?
> В самом браузере зашит список публичных СТ и их подписи, соотв он проверит, что подписи тут валидны
А здесь мы верим браузерам...

Ответить | Правка | Наверх | Cообщить модератору

29. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" –1 +/–

Сообщение от Аноним (29), 07-Ноя-23, 20:50

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

Ответить | Правка | Наверх | Cообщить модератору

30. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 08-Ноя-23, 13:47

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

Ответить | Правка | Наверх | Cообщить модератору

32. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (29), 08-Ноя-23, 21:41

Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт от уязвимого железа. Но ты почему-то решил не доверять именно браузеру, который почему-то уместен в разговоре «конкретно о сертификатах», а железо, на котором он исполняется почему-то нет. Уж что-что, а переобуваться в прыжке любой опеннетчик умеет на олимпийском уровне.

Ответить | Правка | Наверх | Cообщить модератору

33. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 09-Ноя-23, 00:00

> Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт от уязвимого железа.
Я не знаю, осталась или нет одна очень интересная лаборатория в России, в который чудесно могли заглядывать под штаники буржуйких процессоров еще 30 лет назад, а потом вдруг появлялись ВМ80, но думаю что онa не только осталaсь, но и развилaсь (особенно после разгадки не подключенных никуда 5-и транзисторов на подложке :)
> Но ты почему-то решил не доверять именно браузеру
Я верил очень давно, но теперь не верю и не буду верить в безплатный сыр в любом его представлении, надеюсь и вы это поймете со временем
>  Уж что-что, а переобуваться в прыжке любой опеннетчик умеет на олимпийском уровне.
Сорри, я глубины этой мысли - не понял

Ответить | Правка | Наверх | Cообщить модератору

31. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 08-Ноя-23, 21:16

Прям во время, специально для вас постарались:
https://www.theregister.com/2023/11/08/europe_eidas_browser/

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

8. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 22-Окт-23, 14:35

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

Ответить | Правка | Наверх | Cообщить модератору

12. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (11), 24-Окт-23, 12:53

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

Ответить | Правка | Наверх | Cообщить модератору

14. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 24-Окт-23, 13:20

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

Ответить | Правка | Наверх | Cообщить модератору

17. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (11), 24-Окт-23, 16:58

>> при выписке сертификата в нём должно появиться не менее 2-х записей из
>> двух баз СТ.
> И оба, три СТ... находятся под чей юрисдикцией?
> Если вам ну очень убедительно скажут, - поставить фильтр отсекающий выдачу "нужным
> людям", вы ведь точно откажетесь, правда?
ну там, типа, блокчейн база.. есть некоторые сложности, математического порядка, убрать часть из середины списка... или потом объяснять откуда взялся сертификат с подписью этого ЦТ внутри, не существующий в самом СТ.
И да, ЦТ это  не та постгресовая базка, которую покажут по https://crt.sh/?Identity=%25.opennet.ru. Это агрегатор, по разным ЦТ для удобства.. Можно мониторить все СТ самостоятельно, список есть, он публичен. (оно немного не быстро, т.к. там реально надо перпелопатить все миллиарды записей) но если этим заниматься постоянно, то т.к. блокчейн, то не надо там каждый раз вычитывать с начала времён, а можно продолжать с ранее законченного места. В общем я это делаю для себя по своим доменам.
и уж точно ни РФ ни ФРГ спецслужбы там не смогли бы ни на что повлиять... если там есть дыры в математике, или процедуре, то доступны они только одной стране. Ну и как бы не факт они там есть.. Скорее дыры есть в алгоритмах шифрования, которые позволяют им читать что им надо безо всей этой вот мишуры.. и ключ под сертификат им скорее всего не нужен, сам трафик, который представляет интерес шифруется же не им. Это всё для установления связи и проверки, что попали туда изначально.

Ответить | Правка | Наверх | Cообщить модератору

19. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от OpenEcho (?), 25-Окт-23, 00:02

> ну там, типа, блокчейн база..
Тот самый блокчэин, который можно модефицировать имея более 50% котроля.
А сами СТ: Apple, Google, Sectigo, Censys, Cloudflare, digicert, facebook...
sorry, - но волки, заботящиеся о баранах
Или там есть кто то из Индии, Китая, России, Казахстана с более чем 50% контроля над блок чэин?

Ответить | Правка | Наверх | Cообщить модератору

9. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +1 +/–

Сообщение от OpenEcho (?), 22-Окт-23, 15:08

Кстати, для копи-пастеров, бит 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/

Ответить | Правка | Наверх | Cообщить модератору

20. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от VecH (ok), 25-Окт-23, 04:56

В каком формате данные вколачивать на dns.he.net ?
Что не вставлял, пишет что invalid

Ответить | Правка | Наверх | Cообщить модератору

25. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от ivan_erohin (?), 29-Окт-23, 08:32

> В каком формате данные вколачивать на dns.he.net ?
> Что не вставлял, пишет что invalid
BIND 9.18.19-1 - все работает. обратитесь в техподдержку электро хурриканов.

Ответить | Правка | Наверх | Cообщить модератору

22. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от придурок (?), 25-Окт-23, 21:06

браузер заверещит же чё тут защищаться то

Ответить | Правка | Наверх | Cообщить модератору

35. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (35), 16-Ноя-23, 13:17

Нет. Серт же действительный. Вы про кейс jabber.ru таки почитайте сначала.

Ответить | Правка | Наверх | Cообщить модератору

27. "Раздел полезных советов: Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Tron is Whistling (?), 29-Окт-23, 09:50

Как вы понимаете, всё это - honor-based, и никаких гарантий, что некий CA (даже тот, что обычно CAA хонорит) не выпишет серт из-за сбоя с проверкой этого самого CAA - нет.

Ответить | Правка | Наверх | Cообщить модератору

28. "Раздел полезных советов: Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Tron is Whistling (?), 29-Окт-23, 09:51

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от НоуНэйм (?), 12-Ноя-23, 15:32

Защититься от этого - элементарно и просто.
самовыпущенный сертификат.

Ответить | Правка | Наверх | Cообщить модератору

36. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (35), 16-Ноя-23, 13:45

Это да, но вот потом вам надо будет, чтобы юзеры проверяли, что этот сертификат самовыпустил именно ты, а не васян-хацкер или тащмайор. Вручную через какой-то условно доверенный канал.

Ответить | Правка | Наверх | Cообщить модератору

37. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером" +/–

Сообщение от Аноним (-), 17-Ноя-23, 17:08

Какой шикарный костыль. Потом окажется что DNS тоже можно подменять, понадобится еще DNSSEC какой-нибудь кривущий и что там еще.
В общем этажерка https/tls начинает предсказуемо разваливаться прямо в воздухе.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от Аноним (1), 21-Окт-23, 13:33
Гдето в заголовке стоит добавить что речь о получении tls серта сервером. Для клиента задача решается чуть по другому: https://www.linux.org.ru/forum/admin/15104732?cid=15113619 https://www.linux.org.ru/forum/admin/15104732?cid=15113671
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от Аноним (2), 21-Окт-23, 15:37
	Там просто сверяют эталонный список корневых сертификатов со списком, установленным у клиента. Это не поможет в ситуации как с jabber.ru (https://www.opennet.dev/59965 ), когда валидный сертификат был получен владельцем сервера в Let's Encrypt и MITM-атакующий тоже получил фиктивный сертификат через Let's Encrypt, на время переправив трафик к себе. Раньше помогал pinning сертификатов, но его убрали из браузеров и он был актуален для долгожвивущих сертификатов, а на тех, что на 3 месяца выдаются.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"	+1 +/–
	Сообщение от fyjybv (?), 21-Окт-23, 16:34
	>привязка DNS к учётной записи letsencrypt может быть поможет
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Защита от подмены TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от Пряник (?), 26-Окт-23, 14:22
	HPKP ещё от компрометации центра сертов защищает.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору

4. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+4 +/–
Сообщение от Аноним (4), 21-Окт-23, 22:17
И все равно все сводится к ЦА. Могут проверить, а могут и выпустить для особого случая непроверенный сертификат. Еще в нулевые сертификаты за это критиковались, но публичные случаи были достаточно редки, а после джаббера думаю очевидно что современная инфраструктура не отражает современных потребностей (у ssl есть и другие проблемы с конфидициальностью) и все должно быть перестроено на сквозное шифрование (вероятно в течение десятилетий) и децентрализованный веб.
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+2 +/–
	Сообщение от Аноним (11), 24-Окт-23, 12:42
	Это палево, выписать сертификат если у вас есть политика САА и атакующий не имеет валидного ключа. тут фигня в том что.. для того чтобы выписать сертификат, его надо сначала записать в СТ.. если не записать в СТ то браузер его (сертификат выписанный публичным ЦА, но не имеющем записи в СТ) отвергнет. тоесть владелец имеет возможность спалить факт выписки неустановленного сертификата, если контролирует появления своих сертификатов в СТ. Когда у того же ЛЕ выяснилось, что они проверяли не каждый раз САА а только раз в неделю, они поменяли политику и отозвали всё что небыло проверено по САА непосредственно в момент выписки. Это кстати то, почему сертификат минцифры - зло.. СТ подписей нет, (его не в списке публичных ЦА соотв браузер регистраций в СТ не требует, этакий корпоративный СА) и хрен владелец сайта узнает, что ему понавыписывали поддельных сертификатов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от fi (ok), 25-Окт-23, 09:38
	> перестроено на сквозное шифрование вы попутали, это две разные задачи.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору

5. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от OpenEcho (?), 22-Окт-23, 13:54
> 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 с отдельной, выделенной только для, админской тачки и деплоить уже потом выданные сертификаты на серваки
Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+1 +/–
	Сообщение от Tron is Whistling (?), 29-Окт-23, 09:46
	"На облаках" вы можете генерировать хоть у себя на коленке - "заглянувший" внутрь хоста вася всё равно получит приватный ключ вашего сертификата вместе с сертификатом, и даже выписывать поддельный серт не надо. И ничего вообще от этого не спасёт. Кроме отказа от "облачка" собственной инфраструктуры. Там другие проблемы с безопасностью, но конкретно этой - нет. Ну или принять этот риск как возможное неизбежное зло и учитывать.
	Ответить \| Правка \| Наверх \| Cообщить модератору

6. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+2 +/–
Сообщение от OpenEcho (?), 22-Окт-23, 14:15
Ко всему тому, что написанно в статье + выполненно условие описанное выше мной, не плохо бы еще и перестраховаться и кронить переодически то что ниже ``` <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>?
Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от ivan_erohin (?), 29-Окт-23, 08:27
	> На этом сайте когда нибудь можно уже <code></code> или безобидный <xmp></xmp>? 1) и так все понятно. 2) все равно переделывать. например запрос на crt.sh слать (и ответ получать) по двум разным каналам. т-щ майор идущее через открытый интернет РФ подделает, а херр гауптман из BND - нет. или наоборот.
	Ответить \| Правка \| Наверх \| Cообщить модератору

7. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	–1 +/–
Сообщение от OpenEcho (?), 22-Окт-23, 14:28
Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею и не сидят на бабках мордакниги и добросовестно все сливают в СТ ;)
Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+1 +/–
	Сообщение от Аноним (11), 24-Окт-23, 12:55
	> Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот > ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею > и не сидят на бабках мордакниги и добросовестно все сливают в > СТ ;) А им деваться некуда... веб браузеры не возьмут сертификат без записи из СТ..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 24-Окт-23, 13:24
	>> Да, и до кучи, покрехтелки: Hetzner & Linode - плохие, а вот >> ЛетсШитКрипт - "хорошие"... они то уж точно работают исключительно за идею >> и не сидят на бабках мордакниги и добросовестно все сливают в >> СТ ;) > А им деваться некуда... веб браузеры не возьмут сертификат без записи из > СТ.. А с каких это пор браузеры стали в СТ заглядывать? Вы с OCSP не перепутали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+1 +/–
	Сообщение от Аноним (11), 24-Окт-23, 16:42
	Вот как раз в ОCSP они перестали почти все заглядывать уже давно. А в сам СТ им заглядывать нет нужны, всё что нужно, есть в сертификате, который сервер любезно сообщает сам. openssl s_client -showcerts -connect opennet.ru:443 < /dev/null \| openssl x509 -text ... CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : B7:3E:FB:24:DF:9C:4D:BA:75:F2:39:C5:BA:58:F4:6C: 5D:FC:42:CF:7A:9F:35:C4:9E:1D:09:81:25:ED:B4:99 Timestamp : Sep 8 20:02:31.632 2023 GMT Extensions: none Signature : ecdsa-with-SHA256 30:44:02:20:29:D5:65:98:8D:F5:BE:5E:80:72:58:68: 51:89:EE:CF:94:9E:BE:AB:95:C6:90:B1:58:34:11:B0: 32:55:76:59:02:20:6F:75:88:3A:18:D4:72:3F:C9:E2: CB:53:E8:26:6F:EF:E7:53:57:C8:E2:64:CD:ED:12:7F: 71:30:9B:82:5A:E2 Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 7A:32:8C:54:D8:B7:2D:B6:20:EA:38:E0:52:1E:E9:84: 16:70:32:13:85:4D:3B:D2:2B:C1:3A:57:A3:52:EB:52 Timestamp : Sep 8 20:02:31.647 2023 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:20:3F:9D:B2:BA:07:7D:0C:02:95:AC:D5:58: 79:4B:74:A0:F1:EA:AE:2E:DE:D6:3D:48:8E:CE:4F:47: 8A:C7:BD:20:02:21:00:B4:1A:01:2D:80:E8:AB:82:4E: 54:D0:C1:7C:6F:46:18:8A:02:B7:64:B7:55:4A:32:60: A6:C5:E7:42:F3:A4:3C ... тоже самое в уже декодированном виде можно посмотреть во вкладке security в нетворк мониторе хрома Certificate Transparency SCT Let's Encrypt 'Oak2023' log (Embedded in certificate, Verified) SCT Cloudflare 'Nimbus2023' Log (Embedded in certificate, Verified) В самом браузере зашит список публичных СТ и их подписи, соотв он проверит, что подписи тут валидны.. Есть и второй способ, когда веб сервер сам сливает сертификат в СТ и добавляет информацию о СТ с подписями в ответе вместе с сертификатом, на случай если информации о СТ нет в самом сертификате, но сейчас публичные СА таких не выдают, а те что были выданы ранее, те давно протухли.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 24-Окт-23, 18:19
	> А в сам СТ им заглядывать нет нужны Т.е. просто верить на слово СА тому что они подписали? > В самом браузере зашит список публичных СТ и их подписи, соотв он проверит, что подписи тут валидны А здесь мы верим браузерам...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	–1 +/–
	Сообщение от Аноним (29), 07-Ноя-23, 20:50
	> А здесь мы верим браузерам... А ещё ядру ОС, библиотекам, компиляторам, авторам ЯП, а то и вовсе центральным процессорам, модулям памяти и даже сетевым картам. Боюсь выход только один: направить оптоволокно прямо в глаз и считывать сигналы напрямую. Уж фотоны-то точно не подведут!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 08-Ноя-23, 13:47
	>> А здесь мы верим браузерам... > А ещё ядру ОС, библиотекам, компиляторам, авторам ЯП, а то и вовсе > центральным процессорам, модулям памяти и даже сетевым картам. Боюсь выход только > один: направить оптоволокно прямо в глаз и считывать сигналы напрямую. Уж > фотоны-то точно не подведут! "Сильно" сказал... Только мы здесь говорили конкретно о сертификатах. Все что ты перечислили, - возможно перепроверить, а вот сертификаты это такая штука которая связанна с понятием криптография, которая для того и сделана чтобы что-то скрыть - НАДЕЖНО
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от Аноним (29), 08-Ноя-23, 21:41
	Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт от уязвимого железа. Но ты почему-то решил не доверять именно браузеру, который почему-то уместен в разговоре «конкретно о сертификатах», а железо, на котором он исполняется почему-то нет. Уж что-что, а переобуваться в прыжке любой опеннетчик умеет на олимпийском уровне.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 09-Ноя-23, 00:00
	> Никакая, даже самая лучшая и максимально пост-квантовая криптография не спасёт от уязвимого железа. Я не знаю, осталась или нет одна очень интересная лаборатория в России, в который чудесно могли заглядывать под штаники буржуйких процессоров еще 30 лет назад, а потом вдруг появлялись ВМ80, но думаю что онa не только осталaсь, но и развилaсь (особенно после разгадки не подключенных никуда 5-и транзисторов на подложке :) > Но ты почему-то решил не доверять именно браузеру Я верил очень давно, но теперь не верю и не буду верить в безплатный сыр в любом его представлении, надеюсь и вы это поймете со временем > Уж что-что, а переобуваться в прыжке любой опеннетчик умеет на олимпийском уровне. Сорри, я глубины этой мысли - не понял
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 08-Ноя-23, 21:16
	Прям во время, специально для вас постарались: https://www.theregister.com/2023/11/08/europe_eidas_browser/
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору

8. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от OpenEcho (?), 22-Окт-23, 14:35
> и подключиться к сервисам мониторинга CT-логов (Certificate Transparency, отражают выданные удостоверяющими центрами сертификаты) Может кто-нибудь гарантировать, что то самый СТ, как бы случайно, (ну "ошибочки" они же у всех бывают, правда? Особенно преднамеренные) вдруг пропустит выданный "кому-то" серт (по большому блату/просьбе) ?
Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от Аноним (11), 24-Окт-23, 12:53
	> Может кто-нибудь гарантировать, что то самый СТ, как бы случайно, (ну "ошибочки" > они же у всех бывают, правда? Особенно преднамеренные) вдруг пропустит выданный > "кому-то" серт (по большому блату/просьбе) ? при выписке сертификата в нём должно появиться не менее 2-х записей из двух баз СТ. соотв. сначала серт регистрируется в СТ а потом подписывается (для этого там есть такая штука как пресертификат, который и регистрируется в СТ) и только потом отдаётся клиенту. Веб браузер сертификат без инфы от СТ должен отвергнуть. Кроме того многие регистраторы, включая ЛЕ, в СТ сливают и сам выписанный сертификат (а не только пресертификат) если же сам сертификат туда не попадает, его туда временами заливает ктото еще. В общем появление пресертификата достаточно, чтобы было понятно, что сертификат выписан.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 24-Окт-23, 13:20
	> при выписке сертификата в нём должно появиться не менее 2-х записей из > двух баз СТ. И оба, три СТ... находятся под чей юрисдикцией? Если вам ну очень убедительно скажут, - поставить фильтр отсекающий выдачу "нужным людям", вы ведь точно откажетесь, правда? > соотв. сначала серт регистрируется в СТ а потом > подписывается (для этого там есть такая штука как пресертификат, который и > регистрируется в СТ) и только потом отдаётся клиенту. Веб браузер сертификат > без инфы от СТ должен отвергнуть. > Кроме того многие регистраторы, включая ЛЕ, в СТ сливают и сам выписанный > сертификат (а не только пресертификат) если же сам сертификат туда не > попадает, его туда временами заливает ктото еще. В общем появление пресертификата > достаточно, чтобы было понятно, что сертификат выписан. С хэндшейком оно все технически понятно, но когда у кого-то есть права подкручивать, то... ну вы поняли...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от Аноним (11), 24-Окт-23, 16:58
	>> при выписке сертификата в нём должно появиться не менее 2-х записей из >> двух баз СТ. > И оба, три СТ... находятся под чей юрисдикцией? > Если вам ну очень убедительно скажут, - поставить фильтр отсекающий выдачу "нужным > людям", вы ведь точно откажетесь, правда? ну там, типа, блокчейн база.. есть некоторые сложности, математического порядка, убрать часть из середины списка... или потом объяснять откуда взялся сертификат с подписью этого ЦТ внутри, не существующий в самом СТ. И да, ЦТ это не та постгресовая базка, которую покажут по https://crt.sh/?Identity=%25.opennet.ru. Это агрегатор, по разным ЦТ для удобства.. Можно мониторить все СТ самостоятельно, список есть, он публичен. (оно немного не быстро, т.к. там реально надо перпелопатить все миллиарды записей) но если этим заниматься постоянно, то т.к. блокчейн, то не надо там каждый раз вычитывать с начала времён, а можно продолжать с ранее законченного места. В общем я это делаю для себя по своим доменам. и уж точно ни РФ ни ФРГ спецслужбы там не смогли бы ни на что повлиять... если там есть дыры в математике, или процедуре, то доступны они только одной стране. Ну и как бы не факт они там есть.. Скорее дыры есть в алгоритмах шифрования, которые позволяют им читать что им надо безо всей этой вот мишуры.. и ключ под сертификат им скорее всего не нужен, сам трафик, который представляет интерес шифруется же не им. Это всё для установления связи и проверки, что попали туда изначально.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от OpenEcho (?), 25-Окт-23, 00:02
	> ну там, типа, блокчейн база.. Тот самый блокчэин, который можно модефицировать имея более 50% котроля. А сами СТ: Apple, Google, Sectigo, Censys, Cloudflare, digicert, facebook... sorry, - но волки, заботящиеся о баранах Или там есть кто то из Индии, Китая, России, Казахстана с более чем 50% контроля над блок чэин?
	Ответить \| Правка \| Наверх \| Cообщить модератору

9. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+1 +/–
Сообщение от OpenEcho (?), 22-Окт-23, 15:08
Кстати, для копи-пастеров, бит 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/
Ответить \| Правка \| Наверх \| Cообщить модератору

20. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от VecH (ok), 25-Окт-23, 04:56
В каком формате данные вколачивать на dns.he.net ? Что не вставлял, пишет что invalid
Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
	Сообщение от ivan_erohin (?), 29-Окт-23, 08:32
	> В каком формате данные вколачивать на dns.he.net ? > Что не вставлял, пишет что invalid BIND 9.18.19-1 - все работает. обратитесь в техподдержку электро хурриканов.
	Ответить \| Правка \| Наверх \| Cообщить модератору

22. "Защита от подмены серверных TLS-сертификатов в результате MITM-атаки провайдером"	+/–
Сообщение от придурок (?), 25-Окт-23, 21:06
браузер заверещит же чё тут защищаться то
Ответить \| Правка \| Наверх \| Cообщить модератору