Как кэшировать пароль сертификата клиента SSL в клиентском приложении с помощью libcurl

У нас есть (многооперационное) приложение, которое взаимодействует с https-сервером с помощью libcurl и использует сертификацию клиента SSL. Если сертификация клиента защищена паролем, приложение должно попросить пользователя ввести пароль. Приложение отправляет на сервер сотни различных https-запросов, поэтому мы не можем просить пользователя вводить пароль каждый раз, когда создается новое соединение. Теперь мы просто предлагаем пользователю ввести пароль один раз при запуске приложения, а затем устанавливаем пароль curllib с помощью опции «CURLOPT_KEYPASSWD». Но я беспокоюсь о том, что злоумышленник может легко взломать запущенный процесс и прочитать пароль сертификации клиента. Могу ли я каким-либо образом кэшировать пароль сертификации клиента, а также предотвратить его легкое чтение из памяти?


person Long Cheng    schedule 04.12.2009    source источник


Ответы (1)


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

Несколько советов по борьбе с атаками swap и coldboot:

  • Заблокируйте память, в которой хранится пароль, не допускайте ее выгрузки (mlock+mprotect и на posix, в Windows тоже есть подобные функции)
  • возможно, зашифровать память, в которой хранится пароль, и расшифровать ее только при использовании пароля.

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

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

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

person Martin Paljak    schedule 04.12.2009