PHP Socket Server (для push-уведомлений Android) - проблема безопасности / аутентификации

Question

Я недавно написал сервер сокетов на PHP, который будет обрабатывать связь между приложением для телефона Android и моим веб-сервером PHP. Из-за того, что Android изначально не поддерживает push-уведомления, мы будем использовать наш веб-сервер в качестве промежуточного слоя для обработки наших «толчков».

Сервер сокетов стабилен, хорошо работает и, кажется, хорошо масштабируется. Хотя в конечном итоге я хотел бы переписать это на C, у меня нет навыков, необходимых для того, чтобы сделать это прямо сейчас, поэтому я собираюсь остаться в PHP на некоторое время. На данный момент наш эмулятор Android может обмениваться данными через сервер, получать сообщения и т. Д., Так что вся эта часть покрыта.

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

Вопрос в том, как мне защитить такой сервер? Давайте предположим, что я работаю на порту 25000 - могу ли я установить какой-то уровень SSL на этом порту и ожидать, что устройства, такие как Android, смогут обмениваться данными через этот порт без каких-либо специальных протоколов или переходов через скачки?

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

Любые предложения по этому вопросу были бы очень полезны - я довольно новичок в прямой связи TCP из PHP и чувствую, что мне, возможно, просто не хватает чего-то простого, что позволяет проводить аутентификацию на этом уровне.

Дополнительная информация: Если мне удастся надежно получить действительное имя пользователя и пароль, я буду использовать MySQL для проверки пользователя, а затем принять / отклонить его соединение на основе результатов запроса.

Заранее спасибо ..

Answer 1

Я не думаю, что SSL действительно решит вашу проблему. В лучшем случае с SSL вы можете предоставить каждому клиенту клиентский сертификат и выполнить проверку сертификата клиента на сервере. Но вам нужно будет управлять тоннами сертификатов. Или дать всем один и тот же клиентский сертификат (не очень хорошая идея).

Вы должны будете аутентифицировать клиента, используя его учетные данные. Вы правы в том, что не хотите отправлять учетные данные в виде простого текста по сети, но есть простые альтернативы. Взгляните, например, на Дайджест-аутентификация HTTP (http://en.wikipedia.org/wiki/Digest_access_authentication) или xAuth (http://dev.twitter.com/pages/xauth).) Вам не нужно реализовывать эти методы через HTTP; вы также можете отправить запрос (область) через простой сокет tcp после того, как вы принял соединение. Клиент должен отправить действительный ответ в течение короткого периода времени, или сервер прерывает соединение.

Кстати, вы рассматривали потоковую передачу HTTP? Смотри http://ajaxpatterns.org/HTTP_Streaming Это, вероятно, сделает вашу жизнь намного проще, поскольку вы можете рассчитывать на то, что какой-то другой сервис (например, Apache) сделает за вас тяжелую работу, и вы сможете сосредоточиться на коммерческой ценности вашего приложения.

Answer 2

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

Теперь, если вы уже внедрили сокет-сервер, добавить поддержку TLS легко. Просто запустите stunnel и ваш сокет-сервер PHP будет принимать запросы только на локальном интерфейсе.

Answer 3

Не уверен, почему вы, ребята, не использовали некоторые готовые библиотеки / сервер сообщений для java, а затем создайте службу Android, которая подключается к брокеру сообщений и обрабатывает всю первоначальную аутентификацию. Сервис просто будет сидеть и ждать любых входящих сообщений.

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

Я сделал это (я использовал библиотеку rabbitmq-java и сервер очереди сообщений rabbitmq) и в мгновение ока получил уведомление в стиле push для своего приложения. Даже с устройствами Android 1.5.

О безопасности:

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

Answer 4

вы можете рассмотреть: Обмен сообщениями между облаками и устройствами: http://code.google.com/android/c2dm/index.html

Единственным недостатком является то, что он поддерживается только Android> = 2,2