Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Oleksandr Gavenko 
On 2015-11-24, Artem Chuprina wrote:

> Тут, вероятно, для начала нужен некоторый ликбез.
>
> Клиенты доверяют сертификату сервера, если этот сертификат подписан
> доверенным центром сертификации.  Вот то самое "ca" в ca-certificates.
> Certification Authority.  У CA тоже есть сертификат, и подпись на
> сертификате сервера проверяется об этот сертификат (там содержится
> открытый ключ подписи).
>
> Для построения цепочки доверия нужно выполнение нескольких условий.
> Применительно к твоей ситуации, не выполнено в первую очередь условие
> "сертификат сервера и сертификат CA - разные сертификаты, с разными
> разрешенными областями применения".
>
> Чтобы нормально работало, надо сделать честный сертификат CA,
> распространить его по клиентам, в норме - установить в набор доверенных
> корневых (это то, что ты пытался сделать с сертификатом сервера),
> сделать честный серверный сертификат и подписать его ключом CA.
>
> Или купить серверный сертификат у какого-нибудь известного CA, про
> которого большинство клиентов знает из коробки.  Это минус необходимость
> устанавливать свой сертификат CA на клиентов - довольно сложная операция
> для юзера на винде (вероятно, разная для разных версий винды),
> работоспособная не в каждом андроиде, и т.п.
>
> Я не знаю точно, что именно делает proftpd-gencert, но почти наверняка
> он делает самоподписанный сертификат сервера, на котором можно защищать
> соединение, но которому в нормальной инфраструктуре никто не будет
> доверять.
>
> Сделать честно не то чтобы офигительно сложно, но я не знаю простых
> энд-юзерских инструментов для этого.  Сам тупо пользуюсь openssl, но я
> этой криптографией занимался профессионально, и понимаю, что делать с
> его ключами и конфигом.  А так-то openssl как утилита - штука
> отладочная, для реальной работы не предазначенная.  Хотя может.
>
> Вроде бы, в комплекте gnutls было что-то попроще для построения PKI.

Да, схема то закручена. Вместо прямого доверия cертификату сервера (как я
думал выше что получится) мы доверяем всем сетрификатам подписаными доверенным
CA.

В общем ниже сырой материал, подготовленый для блогозаписи.

Может есть проще (я встречал упоминание о ca.pl скрипте) но так сработало.
openssl.cnf подбирал копированием /usr/lib/ssl/openssl.cnf подряд по
выпадающим ошибкам от "openssl ca". Остальное извлек из кучи вкладок браузера.

Я тоже занимался криптографией (БИФИТ, оптимизация криптопримитивов), но
сменил работу в то время как подоспели прикладные задачи (связать примитивы в
публичные API и PKI), не успел помучится с x509 и PKI ))



Create CA root self-signed certificate::

  $ openssl req -x509 -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout 
ca-root-key.pem -out ca-root-cert.pem
  ...
  $ ls ca-root-*.pem
  ca-root-cert.pem  ca-root-key.pem

Dump content::

  $ openssl x509 -text -noout -in ca-root-cert.pem
  ...
  $ openssl pkey -text -noout -in ca-root-key.pem
  ...

Check certificate purpose::

  $ openssl x509 -purpose -in ca-root-cert.pem
  ...

Generate server key and certificate::

  $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout 
server-key.pem -out server-cert.csr
  $ ls server-*.pem
  server-cert.csr  server-key.pem

Dump content::

  $ openssl req -text -noout -in server-cert.csr
  ...
  $ openssl pkey -text -noout -in server-key.pem
  ...

To fill subject automatically::

  $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -subj 
"/C=UA/ST=User/L=City/O=Corp/OU=SubCorp/CN=myvps.com" -keyout server-key.pem 
-out server-cert.csr


Prepare use minimal ``openssl.cnf``::

  [ ca ]
  default_ca  = CA_default

  [ CA_default ]
  new_certs_dir = .
  database = index.txt
  serial = serial.txt

  default_md  = default
  policy  = policy_anything

  [ policy_anything ]
  countryName = optional
  stateOrProvinceName = optional
  localityName= optional
  organizationName= optional
  organizationalUnitName  = optional
  commonName  = supplied
  emailAddress= optional

Prepare some CA database files::

  $ echo 01 > serial.txt
  $ touch touch index.txt index.txt.attr

Sign server CSR with CA key::

  $ openssl ca -days 1000 -config openssl.cnf -cert ca-root-cert.pem -keyfile 
ca-root-key.pem -out server-cert.pem -in server-cert.csr

Dump signed server certificate::

  $ openssl x509 -text -noout -in server-cert.pem
  ...

Copy CA certificate to Debian tructed store::

  $ sudo cp ca-root-cert.pem /usr/share/ca-certificates/my/my-ca-root-cert.crt

and register certificate::

  $ sudo dpkg-reconfigure ca-certificate

Copy signed server key + certificate to server and resister it::

  $ scp server-key.pem server-cert.pem user@vps
  $ ssh user@vps
  % sudo cp server-cert.pem  /etc/ssl/certs/proftpd.crt
  % sudo cp server-key.pem  /etc/ssl/private/proftpd.key

After all I can run::

  $ lftp ftp://u...@myvps.com
  lftp u...@myvps.com:~> ls
  -rw-r-   1 ftp  ftp   276 Nov 24 20:16 index.html

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Oleksandr Gavenko 
On 2015-11-24, Victor Wagner wrote:

>> Если разобраться с сертификатами, то мне ftps кажется тоже хорошим
>> решением, особенно учитывая что через ftp-сервер можно задавать права
>> доступа, ложить файлы с нужными владельцами и правами и использовать
>> свою базу авторизации (ftpasswd).
>  
> Если разобраться с сертификатами то DAV в общем-то решает все те же
> задачи, только лучше.

У меня когда-то была идея на SVN+WebDAV внедрить репозиторий для артефактов
сборки (вместо FTP, т.к. были случаи когда подменялись библиотеки участвующие
в релизной сборке - нельзя было понять произошло ли это событие и кем/когда).

В SVN хранилище есть контрольные суммы (на сколько я помню также от контента),
позволяет выявить повреждения.

Хранится история кто и когда поместил файл.

Хуками можно запретить перезаписывание файла.

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

Зато встречал стягивание по HTTP (без S) библиотек с Maven-репозиториев.

-- 
Best regards!

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Artem Chuprina 
Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Wed, 25 Nov 2015 
01:50:18 +0200:

Вот меня в нижеприведенном прям смущает, что конфиг совсем
минималистичный.  openssl нынче что, сам догадывается поставить
правильное назначение сертификата в зависимости от того, делают его
самоподписанным или подписывают заявку?

Можно посмотреть вывод openssl x509 -text -noout этих обоих сертификатов
в части X509v3 extensions?

У меня для сертификата CA там показывают

X509v3 Basic Constraints: 
CA:TRUE
X509v3 Key Usage: 
Certificate Sign, CRL Sign

а для сертификата сервера 

X509v3 Basic Constraints: 
CA:FALSE
Netscape Cert Type: 
SSL Server
X509v3 Extended Key Usage: 
TLS Web Server Authentication

 OG> В общем ниже сырой материал, подготовленый для блогозаписи.

 OG> Может есть проще (я встречал упоминание о ca.pl скрипте) но так сработало.
 OG> openssl.cnf подбирал копированием /usr/lib/ssl/openssl.cnf подряд по
 OG> выпадающим ошибкам от "openssl ca". Остальное извлек из кучи вкладок 
браузера.

 OG> Я тоже занимался криптографией (БИФИТ, оптимизация криптопримитивов), но
 OG> сменил работу в то время как подоспели прикладные задачи (связать 
примитивы в
 OG> публичные API и PKI), не успел помучится с x509 и PKI ))

 OG> 

 OG> Create CA root self-signed certificate::

 OG>   $ openssl req -x509 -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout
 OG> ca-root-key.pem -out ca-root-cert.pem
 OG>   ...
 OG>   $ ls ca-root-*.pem
 OG>   ca-root-cert.pem  ca-root-key.pem

 OG> Dump content::

 OG>   $ openssl x509 -text -noout -in ca-root-cert.pem
 OG>   ...
 OG>   $ openssl pkey -text -noout -in ca-root-key.pem
 OG>   ...

 OG> Check certificate purpose::

 OG>   $ openssl x509 -purpose -in ca-root-cert.pem
 OG>   ...

 OG> Generate server key and certificate::

 OG>   $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -keyout 
server-key.pem -out server-cert.csr
 OG>   $ ls server-*.pem
 OG>   server-cert.csr  server-key.pem

 OG> Dump content::

 OG>   $ openssl req -text -noout -in server-cert.csr
 OG>   ...
 OG>   $ openssl pkey -text -noout -in server-key.pem
 OG>   ...

 OG> To fill subject automatically::

 OG>   $ openssl req -sha256 -days 1000 -nodes -newkey rsa:4096 -subj
 OG> "/C=UA/ST=User/L=City/O=Corp/OU=SubCorp/CN=myvps.com" -keyout 
server-key.pem
 OG> -out server-cert.csr


 OG> Prepare use minimal ``openssl.cnf``::

 OG>   [ ca ]
 OG>   default_ca  = CA_default

 OG>   [ CA_default ]
 OG>   new_certs_dir = .
 OG>   database = index.txt
 OG>   serial = serial.txt

 OG>   default_md  = default
 OG>   policy  = policy_anything

 OG>   [ policy_anything ]
 OG>   countryName = optional
 OG>   stateOrProvinceName = optional
 OG>   localityName= optional
 OG>   organizationName= optional
 OG>   organizationalUnitName  = optional
 OG>   commonName  = supplied
 OG>   emailAddress= optional

 OG> Prepare some CA database files::

 OG>   $ echo 01 > serial.txt
 OG>   $ touch touch index.txt index.txt.attr

 OG> Sign server CSR with CA key::

 OG>   $ openssl ca -days 1000 -config openssl.cnf -cert ca-root-cert.pem 
-keyfile
 OG> ca-root-key.pem -out server-cert.pem -in server-cert.csr

 OG> Dump signed server certificate::

 OG>   $ openssl x509 -text -noout -in server-cert.pem
 OG>   ...

 OG> Copy CA certificate to Debian tructed store::

 OG>   $ sudo cp ca-root-cert.pem 
/usr/share/ca-certificates/my/my-ca-root-cert.crt

 OG> and register certificate::

 OG>   $ sudo dpkg-reconfigure ca-certificate

 OG> Copy signed server key + certificate to server and resister it::

 OG>   $ scp server-key.pem server-cert.pem user@vps
 OG>   $ ssh user@vps
 OG>   % sudo cp server-cert.pem  /etc/ssl/certs/proftpd.crt
 OG>   % sudo cp server-key.pem  /etc/ssl/private/proftpd.key

 OG> After all I can run::

 OG>   $ lftp ftp://u...@myvps.com
 OG>   lftp u...@myvps.com:~> ls
 OG>   -rw-r-   1 ftp  ftp   276 Nov 24 20:16 index.html
 OG>   lftp u...@myvps.com:/> exit

 OG> without::

 OG>   $ lftp -e 'set ssl:verify-certificate no' ftp://u...@myvps.com

 OG> Note that ftp:// URL domain name SHOULD match certificate CN name or you 
get error::

 OG>   Fatal error: Certificate verification: certificate common name doesn't 
match
 OG> requested host name ‘myvps.com’

Тут есть еще такая штука, как X509v3 Subject Alternative Name.  У меня, 
например,

X509v3 Subject Alternative Name: 
DNS:nest.lasgalen.net, DNS:jabber.lasgalen.net, 
DNS:mail.lasgalen.net

В конфиге это задается

subjectAltName=DNS:nest.lasgalen.net,DNS:jabber.lasgalen.net,DNS:mail.lasgalen.net

Сколь я помню, при наличии subjectAltName CN игнорируется (в смысле,
если имя хоста совпадает с CN, но отсутствует в subjectAltName,
сертификат считается непригодным для этого хоста).

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Mikhail A Antonov 
24.11.2015 09:01, Artem Chuprina пишет:
> Сделать честно не то чтобы офигительно сложно, но я не знаю простых
> энд-юзерских инструментов для этого.  Сам тупо пользуюсь openssl, но я
> этой криптографией занимался профессионально, и понимаю, что делать с
> его ключами и конфигом.  А так-то openssl как утилита - штука
> отладочная, для реальной работы не предазначенная.  Хотя может.
Можно посмотреть на tinyca. Оно с гуём относительно просто создаёт свой
CA и этим CA подписывает.
На сколько я помню, tinyca не умеет работать с сертификатами на
несколько имён, но т.к. она (программа) является лишь гуём для вызова
openssl - это решаемо.

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Max Kosmach 

25.11.2015 9:53, Mikhail A Antonov пишет:

24.11.2015 09:01, Artem Chuprina пишет:

Сделать честно не то чтобы офигительно сложно, но я не знаю простых
энд-юзерских инструментов для этого.  Сам тупо пользуюсь openssl, но я
этой криптографией занимался профессионально, и понимаю, что делать с
его ключами и конфигом.  А так-то openssl как утилита - штука
отладочная, для реальной работы не предазначенная.  Хотя может.

Можно посмотреть на tinyca. Оно с гуём относительно просто создаёт свой
CA и этим CA подписывает.
На сколько я помню, tinyca не умеет работать с сертификатами на
несколько имён, но т.к. она (программа) является лишь гуём для вызова
openssl - это решаемо.


Еще есть простой набор скриптов easy-rsa из openvpn. Есть отдельным пакетом в Debian. В первом приближении самодостаточен и прост в использовании и 
легко модифицируется под сови нужды.





--
С уважением,
Космач Максим

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Andrey Melnikoff 
Oleksandr Gavenko  wrote:

> Выяснил что plain ftp передает пароль в открытом виде в момент авторизации.
Он так лет 30+ последних делает.

> Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы.

> Не могу вьехать что делать что бы proftpd + inetd работал безопасно.
Выкинуть. Это им поможет.
А использовать вместо - sftp. Софтин под винду - валом.

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Victor Wagner 
On Tue, 24 Nov 2015 02:30:58 +0200
Oleksandr Gavenko  wrote:

> Выяснил что plain ftp передает пароль в открытом виде в момент
> авторизации.
> 
> Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах
> работы.
> 
> Не могу вьехать что делать что бы proftpd + inetd работал безопасно.

1. Не использовать ftp для неанонимного доступа.
2. Сделать так, чтобы директории, доступные для анонима на запись, не
были доступны для него же на чтение (а то превратят сервер в хаб для
обмена порнухой)
3. Во всех остальных случаях использовать протоколы, отличные от ftp.

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Oleksandr Gavenko 
On 2015-11-24, Tim Sattarov wrote:

> а SFTP или Rsync over SSH не нравится ?

Нет опыта работы, сейчас поискал как ограничивать доступ, вот что есть:

Для SFTP решение в виде:

  $ sudo groupadd sftp
  $ sudo usermod username -g sftp
  $ sudo usermod username -s /bin/false
  $ sudo usermod username -d /home/username

  $ cat /etc/ssh/sshd_config
  ...
  Match Group sftp
  ChrootDirectory %h
  ForceCommand internal-sftp
  AllowTcpForwarding no
  ...

Или 

  $ cat /etc/ssh/sshd_config
  ...
  Match User restricted
  ChrootDirectory /srv/data/ANY-PATH
  ForceCommand internal-sftp
  AllowTcpForwarding no
  ...

Для rsync:

  https://www.debian.org/mirror/push_server 

  $ cat /etc/rsyncd.conf

  uid = nobody
  gid = nogroup
  max connections = 25
  socket options = SO_KEEPALIVE

  [debian]
path = /srv/debian/mirror
comment = The Debian Archive (~250 GB)
auth users = authorized_account1,authorized_account2,authorized_accountN
read only = true
secrets file = /etc/rsyncd/debian.secrets

  $ cat /etc/rsyncd/debian.secrets

  authorized_account1:a_password
  authorized_account2:another_password
  authorized_accountN:password

  $ cat /etc/initd

  rsync  stream  tcp nowait  root /usr/bin/rsync rsyncd 
--daemon

Как видно для rsync есть возможность задать синтетические авторизационные
данные, для sftp - только пользователи системы. Этим rsync больше нравится.

-- 
Best regards!

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Oleksandr Gavenko 
On 2015-11-24, Tim Sattarov wrote:

> тут бы я посмотрел на ftp:ssl-* значения
> curl попробовать с -k
>
> и смотреть как работает SSL соединение с помощью openssl
>
> openssl s_client -connect vps:990

Спасибо за подсказку, отладил эту проблему:

  bash# openssl s_client -connect vps:990
  CONNECTED(0003)
  140416106407568:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown 
protocol:s23_clnt.c:794:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent

  bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps:990
  lftp user@vps:~> ls
  drwxr-xr-x   5 user user 4096 Nov 22 18:04 devel
  drwxr-xr-x   2 user user 4096 Oct 10 16:14 tmp
  lftp user@vps:/> exit

Т.е. на ftps у меня не FTP через SSL/TLS, а некое расширение протокола FTP с
SSL/TLS.

Собвтвенно это возвращает меня к вопросу - что же это такое протокол FTPS,
какие клиенты/серверы поддерживают?

-- 
Best regards!

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Oleksandr Gavenko 
On 2015-11-24, Victor Wagner wrote:

> 1. Не использовать ftp для неанонимного доступа.
> 2. Сделать так, чтобы директории, доступные для анонима на запись, не
> были доступны для него же на чтение (а то превратят сервер в хаб для
> обмена порнухой)

Ясно. Я ранее знал практике публичных бесплатных хостингов - позволять
загружать странички через небозопасный FTP. На ум приходит narod.ru и blogspot
до покупки Google'ом.

Ожидал что есть TLS расширение, обеспечивающие безопасность.

Есть стандарт

  https://tools.ietf.org/html/rfc2228
FTP Security Extensions

со страшными словами GSSAPI/Kerberos 4, который судя по:

  http://www.proftpd.org/docs/rfc.html

не реализован полностью в proftpd. В то же время есть

  https://tools.ietf.org/html/rfc4217

который реализован в модуле mod_tls (и согласован с командой AUTH от rfc2228):

  http://www.proftpd.org/docs/howto/TLS.html

Оказывается что rfc4217 это не FTP в обертке TLS, а гибрид:

  12.1.  Establishing a Protected Session

  Client   Server
 control  data data   control
   ==

  socket()
  bind()
 socket()
 connect()  > accept()
   <  220
 AUTH TLS   >
   <  234
 TLSneg()  <> TLSneg()  <== Тут зашифровано?
 PBSZ 0 >
   <  200
 PROT P >
   <  200
 USER fred  >
   <  331
 PASS pass  >
   <  230

И далее у нас есть возможность передавать данные либо открыто, либо защищенно
по data-каналу.

Стандарта на обертку FTP в TLS, судя по выдержке:

  Negotiation is not supported with implicit FTPS configurations. A client is
  immediately expected to challenge the FTPS server with a TLS ClientHello
  message. If such a message is not received by the FTPS server, the server
  should drop the connection.

из:

  https://en.wikipedia.org/wiki/FTPS

и:

  A.  Deprecated SSL negotiation mechanisms

   There are two other mechanisms that have been used for FTP over SSL,
   these mechanisms do not conform to [RFC-2228] and so are now
   deprecated.  They are documented below.

   i) Implicit SSL protection of the FTP session

  There is a port, registered with the IANA, for secure FTP using
  ssl {FTP-TLSPORT}.  This approach can be likened to the [RFC-2818]
  approach for https, in that the SSL negotiation happens upon
  connection  (for the control and all data connections).  This
  approach is not favoured by the IETF and should not be used for
  new FTP-TLS implementations.
из:

 https://tools.ietf.org/html/draft-murray-auth-ftp-ssl-07#appendix-A

нету и нету соответственно нормальных реализаций.

lftp и curl на ftps:// пытаются "пожать руку", proftpd такого скоре всего не
умеет (я в документации не нашел способа).

> 3. Во всех остальных случаях использовать протоколы, отличные от ftp.

Я слышал и некоторые использовал:

 * smb - на сколько толстый сервер? У меня vps с 256 MiB RAM и доступ на
   запись к файлам не основная задача. Как с безопасностью при авторизации?

 * sftp - требует создавать пользователя в системе под каждый разделяемый
   ресурс.

 * rsync - не знаю визуальных оболочек, например как ftp/sftp в MC и
   интерактивных приложений как sftp/lftp. Для безопасности вроде нужно
   тунелировать через ssh.

 * webdav - требует постоянно работающего apache, нужно настраивать SSL.

Из всего только sftp выглядит простым решением.

Если разобраться с сертификатами, то мне ftps кажется тоже хорошим решением,
особенно учитывая что через ftp-сервер можно задавать права доступа, ложить
файлы с нужными владельцами и правами и использовать свою базу авторизации
(ftpasswd).

-- 
Best regards!

Re: proftpd + inetd + ssl/tls и другие вопросы.

2015-11-24 Пенетрантность Victor Wagner 
On Tue, 24 Nov 2015 15:31:59 +0200
Oleksandr Gavenko  wrote:


> Я слышал и некоторые использовал:
> 
>  * smb - на сколько толстый сервер? У меня vps с 256 MiB RAM и доступ
> на запись к файлам не основная задача. Как с безопасностью при
> авторизации?


С прошлого века не слышал, чтобы пользовались не в локальной сети. 

>  * sftp - требует создавать пользователя в системе под каждый
> разделяемый ресурс.


Не вижу никаких преимуществ перед scp или rsync over ssh

И для той, и для другой нужно работать с системными пользователями.
Совершенно не обязательно "пользователя на каждый разделяемый ресурс".
Можно пользователя на каждого пользователя и группу на каждый
разделяемый ресурс.


 
>  * rsync - не знаю визуальных оболочек, например как ftp/sftp в MC и
>интерактивных приложений как sftp/lftp. Для безопасности вроде
> нужно тунелировать через ssh.

Вот у rsync протокол аутентификации достаточно безопасный. Так что если
контент светить не жалко, можно использовать и без ssh.
 
>  * webdav - требует постоянно работающего apache, нужно настраивать
> SSL.

webdav - не знаю удобных клиентов. cadaver неудобный какой-то,
монтирование с помощью davfs не гарантирует своевременной доставки
файлов. С клиентом который бы позволял читать-писать файлы только через
опции командной строки - вообще все плохо. В vim netrw пытается cadaver
использовать, но у него не получается.

А вот в качестве сервера apache cовершенно необязателен. Можно и nginx
какой-нибудь.

А SSL настраиватьп придется и в случае если FTPS использовать. SSL в
любом случае надо настраивать, если хочешь использовать серверную
сторону протокола. Иначе она ничего не защищает.

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




> Если разобраться с сертификатами, то мне ftps кажется тоже хорошим
> решением, особенно учитывая что через ftp-сервер можно задавать права
> доступа, ложить файлы с нужными владельцами и правами и использовать
> свою базу авторизации (ftpasswd).
 
Если разобраться с сертификатами то DAV в общем-то решает все те же
задачи, только лучше.