Slashdot Mirror


Chrome To Force Domains Ending With Dev and Foo To HTTPS Via Preloaded HSTS (ttias.be)

Developer Mattias Geniar writes (condensed and edited for clarity): One of the next versions of Chrome is going to force all domains ending with .dev and .foo to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header. This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD:


This adds the following line to Chromium's preload lists:
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },

It forces any domain on the .dev gTLD to be HTTPs.

What should we [developers] do? With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else. There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.

7 of 220 comments (clear)

  1. Please see RFC6761 by mysidia · · Score: 4, Informative

    .invalid and .localhost are already reserved for private usage.

  2. .localhost TLD? by TheRealMindChild · · Score: 3, Informative

    And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds

    Cmon, we aren't talking some crazy complicated configuration here. DNSMasq: add "address=/localhost/127.0.0.1" to your config file. Boom. Done.

    --

    "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
  3. Re:Maybe...? by ArhcAngel · · Score: 3, Informative

    Might I suggest Waterfox? It's based on the current Firefox code but strips out the tracking and puts NPAPI plugins back. It runs on Windows, Mac, and Linux. No mobile version yet.

    --
    "A person is smart. People are dumb, panicky dangerous animals and you know it." - K
  4. Re:Maybe...? by fuzzyf · · Score: 3, Informative

    Http means anyone can inject BeEF hooks in your browser sitting at the local Starbucks. No matter how unimportant yyour content might be.

    http://beefproject.com/
    It's so easy you can do it with a phone using an app like dSploit.

    Http used to be ok, today every scriptkiddie has access to tools that will pwn any browser with a mitm attack.
    Also, any http security header you might add from your site is useless without https.

  5. The requirement to own and renew a domain by tepples · · Score: 3, Informative

    Web browsers require HTTPS server operators to obtain a fully-qualified domain name and a certificate from a certificate authority trusted by the browser publisher. Though Let's Encrypt makes certificates available without charge to domain owners, the domain itself still requires a recurring payment to a third party. The requirement to own a domain and keep it renewed imposes an extra $15 per year (source: Gandi.net) tax on running a server inside a home LAN.

    1. Re:The requirement to own and renew a domain by JohnFen · · Score: 3, Informative

      In a home LAN you can just use a self-signed certificate and add the cert to your browsers' trust stores.

      Yes, this.

      You can even, for complex home environments, run your own CA, install your own CA's cert and then use it to sign individual certs all day long without further hassle.

      The only reason you'd ever have to have a cert signed by a third party CA is if you want strangers to use your services and don't want to require them to install a special cert to do so.

  6. NOPE by cfalcon · · Score: 4, Informative

    Modded +5, Informative, but both of its statements are inaccurate. .localhost is reserved for 127.0.0.1 and no other thing. .invalid is reserved for NO use, it should never resolve.

    https://tools.ietf.org/html/rf...

    Localhost:
    Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

    Invalid:
    Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).

    Neither of these are meant for use on a local internet. .localhost is meant to resolve to loopback, and .invalid is meant to never resolve but instead give NXDOMAIN.

    Maybe there are domains reserved for private usage, but it ain't these two.