Защищенная HTTP-связь для компонентов коммерческого продукта

Скажем, я хочу отправить коммерческий продукт с двумя компонентами, написанными на Java, которые взаимодействуют друг с другом в локальной сети с использованием API RESTful. Это может быть музыкальный менеджер, база данных контактов, кулинарная книга --- что важно, что это разумный и крайне вероятный сценарий.

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

Итак, как я могу сделать сообщение безопасным?

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

Так что мне делать? Отправляйте всем свой собственный самозаверяющий сертификат и делайте очень плохое впечатление, например отключите проверку сертификата в Java? Ужасно, я знаю. Но по крайней мере информация не будет проходить по строке в виде обычного текста.

У кого-нибудь есть лучшие решения?

Ответы

Ответ 1

Обновлено 20 сентября '15, чтобы уточнить моменты, поднятые в комментариях

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

  • Установите серверную часть. Во время установки программно создайте самозаверяющий сертификат с использованием имени хоста целевого компьютера. Если для компьютера нет записи DNS (например, myserver.mycorp.com), используйте его IP-адрес - он должен быть статичным, поскольку нам нужно указать на него часть клиента. Вы можете использовать Bouncy Castle API для создания сертификата в коде.

  • Установите клиентскую часть на другой компьютер и скопируйте сгенерированный сертификат в папку установки. Выполнение этого вручную эффективно устанавливает доверие между сервером и клиентом. Попытка сделать это автоматически через незашифрованное соединение по враждебной сети будет победить цель.

  • Поскольку вы обеспечиваете связь строго между вашими собственными частями приложения, вы полностью контролируете, какие сертификаты доверяют приложению. На клиенте создайте хранилище ключей и добавьте к нему сгенерированный сертификат:

    FileInputStream fis = new FileInputStream(yourCertificateFile);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate c = (X509Certificate)cf.generateCertificate(fis);

KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType());
ks.load(null, aRandomKeystorePasswordCharArray);
ks.setCertificateEntry(aUniqueNameForYourCertificate, c);

FileOutputStream fos = new FileOutputStream(aRandomKeystoreFileName);
ks.store(fos, aRandomKeystorePasswordCharArray);
fos.close();

    Сообщите JVM, что ваше приложение будет доверять сертификатам только из собственного хранилища ключей.

    // replace backslashes '\' with slashes '/' in aRandomKeystoreFileName on Windows
System.setProperty("javax.net.ssl.trustStore", aRandomKeystoreFileName);
System.setProperty("javax.net.ssl.trustStorePassword", aRandomKeystorePassword);

Ответ 2

Посмотрите на OAuth 2.0 для обеспечения ваших услуг, и вы должны предоставлять токены только своим клиентам вместо двухстороннего SSL. Facebook, Google и т.д. Использует его.

https://en.wikipedia.org/wiki/OAuth

Ответ 3

В вашем связанном ответе представлено другое решение: вместо отключения проверки сертификата для самозаверяющих сертификатов" Экспорт сертификата (...) и импорт его в вашу JVM доверенное хранилище.

Итак, только когда первый неизвестный сертификат найден, попросите подтверждение пользователя.

Ответ 4

Посмотрите на сравнение между Facebook Connect, OAuth и OpenID по адресу TheNextWeb

OpenID: OpenID служит третьей стороной, которая может проверить, кто вы

OAuth: более безопасный и безопасный способ доступа людей к доступу

Facebook Connect. С помощью Facebook Connect мы видим элементы OpenID и OAuth. Facebook Connect может подтвердить, что вы являетесь тем, кем вы говорите, и затем может предоставить доступ к вашим данным, как только вы дадите ему разрешение на это.

Сводка:

OpenID и OAuth считают, что у них есть коллективный правильный ответ, но Facebook явно думает, что он имеет свои собственные. Мы должны видеть, как он формируется в будущем.