[Systems] [Fwd: Re: Server Name Indication - Wikipedia, the free encyclopedia]

[Bernie Innocenti]

El Sun, 22-08-2010 a las 21:13 +0200, Sascha Silbe escribió:

> If you want to
> a) support most browsers, including IE < 7 / WinXP and

I had no idea SNI was already supported by almost all browsers.
I'll try setting a different certificate for the wiki and see what
happens.

> b) not get users scared by SSL warnings and
> c) not pay lots of money,

To me, it's not a matter of money--we're talking about $50/year for a
wildcard certificate, quite affordable. It's a matter of principle: I'd
rather not use my money to promote the SSL extortion lobby.


> then you need one IP address per virtual host you'd like to use SSL with.
> In combination with IPv4 address scarcity this means we can't offer SSL
> for most virtual hosts for all users.

We actually have a dozen free IPv4 addresses, but they're available to
treehouse, not sunjammer. The two machines are in the same network, but
firewall rules on the dom0 prevent sunjammer from using anything but its
own IP.


> So while we unfortunately can't use https for links to more than one
> (or a few) of our "outward facing" services, we can
> a) use it for our "internal" services (and tell our users to use
>    a browser that is SNI capable and/or includes the CAcert root
>    cert, like Iceweasel/Firefox or Browse, and

This is what we've been doing so far with the *.sugarlabs.org
certificate signed by CAcert.


> b) maybe even do an automatic upgrade to https if the User-Agent
>    indicates a browser version that should have SNI support. This
>    would especially be useful for password-based login pages (i.e.
>    wiki and Trac).

You mean an http redirect? Can Apache do this without employing
mod_perl?


> On a related note, would it be possible to get a single additional
> IPv4 address on sunjammer for SSO usage (see other thread)?

I could ask the the FSF to change the rules, but I'd rather not bother
them at this time because I'm behind on a bunch of work I'm supposed to
do for them :-)

Perhaps in October, when I'll be able to perform the change myself.


>  Unlike
> SNI, enabling client certificate requests on the server will have
> an impact on some browsers (pops up a certificate selection dialog)
> so we can't do it on the main https server. As many brain-dead
> firewalls block everything other than port 80 and 443, we can't just
> use a different port either.
> If we can't get another IPv4 address for sunjammer, we'd need to
> move Trac (and later the wiki) to housetree or treehouse (where we
> should have a spare IPv4 address AFAICT).

These are low-security services, I wouldn't bother to protect them
further with SSL. What would a potential eavesdropper do with my Trac
identity? Append angry comments to tickets in my name? I don't need any
help with this :-)

However, if we employ the wiki identity for CAS--which is exactly what
alsroot has been working on--the wiki password would start to become
quite serious: you could use it to build and distribute binary packages
in the name of someone else. In this case, I'd feel safer with SSL by
default.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/