Использование и декодирование необработанных данных SSL в качестве доказательства

#ssl #ssl-certificate #tls1.2 #tls1.3

#ssl #шифрование #https #декодирование

Вопрос:

Я хотел бы декодировать и хранить необработанные данные SSL/TLS, чтобы что-то доказать в будущем, я думаю, будет лучше, если я опишу это на примере:

1) Существует удаленная конечная точка REST, доступная через SSL и предоставляющая некоторые полезные данные. Эта конечная точка контролируется какой-то третьей стороной, и я не могу ее контролировать.

2) Я отправляю запрос GET на эту конечную точку и сохраняю необработанный SSL-трафик ответа в одном файле, а затем декодированный ssl-трафик в другом файле

3) Кроме того, я сохраняю SSL-сертификат этой конечной точки в отдельном файле (я предполагаю, что эту операцию нужно будет выполнить только один раз)

Если я правильно понимаю, когда у меня будут все данные из описанных выше шагов и в будущем, когда другая третья сторона попросит меня подтвердить, что в какой-то момент в прошлом на удаленном сервере были определенные данные, я мог бы:

1) Предъявите им сертификат, который я сохранил (шаг 3). Поскольку этот сертификат подписан известным авторитетом, вероятность того, что я смогу его подделать, практически равна нулю

2) Предоставьте им НЕОБРАБОТАННЫЕ данные SSL вместе с способом их декодирования с использованием указанного выше сертификата

3) В декодированных заголовках ответов REST также должно присутствовать время удаленного сервера.

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

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

Есть ли способ автоматизировать такие сценарии? Я имею в виду, есть ли способ записать необработанные данные SSL в форме, которая позволила бы легко декодировать их позже?

Я пробовал использовать браузер firefox/chrome вместе с файлами sslkeylog и отслеживать трафик с помощью wireshark — это действительно работает, но есть ли способ автоматизировать его с помощью какой — либо библиотеки REST, так как использование firefox и запись SSL-ключей каждый раз может быть проблематичным-может потребоваться хранить тысячи этих запросов в час, и выполнение этого вручную будет полной занятостью, кроме того, я не уверен, есть ли способ доказать, что эти ключи, хранящиеся в файлах ssskeylog, на самом деле соответствуют сертификату удаленного сервера…

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

1. Технология, которую вы ищете, называется цифровой подписью. Ваш нынешний подход не подходит и неосуществим.

Ответ №1:

Нет, вы не можете доказать, что сервер отправил данные. Например, с помощью TLS_RSA_WITH_AES_256_CBC_SHA256 в качестве набора шифров вы можете подделать все данные с обеих сторон за весь сеанс TLS, даже не связываясь с сервером. И серверная сторона также может произвести такую подделку. Как отмечает EJP, единственное, что вы не можете подделать, — это подписанные данные. С шифрами RSA единственное, что подписано, — это сертификаты, но они не меняются и криптографически не привязаны к сеансу TLS.

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

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

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

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

3. Спасибо вам за ответ. Поэтому я предполагаю, что нет никакого способа доказать, что данные поступили с определенного сервера, если он не подписывает данные и использует только TLS?

4. @Pma: Вы можете доказать, что данные поступили либо от клиента, либо от сервера, но вы не можете доказать ничего более конкретного.

5. @Pma: tlsnotary действительно звучит многообещающе. Он выглядит ориентированным на то, чтобы позволить клиенту доказать, что он генерировал указанный HTTPs-веб-трафик, а не позволять серверу что-то доказывать. И, конечно, я не знаю ни о каком анализе безопасности протокола tlsnotary.