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

Question

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

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

---

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

Спасибо!

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Если есть несоответствие, данные были изменены во время его передачи.

Answer 4

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

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

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

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

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

Answer 5

Вы путаете вопросы: уровень безопасности

1. транспорт, который обеспечивает SSL; и
2. аутентификация клиента, которой нет SSL.

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

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

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

Answer 6

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

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

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

Answer 7

TLS действительно обеспечивают аутентификацию клиента в рукопожатии