Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing .app, a more secure home for apps on the web

blog.google

Post reply on HN
Print view View original

21–30 of 378 posts

Re: Introducing .app, a more secure home for apps on the web

#21

Post by CydeWeys »

snarfy wrote: post #20
chatmasta wrote: post #8

If it’s not clear from the article, HTTPS is required for all .app domains, which Google accomplished by adding the .app TLD to the default chrome HSTS preload list. Interestingly that will only ensure HTTPS only when using a browser with HSTS enabled with a preload list that includes the .app TLD. Therefore non-web code, or code in browsers without the TLD in the HSTS preload list, will be able to make HTTP requests…

How does that work in say, Firefox?

The HSTS preload list is built into Firefox too (like all major browsers), and automatically rewrites any affected http URLs to https before issuing any requests over the network.

Re: Introducing .app, a more secure home for apps on the web

#22

Post by ovao »

eganist wrote: post #15

Moves like this intrigue me. On the one hand, I support creating new platforms with security built-in by default, but on the flip side, the Chrome team just axed HPKP without even so much as bothering to try to refine it to mitigate the footguns. I don't understand how the web-facing security decisions at Google are made. :/

There are motivating reasons for that[0]. The Expect-CT header is its replacement, and is getting picked up by recent versions of Chrome.

[0]: https://scotthelme.co.uk/im-giving-up-on-hpkp/

Re: Introducing .app, a more secure home for apps on the web

#23

Post by detaro »

snarfy wrote: post #20
chatmasta wrote: post #8

If it’s not clear from the article, HTTPS is required for all .app domains, which Google accomplished by adding the .app TLD to the default chrome HSTS preload list. Interestingly that will only ensure HTTPS only when using a browser with HSTS enabled with a preload list that includes the .app TLD. Therefore non-web code, or code in browsers without the TLD in the HSTS preload list, will be able to make HTTP requests…

How does that work in say, Firefox?

Exactly the same, the preload list data is public and used by all the major browsers.

Re: Introducing .app, a more secure home for apps on the web

#25

Post by chatmasta »

detaro wrote: post #23
snarfy wrote: post #20

Earlier quoted context omitted.

How does that work in say, Firefox?

Exactly the same, the preload list data is public and used by all the major browsers.

What is the "single source of truth" for the HSTS preload list? It must be on a server somewhere... who runs the server? Which browsers use this list by default?

Re: Introducing .app, a more secure home for apps on the web

#27

Post by toomuchtodo »

CydeWeys wrote: post #19
dmurray wrote: post #4

> The big difference is that HTTPS is required to connect to all .app websites...Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way. This sounds good but how does it really help users or developers compared to having a .com website that uses HTTPS? Expecting that users will think "oh, .app, must be sec…

Tech lead of Google Registry here. I can help answer some questions. HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.c…

What are your thoughts on HSTS for a TLD when a CA can then revoke a site’s cert, preventing access entirely (See: Comodo and Sci-Hub).

Re: Introducing .app, a more secure home for apps on the web

#30

Post by CydeWeys »

toomuchtodo wrote: post #27
CydeWeys wrote: post #19

Earlier quoted context omitted.

Tech lead of Google Registry here. I can help answer some questions. HSTS preloading offers the highest possible level of security, as the user's browser is enforcing the use of HTTPS. Merely serving via HTTPS is only optional security, as any man-in-the-middle attacker can strip that encryption (see sslstrip, released six years ago). For more information see my blog post from last year: https://security.googleblog.c…

What are your thoughts on HSTS for a TLD when a CA can then revoke a site’s cert, preventing access entirely (See: Comodo and Sci-Hub).

You can always get a new SSL certificate from someone else quite easily (e.g. Let's Encrypt). So that's a temporary problem at worst.
Post reply on HN