Questions[gnutls](server)

My system is Debian Buster:

~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

I have run the following commands attempting to install Php 8.0

sudo apt -y install lsb-release apt-transport-https ca-certificates 
sudo apt update && sudo apt upgrade -y 
sudo reboot
sudo apt -y install lsb-release apt-transport-https ca-certificates 
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
sudo apt update
sudo apt -y install php8.0

apt update then spits out the following error, which leads to php8.0 not being an existing package:

Resolving packages.sury.org (packages.sury.org)... 172.67.182.150, 104.21.18.148, 2606:4700:3030::ac43:b696, ...
Connecting to packages.sury.org (packages.sury.org)|172.67.182.150|:443... connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [49]: Access was denied
Unable to establish SSL connection.

I know this is not a networking issue because I can ping 'google.com' and 8.8.8.8 along with downloading packages from other third parties. I cannot seem to figure out how to get this work, I would be open to alternatives to Sury to get Php 8.0 installed. Is this my issue or an issue with Sury? Nevertheless, Sury seems to be the best way to get Php 8.0.

Hopefully, someone way smarter than me knows why this is not working. If you have any further questions you can comment or private message me. Thank you in advance!

We have an openldap server and don't want to allow unencrypted communication, so acceptable is either tls over port 389 (starttls) or ssl over 636 (ldaps).

As we use slapd.conf for configuration, olcSecurity isn't an option.

TLSCipherSuite seems to be the way to do it with slapd.conf. But when using that slapd either doesn't start or ignores the settings (i.e. accepts unencrypted requests).

slapd doesn't start (error: TLS init def ctx failed: -1) when using:

- TLSCipherSuite ALL
- TLSCipherSuite Default
- TLSCipherSuite ALL:!NULL
- TLSCipherSuite ALL:!aNULL
- TLSCipherSuite AES256-SHA #one of the ciphers offered by openssl

slapd starts but accepts unencrypted requests when using:

- TLSCipherSuite NORMAL
- TLSCipherSuite NORMAL:!NULL #would be acceptable
- TLSCipherSuite !NULL #would be acceptable

We test with

ldapsearch -L -x -W -h [SERVER] -D [USER] - b [SEARCHBASE] uid=[USER] 

(unencrypted)

and

ldapsearch -L -x -W -ZZ -h [SERVER] -D [USER] - b [SEARCHBASE] uid=[USER]

(encrypted)

The os openldap is running on is debian 8.7. The openldap version seems to be using gnutls, not openssl, so that may be the reason for the problems.

But the last three TLSCipherSuite variations seem to be valid syntax, at least slapd starts without errors. Why doesn't !NULL prevent slapd from accepting unencrypted requests? The last two (use any cipher available but don't allow no cipher) would be acceptable.

Are additional settings / parameters required?

Note that we tried the suggestions given here (as described above) but that didn't work.

I have an Arch Linux system running vsftpd which has been functioning with FTPES for the past year now. Within the past two days, I have noticed that all of my FTP clients fail to connect over FTPES. When I connect using FileZilla 3.17.0 on Windows 7, I notice that a GnuTLS error -15 occurs when the directory list is being sent:

This is passive FTPES with host specified using WAN IP:

Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PASV
Response:   227 Entering Passive Mode (###,###,###,###,27,163).
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

FileZilla then retries the connection with identical results, then it stops attempting to connect. A previous version of FileZilla also showed a GnuTLS -110 error, though I do not have output saved containing that error.

I've read some posts which suggest that this issue is caused by a problem with the passive FTP configuration. Passive FTP has been working on this server for a while now, and I have not made any changes to any relevant configuration files. To be sure, I tried connecting using active mode. Everything seems normal until I receive an Illegal PORT command error, at which point FileZilla tries using passive again.

This is "active" FTPES with host specified using WAN IP:

Status: Connecting to ###.###.###.###:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,98
Response:   500 Illegal PORT command.
Command:    PASV
Response:   227 Entering Passive Mode (###,###,###,###,27,103).
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

The problem here seems to be that, even though I enter my WAN IP address, active mode still tries to use a local IP address in that PORT command. Another FTP client, FTP Client Pro version 3.0.4 on iOS, gives the error "Server doesn't seem to support Active mode." I then tried connecting to my server locally, and while this time the client didn't lapse into passive mode, the TLS error persists.

This is active FTPES with host specified using local IP:

Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,129
Response:   200 PORT command successful. Consider using PASV.
Command:    LIST
Response:   150 Here comes the directory listing.
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Error:  Disconnected from server: ECONNABORTED - Connection aborted
Error:  Failed to retrieve directory listing
Status: Disconnected from server

Finally, I have tried connecting without using encryption. Though I avoid it if at all possible, I must leave unencrypted connections supported in order to connect from some restrictive networks. Both active and passive settings in FileZilla work over the public Internet with encryption disabled, though both types show the same output:

This is active/passive plain FTP with host specified using WAN IP:

Status: Connecting to 98.220.249.102:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Status: Calculating timezone offset of server...
Status: Timezone offset of server is 0 seconds.
Status: Directory listing of "/" successful

Because this server is behind a router, it is configured such that passive FTP will not work locally; see vsftpd.conf below. In the interest of trying out all of the connection possibilities, here is FileZilla's output for making an active, unencrypted connection locally. It fails, but I am not too concerned as I never use that combination of settings.

This is active plain FTP with host specified using local IP:

Status: Connecting to 192.168.0.2:21...
Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Switching to Binary mode.
Command:    PORT 192,168,0,7,240,195
Response:   200 PORT command successful. Consider using PASV.
Command:    LIST
Response:   150 Here comes the directory listing.
Response:   500 OOPS: priv_sock_get_cmd
Error:  Failed to retrieve directory listing
Error:  Connection closed by server

Here is my /etc/vsftpd.conf, minus the comments. This is essentially the same file that I have been using successfully for the past year.

anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
xferlog_enable=YES
port_enable=YES
connect_from_port_20=YES
ftpd_banner=Welcome to HOSTNAME (vsftpd on ArchLinux).
chroot_local_user=YES
allow_writeable_chroot=YES
listen=YES
ssl_enable=YES
force_local_logins_ssl=NO
force_local_data_ssl=NO
ssl_tlsv1=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem
pasv_min_port=7000
pasv_max_port=7100
pasv_address=###.###.###.###

The latest full upgrade to my Arch system prior to noticing this issue was on 17 April 2016 and included upgraded gnutls (3.4.10-1 -> 3.4.11-1). The most recent upgrade to vsftpd was on 9 March 2016 (3.0.3-1 -> 3.0.3-2), so instead of downgrading only gnutls, I restored the entire system to its state on 9 March 2016 using the Arch Linux Archive. This did not help, and I subsequently upgraded the system to match the current repositories. The output provided here was generated using the up-to-date system as of the date of this post (23 April 2016). I am uncertain as to when exactly this error began, as I do not use my FTP server frequently enough to notice it immediately.

As I stated earlier, my relevant configurations have not changed since my FTP server was last working, aside from changes made to post the information here.

My goal is to get passive FTPES working over the public Internet again. It is acceptable if I must sacrifice unencrypted active FTP, but I would still like to leave that available for those rare times that I need it. What do I need to do to repair this?

I have some problems with Vstpd, and I don't know whether they are related or not.

One problem is that FireFTP can't get past the directory listing phase - it just stucks there forever, no error messages. Filezilla works, however it too sometimes gets stuck. In particular there are some files that just won't upload -- they too are stuck forever, sometimes a few bytes go through; here, too, no error messages server-side, and just a timeout client-side. Other clients seem totally unaffected (in particular Cyberduck on windows and Transmit on mac always worked flawlessly).

With FileZilla, the file I am attempting to upload will be created on the server with zero byte size, but nothing will be uploaded. If the file was already there, it will be emptied. I can also upload other files to the same directory, so it is not a permissions issue.

Is there any problem with my configuration? Am I using an outdated version? (It's Ubuntu 10.04). Here is vsftpd.conf. Using a self-signed cert.

Maybe this is a Linux problem??? Using Ubuntu 12.04 as client OS.

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
dual_log_enable=YES
xferlog_std_format=NO
xferlog_file=/var/log/vsftpd.log
session_support=YES

connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem

ssl_enable=YES
require_ssl_reuse=NO
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
ssl_ciphers=HIGH

I am getting gnutls specific errors in my Tornado webserver while processing Google OpenID SSL responses. One of the suggestions I got from Tornado mailing list is to try OpenSSL backend instead of gnutls. But it doesn't seem to be straightforward on Ubuntu server (11.10).

On Ubuntu server, gnutls is provided by libcurl3-gnutls package and openssl curl support is provided by libcurl4-openssl-dev package. (I don't know why the later is named 4 and dev, but I couldn't find any other openssl+curl package in apt-cache search).

I had libcurl3-gnutls installed by default, but not libcurl4-openssl-dev. So I installed the later and restarted Torando instances. But that didn't seem to work. I still got same gnutls errors.

I found old discussions on curl mailing lists regarding the problems of supporting different SSL backends to libcurl, but didn't find exactly how is it done today. So far my guess is openssl is built into libcurl and gnutls is provided through separate package (that will explain why there is no libcurl3-openssl). But how do I make libcurl to pick up openssl backend and not gnutls? Is there some option in libcurl/pycurl API to do this?

I tried uninstalling libcurl3-gnutls, but apt-get prompted that it will also remove python-pycurl along with it. So that won't do.