Будет ли аутентификация через HTTPS замедлять мое приложение?

Я строю веб-приложение и веб-сервис RESTful.

Я читал различные статьи о лучшем способе аутентификации запросов к веб-сервису.

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

Я не совсем уверен, что это включает. Означает ли это, что весь мой веб-сервис должен быть на защищенном сервере? Это замедлит процесс?

Прежде всего, попытайтесь понять, как работает аутентификация SSL (HTTPS) и HTTP.

Обычные методы HTTP-аутентификации (Digest, Basic и любые схемы аутентификации на основе форм + cookie, которые вы можете реализовать поверх HTTP) сами по себе небезопасны, поскольку они отправляют информацию аутентификации более или менее в виде открытого текста. Вне зависимости от того, находятся ли данные в полях или заголовках POST, и применяется ли кодировка base64, это не имеет никакого значения, пароль ясно виден любому, кто имеет доступ к сетевому трафику. Это означает, что HTTP-аутентификация по ненадежному каналу бесполезна: злоумышленнику, который прочитает ваш пароль, достаточно лишь немного понюхать сеть.

SSL реализует безопасный канал связи по изначально небезопасному каналу. Это работает примерно так:

1. Сервер отправляет подписанный сертификат
2. Клиент проверяет сертификат по списку известных ключей подписи; подписи сертификатов могут быть объединены в цепочку, так что каждый узел говорит: «Если подпись, которая подписывает меня, является хорошей, то и я тоже», но в конечном итоге цепочка должна быть преобразована в один из нескольких доверенных органов, предварительно настроенных на клиенте.
3. Клиент использует открытый ключ шифрования сервера для отправки общего секрета
4. Сервер расшифровывает общий секрет с помощью закрытого ключа (поскольку закрытый ключ имеет только законный сервер, другие серверы не смогут расшифровать общий секрет)
5. Клиент отправляет фактические данные запроса, зашифрованные с использованием общего секрета
6. Сервер расшифровывает данные запроса, затем отправляет зашифрованный ответ
7. Клиент расшифровывает ответ и представляет его пользователю.

Обратите внимание на несколько важных моментов:

• Цепочка сертификатов позволяет клиентам удостовериться, что сервер, с которым они общаются, является реальным, а не кто-то перехватывает их запросы. Вот почему вы должны купить настоящий сертификат SSL, и почему браузеры выдают вам страшные предупреждения, когда вы заходите на сайт, который использует недействительный, просроченный или иным образом неверный сертификат: все шифрование в мире не поможет, если вы говорить не с тем человеком.
• Открытое / частное шифрование, используемое для обмена секретом, гарантирует, что успешное взаимодействие будет работать только между этой конкретной парой клиента и сервера: перехваченные сетевые пакеты будут зашифрованы, и им потребуется личный ключ сервера для получения данных.
• Симметричное шифрование используется для большей части запроса, потому что оно имеет гораздо меньшую нагрузку на производительность, чем шифрование с помощью закрытого / открытого ключа. Тем не менее, ключ (общий секрет) обменивается с использованием шифрования с закрытым / открытым ключом, поскольку это единственный способ сделать это безопасным способом (за исключением передачи его по отдельному каналу, такому как курьерская служба).

Очевидно, что это связано с некоторыми накладными расходами, но это не так плохо, как вы думаете - это в основном в масштабе, где «выбрасывать больше оборудования» является подходящим ответом, если вы не готовитесь к абсолютно огромным объемам трафика ( думаю гугл или фейсбук). При нормальных обстоятельствах, то есть при обычном использовании веб-приложения, издержки SSL незначительны, и, следовательно, как только у вас появятся какие-либо конфиденциальные данные, лучше всего просто запускать все через SSL, включая ресурсы. SSL также является единственным жизнеспособным способом защиты HTTP-трафика; другие методы просто не так стандартизированы и, следовательно, не получили широкой поддержки, и вы абсолютно не хотите реализовывать эти вещи самостоятельно, потому что, честно говоря, слишком легко их неправильно понять.

TL; DR: Да, SSL + Basic Authentication - хорошая идея, да, вам нужен защищенный сервер (и действительный сертификат ), да, это немного замедлит работу, но нет, это не то, о чем беспокоиться, верно Теперь.

HTTPS (SSL) не является аутентификацией пользователя FYI. Он просто обеспечивает шифрование между двумя конечными точками.

Но да, есть крошечные накладные расходы от этого (хотя этого недостаточно, чтобы гарантировать изменение в планах / оборудовании). Глянь сюда :

/programming/548029/how-much-overhead-does-ssl-impose

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

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

Обычная аутентификация - это установка имени пользователя и пароля в заголовке http-запроса. Если вы не используете SSL или эквивалент, тогда это имя пользователя и пароль отправляются в виде обычного текста и тривиально для любого.

В настоящее время большинство веб-серверов поддерживают HTTPS «из коробки», и хотя это добавляет накладные расходы на каждый вызов, эти накладные расходы минимальны.

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

Не так давно Джефф Этвуд написал краткое сообщение в блоге о том, стоит ли использовать полное шифрование. Он описывает некоторые примеры из реальной жизни и несколько строк о производительности.

Кроме того, он ссылается на эту статью о тематическом исследовании Gmail, цитируя следующее:

В январе этого года (2010) Gmail перешел на использование HTTPS для всего по умолчанию. Ранее он был представлен как опция, но теперь все наши пользователи постоянно используют HTTPS для защиты своей электронной почты между браузерами и Google. Для этого нам пришлось развернуть без дополнительных машин и специального оборудования. На наших производственных интерфейсных машинах SSL / TLS составляет менее 1% загрузки ЦП, менее 10 КБ памяти на соединение и менее 2% нагрузки на сеть. Многие считают, что SSL занимает много процессорного времени, и мы надеемся, что приведенные выше цифры (впервые опубликованные) помогут развеять это.

Он также упоминает о некоторых недавних улучшениях в кэшировании страниц на стороне клиента через HTTPS браузером .

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

• Поддержание качества программного обеспечения при добавлении дополнительной сложности для уже занятых команд,
• Кэширование прокси гораздо сложнее правильно настроить и требует изменений кода,
• Трудно получить право на безопасность для коллапса контента из разных источников,
• Малогабаритные мобильные устройства могут бороться с шифрованием.

Базовая аутентификация HTTP без вашей собственной обработки сеанса, вероятно, оставит вас открытыми для атак подделки межсайтовых запросов. Вероятно, вы можете использовать его, если вы работаете с собственной обработкой сеанса, но у вас могут возникнуть проблемы с обеспечением чистой функции выхода из системы.

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

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

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

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