Насколько безопасно мое SSL-соединение даже с SSL-сертификатом?

Question

У меня есть клиентская программа, которая общается с веб-сервером через соединение SSL (https). Насколько безопасна эта связь? Я купил SSL-сертификат, установленный на моем веб-сервере, поэтому я понимаю, что даже если кто-то попытается провести атаку между моим клиентом и моим сервером, у него не будет сертификата? Это правда?

Так, например, если они попытались перенаправить имя хоста www.myserver.com на принадлежащий им ip, https все равно потерпит неудачу, поскольку соединение сообщит о ненадежном источнике без установленного сертификата?

---

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

Спасибо!

Answer 1

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

Answer 2

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

Answer 3

Да, как правило, вы защищены от атак MitM при использовании SSL, который был разработан (и пересмотрен) для его предотвращения.

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

Для максимальной безопасности соединения вы должны строго ограничить сертификаты, приемлемые для клиента - фактически вы можете даже ограничить его до точного соответствия, сохраняя сам сертификат (или хэш сертификата) на клиенте. В этом случае вы даже не заботитесь о сопоставлении имени хоста - и вы исключаете даже крошечный шанс, что враждебному посреднику удалось получить действительный сертификат от вашего ЦС с вашим именем хоста, а также подорванный DNS.

Answer 4

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

Если какой-либо из ЦС, которому доверяет ваше клиентское приложение, выдал сертификат с тем же именем хоста, этот сертификат можно использовать при атаке MITM. (И совсем не случайно, что сертификаты были выданы "неправильным" людям).

Какие ЦС используются в процессе для определения правильности подписи, зависит от вашей библиотеки SSL и от того, как вы ее использовали.

т.е. в случае браузеров Firefox поставляется с набором сертификатов CA от более или менее авторитетных поставщиков SSL, которым ваш браузер доверяет по умолчанию.

Windows также имеет хранилище сертификатов, которому IE доверяет по умолчанию, и я предполагаю, что другие приложения, использующие библиотеки SSL Microsoft, могут либо использовать это хранилище сертификатов, либо использовать его по умолчанию.

Answer 5

Tls обеспечивает аутентификацию клиента при рукопожатии

Answer 6

Вы путаете вопросы:

1. безопасность транспортного уровня, которую обеспечивает SSL; и
2. аутентификация клиента, которая не поддерживается SSL.

В зависимости от вашего приложения вы можете рассмотреть возможность использования чего-то вроде туннеля SSH. Это обеспечивает как надежную криптографию для защиты транспорта, так и учетные данные для входа в систему с использованием криптографии с открытым ключом.

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

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

Answer 7

Данные, передаваемые между сервером и клиентом, шифруются.

Так, например, если они пытались перенаправить имя хоста www.myserver.com на IP, которым они владеют, https будет по-прежнему не удается, потому что соединение будет сообщить о ненадежном источнике без сертификат установлен?

Да. Но все же предупреждающее сообщение может быть проигнорировано пользователем, если он не беспокоится о безопасности. Только общение безопасно и безопасно. Если есть клиентская программа (вирус), которая может интерпретировать полученные данные и делать все, что захочет. Поэтому лучше информировать клиента (пользователя) о проблемах безопасности и важности наличия «безопасного» ПК.

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

В случае несоответствия данные были изменены во время их передачи.