Обеспечивает ли SSL-соединение целостность?

Я новичок в криптографии и пытаюсь реализовать безопасное приложение для чата с использованием OpenSSL.

Я хочу гарантировать, что общедоступные сообщения (которые будут показаны всем пользователям) не могут быть изменены во время передачи.

Гарантирует ли это использование SSL-соединения?

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

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

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

Что касается целостности, обратите внимание, что она зависит от подлинности. Целостность гарантирует, что, когда Алиса с кем-то разговаривает, никто, кроме Алисы, не может изменить данные, которыми они обмениваются. Но если Алиса хочет поговорить с Бобом, ей не поможет то, что она может иметь немодифицированное общение с неопознанной стороной: ей нужно знать, что у нее немодифицированное общение с Бобом. TLS — это клиент-серверный протокол, который всегда гарантирует подлинность сервера. Опционально может гарантировать подлинность клиента.

Имейте в виду, что в версиях TLS до 1.2 есть несколько необычных наборов шифров с пониженными гарантиями безопасности.Хотя конфигурация по умолчанию всех основных библиотек TLS отключает эти наборы шифров по умолчанию, вам нужно быть осторожным, чтобы случайно не включить их. TLS 1.3 имеет только наборы шифров с полной безопасностью (отметим, что проверка подлинности клиента по-прежнему необязательна, поскольку TLS предназначен для поддержки неизвестных клиентов, подключающихся к известным серверам).

Наконец, имейте в виду, что TLS может предоставить только гарантии безопасности при передаче. Двум случайным машинам в Интернете трудно общаться напрямую, поэтому чат обычно проходит через центральный сервер. Если вы полагаетесь только на TLS между каждым клиентом и сервером, TLS защищает сообщение, когда оно передается между клиентом 1 и сервером, а также когда оно передается между сервером и клиентом 2. Но программное обеспечение сервера должно гарантировать безопасность. безопасность сообщения между ними — например, что сообщение направляется правильному получателю. Существуют более сложные протоколы, которые могут гарантировать сквозную безопасность сообщений. Сигнал. Приложения, использующие такие протоколы, могут по-прежнему использовать TLS между переходами. Это может, например, помочь конфиденциальности, скрыв от перехватчика информацию о том, кто с кем разговаривает, или помочь избежать расходования ресурсов на маршрутизацию поддельных сообщений, которые в противном случае были бы удалены только после того, как они достигнут предполагаемого получателя).

TLS (правильное название того, что вы называете SSL) действительно обеспечивает сквозные гарантии целостности; то есть получатель может знать, что он получил именно то, что отправил отправитель.

Однако это двухточечный протокол; любое сообщение (рекордер) идет от определенного отправителя и к определенному получателю.

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

Вы заявляете, что у вас есть публичные сообщения; как сообщение попадает к нескольким получателям? TLS просто дает вам соединения точка-точка (каналы); как вы превращаете это в систему вещания? Отправляет ли отправитель сообщение каждому получателю, используя независимые соединения TLS? Пересылает ли первоначальный получатель сообщение другим получателям? Помещает ли отправитель сообщение в общую область, которую могут прочитать различные получатели?

В первом случае TLS обеспечит сквозную целостность (при условии, что отправителю можно доверять, чтобы отправить одно и то же сообщение — TLS ничего не делает для проверки этого).

Во втором случае (сообщение пересылается) ничто не мешает первоначальному получателю модифицировать пересылаемое им сообщение — если ему можно доверять, что он этого не сделает, это безопасно. Если ему нельзя доверять, потребуется некоторая защита за пределами TLS (например, подпись с открытым ключом отправителя).

В третьем случае (сообщение, помещенное в общую область) TLS не обеспечивает никакой защиты — потребуется что-то вроде подписи.

Да, TLS может обеспечить сквозное шифрование, целостность и подлинность сообщений для транспорта — это не просто так называется Transport Layer Security.

Однако вам необходимо установить доверительные отношения с обеими сторонами: если вы не можете идентифицировать клиентов, противник может замаскироваться под одного из них и, вероятно, также получит сообщение. Как правило, с PKIX вам все равно нужно доверять серверу (точно так же, как это делают браузеры), но если вы этого не сделаете, злоумышленник может выдать себя за сервер и отправлять сообщения клиентам; это не повредит конфиденциальности или целостности самих сообщений после настройки сеанса, но это не то, что вы хотите.

Аутентификация клиента является необязательной для TLS, что обычно пропускается для соединений браузер-сервер. Например, В интернет-магазинах это не проблема: вы входите в систему, используя пароль (который может быть не очень безопасным), но если вы платите, вы проходите аутентификацию в своем банке. Однако для приложения чата вы можете захотеть также аутентифицировать клиента с помощью клиентского сертификата. Если такая PKI невозможна, вы можете сделать это так же, как и в браузере: сначала подключиться к серверу, а затем аутентифицировать клиента, используя соединение, для которого сервер уже аутентифицирован.

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

Примечания:

• Это может быть хорошей идеей, чтобы посмотреть, например. протокол Signal, который больше ориентирован на приложения для чата;
• Я настоятельно рекомендую TLS 1.3, если вы выбираете TLS;
• Имейте в виду, что лишь немногие криптографические протоколы защищены от квантовых компьютеров, поэтому, если вы хотите хранить секреты дольше 10 лет, вам нужно искать глубже.

Я тоже новичок в криптографии, но недавно я работал над проектом SSL. Вот подробнее в инструкция о процессе рукопожатия SSL (TLS 1.2 и TLS 1.3)

Что делает процесс рукопожатия SSL, так это генерирует ключ симметрии с использованием асимметричного шифрования.

Перед этапом обмена ключами клиент или сервер (или оба) проверят личность другого, которая определена в tls_process_cert_verify(). И сервер отправит клиенту подпись буфера рукопожатия.

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

Итак, вот собственность ЦРУ:
конфиденциальность: мастер-ключ шифрует данные приложения.
Integrityï¼ Хэш буфера рукопожатия
Подлинность: проверка сертификации и подпись буфера рукопожатия.

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

Когда рукопожатие завершено. Уровень записи TLS использует hmac для защиты целостности сеанса.