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!
