4 ms·

He makes a 'technically correct' case for fully qualified domain names, but I'm not sure this a real problem. Under what circumstances are things really improve

He makes a 'technically correct' case for fully qualified domain names, but I'm not sure this a real problem. Under what circumstances are things really improved by using them? If your DNS server is untrustworthy, this doesn't help. If your DNS server is trustworthy, do fully qualified domain names help you? There's almost nothing on the web about 'Common Internet Scheme'. [0] Also, it's a little ironic that we're reading a page on spoofing, from a site which doesn't support HTTPS. [0] https://www.google.com/search?q="Common+Internet+Scheme" https://www.google.com/search?q="Common+Internet+Scheme"

thefounder 7y ago
>> Also, it's a little ironic that we're reading a page on spoofing, from a site which doesn't support HTTPS. Let's encrypt didn't exist in 2004.
- micheljansen 7y ago
  But HTTPS did. You just had to pay to get a certificate.
  - doublerabbit 7y ago
    You had to pay a fair bit of money back then for SSL. And why does a static html site need https? I’m all for encryption but we just HTTPS things pointlessly. Why can’t I use my own self-signed certificate, it’s the same thing.
    - joeraut 7y ago
      HTTPS everywhere has other advantages, such as preventing ISPs from injecting scripts or content into HTTP pages. [0] [0] https://news.ycombinator.com/item?id=21389657 https://news.ycombinator.com/item?id=21389657
    - metafunctor 7y ago
      Because without HTTPS, the content can be modified in transit. Some free Wi-Fi access points and evil ISPs, for example, will inject ads and trackers.
    - msh 7y ago
      There is a good explanation of why your static site need ssl here: https://youtu.be/_BNIkw4Ao9w https://youtu.be/_BNIkw4Ao9w
    - MaxBarraclough 7y ago
      HTTPS should be used even for static sites. 1. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [0]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [1]. 2. As someone here already mentioned, it prevents ads/trackers/malware being injected into the page by unscrupulous ISPs (this really has happened [2]) 3. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad. 4. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though. 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just two reasons: firstly, reduced admin overhead not having to bother with certs, and secondly, it enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3] > Why can’t I use my own self-signed certificate, it’s the same thing. It is not. I don't think you understand the role of CAs. Self-signed certs do not provide protection against connecting to an impersonator. [0] https://www.theguardian.com/us-news/2016/jan/13/us-library-records-purged-data-privacy https://www.theguardian.com/us-news/2016/jan/13/us-library-r... [1] https://arstechnica.com/information-technology/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/ https://arstechnica.com/information-technology/2015/04/it-wa... [2] https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ [3] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/
      - doublerabbit 7y ago
        I’ll agree to disagree, because otherwise the conversation would be moot. I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. A medical site is different to a static html site like listed in the post. ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application. “run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.
    - micheljansen 7y ago
      You could get one for under $10/y which is not what I’d call a fair bit of money. I think the problem with HTTPS/SSL was that it tried to solve two problems at once (trust and encryption) without a practical way to separate them. You can argue that’s justified (what’s the point knowing the connection is encrypted if you don’t know who is on the other side), but those panicky browser alerts made self signed SSL certificates all but useless. That’s why we need letsencrypt now.
  - thefounder 7y ago
    Even with let's encrypt it still seems odd to me that you need a 3rd party to confirm you own a domain name(and issue a certificate for it). The web trust model is broken.
throw0101a 7y ago
> Under what circumstances are things really improved by using them? Not necessarily "improved", but it could add to predictability. A lot of places probably use(d) "dev" as an internal sub-domain, and then ICANN went and approved Google's .dev TLD: * https://en.wikipedia.org/wiki/.dev https://en.wikipedia.org/wiki/.dev * https://www.iana.org/domains/root/db/dev.html https://www.iana.org/domains/root/db/dev.html Also, Google's .prod: * http://www.iana.org/domains/root/db/prod.html http://www.iana.org/domains/root/db/prod.html * https://icannwiki.org/.prod https://icannwiki.org/.prod
- bityard 7y ago
  A similar thing happened where I work. Say our domain name was `example.com`, we had a fleet of hosts at `foo.build.example.com`, `bar.build.example.com`. The internal network handed out `example.com` as the DNS search string but web browsers always try the FQDN first. On the day the `.build` gTLD went live, people who use short names in their URLs (just about everyone) could no longer access these hosts and I was the one who got to figure out why.
  - bluejekyll 7y ago
    When creating test domains these RFCs should be followed: https://tools.ietf.org/html/rfc6761 https://tools.ietf.org/html/rfc6761 Which updated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606 Basically, there are only a few reserved TLDs, .example.[com.|org.|net.], .test., .invalid., and .localhost. (rfc2606). RFC6761 clarifies how each should be used.
    - Sylamore 7y ago
      His issue wasn't the domain they used becoming a TLD, his issue was a subdomain they used became a TLD and the DNS resolvers of his clients were not configured to append the parent domain first, probably the search list wasn't populated.
      - bluejekyll 7y ago
Jaruzel 7y ago
> ..but I'm not sure this a real problem If you are inside a large corporate network, that spans the globe and has many internal domain names, and a lot of DNS forwarding, it's a very real problem. Especially when trying to debug inconsistent name resolution.

thefounder 7y ago

>> Also, it's a little ironic that we're reading a page on spoofing, from a site which doesn't support HTTPS. Let's encrypt didn't exist in 2004.

micheljansen 7y ago
But HTTPS did. You just had to pay to get a certificate.
- doublerabbit 7y ago
  You had to pay a fair bit of money back then for SSL. And why does a static html site need https? I’m all for encryption but we just HTTPS things pointlessly. Why can’t I use my own self-signed certificate, it’s the same thing.
  - joeraut 7y ago
    HTTPS everywhere has other advantages, such as preventing ISPs from injecting scripts or content into HTTP pages. [0] [0] https://news.ycombinator.com/item?id=21389657 https://news.ycombinator.com/item?id=21389657
  - metafunctor 7y ago
    Because without HTTPS, the content can be modified in transit. Some free Wi-Fi access points and evil ISPs, for example, will inject ads and trackers.
  - msh 7y ago
    There is a good explanation of why your static site need ssl here: https://youtu.be/_BNIkw4Ao9w https://youtu.be/_BNIkw4Ao9w
  - MaxBarraclough 7y ago
    HTTPS should be used even for static sites. 1. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [0]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [1]. 2. As someone here already mentioned, it prevents ads/trackers/malware being injected into the page by unscrupulous ISPs (this really has happened [2]) 3. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad. 4. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though. 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just two reasons: firstly, reduced admin overhead not having to bother with certs, and secondly, it enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3] > Why can’t I use my own self-signed certificate, it’s the same thing. It is not. I don't think you understand the role of CAs. Self-signed certs do not provide protection against connecting to an impersonator. [0] https://www.theguardian.com/us-news/2016/jan/13/us-library-records-purged-data-privacy https://www.theguardian.com/us-news/2016/jan/13/us-library-r... [1] https://arstechnica.com/information-technology/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/ https://arstechnica.com/information-technology/2015/04/it-wa... [2] https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ [3] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/
    - doublerabbit 7y ago
      I’ll agree to disagree, because otherwise the conversation would be moot. I just disagree that we should “HTTPS” everything and that’s partly because of the overhead. A medical site is different to a static html site like listed in the post. ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not. And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application. “run acme encryptbot” no thanks. When I want a pure server with nothing other than my application I don’t want to download a certificate bot, install (lang) and let it mess with my configuration. I don’t dismiss that HTTPS is important but I feel platform is flawed. Owned by corporate greed. It’s security based upon pay us money or else model.
  - micheljansen 7y ago
    You could get one for under $10/y which is not what I’d call a fair bit of money. I think the problem with HTTPS/SSL was that it tried to solve two problems at once (trust and encryption) without a practical way to separate them. You can argue that’s justified (what’s the point knowing the connection is encrypted if you don’t know who is on the other side), but those panicky browser alerts made self signed SSL certificates all but useless. That’s why we need letsencrypt now.
- thefounder 7y ago
  Even with let's encrypt it still seems odd to me that you need a 3rd party to confirm you own a domain name(and issue a certificate for it). The web trust model is broken.

throw0101a 7y ago

> Under what circumstances are things really improved by using them? Not necessarily "improved", but it could add to predictability. A lot of places probably use(d) "dev" as an internal sub-domain, and then ICANN went and approved Google's .dev TLD: * https://en.wikipedia.org/wiki/.dev https://en.wikipedia.org/wiki/.dev * https://www.iana.org/domains/root/db/dev.html https://www.iana.org/domains/root/db/dev.html Also, Google's .prod: * http://www.iana.org/domains/root/db/prod.html http://www.iana.org/domains/root/db/prod.html * https://icannwiki.org/.prod https://icannwiki.org/.prod

bityard 7y ago
A similar thing happened where I work. Say our domain name was `example.com`, we had a fleet of hosts at `foo.build.example.com`, `bar.build.example.com`. The internal network handed out `example.com` as the DNS search string but web browsers always try the FQDN first. On the day the `.build` gTLD went live, people who use short names in their URLs (just about everyone) could no longer access these hosts and I was the one who got to figure out why.
- bluejekyll 7y ago
  When creating test domains these RFCs should be followed: https://tools.ietf.org/html/rfc6761 https://tools.ietf.org/html/rfc6761 Which updated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606 Basically, there are only a few reserved TLDs, .example.[com.|org.|net.], .test., .invalid., and .localhost. (rfc2606). RFC6761 clarifies how each should be used.
  - Sylamore 7y ago
    His issue wasn't the domain they used becoming a TLD, his issue was a subdomain they used became a TLD and the DNS resolvers of his clients were not configured to append the parent domain first, probably the search list wasn't populated.
    - bluejekyll 7y ago

Jaruzel 7y ago

> ..but I'm not sure this a real problem If you are inside a large corporate network, that spans the globe and has many internal domain names, and a lot of DNS forwarding, it's a very real problem. Especially when trying to debug inconsistent name resolution.