Я разрабатываю веб-приложение, которое работает на сервере, локальном в той же сети, что и клиент. По сути, вместо центрального веб-сервера каждый сайт клиента будет иметь свой собственный сервер, размещенный в сети. Сервер - CentOS, а клиентами - любой веб-браузер.
Я хотел бы зашифровать обмен данными между веб-браузером и сервером в сети, чтобы другим пользователям в сети было сложно видеть обмен данными между клиентом и сервером. Однако, поскольку клиент не будет получать доступ к серверу через общедоступный URL-адрес, я понимаю, что я не могу использовать подписанный сертификат SSL, что оставляет меня уязвимым для атак путем внедрения сертификата SSL.
У меня также нет контроля над сетью, в которой устанавливаются эти системы, поэтому я не могу надежно выполнять фильтрацию MAC-адресов или фильтрацию диапазона IP-адресов (хотя они в любом случае в значительной степени неэффективны, так что это не большая потеря).
Мои вопросы: 1. Правильно ли я понимаю это, или я все же могу использовать SSL? Если да, то как? 2. Какие у меня есть варианты, кроме сертификата SSL? Я бы предпочел не прибегать к развертыванию собственного шифрования, поскольку это должно было быть реализовано на JavaScript, что оставило бы меня открытым для злоумышленников, просто переписывающих код шифрования по мере его доставки в браузер.
Спасибо за вашу помощь / комментарии!
Однако, поскольку клиент не будет получать доступ к серверу через общедоступный URL-адрес, я понимаю, что я не могу использовать подписанный сертификат SSL, что оставляет меня уязвимым для атак путем внедрения сертификата SSL.
Это чепуха. Не требуется, чтобы сертификаты, подписанные доверенными центрами сертификации, использовались только на общедоступных URL-адресах.
Другие варианты? IPSec, OpenVPN и т. Д. Но, честно говоря, настройка SSL с помощью доверенного сертификата, вероятно, является самым быстрым и простым вариантом. Дайте вашим клиентам возможность загружать свой собственный ключ / сертификат на сервер, и тогда они смогут решить, хотят ли они использовать частный центр сертификации или публичный.
Помимо использования SSL для доступа к веб-сайтам, вы можете использовать 802.1x для обеспечения зашифрованной связи в вашей локальной сети в целом. Это немного сложнее, чем можно объяснить в одном посте, но обычно это включает в себя настройку метода аутентификации хоста в локальной сети.
Типичным вариантом использования этой конкретной технологии является обеспечение того, чтобы к сети могли подключаться только узлы, санкционированные ИТ-отделом, но она имеет дополнительное (сильное) преимущество, заключающееся в том, что все в сети зашифровано.
Вот ресурс, который дает полезное объяснение: http://services.geant.net/cbp/Knowledge_Base/Security/Documents/gn3-na3-ufs_133.pdf
Имейте в виду, что это обычно крупный проект. Если все, что вы хотите сделать, это зашифровать связь и обеспечить аутентификацию вашего конкретного внутреннего веб-приложения, просто используйте TLS (с сертификатом, подписанным из общедоступного корня, если хотите, и вы используете публично делегированный домен, который вы контролируете изнутри, или с вашим собственным локальным PKI, если нет).
Если у вас есть некоторый контроль над конфигурацией клиентских устройств, вы можете выступать в качестве удостоверяющего центра, используя команду OpenSSL, Red Hat / Fedora Dogtag PKI или роль CA для сервера домена Active Directory.
Создайте ЦС под вашим контролем, попросите клиентов установить сертификат из вашего ЦС в хранилище доверенных ЦС своих клиентов (http://technet.microsoft.com/en-us/library/cc772491.aspx для клиентов Windows или используйте что-то вроде Puppet или CFEngine для установки корневого сертификата в /etc/ssl/certs/ca-certificates.crt и базу данных NSS для Linux).
Когда вы отправляете решение своим клиентам, предоставьте им сертификат для установки на веб-сервере внутри вашего решения (предоставьте им инструкции, обычно несложные), с полным именем хоста сервера в SubjectAlternateName в сертификате.
Если вам нужны подробности, дайте мне знать.