Freeze break request: allow https with ask.fedoraproject.org

[Toshio Kuratomi]

On Mon, Oct 29, 2012 at 12:24:35PM -0600, Kevin Fenzi wrote:
> We have a request at: 
> https://fedorahosted.org/fedora-infrastructure/ticket/3535
> to allow https for ask.fedoraproject.org. 
> 
> This is a pretty simple change: 
> 
> diff --git a/manifests/services/proxy.pp b/manifests/services/proxy.pp
> index df0a733..af80b44 100644
> --- a/manifests/services/proxy.pp
> +++ b/manifests/services/proxy.pp
> @@ -351,7 +351,9 @@ class proxy {
>      httpd::website { "ask.fedoraproject.org":
>          ips            => $wildcard_fpo_ips,
>          server_aliases => [ "ask.stg.fedoraproject.org" ],
> -        ssl            => false,
> +        ssl            => true,
> +        cert_name      => "wildcard.fedoraproject.org",
> +        sSLCertificateChainFile => "wildcard.fedoraproject.org.intermediate.cert",
>      }
>  
>      httpd::website { "darkserver.fedoraproject.org":
> 
> Any +1's? Or should we just wait until after freeze?
> 
I think that there's a potential for sniffing of the session cookie that an
authenticated user has once they'e logged into ask.fp.o here.  If an attacker
sniffs the session cookie they can probably use that cookie to ask and
answer questions as that user.

With that in mind, I think we should force https on ask.fp.o.

+1 to that for several reasons:

1) security issue -- restricted to only ask.fp.o; won't compromise other
   services directly
2) while the change occurs on the proxy server, the change there is minimal.
3) ask.fp.o itself lives on its own servers and isn't critical to the
   release.
4) beta hasn't gone gold yet so there's still a potential to slip.  Better
   to get this done now while release is at minimum a week away than to get
   into the week-by-week portion of this freeze.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20121029/55c61dec/attachment.sig>