WedX - журнал о программировании и компьютерных науках

Актуален ли протокол HTTPS для веб-сервисов REST API?

У меня есть HTTP REST API в PHP, используемый приложением для iPhone.

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

Я не очень разбираюсь в вопросах безопасности и нигде не нашел четкого ответа на свой вопрос:

Актуален ли HTTPS для БЕЗГРАНИЧНОГО REST API?

Насколько я понял, HTTPS делает 2 вещи:

  • зашифровать вашу сессию
  • доказать клиенту, что сервер, с которым он разговаривает, защищен

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

Кто-нибудь может мне прояснить?

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

Спасибо !

php api rest https
24.04.2012

  • HTTPS выполняет две функции: - шифрование соединения - доказывает клиенту, что сервер, с которым он разговаривает, является тем, кем он себя называет ‹- исправлено для вас 24.04.2012
  • Мое другое решение - зашифровать данные запросов с помощью системы открытых / закрытых ключей. Звучит как хороший план. Почему бы не реализовать SSL (HTTPS) ;-) 24.04.2012

Ответы:


1

Да, это. HTTPS не имеет ничего общего с приложением, это протокол туннелирования. Несмотря на то, что TLS сам по себе является протоколом с отслеживанием состояния, его HTTP-часть - нет.

Так же, как если бы вы использовали VPN, у вас все еще может быть приложение на основе REST. TLS просто устанавливает и автоматически разрывает туннель для каждого соединения.

Тем не менее, есть смысл в использовании аспектов конвейерной обработки HTTP и HTTPS для повышения пропускной способности по TLS-соединениям, но это аспект настройки производительности, не связанный с самим приложением.

24.04.2012
  • Спасибо Уиллу Хартунгу, вы объяснили именно то, что мне было непонятно. У меня было ощущение, что часть HTTPS с отслеживанием состояния может быть сброшена при каждом запросе, но я совсем не был уверен. 25.04.2012
  • REST не имеет состояния, и запросы обрабатываются индивидуально. Таким образом, добавление накладных расходов на ssl-рукопожатие является проблемой. Есть ли обходной путь? 21.09.2020
  • @ S.M.Mousavi, как уже упоминалось, использует аспект туннелирования HTTP (S). Вы можете использовать пулы соединений для поддержания открытых соединений с вашими серверами в подобных ситуациях. Только не забывайте регулярно обновлять их. 21.09.2020
  • @WillHartung REST не имеет состояния, чтобы иметь возможность обрабатывать большие запросы. Но очень скоро ресурсы сервера будут использованы, если ему придется обрабатывать открытые соединения. Вместо этого в качестве основной идеи мы можем использовать начальное согласование для обмена симметричным ключом, если нет официального стандарта. 22.09.2020
  • @ S.M.Mousavi, как говорится в сообщении, TLS не имеет ничего общего с природой REST без сохранения состояния, точно так же, как VPN не влияет на REST. Открытые соединения дешевы. Вы можете привязать свой TLS к переднему прокси-серверу или балансировщику нагрузки и держать его открытым (тысячи и тысячи), чтобы не повлиять на ваши внутренние серверы. Я бы определенно не рекомендовал внедрять ваш собственный криптопротокол, как вы предлагаете. Вся суть TLS состоит в том, чтобы обменяться симметричным ключом и посмотреть на трудности, с которыми они столкнулись. 22.09.2020
  • Спасибо @WillHartung. Как мы знаем, REST не имеет гражданства. Таким образом, используемые базовые технологии должны быть максимально подходящими (по крайней мере, не нарушая природу REST без сохранения состояния). Таким образом, открытые соединения с сохранением состояния кажутся плохой идеей. На самом деле использование чистого HTTP или HTTPS кажется более точным. Проблема заключается в накладных расходах на установление связи SSL (затраты на безопасность). Ищу любую опытную идею. 30.09.2020

    • 2

    HTTPS очень актуален, и да, это из-за двух упомянутых вами моментов. Знаете ли вы, что OAuth 2 фактически применяет HTTPS?

    Самостоятельное шифрование также может быть вариантом, но вы теряете ту часть, в которой API прост в использовании.

    Большинство атак типа «злоумышленник посередине» на «простые» HTTP-запросы включают в себя кражу учетных данных и подделку запросов, но они также могут читать отправленные и полученные данные. Если ваша проблема связана с нечитаемостью данных, используйте HTTPS. Если поддельные запросы - единственная проблема, будет достаточно протокола аутентификации, такого как OAuth 1 (а не 2). .

    24.04.2012
  • Не уверен, что вы подразумеваете, выполняя все шифрование самостоятельно, но это звучит как плохая идея. 24.04.2012
  • @RepWhoringPeeHaa Я имел в виду ручное шифрование данных с помощью системы открытого / закрытого ключа, как упоминается в вопросе. 24.04.2012
  • Ага. Каждый раз, когда я слышу, как кто-то предлагает попробовать выполнить шифрование самостоятельно, я обычно радуюсь триггеру. И я не говорю о довольном голосовании :) 24.04.2012
  • @RepWhoringPeeHaa Я большой поклонник SSL, но никогда не сказал бы никому реализовать свой собственный уровень криптографии вместо использования SSL. Кроме того, в Apple App Store не очень нравится, когда вы создаете свою собственную систему шифрования 24.04.2012
  • Спасибо, ребята, за ваш вклад. Я обязательно сначала попробую HTTPS. 25.04.2012

    • 3

    Если вы не хотите внедрять SSL, попробуйте https://www.jcryption.org/. Я не знаю, будет ли он работать в среде без сохранения состояния, но, возможно, стоит попробовать. По сути, это плагин jquery, который обрабатывает создание ассоциаций пар ключей для передаваемых данных. Однако может быть только для отправки формы. Мы использовали его для шифрования учетных данных в моей старой компании.

    24.04.2012
  • Криптовалюта JavaScript - вообще плохая идея: matasano.com/articles/javascript-cryptography 25.04.2012

    • 4

    Обязательно используйте HTTPS, если данные являются конфиденциальными - он шифрует на транспортном уровне, что вы и ищете. Как уже указывалось, oAuth 2.0 по существу требует этого. Вы можете потенциально избежать человека в середине, используя хеширование / подпись, как в oAuth 1.0, и избежать использования SSL, но тогда тело все еще остается открытым (вы избегали отправки учетных данных API в открытом виде, но не в теле).

    25.04.2012
    Новые материалы
    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..
    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..
    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..
    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..
    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..
    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..
    ИИ в аэрокосмической отрасли
    Каждый полет – это шаг вперед к великой мечте. Чтобы это происходило в их собственном темпе, необходима команда астронавтов для погони за космосом и команда технического обслуживания..
    Для любых предложений по сайту: [email protected]