[v2] WebUI: print more information on used nameservers

Message ID 20170908195822.6af0659b.peter.mueller@link38.eu
State New
Headers show
Series
  • [v2] WebUI: print more information on used nameservers
Related show

Commit Message

Peter Müller Sept. 8, 2017, 5:58 p.m.
Show rDNS/PTR entry and country flag of the used nameservers on the
nameserver status list at "netexternal.cgi".

These information might be useful for debugging, or are just "nice to
have" and do not harm anything. :-)

Changes since v1: Corrected file link to country.cgi and added title to flag.
Please disregard the first version of this patch.

Signed-off-by: Peter Müller <peter.mueller@link38.eu>
---

Comments

Matthias Fischer Sept. 9, 2017, 10:37 a.m. | #1
Hi,

On 08.09.2017 19:58, Peter Müller wrote:
> ...
> Please disregard the first version of this patch.
> ...

You can do this on your own:

E.g.: Log in to http://patchwork.ipfire.org/project/ipfire/list/, mark
http://patchwork.ipfire.org/patch/1414/ as "superseded" (bottom of page:
'Change state' to anything you like) and apply changes.

HTH,
Matthias
Peter Müller Sept. 12, 2017, 4:38 a.m. | #2
Hello Matthias,

thanks for the reply and the link to patchwork.

I did not use it since the login page transmits credentials
in plain text, and HTTPS seems to be broken on that page.

When you enter https://patchwork.ipfire.org/, there is a
CA warning and then the server redirects to http://www.ipfire.org/.
Strange. :-)

But I would be happy to mark the patch obsolete on my own,
since it saves time and effort for the developers.

Best regards,
Peter Müller

> Hi,
> 
> On 08.09.2017 19:58, Peter Müller wrote:
> > ...
> > Please disregard the first version of this patch.
> > ...  
> 
> You can do this on your own:
> 
> E.g.: Log in to http://patchwork.ipfire.org/project/ipfire/list/, mark
> http://patchwork.ipfire.org/patch/1414/ as "superseded" (bottom of page:
> 'Change state' to anything you like) and apply changes.
> 
> HTH,
> Matthias
Matthias Fischer Sept. 12, 2017, 4:26 p.m. | #3
Hi Peter,

On 12.09.2017 06:38, Peter Müller wrote:
> thanks for the reply and the link to patchwork.

You're welcome... ;-)

> I did not use it since the login page transmits credentials
> in plain text, and HTTPS seems to be broken on that page.

Confirmed. While writing to you, I used
http://patchwork.ipfire.org/project/ipfire/list/. This worked.

> When you enter https://patchwork.ipfire.org/, there is a
> CA warning and then the server redirects to http://www.ipfire.org/.
> Strange. :-)

As I wrote: confirmed.

> But I would be happy to mark the patch obsolete on my own,
> since it saves time and effort for the developers.

Could someone of these please take a look at this?

Best,
Matthias
Michael Tremer Sept. 14, 2017, 8:41 p.m. | #4
Hi,

On Tue, 2017-09-12 at 18:26 +0200, Matthias Fischer wrote:
> Hi Peter,
> 
> On 12.09.2017 06:38, Peter Müller wrote:
> > thanks for the reply and the link to patchwork.
> 
> You're welcome... ;-)
> 
> > I did not use it since the login page transmits credentials
> > in plain text, and HTTPS seems to be broken on that page.
> 
> Confirmed. While writing to you, I used
> http://patchwork.ipfire.org/project/ipfire/list/. This worked.
> 
> > When you enter https://patchwork.ipfire.org/, there is a
> > CA warning and then the server redirects to http://www.ipfire.org/.
> > Strange. :-)
> 
> As I wrote: confirmed.
> 
> > But I would be happy to mark the patch obsolete on my own,
> > since it saves time and effort for the developers.
> 
> Could someone of these please take a look at this?

You mean moving this to HTTPS? Yes. I have that on my list.

Unfortunately I am still not a huge fan of Let's Encrypt. So anyone in
favour or against using our own CA?

Best,
-Michael

> 
> Best,
> Matthias
Matthias Fischer Sept. 15, 2017, 3:05 p.m. | #5
Hi Michael,

On 14.09.2017 22:41, Michael Tremer wrote:
> Hi,
> 
> On Tue, 2017-09-12 at 18:26 +0200, Matthias Fischer wrote:
>> Hi Peter,
>> 
>> On 12.09.2017 06:38, Peter Müller wrote:
>> ...

>> ...

>> Could someone of these please take a look at this?
> 
> You mean moving this to HTTPS? Yes. I have that on my list.
> 
> Unfortunately I am still not a huge fan of Let's Encrypt. So anyone in
> favour or against using our own CA?

No. ;-)

> Best,
> -Michael
> 
>> 

Best,
Matthias
Peter Müller Sept. 15, 2017, 8:26 p.m. | #6
Hello Michael, hello Matthias,

a few thoughts on this from me:

(1) @Michael: Thank you for having a look at this. In
my opinion, enabling HTTPS on all *.ipfire.org sites by
default would be a huge security benefit.

Of course, this needs time and testing, so no pressure. :-)

Especially on download sites HTTPS would be nice in
case someone verifies the downloaded ISO - when transmitted
in plaintext, both image and checksum might be modified
by a MITM.

Further, there is still SHA1 in use on http://download.ipfire.org/,
but that is another issue.

(2) Speaking about the CAs: I do not know what opinion
to have here.

On the one hand, using your own project CA is good since
nobody except the visitors has to rely on some external
certificate signing company.

Publishing the TLSA-records tells everyone that this CA -
which is untrusted by all current browsers - is legitimate
on *.ipfire.org.

On the other hand, there are two points against it:
(a) Nobody actually uses TLSA/DANE for validating web site
certificates (this is different when it comes to SMTP). So,
nearly every user will see a certificate warning.

Personally, i suppose DANE will never be implemented in
web browsers. There are too many collisions with the systems
DNS service, and network stacks, and the network's firewall
rules, and so on. Sad, but that is what we (do not) have.

So, enabling HTTPS on all or at least some very important
IPFire sites will cause more user complaints.

Further, and that is a _very_ big problem in my eyes, it
actually decreases transport encryption security: Every time
a user accesses *.ipfire.org, he/she/it has to bypass a
certificate warning - at least in FF, there is no easy way
to store the exception permanently.

In case a MITM injects his own certificate to break TLS,
the user will see a certificate warning which is nearly
identical to those shown usually for IPFire's CA. And the
user will mostly bypass this - very well-known - warning,
an the attacker won.

To prevent this, you MUST check the certificates checksum
against the value you know is legitimate. Every time.

Nobody will do so.

(b) As I mentioned above, I completely understand your point
having an own CA. However, I do not think this is so important
for public web services:

As far as I am concerned, there is no "trust" in case of CA
companies. Some of them showed a really unprofessional behaviour
(DigiNotar, WoSign, Symantec, ...) and are/were either kicked
off business by their customers or the web browser developers.

You only "trust" a CA to validate if a certain domain really
belongs to the person who claims so.

In case there is a certificate in use signed by a foreign CA,
what should happen? Nobody except the server admin has the
private key, and there are many techniques to prevent modern
browsers accepting any certificate for your domain, such as:
- DANE/TLSA (specifies which certificate [chain] is valid)
- CAA (DNS record, rather new, specifies which CAs can issue
certificates for this site, might be supported by common browsers
some day)
- HSTS (preventing a MITM from downgrading to plaintext)
- HPKP (as DANE, but supported by modern browsers, TOFU
[Trust On First Use] = first connection must be clean)

Except from going out of business, I do not see any risk for
a web site owner here. That is, in case all or some of the
mentioned methods are implemented.

Let's Encrypt (LE) seems to be different from other CAs since
they use standardised methods and act quite transparently.
Further, there are some "major players" behind it (Mozilla,
EFF, ...) which have a good reputation. This - hopefully -
means that there will be no security breaches like in case
of DigiNotar.

To come to an end, using LE as a CA for *.ipfire.org will
not harm the security of IPFire significantly. It reduces
browser alerts and a possible security threat (see above),
making it easier to deploy HTTPS.

Needless to say, DANE/HSTS/CAA are obligatory.

Best regards,
Peter Müller
Matthias Fischer Sept. 17, 2017, 7:39 a.m. | #7
Hi,

Working on some 'cosmetics', I would suggest to add a few
"align="center=" (Looks somehow better - please see below):

On 08.09.2017 19:58, Peter Müller wrote:
> Show rDNS/PTR entry and country flag of the used nameservers on the
> nameserver status list at "netexternal.cgi".
> 
> These information might be useful for debugging, or are just "nice to
> have" and do not harm anything. :-)
> 
> Changes since v1: Corrected file link to country.cgi and added title to flag.
> Please disregard the first version of this patch.
> 
> Signed-off-by: Peter Müller <peter.mueller@link38.eu>
> ---
> diff --git a/html/cgi-bin/netexternal.cgi b/html/cgi-bin/netexternal.cgi
> index 299612d4c..6fe0cc7d6 100644
> --- a/html/cgi-bin/netexternal.cgi
> +++ b/html/cgi-bin/netexternal.cgi
> @@ -25,9 +25,13 @@ use strict;
>  #use warnings;
>  #use CGI::Carp 'fatalsToBrowser';
>  
> +use IO::Socket;
> +use Geo::IP::PurePerl;
> +
>  require '/var/ipfire/general-functions.pl';
>  require "${General::swroot}/lang.pl";
>  require "${General::swroot}/header.pl";
> +require "${General::swroot}/geoip-functions.pl";
>  require "${General::swroot}/graphs.pl";
>  
>  my %color = ();
> @@ -99,6 +103,12 @@ if ( $querry[0] ne~ ""){
>  						<strong>$Lang::tr{'nameserver'}</strong>
>  					</th>
>  					<th align="center">
> +						<strong>$Lang::tr{'flag'}</strong>
> +					</th>
> +					<th align="center">
> +						<strong>$Lang::tr{'rdns'}</strong>
> +					</th>
> +					<th align="center">
>  						<strong>$Lang::tr{'status'}</strong>
>  					</th>
>  				</tr>
> @@ -139,9 +149,22 @@ END
>  
>  		my $table_colour = ($id++ % 2) ? $color{'color22'} : $color{'color20'};
>  
> +		# Get rDNS entry for nameserver (might be useful)
> +		my $iaddr = inet_aton($nameserver);
> +		my $rdns = gethostbyaddr($iaddr, AF_INET);
> +	        if (!$rdns) { $rdns = $Lang::tr{'lookup failed'}; }
> +		
> +		# Get country flag for the nameserver (might be useful)
> +		my $gi = Geo::IP::PurePerl->new();
> +	        my $ccode = $gi->country_code_by_name($nameserver);
> +       		my $fcode = lc($ccode);
> +	        my $flag_icon = &GeoIP::get_flag_icon($fcode);
> +
>  		print <<END;
>  			<tr bgcolor="$table_colour">
>  				<td>$nameserver</td>

Changed to: <td align="center">$nameserver</td>

> +				<td align="center"><a href="country.cgi#$fcode"><img src="$flag_icon" border="0" align="absmiddle" alt="$ccode" title="$ccode"></a></td>	
> +				<td>$rdns</td>

Changed to: <td align="center">$rdns</td>

>  				<td bgcolor="$bgcolour" align="center">
>  					<font color="$colour"><strong>$message</strong></font>
>  				</td>
> ...
...

Jm2C! ;-)

Best,
Matthias

Patch

diff --git a/html/cgi-bin/netexternal.cgi b/html/cgi-bin/netexternal.cgi
index 299612d4c..6fe0cc7d6 100644
--- a/html/cgi-bin/netexternal.cgi
+++ b/html/cgi-bin/netexternal.cgi
@@ -25,9 +25,13 @@  use strict;
 #use warnings;
 #use CGI::Carp 'fatalsToBrowser';
 
+use IO::Socket;
+use Geo::IP::PurePerl;
+
 require '/var/ipfire/general-functions.pl';
 require "${General::swroot}/lang.pl";
 require "${General::swroot}/header.pl";
+require "${General::swroot}/geoip-functions.pl";
 require "${General::swroot}/graphs.pl";
 
 my %color = ();
@@ -99,6 +103,12 @@  if ( $querry[0] ne~ ""){
 						<strong>$Lang::tr{'nameserver'}</strong>
 					</th>
 					<th align="center">
+						<strong>$Lang::tr{'flag'}</strong>
+					</th>
+					<th align="center">
+						<strong>$Lang::tr{'rdns'}</strong>
+					</th>
+					<th align="center">
 						<strong>$Lang::tr{'status'}</strong>
 					</th>
 				</tr>
@@ -139,9 +149,22 @@  END
 
 		my $table_colour = ($id++ % 2) ? $color{'color22'} : $color{'color20'};
 
+		# Get rDNS entry for nameserver (might be useful)
+		my $iaddr = inet_aton($nameserver);
+		my $rdns = gethostbyaddr($iaddr, AF_INET);
+	        if (!$rdns) { $rdns = $Lang::tr{'lookup failed'}; }
+		
+		# Get country flag for the nameserver (might be useful)
+		my $gi = Geo::IP::PurePerl->new();
+	        my $ccode = $gi->country_code_by_name($nameserver);
+       		my $fcode = lc($ccode);
+	        my $flag_icon = &GeoIP::get_flag_icon($fcode);
+
 		print <<END;
 			<tr bgcolor="$table_colour">
 				<td>$nameserver</td>
+				<td align="center"><a href="country.cgi#$fcode"><img src="$flag_icon" border="0" align="absmiddle" alt="$ccode" title="$ccode"></a></td>	
+				<td>$rdns</td>
 				<td bgcolor="$bgcolour" align="center">
 					<font color="$colour"><strong>$message</strong></font>
 				</td>
@@ -271,3 +294,4 @@  sub check_dnssec($$) {
 
 	return $aware + $validating;
 }
+
diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl
index 0138cbc02..a63eb3160 100644
--- a/langs/de/cgi-bin/de.pl
+++ b/langs/de/cgi-bin/de.pl
@@ -1902,6 +1902,7 @@ 
 'quick playlist' => 'Quick Playlist',
 'ram' => 'RAM-Speicher',
 'random number generator daemon' => 'Random Number Generator Daemon',
+'rdns' => 'rDNS',
 'read bytes' => 'Gelesene Bytes',
 'read list' => 'Liste der Leseberechtigten',
 'real address' => 'Reale Addresse',
diff --git a/langs/en/cgi-bin/en.pl b/langs/en/cgi-bin/en.pl
index b3aee5a2b..13c18f4c8 100644
--- a/langs/en/cgi-bin/en.pl
+++ b/langs/en/cgi-bin/en.pl
@@ -1936,6 +1936,7 @@ 
 'quick playlist' => 'Quick Playlist',
 'ram' => 'RAM',
 'random number generator daemon' => 'Random Number Generator Daemon',
+'rdns' => 'rDNS',
 'read bytes' => 'Read Bytes',
 'read list' => 'list with readonly hosts',
 'real address' => 'Real Address',