Re: proftpd + inetd + ssl/tls и другие вопросы.
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Tue, 24 Nov 2015 02:30:58 +0200:
OG> Выяснил что plain ftp передает пароль в открытом виде в момент авторизации.
OG> Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы.
OG> Не могу вьехать что делать что бы proftpd + inetd работал безопасно.
OG> В общем на сервере выполнил:
OG> $ sudo proftpd-gencert
OG> /etc/proftpd/proftpd.conf::
OG> Include /etc/proftpd/tls.conf
OG> /etc/proftpd/tls.conf::
OG> TLSEngine on
OG> TLSLog /var/log/proftpd/tls.log
OG> TLSProtocol SSLv23
По нынешним временам SSL v2 и v3 считается за "шифрование отсутствует".
В смысле, дыры и их эксплойты в этих версиях протокола известны.
OG> TLSRSACertificateFile /etc/ssl/certs/proftpd.crt
OG> TLSRSACertificateKeyFile /etc/ssl/private/proftpd.key
OG> TLSOptions NoCertRequest EnableDiags
OG> TLSVerifyClient off
OG> TLSRequired on
OG> Пробую:
OG> bash# lftp ftp://user@vps
OG> Password:
OG> lftp user@vps:~> ls
OG> ls: Fatal error: Certificate verification: Not trusted
OG> lftp user@vps:~> exit
OG> bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps
OG> Password:
OG> lftp user@vps:~> ls
OG> drwxr-xr-x 5 user user 4096 Nov 22 18:04 devel
OG> drwxr-xr-x 2 user user 4096 Oct 10 16:14 tmp
OG> Обычная команда `ftp` из `/usr/bin/netkit-ftp` не поддерживает SSL:
OG> bash# ftp -n vps
OG> Connected to vps.
OG> 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30]
ftp>> ls
OG> 550 SSL/TLS required on the control channel
OG> ftp: bind: Address already in use
ftp>> user user
OG> ^C
OG> 421 Service not available, remote server has closed connection
ftp>> exit
OG> `curl` тоже работает::
OG> $ curl --ftp-ssl -k --netrc ftp://user@vps/.bashrc
OG> Нужно ли в inetd.conf использовать ftps или ftp:
OG> ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd
OG> ftps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd
OG> У меня на ftps ошибки:
OG> bash# curl --ftp-ssl -k --netrc ftps://user@vps/.bashrc
OG> curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.
OG> bash# lftp ftps://user@vps
OG> lftp user@vps:~> ls
OG> ls: Fatal error: gnutls_handshake: An unexpected TLS packet was received.
OG> Такое ощущение что для ftps:// используется другой протокол, чем на ftp:// с
OG> включенным SSL.
Да. ftps начинается с SSL/TLS handshake, и уже только после того, как
защищенное соединение установилось, начинается диалог по протоколу FTP.
В случае с ftp сначала начинается диалог по FTP, внутри него выдается
просьба поднять TLS, и после того, как он поднят, продолжается диалог по
FTP.
OG> Как правильно запретить общение открытым текстом и настроить SSL/TLS в proftpd?
По идее, при настройке TLSRequired on разницы в безопасности быть не
должно - FTP не поддерживает вроде бы pipelining, на USER сервер выдаст
вон то, что он выдает команде ftp, и до пароля дело не дойдет.
OG> Далее вопрос как в Debian сделать публичный ключ proftpd доверенным на
OG> клиентах?
OG> Я пробовал как:
OG> $ sudo mkdir /usr/share/ca-certificates/vps
OG> $ sudo scp user@vps:/etc/ssl/certs/proftpd.crt /usr/share/ca-certificates/vps/proftpd.crt
OG> $ sudo dpkg-reconfigure ca-certificates
OG> $ sudo update-ca-certificates --fresh
OG> Но curl и lftp игнорируют Дебиановские соглашения о сертификатах. Или я
OG> неверно готовлю. При том proftpd.crt виден в конце:
Второе.
Тут, вероятно, для начала нужен некоторый ликбез.
Клиенты доверяют сертификату сервера, если этот сертификат подписан
доверенным центром сертификации. Вот то самое "ca" в ca-certificates.
Certification Authority. У CA тоже есть сертификат, и подпись на
сертификате сервера проверяется об этот сертификат (там содержится
открытый ключ подписи).
Для построения цепочки доверия нужно выполнение нескольких условий.
Применительно к твоей ситуации, не выполнено в первую очередь условие
"сертификат сервера и сертификат CA - разные сертификаты, с разными
разрешенными областями применения".
Чтобы нормально работало, надо сделать честный сертификат CA,
распространить его по клиентам, в норме - установить в набор доверенных
корневых (это то, что ты пытался сделать с сертификатом сервера),
сделать честный серверный сертификат и подписать его ключом CA.
Или купить серверный сертификат у какого-нибудь известного CA, про
которого большинство клиентов знает из коробки. Это минус необходимость
устанавливать свой сертификат CA на клиентов - довольно сложная операция
для юзера на винде (вероятно, разная для разных версий винды),
работоспособная не в каждом андроиде, и т.п.
Я не знаю точно, что именно делает proftpd-gencert, но почти наверняка
он делает самоподписанный сертификат сервера, на котором можно защищать
соединение, но которому в нормальной инфраструктуре никто не будет
доверять.
Сделать честно не то чтобы офигительно сложно, но я не знаю простых
энд-юзерских инструментов для этого. Сам тупо пользуюсь openssl, но я
этой криптографией занимался профессионально, и понимаю, что делать с
его ключами и конфигом. А так-то openssl как утилита - штука
отладочная, для реальной работы не предазначенная. Хотя может.
Вроде бы, в комплекте gnutls было что-то попроще для построения PKI.
OG> /etc/ssl/certs/ca-certificates.crt
OG> Также если кормить напрямую:
OG> bash# curl -v --ftp-ssl --cacert /usr/share/ca-certificates/vps/proftpd.crt --netrc ftp://user@vps/.bashrc
OG> * Trying 149.202.132.30...
OG> * Connected to vps (149.202.132.30) port 21 (#0)
OG> < 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30]
>> AUTH SSL
OG> < 234 AUTH SSL successful
OG> * found 1 certificates in /usr/share/ca-certificates/vps/proftpd.crt
OG> * found 728 certificates in /etc/ssl/certs
OG> * ALPN, offering http/1.1
OG> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
OG> * server certificate verification failed. CAfile: /usr/share/ca-certificates/vps/proftpd.crt CRLfile: none
OG> * Closing connection 0
OG> curl: (60) server certificate verification failed. CAfile: /usr/share/ca-certificates/vps/proftpd.crt CRLfile: none
OG> More details here: http://curl.haxx.se/docs/sslcerts.html
OG> curl performs SSL certificate verification by default, using a "bundle"
OG> of Certificate Authority (CA) public keys (CA certs). If the default
OG> bundle file isn't adequate, you can specify an alternate file
OG> using the --cacert option.
OG> If this HTTPS server uses a certificate signed by a CA represented in
OG> the bundle, the certificate verification probably failed due to a
OG> problem with the certificate (it might be expired, or the name might
OG> not match the domain name in the URL).
OG> If you'd like to turn off curl's verification of the certificate, use
OG> the -k (or --insecure) option.
OG> --
OG> Best regards!
Reply to: