Your message dated Sat, 4 Feb 2017 22:40:44 +0100
with message-id <[email protected]>
and subject line Re: Bug#298613: TLS fails if the virtual host is setup to 
listen on 0.0.0.0
has caused the Debian Bug report #298613,
regarding TLS fails if the virtual host is setup to listen on 0.0.0.0
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
298613: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298613
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: proftpd
Version: 1.2.10-10
Severity: important

Hi!

I discovered today that the tls setup of my server had stopped to work, I
don't use it much, so I cannot tell on wich version this broke, but I know
why it doesn't work.

The thing is that I'm running this in a machine with dynamic IP and thus I
have setup the virtual host on which I want to run the TLS setup this way:

<VirtualHost 0.0.0.0>
Port 990
TLSEngine on
TLSRequired control
...

This used to work ok, however it doesn't right now, on the other hand, if I
change the 0.0.0.0 with the IP that the interface has at that moment, it
works ok.

I don't know if this was intentional, to avoid people using 0.0.0.0, but
some of us have the need to listen on 0.0.0.0 for TLS connections as we
don't know the IP that the interface may have at a given time.

This is a simple test one can do to find out this:

manty@rut:~$ telnet 80.103.205.104 990
Trying 80.103.205.104...
Connected to 80.103.205.104.
Escape character is '^]'.
220 ProFTPD 1.2.10 Server (Debian) [80.103.205.104]
AUTH TLS
500 AUTH not understood
quit
221 Goodbye.
Connection closed by foreign host.

The correct answer to the AUTH TLS command should be 234 AUTH TLS successful
which I get if I set up the 80.103.205.104 (my current IP) instead of the
0.0.0.0 one that I have set up and that I'd like to keep.

If you need any more info about the setup or something, just tell me.

Regards!

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i586)
Kernel: Linux 2.4.29
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages proftpd depends on:
ii  adduser                     3.63         Add and remove users and groups
ii  debconf                     1.4.30.11    Debian configuration management sy
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libcap1                     1:1.10-14    support for getting/setting POSIX.
ii  libpam0g                    0.76-22      Pluggable Authentication Modules l
ii  libssl0.9.7                 0.9.7e-2     SSL shared libraries
ii  libwrap0                    7.6.dbs-6    Wietse Venema's TCP wrappers libra
ii  netbase                     4.20         Basic TCP/IP networking system
ii  proftpd-common              1.2.10-10    Versatile, virtual-hosting FTP dae
ii  ucf                         1.14         Update Configuration File: preserv

-- debconf information:
* shared/proftpd/warning:
* shared/proftpd/inetd_or_standalone: standalone


--- End Message ---
--- Begin Message ---
Version: 1.3.3-1

On 08.03.05 Santiago Garcia Mantinan ([email protected]) wrote:

Hi Santiago,

> I discovered today that the tls setup of my server had stopped to work, I
> don't use it much, so I cannot tell on wich version this broke, but I know
> why it doesn't work.
> 
> The thing is that I'm running this in a machine with dynamic IP and thus I
> have setup the virtual host on which I want to run the TLS setup this way:
> 
> <VirtualHost 0.0.0.0>
> Port 990
> TLSEngine on
> TLSRequired control
> ...
> 

I noticed today that upstream has fixed this long time ago:

http://bugs.proftpd.org/show_bug.cgi?id=2680
Bug 2680 - Add support for <VirtualHost 0.0.0.0>.

> This used to work ok, however it doesn't right now, on the other hand, if I
> change the 0.0.0.0 with the IP that the interface has at that moment, it
> works ok.
> 
> I don't know if this was intentional, to avoid people using 0.0.0.0, but
> some of us have the need to listen on 0.0.0.0 for TLS connections as we
> don't know the IP that the interface may have at a given time.
> 
> This is a simple test one can do to find out this:
> 
> manty@rut:~$ telnet 80.103.205.104 990
> Trying 80.103.205.104...
> Connected to 80.103.205.104.
> Escape character is '^]'.
> 220 ProFTPD 1.2.10 Server (Debian) [80.103.205.104]
> AUTH TLS
> 500 AUTH not understood
> quit
> 221 Goodbye.
> Connection closed by foreign host.
> 
> The correct answer to the AUTH TLS command should be 234 AUTH TLS successful
> which I get if I set up the 80.103.205.104 (my current IP) instead of the
> 0.0.0.0 one that I have set up and that I'd like to keep.
> 
> If you need any more info about the setup or something, just tell me.
> 

Attachment: signature.asc
Description: Digital signature


--- End Message ---

Reply via email to