[llvm-dev] [SERVER UPDATE] Moving clang, clang-analyzer, libcxxabi, libcxx ... websites to new server
Stephen Checkoway via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 13 13:13:04 PST 2017
> 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
More information about the llvm-dev
mailing list