LINUX.ORG.RU

Хочу только напомнить, что владелец приватного ключа от любого из ваших корневых сертификатов технически может в любой момент наклепать сертификатов под (почти) все сайты в интернете (кроме тех, где используется certificate pinning) и начать расшифровывать весь ваш HTTPS-траффик.

balsoft ★★
()
Ответ на: комментарий от DrBrown

Потому что валидный сертификат Amazon содержит публичный ключ Амазона и подпись американского удостоверяющего центра, а не удостоверяющего центра Минцифры РФ.

Пользователь или кто-то другой с поддельным сертификатом Амазона не смогут получить доступ к американскому магазину, так как клиент не сможет: 1) подтвердить подлинность поддельного сертификата Амазона; 2) не сможет сформировать валидный сеансовый ключ (ага - из-за поддельного публичного ключа Амазона) и открыть защищённый канал передачи данных с сайтом Amazon.

iZEN ★★★★★
()
Ответ на: комментарий от DrBrown

А, то есть MITM в принципе невозможен.

Не стоит успокаиваться, iZEN ответил не на ваш вопрос, а про подделку сертификата Amazon.

При атаке типа MITM ваш трафик будет перешифровываться на лету, от вас до перехватчика будет действовать поддельный сертификат Amazon, но из-за доверия к корневому сертификату он будет у вас в браузере выглядеть валидным (хотя в свойствах и будет видно, что выдали его в РФ). А от перехватчика до Amazon будет использоваться нормальный сертификат, и Amazon примет перехватчика за вас. Браузеры конечно имеют какую-то защиту от подделки доменов, типа HSTS, но уповать на неё не стоит.

Корневые сертификаты имеют слишком много власти…

raspopov
()
Ответ на: комментарий от DrBrown

А, то есть MITM в принципе невозможен.

При условии, что пользователь не пользуется левым браузером и каждый раз проверяет сертификат критически важного сайта, с которым он работает.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Потому что валидный сертификат Amazon содержит публичный ключ Амазона и подпись американского удостоверяющего центра, а не удостоверяющего центра Минцифры РФ.

Сертификат на *.amazon.com, подписанный CA Минцифры РФ, будет технически валидным.

подтвердить подлинность поддельного сертификата Амазона;

Добавляя сертификат какого угодно CA в качестве корневого себе в систему или браузер, вы говорите браузеру считать сертификаты, подписанные этим корневым сертификатом, за подлинные, так что подлинность проверить получится.

не сможет сформировать валидный сеансовый ключ (ага - из-за поддельного публичного ключа Амазона) и открыть защищённый канал передачи данных с сайтом Amazon.

Зато клиент отлично сможет открыть защищенный канал до сервера злоумышленника, прикидывающегося amazon.com (например, с помощью отравления DNS-кэша, или просто подконтрольных злоумышленнику DNS-серверов), а сервер злоумышленника уже установит защищенное соединение до amazon.com, заодно читая (или даже изменяя) весь траффик. И с точки зрения амазона, и с точки зрения клиента это соединение будет защищенным, и пользователь увидит зеленый замочек перед amazon.com. Если он не проверит, кто же выпустил этот сертификат, то поводов для подозрений не будет.

balsoft ★★
()
Ответ на: комментарий от balsoft

А чего тут доказывать? Для mitm надо для начала трафик хотя бы перехватывать. И все сайты, где хоть что то ценное, могут прописать проверку сертификата. Дня не пройдет, как все узнают, что в природе появились левые сертификаты.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

все сайты, где хоть что то ценное, могут прописать проверку сертификата

Переданную на клиент по стороннему, заведомо защищённом каналу? Ты серьёзно не видишь, какой бред несёшь? Да ещё и опасный. Вступай в клуб непонимающих PKI и MITM, и сиди там молча, чтобы не подставлять других.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от AVL2

проверку сетрификата ?? это как ?? чет я не слышал чтоб джавскрипт имел доступ к параметрам сертификата канала связи.

кстати весьма удобный метод проверки. кто умный в джаваскриптах чё скажет ??

хотя да. митм с большой вероятностью модифицирует/вырежет этот кусок кода…

pfg ★★★★★
()
Ответ на: комментарий от balsoft

Добавляя сертификат какого угодно CA в качестве корневого себе в систему или браузер, вы говорите браузеру считать сертификаты, подписанные этим корневым сертификатом, за подлинные, так что подлинность проверить получится.

…при условии, что сайт проведёт проверку у себя полученного от клиента хэша сертификата CA (или его доверенного «промежуточного» сертификата) на предмет того, подписывал ли этот уважаемый CA (или его миньон) его сертификат или нет, и выдаст заключение о продолжении сеанса связи (а может и не выдать такого заключения — отобьёт попытку защищённого соединения из-за подсунутой чуши).

iZEN ★★★★★
()
Ответ на: комментарий от DrBrown

Я немного ошибся — проверки цепочек доверия, в том числе загруженного с сайта сертификата в процессе обращения клиента, осуществляются браузером клиента.

Сертификат открытого ключа сайта выдаётся центром сертификации (промежуточным центром сертификации, сертификат которого, в свою очередь, заверен корневым центром сертификации). Сертификат открытого ключа загружается браузером клиента из ответа сайта и, проходя проверку в браузере, таким образом, достраивает цепочку доверия от клиента к сайту.

Если данные сертификата(ов) не будут в каком-то месте совпадать с данными из адресной строки и ответа сайта, установление защищённого соединения с сайтом будет невозможно — сайт не пройдёт проверку.

Чтобы предотвратить атаку «человек-по-середине», клиенту достаточно видеть/осознавать данные адресной строки и сертификат сайта, с которым он имеет дело. Левые сборки браузеров могут помешать этому. Поэтому клиенту нужно пользоваться только теми браузерами, которым он доверяет, а не поддельными репликами.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от DrBrown

Сбером https://sber.ru/ в настоящее время используется сертификат:

Кому выдан: Sberbank of Russia PJSC
Идентификатор ключа субъекта: 2B:5E:D2:D7:B4:59:71:78:68:50:B2:D1:E6:81:CB:27:16:D7:8A:F4
Кем выдан: GlobalSign RSA OV SSL CA 2018
Идентификатор ключа центра сертификатов: F8:EF:7F:F2:CD:78:67:A8:DE:6F:8F:24:8D:88:F1:87:03:02:B3:EB
Дата выдачи: воскресенье, 27 февраля 2022 г., 15:51:11 GMT
Срок действия: пятница, 31 марта 2023 г., 15:51:11 GMT
Отпечаток SHA-256: FE 74 82 CE 01 1D A4 22 F0 DC 4D F7 B8 51 A7 7E
81 D9 E8 83 4B 2D 22 07 AC BC 4A A7 22 E1 C0 2D
Отпечаток SHA-1: 0C 89 EA 98 6C 5B 65 62 8F 26 9F 06 E0 FF 37 71
6C 14 D9 51
iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 3)
Ответ на: комментарий от iZEN

Если данные сертификата(ов) не будут в каком-то месте совпадать с данными из адресной строки и ответа сайта, установление защищённого соединения с сайтом будет невозможно — сайт не пройдёт проверку.

MITM позволяет элементарно подсунуть всю цепочку сертификатов от корневого до сертификата сайта. На практике это используется в некоторых корпоративных сетях, где весь доступ в «большой» интернет идет через перехватывающий HTTPS-proxy, который расшифровывает, анализирует и возможно блокирует весь траффик. Для подключения через подобный прокси как раз нужно добавить в браузер корневой сертификат.

balsoft ★★
()
Ответ на: комментарий от balsoft

MITM делает связь неустойчивой и замедленной. Это видно невооружённым глазом. Чем больше людей владеют корневыми сертификами и имеют способ обмениваться информацией о них (даже через нетрадиционные каналы передачи), тем надёжнее защищённые интернет-соединения.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

MITM делает связь неустойчивой и замедленной. Это видно невооружённым глазом.

Это просто неверно.

Чем больше людей владеют корневыми сертификами и имеют способ обмениваться информацией о них (даже через нетрадиционные каналы передачи), тем надёжнее защищённые интернет-соединения.

А это неверно семантически. Похоже вы путаете сертификаты вообще с чем-то другим, но невозможно предположить с чем конкретно.

raspopov
()
Ответ на: комментарий от DrBrown

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

Что ты будешь делать, если эти центры отзовут сертификаты для всех сайтов доменной зоны .ru?

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от pfg

Через аддоны можно сделать, через штатный жаваскрипт нельзя.
Так-то можно и через жаваскрипт данные шифровать.
И, ЧСХ, очень много говносайтов так и делает.
Работает ровно до тех пор пока кто-нибудь не решит туда влезть.

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от Goury

Для зоны .ru? Сомневаюсь. Захотели выдали, захотели отозвали.

Отказ продления сертификата ничем не обернулся для центра. Почему отзыв сертификатов в произвольном или массовом порядке должен им как-то навредить?

grem ★★★★★
()
Ответ на: комментарий от Goury

Потому что в тот момент как они это сделают к ним будет утрачено доверие и их удалят из всех браузеров.

digicert и thawte именно это недавно и сделали. Revoke ещё не истёкших и оплаченных сертификатов ВТБ, ЦентроБанка и т.д. И чё? Их отовсюду убрали?

SkyMaverick ★★★★★
()
Ответ на: комментарий от pfg

Ну так я и не удивляюсь, почему jetbrains, например, закрыли бизнес в РФ. Его владельцы входят во всякие списки имеющих российское гражданство миллиардеров и сохранение «нейтралитета» было очень чревато на фоне шмонания остальных. Иначе бы их бизнес очень быстро отжали бы.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)