Шифрование данных при передаче в Windows, C ++ и Java - PullRequest
0 голосов
/ 06 февраля 2020

У меня есть требование для шифрования «данных в пути» для нашего клиент-серверного приложения. Наш сервер написан на C ++ и работает на Windows. Наши клиенты находятся на C ++ Windows, а также Java. Мы используем TCP / IP для нашего общения, делаем прямые вызовы с обычными API Winsock, такими как connect, send, bind и т. Д. c., И мы используем наши собственные номера портов (ни один из которых не равен 80 или 443). Конечно, клиентский код Java делает стандартные сетевые вызовы Java TCP / IP для связи с сервером Windows. Я все еще на начальном этапе расследования, и я пытаюсь понять всю смесь технологий, протоколов, шифров и т. Д. c. Я нашел эту статью, которая выглядит великолепно: [https://www.codeproject.com/Articles/1000189/A-Working-TCP-Client-and-Server-With-SSL] [1] Название этой статьи - SSL, но на самом деле он использует TLS 1.2. Похоже, что TLS 1.2 является для нас очень хорошим решением, и, похоже, добавить эти вызовы шифрования в наш код должно быть достаточно просто.

Итак, мои вопросы: является ли TLS способом go ? Или есть какая-то другая технология, которая будет лучше подходить? Я не хочу упускать из виду что-то более простое, например: «О, просто включите ЭТУ настройку, и все ваши сообщения будут зашифрованы». Значение: было бы хорошо, если бы Windows сделал всю работу за нас. Я не думаю, что сторонняя VPN подойдет для нас, потому что / 1021 * мы хотим получить полный контроль, и клиенты не захотят доверять сторонней организации свои конфиденциальные данные. Решение также должно работать с клиентом, написанным на Java. Выполните быстрый поиск в Google: Java поддерживает TLS, и он должен иметь возможность согласовывать связь с нашим сервером C ++ Windows, правильно? Я знаю, что есть HTTPS, но так как мы делаем прямые вызовы Winsock API, используя наши собственные номера портов, кажется, что HTTPS не подходит для нас, верно? Я также читал об OpenSSL, но поскольку это C -библиотека, она не подходит для Java, верно?

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

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

1 Ответ

2 голосов
/ 06 февраля 2020

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

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

Еще одна важная возможность, которую следует учитывать, - это VPN, в частности OpenVPN.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...