llvm dev - Jan 2017 - [SERVER UPDATE] Moving clang, clang-analyzer, libcxxabi, libcxx ... websites to new server

> On Jan 13, 2017, at 12:35 PM, James Y Knight via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Thu, Jan 5, 2017 at 5:26 PM, Tanya Lattner via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Are you fixing the SSL problem?
> Yes. The new server will have SSL support for all websites and have an
updated certificate.
> 
> Is there any plan to make the migrated sites SSL-only? That is, have
http://clang.llvm.org/** <http://clang.llvm.org/**> only serve a redirect
to https://clang.llvm.org/** <https://clang.llvm.org/**> instead of
serving content over http.
> 
> If not, that'd be a great thing to add to the plans. :)
I’m curious: why?
I understand that you want anything authenticated (bugzilla, …) or the
binary/source download, but what’s the reason to use SSL for looking up doxygen
or LangRef? (Easier to setup or get it right could be a reason, I don’t know)

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170113/381a3694/attachment.html>

On Fri, Jan 13, 2017 at 3:47 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> On Jan 13, 2017, at 12:35 PM, James Y Knight via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Thu, Jan 5, 2017 at 5:26 PM, Tanya Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> *Are you fixing the SSL problem?*
>> Yes. The new server will have SSL support for all websites and have an
>> updated certificate.
>>
>
> Is there any plan to make the migrated sites SSL-only? That is, have
> http://clang.llvm.org/** only serve a redirect to
> https://clang.llvm.org/** instead of serving content over http.
>
> If not, that'd be a great thing to add to the plans. :)
>
>
> I’m curious: why?
> I understand that you want anything authenticated (bugzilla, …) or the
> binary/source download, but what’s the reason to use SSL for looking up
> doxygen or LangRef? (Easier to setup or get it right could be a reason, I
> don’t know)
>
Well, sure, that's one reason: it's much easier to ensure that
everything
that matters is properly protected, if you always protect everything. You
don't have to think about it anymore, and you won't mess up and
accidentally allow unencrypted binary downloads, which puts users at
unnecessary risk of tampering when they forget to explicitly type https.

Also: do you really want your site's visitors to be running the random
javascript that Comcast injects into it? Using https avoids that, too.

But beyond that: there's no downside. Why should *anyone* continue to serve
http traffic? It's just all around better and safer to require https, for
everything, always.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170113/4cb97bd9/attachment.html>

> On Jan 13, 2017, at 14:47, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> On Jan 13, 2017, at 12:35 PM, James Y Knight via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>> 
>> Is there any plan to make the migrated sites SSL-only? That is, have
http://clang.llvm.org/** only serve a redirect to https://clang.llvm.org/**
instead of serving content over http.
>> 
>> If not, that'd be a great thing to add to the plans. :)
> 
> I’m curious: why?
> I understand that you want anything authenticated (bugzilla, …) or the
binary/source download, but what’s the reason to use SSL for looking up doxygen
or LangRef? (Easier to setup or get it right could be a reason, I don’t know)
I think it's easier to simply enforce the redirect and have everything be
served over TLS. Once you do that, there's never any danger of parts that
require TLS not actually getting it.

E.g., in nginx, I've got

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name my.fqdn.here;
        return 301 https://$server_name$request_uri;
}

and then I know everything is using TLS. (It seems llvm.org is using apache, but
I imagine the apache directives are equally simple.) It seems significantly
easier to maintain than needing to serve different content using HTTP vs. HTTPS.

As an added benefit, every connection tests your TLS configuration meaning that
it's much easier to find problems such as expired certs. For example,
https://llvm.org is using a cert with SHA-1 which it absolutely should not be
doing in 2017. This shows up as insecure for me in Chrome.

(One can also make arguments about how all Internet traffic should be
authenticated at the least, but I think the pure engineering argument that
it's easier to just enforce it everywhere is the better argument.)

-- 
Stephen Checkoway

On Jan 13, 2017, at 3:13 PM, Stephen Checkoway via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> As an added benefit, every connection tests your TLS configuration meaning
that it's much easier to find problems such as expired certs. For example,
https://llvm.org is using a cert with SHA-1 which it absolutely should not be
doing in 2017. This shows up as insecure for me in Chrome.

This is one reason why blindly redirecting http to https is a bad idea.   Unless
you can be sure that everything everywhere is done correctly, you put clients
through extra pain for content that doesn’t need the extra protection.    (Note,
I’m not arguing for or against this particular change … only pointing out that
it isn’t free of consequences.)

Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170113/213e896d/attachment.html>

On Fri, Jan 13, 2017 at 04:07:48PM -0500, James Y Knight via llvm-dev
wrote:
> But beyond that: there's no downside. Why should *anyone* continue to
serve
> http traffic? It's just all around better and safer to require https,
for
> everything, always.
I take you haven't tried to use WiFi at UK airports or coaches recently?
There are a lot of other places with completely broken "transparent"
proxies and forcing HTTPS (especially in combination with HTST) makes
the network unusable.

Joerg