HTTPS suggestion

[Ubi]

Yep, a very nice solution indeed.
But it still gives Explorer errors. (Explorer Errors) + (clueless users) -> Increased Helpdesk requests -> reduced time for Excito crew to answer questions on *this* forum.

[Gordon]

Okay, I can fix that.

Try this for content in `index.php`

Code: Select all

<?php
  $clientIP=$_SERVER["REMOTE_ADDR"];
  $IProute=explode(" ",exec("ip route get ".$clientIP."|grep \"".$clientIP."\" 2>&1"));
  $device=$IProute[2];
  $prefix=($device=="eth0")?"https://".$_SERVER["HTTP_HOST"]:"";
  header("location: $prefix/admin");
?>

[Eek]

Well Excito could fix that by becoming a trusted root CA.
Should not be such a problem if you look at the list of current root CA.

Could also give them extra revenue

[Cheeseboy]

It is actually quite ridiculous how HTTPS works.
Who decides what root CA certificates are trusted by default in your browser? How much kickbacks do verisign and thawte pay the browser manufacturers for this privilege?

I use cacert.org, which means users will have to download the root certificate or add a security exception.

[Ubi]

Indeed.
And it wouldn't be so ridiculous if they actually took effort to verify that you are who you claim you are on the certificate. People managed to get perfectly valid microsoft.com SSL certs a while back. Basically all these bozos do is run a single text command and bill you 20 bucks.

[Gordon]

You can easily create your own root certificate. It's not any different from a regular certificate. The only issue with using certificates is that the server name and the URL you are using to access the page must match to stop your browser from complaining (in case of Internet Explorer I'd like to refer to this as whining though, because of the lack of options to ignore).

Essentially this means that if you have registered to a (dynamic) DNS service to find your B3 from any place on the net, your certificate should reflect this DNS name and you should also use this outside name when you're inside your own LAN environment. There is a workaround, which involves making the webserver listen on alternate TCP ports and use portforwarding rules in your firewall. I guess that would have to go into the advanced-advanced section of the wiki though

[Cheeseboy]

Here is the thing though:
If I create an account for my mother and I want her to use SSL, I would have to go to her home and configure her browser for her.

This is not cool. The whole "trusted" business must change. cacert.org are doing a good job of it.
People are actually travelling all over the place, showing their ID cards or passports to each other in order to try to build up some sort of trust network. We need this kind of work. The web should be able to be secure (by default) even for non-commercial entities

[Ubi]

Although I agree with your point, your analogy goes a bit limp when you consider that passports too have a limited number of trusted certificate issuers (i.e governments). Would you trust a self-signed passport from a made-up "country"?

[Cheeseboy]

Nope
But I would trust one from a normal country.
More than I would one resulting from a monetary transaction with a company that have decided that they have a monopoly on certificates...

EDIT:
And it is not an analogy. People are actually doing what I described in order to get their certificates verified.

[Ubi]

butbutbut
getting a passport is also a monetary transaction with an institution that has decided (generally through wars no less!) that they have a monopoly on issuing passports. There's actually more choice on root CAs then there are on passport issuing authorities!

[Cheeseboy]

true
But still... You get the general idea...

[Eek]

For those who want to do it themselves: http://wiki.excito.org/wiki/index.php/Be_your_own_CA

[Gordon]

For those who want to do it themselves: http://wiki.excito.org/wiki/index.php/Be_your_own_CA

Good show

A word of caution though: do NOT enter passwords while creating the server certificate. If you do, you'll be asked to enter it each time apache starts. Come to think of it, having a password protected certificate may even cause the B3 to halt the boot process while indefinitly waiting for someone to enter that password.

Since these certificates are meant for private use, there's no sense in creating time limited certificates. Just set days for the CA at 7300 (i.e. 20 years) and the server certificate at 3650 (i.e. 10 years). Or just go crazy if you think the B3 might have a longer lifespan, but remember that the CA must always outlive the server certificate.

Place a copy of the public part of the CA (myca.crt) on a location that is accessible through normal http.

[Eek]

that is a good addition,
I was doubting to put that in or not.
will add your comments to the wiki

[Gordon]

I took a closer look at the wiki and I think something is missing there. I don't see the CA being included in the apache server config, so this would lead to an invalid certificate path. Did you test this?