Можно ли использовать шифрование RSA вместо SSL в веб-приложении при публикации?

Допустим, я хочу создать приложение, в котором я не хочу регистрироваться или не могу получить SSL-сертификат (независимо от причины).

Мне было интересно, можно ли получить преимущества безопасности SSL, используя вместо этого RSA.

Я использую библиотеку CrypticoJS — https://github.com/wwwtyro/cryptico)

Например, скажем, когда пользователь ОТПРАВЛЯЕТ информацию в мое приложение. Я бы сделал следующее:

1) Имейте закрытый ключ RSA на сервере и дайте каждому клиенту открытый ключ RSA.

2) На клиенте: шифруйте данные с помощью RSA PublicKey перед POST и зашифрованными данными POST.

3) На сервере: Расшифруйте данные POST с помощью закрытого ключа.

4) На сервере: сохранить расшифрованные данные в БД

Цель состоит в том, чтобы предотвратить взлом конфиденциальной информации и паролей моего пользователя. Я знаю, что не увижу зеленый баннер «Доверие», когда люди посетят мое приложение, но безопасность моего пользователя является приоритетом. Пожалуйста, дайте мне знать, если это возможно. Спасибо.


person Meowzie    schedule 28.12.2014    source источник
comment
Это защитит передаваемые данные от перехвата, но атака «человек посередине» может изменить ваши сценарии, чтобы добавить код, который также отправляет данные, которые вы шифруете, на другой сервер. Вероятно, это был бы лучший вопрос для security.stackexchange.com.   -  person Alexander O'Mara    schedule 28.12.2014
comment
Спасибо за ваш ответ. Чтобы предотвратить посредника, я бы также использовал сеансы с истекающим сроком действия и установил максимум 1 сеанс на каждого пользователя/IP/страну, вошедшего в систему.   -  person Meowzie    schedule 28.12.2014
comment
сеансы не защитят от автоматизированного человека посередине   -  person Jasen    schedule 28.12.2014
comment
@Jasen Итак, что может защитить от атак MITM, кроме сеансов?   -  person Meowzie    schedule 29.12.2014
comment
в основном вам нужен сертификат SSL. Они станут дешевле. letsencrypt.org   -  person Jasen    schedule 29.12.2014
comment
StartSSL предоставляет бесплатные широко распространенные SSL-сертификаты. Если вы действительно имеете в виду это, когда говорите, что безопасность ваших пользователей является приоритетом, то вам следует использовать SSL.   -  person Iridium    schedule 29.12.2014


Ответы (1)


TLS/SSL обеспечивает гораздо больше преимуществ в плане безопасности, чем просто шифрование данных (через RSA или другой алгоритм). Чтобы получить представление о том, как работает TLS/SSL и какие средства защиты он обеспечивает, см. этот ответ от настоящего эксперта: https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847.

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

  • Если у вас нет очень небольшого объема данных для шифрования, использование RSA для шифрования/дешифрования данных может быть медленным. TLS/SSL использует асимметричные алгоритмы, такие как RSA, только для шифрования с симметричным ключом, что дает гораздо лучшую производительность, чем базовое использование RSA для всего шифрования/дешифрования.

  • Без TLS/SSL ваши конечные пользователи не могли быть уверены, что они отправляют свои зашифрованные данные на доверенный веб-сервер. Например, если злоумышленник должен был сидеть в середине запроса (например, через общедоступный Wi-Fi), он мог манипулировать ответами, отправленными с вашего веб-сайта, чтобы изменить используемый открытый ключ RSA, а также URL-адрес для отправки зашифрованных данных. . Ваши конечные пользователи, скорее всего, не заметят, что в этом сценарии что-то не так.

  • Использование TLS/SSL обеспечивает защиту на уровне браузера, которую невозможно полностью воспроизвести, используя только JavaScript. Одним из примеров является доверие к веб-серверу. Если нет SSL-сертификата от доверенного центра сертификации, у ваших конечных пользователей очень мало гарантий того, что их конфиденциальные данные защищены. На защищенных сайтах браузер будет отображать замок и/или зеленую адресную строку в качестве визуального индикатора того, что данные отправляются через защищенное соединение. Если этого нет, пользователи должны быть уверены, что вы реализовали альтернативный механизм безопасности. Даже если у вас есть (что, на мой взгляд, почти невозможно), пользователь не может быть уверен, что атака «человек посередине» не изменит вашу реализацию.

Если, как вы говорите, безопасность ваших пользователей является приоритетом, я настоятельно рекомендую вам рассмотреть возможность использования TLS/SSL для ваших нужд.

person Brice Williams    schedule 29.12.2014