No HTTPS on nginx.org by default
maxim at nginx.com
Mon Aug 22 17:19:55 UTC 2016
On 8/22/16 8:15 PM, Richard Stanway wrote:
> Could you at least fix the https download page, so it doesn't
> directly link to a HTTP PGP key?
It works correctly: https://nginx.org/en/download.html
> On Mon, Aug 22, 2016 at 6:49 PM, Maxim Konovalov <maxim at nginx.com
> <mailto:maxim at nginx.com>> wrote:
> On 8/22/16 7:41 PM, B.R. wrote:
> > The problem is, if the GPG key is served through HTTP, there is no
> > way to authenticate it, since it could be compromised through
> > I am very surprised to see myself being qualified as 'HTTPS
> > when I just spot the obvious.
> But it does not -- our PGP key distributed through a number of
> channels, including HTTPS. Problem solved, case closed?
> > Compromised repository + GPG key is one very powerful way of
> > impersonating another product.
> > TLS provides both encryption and authentication, based on the
> > initial shared circle of trust.
> > Thus you certify the GPG key is authentic and thus, if it verifies
> > the binaries, you ensure the delivered package are produced by the
> > owner of the key, in the end the real author.
> > In 2016, stating that content served over HTTP is 'secure'
> blows my
> > mind and kills your credibility.
> Who did that? What's his name?
> > Now, as Richard pointed out, if you truly believe you need to
> > provide HTTP-only, you can. It would be better if it was in a very
> > visible fashion, though.
> > Where was despotism, again?
> nginx.org <http://nginx.org> already has HTTPS therefore it is
> not HTTP-only.
> > ---
> > *B. R.*
> > On Mon, Aug 22, 2016 at 5:40 PM, Richard Stanway
> > <r1ch+nginx at teamliquid.net <mailto:r1ch%2Bnginx at teamliquid.net>
> <mailto:r1ch+nginx at teamliquid.net
> <mailto:r1ch%2Bnginx at teamliquid.net>>> wrote:
> > 1. You could provide insecure.nginx.org <http://insecure.nginx.org>
> > <http://insecure.nginx.org> mirror for such people, make
> > nginx.org <http://nginx.org> <http://nginx.org> secure by
> > 2. Modern server CPUs are already extremely energy efficient,
> > TLS adds negligible load. See https://istlsfastyet.com/
> > On Mon, Aug 22, 2016 at 12:31 PM, Valentin V. Bartenev
> > <vbart at nginx.com <mailto:vbart at nginx.com> <mailto:vbart at nginx.com
> <mailto:vbart at nginx.com>>> wrote:
> > On Sunday 21 August 2016 15:56:09 B.R. wrote:
> > > It is surprising, since I remember Ilya Grigorik made a talk about TLS
> > > during the first ever nginx conf in 2014:
> > > https://www.youtube.com/watch?v=iHxD-G0YjiU
> > <https://www.youtube.com/watch?v=iHxD-G0YjiU
> > > https://istlsfastyet.com/
> > It's just Ilya's opinion. You are free to agree or not.
> > >
> > > Thus, there is no reason for not going full-HTTPS in delivering Web pages.
> > There are at least two reasons to not use HTTPS:
> > 1. Provide easy access to information for people, who can't
> > use encryption
> > by political, legal, or technical reasons.
> > 2. Don't waste resources on encryption, and thus save our
> > planet.
> > Please, don't be a TLS despot and let people to have a
> > choice to use encryption
> > or not.
> > I think the situation when I can't download new version of
> > OpenSSL using old
> > version of OpenSSL is ridiculous, but they have configured
> > openssl.org <http://openssl.org> <http://openssl.org>
> that way.
> > How I supposed to use Internet then?
> > wbr, Valentin V. Bartenev
> Maxim Konovalov
> Join us at nginx.conf, Sept. 7-9, Austin, TX:
> nginx mailing list
> nginx at nginx.org <mailto:nginx at nginx.org>
> nginx mailing list
> nginx at nginx.org
Join us at nginx.conf, Sept. 7-9, Austin, TX: http://nginx.com/nginxconf
More information about the nginx