And this is why projects like caddyserver, traefik, and similar tools are simply broken by default, e.g.:

https://github.com/caddyserver/caddy/issues/1632

nginx, btw, does automatically support FQDNs for all your virtual hosts, as does apache.

I get the following error when I add a dot at the end of the address for a virtual host in Apache:

Misdirected Request

The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

Apache/2.4.25 (Debian) Server at example.com Port 443

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"

> 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.

But HTTPS did. You just had to pay to get a certificate.

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.

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-r...

[1] https://arstechnica.com/information-technology/2015/04/it-wa...

[2] https://doesmysiteneedhttps.com/

[3] https://whydoesaptnotusehttps.com/

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.

the overhead

The computational overhead is negligible. This simply isn't a credible argument against HTTPS.

Netflix send petabytes of data over HTTPS. There's no excuse for anyone else.

A medical site is different to a static html site like listed in the post.

Different in degree, but not in category. Your browsing habits on ordinary non-sensitive sites can still be used to profile you.

ISP regardless of SSL know which sites I’m visiting

They can still look at the destination IP, yes, and they can probably look at your DNS requests, as secure DNS is currently only rarely used. It's still worth doing. Knowing that someone went on Wikipedia tells you almost nothing. Knowing the specific pages they went to, tells you a great deal.

It’s there in the HTTP host header regardless of SSL or not.

That's not the case. HTTPS encrypts all headers.

transit security can easily be encrypted without SSL

The easy solution is HTTPS.

people are too lazy to encrypt their content within the application.

A universal principle in cyber-security: rolling your own crypto scheme is generally a terrible idea. As I said, Steam and Apt are the exceptions; they use plain HTTP for delivery, and implement secure file verification using hashes. Even here, with competent people running a simple delivery scheme, there can be serious security issues [0].

When it comes to web applications, you cannot implement your own secure delivery, for the obvious reason: an attacker can just replace your code. Sites like LastPass.com still have to use HTTPS to deliver the web app.

Even if it could be done, there would be no reason to. The browser offers you HTTPS, so you get a carefully designed, battle-tested protocol, and a carefully designed, battle-tested implementation. You are entirely shielded from all the complexities. You aren't going to do better in JavaScript.

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.

It's additional configuration work, yes, but I don't accept that it's much of an argument against HTTPs. You still have totally free choice over your tooling and languages.

I don’t dismiss that HTTPS is important but I feel platform is flawed.

You've not presented a single good argument against the technical merits of HTTPS.

Owned by corporate greed. It’s security based upon pay us money or else model.

You can get certs for free. This isn't new. [1]

[0] https://justi.cz/security/2019/01/22/apt-rce.html

[1] https://en.wikipedia.org/wiki/Let%27s_Encrypt

Netflix send petabytes of data over HTTPS. There's no excuse for anyone else.

Uhh, yes, indeed... manufacturing cars is so cheap these days, even General Motors can do it...

That's not the case. HTTPS encrypts all headers.

That's not the case. HTTP uses SNI (for now): https://en.wikipedia.org/wiki/Server_Name_Indication

As I stated I will agree to disagree. I have my own views based on my own experiences as you have yours. This ain’t new to me.

Security is always number one. I wasn’t trying to pitch “these are good arguments”. I am expressing my own, whether right or wrong, secure or insecure. No successful hacking attempts so far on my watch.

Everyone feels so safe using HTTPS but when it cracks we are going to be screwed. let’s not forget about HeartBleed and all the others.

What’s stops a corporation/CA from revoking a certificate because you threaten their business?

It’s moot.

I wouldn’t touch let’s encrypt with a barge poll. If I want a SSL i’d rather fork out in a paid cert as at least there is insurance behind.

When google can create their own CA authority how is that secure? Look at google certs, they’ve planted their own global root cert in your OS without you even approving it.

HTTPS is lazy, might be easy but poor mans security. But to end this debate some is better then none.

You are grossly misinformed on this subject.

I just disagree that we should “HTTPS” everything and that’s partly because of the overhead.

The overhead in any modern CPU is negligible. If you're worried about negligible overhead then why are you using an entire operating system to serve up web pages?

ISP regardless of SSL know which sites I’m visiting. It’s there in the HTTP host header regardless of SSL or not.

The host header is encrypted over HTTPS. Furthermore, SSL isn't used in 2019 as it's insecure and was replaced with TLS. That might be pedantic but it seems to align with what this post is about so I'll mention it.

You're confusing the host header with the server name indication sent in the client hello. There is a huge difference between my ISP knowing I went to example.com (with TLS) or example.com/medical/how_to_deal_with_cancer.html (without HTTPS)

And transit security can easily be encrypted without SSL but people are too lazy to encrypt their content within the application.

I'm not sure what you're suggesting here. The industry standard transport security for HTTP is TLS. Trying to re-invent the wheel is counterproductive and dangerous.

“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.

Then don't. The specification for the acme protocol is open and available to you. You could automate the entire process and even choose a DNS based challenge. Typical use of cerbot, should you choose to use it, does not "mess with your 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.

It literally isn't because Let's Encrypt gives out certs for free. Additionally, so does AWS, Azure, and GCP. If you're paying for a certificate you're doing it wrong.

You have always been free to use self-signed certificates, but then the challenge of convincing your visitors that your certificate really is from you and not someone else who created a self-signed certificate becomes your problem to manage.

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://www.iana.org/domains/root/db/dev.html

Also, Google's .prod:

* http://www.iana.org/domains/root/db/prod.html

* https://icannwiki.org/.prod

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.

When creating test domains these RFCs should be followed: https://tools.ietf.org/html/rfc6761

Which updated: 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.

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.

Well congratulations, you're blocked by my adblocker because of that dot (uBlock Origin with EasyList Liste FR)

Why would that list be blocking fully qualified domain names? Seems more like a bug than a feature, but if there is a good reason for it I'd be interested to learn

I find it wonderful that a link to a page talking about stripping a trailing period from a domain has been linked to with descriptive text from which the trailing period has been stripped from the domain

An interesting effect is http://jdebp.info/ displays “not secure” in the browser and http://jdebp.info./ does not.

I feel dumber for having read this article. Tbf it’s from the early 2000s but it reads like a nasally academic trying to lecture people who work for a living about theory with little to no practical benefit.

Glad to see that http://pn/ and http://pn./ are both apparently working.

I'm pretty sure that at one point I had to supply the trailing dot to make the browser (or resolver) believe it was a real hostname.

What is the deal with that?

Yeah, how does that work?

I'd guess it's the TLD of the Pitcairn Islands set to resolve to this random page. For example

    http://ca. 

resolves to the Canadian domain registrar.

How perplexing that it works at all! I want to know how that works.

It’s just a TLD that actually resolves; Most don’t. For example, http://com./ doesn’t resolve even though it has “subdomains”.

This does though beg the question: can a second level domain (root website) have (what we call) subdomains and not resolve itself? For example, example.example.com would resolve, but example.com wouldn’t?

When I click on the first link in iOS Safari I get sent to a search results page served by my (read: my parents’) ISP. That’s pretty disturbing.

The second link appears to work. It’s a page that says “It works!” but it’s not HTTPS so of course I have no way of knowing whether that’s the ISP playing tricks as well. ;)

Why is that disturbing? For me, the name doesn't resolve (http://pn/).

Assuming you are using your parents' ISP's default DNS servers, isn't it a safe, though less-than-desirable, result for the ISP to forward you to a search page when resolution fails?