Google如何在其.app TLD上强制使用HTTPS? [英] How does Google force HTTPS on their .app TLD?

查看:143
本文介绍了Google如何在其.app TLD上强制使用HTTPS?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在I / O 2018中,Google宣布了新的.app TLD,他们表示这将仅是HTTPS。



我认为DNS只是将域名映射到IP 。



它们如何强制HTTPS?

解决方案

(有点

这称为HSTS预加载,请参见 https:// hstspreload .org /



HSTS(HTTP严格传输安全性)是服务器回复客户端的一种方式:请仅通过HTTPS与我联系(请参阅 https://www.troyhunt.com/the-6-step-happy -path-to-https / 作为示例)。它可以增强安全性,但仍然不能解决一个问题:与给定服务器的第一次连接可以通过HTTP进行,然后浏览器才知道它应该执行HTTPS。



因此



基本上,这是所有主要浏览器代码
中都包含的硬编码列表(请参见 https://caniuse.com/#feat=stricttransportsecurity 以获得兼容性,具体取决于浏览器和版本,或者参见底部的代码链接[1] ),指出哪些域/ TLD启用了HSTS,这意味着根本不允许HTTP连接。



请注意:


  1. 任何人都可以按照一些要求将名称提交到此列表,请参见 https ://hstspreload.org/#submission-requirements

  2. Google(因为它始于Chrome,但现在在浏览器中广泛传播rs)欢迎包括顶级域名(TLD)而不只是主机名,请参见文档结尾,网址为 https://hstspreload.org/ ( TLD预加载)

他们过去确实已经添加了 .DEV ( TLD本身还没有发布,但是Google会很快发布它),这打破了许多开发人员的设置,他们错误地使用了 .DEV 域名来命名他们的域名。本地资源,并且在使用更新的HSTS预加载列表更新浏览器后,他们拒绝连接到没有HTTPS的本地 .DEV 主机。您可以在这里和其他地方找到(例如: https:/ /ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ )许多关于开发人员的恐怖故事对此表示反对,也可能有人为此提供不好的解决方案(例如禁用HSTS预加载,这是一个非常糟糕的主意。)



此外,当您购买 .APP 域名(以及对于 .DEV ),Google(作为 .APP 的注册表)将与所有注册服务商签订合同,确保他们在结帐 .APP 域名的过程中,将显示一条突出的消息,内容如下: .APP是安全的TLD,网站仅适用于SSL证书(原文如此);确保购买SSL证书(SSL证书是直出谷歌文档,这是很可悲的阅读它们的出,因为它是错上加错名词,它应该是一个 X.509认证类别,或者为了不吓anyone任何人,至少是用于TLS通信的证书,如今,没有人应该再使用SSL ...)。



方式, .APP 于5月8日以标准价格向公众开放。



当然,所有这些都是仅与网页浏览有关。您可以在 .APP 域名之上设置任何其他类型的服务,例如电子邮件,而无需任何强制性的TLS(如今,这当然不是一个好主意,但是什么也没有。会避免您这样做)。对于电子邮件,目前正在进行有关基本上具有HSTS的讨论,但对于MTA,请参见 https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/



[1]参见一些带有HSTS预加载列表:





或者您可以在< a href = https://hstspreload.com/ rel = noreferrer> https://hstspreload.com/ 了解名称是否在列表中


In I/O 2018 Google announced their new .app TLD and they said that it will be HTTPS only.

I thought that DNS just maps domain names to IP's.

How are they forcing HTTPS?

解决方案

(a little offtopic here)

It is called HSTS Preloading, see https://hstspreload.org/

HSTS (HTTP Strict Transport Security) is a way for servers to reply to clients: please contact me over HTTPS only (see https://www.troyhunt.com/the-6-step-happy-path-to-https/ for examples). It enhances security but still does not solve one case: the first connection to a given server can happen over HTTP before the browser learns it should have done an HTTPS instead.

Hence come the "preloading" of HSTS.

Basically this is an hardcoded list embarked in all major browsers code (see https://caniuse.com/#feat=stricttransportsecurity for compatibility depending on browser and version, or see at bottom for links to code[1]) that says which domains/TLD are HSTS enabled, which means no HTTP connection allowed to them at all.

Note that:

  1. Anyone can submit names to this list by following some requirements, see https://hstspreload.org/#submission-requirements
  2. Google (as it started with Chrome but it is now spread among browsers) welcome inclusion of TLDs and not only hostnames, see end of document at https://hstspreload.org/ ("TLD Preloading")

They already did add .DEV in the past (the TLD by itself is not live yet, but Google will launch it "soon") which broke many developers setup where they used (wrongly) a .DEV domain name to name their local resources and as soon as their browsers were updated with the newer HSTS preloading list, they refused to connect to their local .DEV host without HTTPS. You can find here and elsewhere (ex: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) many horror stories of developers up in arms against that and also may people offering bad solutions for that (like disabling HSTS preloading which is a very bad idea).

Also when you buy a .APP domain name (and it will be same for .DEV), Google (as registry of .APP) made sure contractually with all registrars that they will, during checkout of a .APP domain name buy, display a prominent message saying something along the line of: ".APP is a secure TLD and websites will only work with an SSL certificate(sic); make sure to buy an SSL certificate" (SSL certificate is straight out of Google documentation and this is very sad to read out of them since it is a doubly wrong term, it should have been an "X.509 certificate" or, in order not to frighten anyone, at least a "certificate used for TLS communications", noone should use SSL anymore nowadays...).

By the way, .APP opened for the public at standard prices yesterday, May 8th.

Of course all of that is only related to web browsing. You could set any other kind of service, like email, on top of a .APP domain name, without any mandatory TLS (which of course is not a good idea nowadays but nothing will refrain you from doing that). For email, there is ongoing discussion to have basically HSTS but for MTAs, see https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

[1] see some source codes with the HSTS preloading list:

or you can use the API at https://hstspreload.com/ to learn if a name is on the list

这篇关于Google如何在其.app TLD上强制使用HTTPS?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆