Сам риски сертификата со знаком
из страницы справочника:
ftpcopy
Obsolete. Use one of the following instead:
get ftp://... -o ftp://...
get -O ftp://... file1 file2...
put ftp://...
mput ftp://.../*
mget -O ftp://... ftp://.../*
or other combinations to get FXP transfer (directly between two ftp
servers). lftp would fallback to plain copy (via client) if FXP trans-
fer cannot be initiated or ftp:use-fxp is false.
таким образом, можно скопировать файл путем выполнения:
get filename -o ftp://user@ftpsite/directory/copyoffile
возможно, это будет работать лучше, чем a put/get если только потому, что Вы будете делать, что-то как FXP и сервер будет использовать его собственную локальную пропускную способность
Сертификат вашего сайта (+ закрытый ключ) должен рассматриваться как любой сертификат сайта. Если кто-то получит закрытый ключ, он сможет выдать себя за ваш сайт. Существует небольшая разница в том, как вы должны доверять службе хостинга для сертификата, выданного коммерческим центром сертификации.
Риски здесь смягчаются тем фактом, что, поскольку вы создали свой собственный центр сертификации, мало кто будет доверять этот CA по умолчанию. Это риск, который фактически ограничен теми, кто решил доверять вашему ЦС.
То же самое относится и к закрытому ключу ЦС. Кто-то, кто получит его закрытый ключ, может выдать любой сертификат.
Самые большие проблемы возникают из-за того, что пользовательские интерфейсы имеют тенденцию одинаково обращаться со всеми доверенными центрами сертификации (кроме сертификатов EV) или очень похожим образом, если пользователь не обращает внимания . В результате, если злоумышленник (а) имел закрытый ключ вашего ЦС и (б) знал пользователя, доверяющего этому ЦС сертификату, он мог бы создать сертификат, действительный для любого веб-сайта, который они хотят.
Ваша оценка рисков должна принять принять во внимание, кто решит доверять этому внутреннему ЦС. Коммерческие центры сертификации, как правило, придерживаются строгих политик в отношении защиты своих закрытых ключей (как правило, неизвлекаемое хранилище на смарт-картах или аналогичное): это часто является требованием, которое необходимо одобрить для включения в большинство браузеров.
Более конкретно о " другая информация ". При проектировании CA может быть важно иметь политику относительно того, какие атрибуты и как, например, структурированы DN субъектов. Я знал несколько центров сертификации, которые никогда не раскрывали информацию о пользователе.
Собственный самоподписанный сертификат не представляет опасности, если люди знают, что это самозаверяющий сертификат. Самый большой риск, который они представляют, - для клиентов.
Например, когда вы раздаете клиенту и устанавливаете начальное соединение, вы захотите убедиться, что они подтвердили его действительность, но кроме этого, единственное преимущество использования третьего party provider - вам не нужно беспокоиться о злоумышленнике, который притворяется вашим сервером, но это означает, что вы были бы взломаны с самого начала, а также имели бы много других проблем.
Итак, самая большая угроза безопасности - это не сообщая людям, что это самозаверяющий сертификат, и не проверять его местонахождение. По крайней мере, по моему мнению. Кроме того, они не управляются центром сертификации, поэтому вы можете '