Hacker News Reader

Comment by brodo | Hacker News Reader

While I can understand the concerns about added complexity, he won‘t be able to keep this up forever. Browsers will deprecate plain HTTP sooner or later.

View on HN

I certainly hope not. Blogs like this will help stop browsers from doing dumb things like deprecating HTTP where appropriate.

I highly doubt that blogs like this will make the slightest impact on those decisions.

There’s this thing called a “long tail” that the Internet was designed to make really large and powerful.

If everyone had their own simple blog (or plan file) instead of Facebook/etc, I think the world would be a better place.

Yeah, I empathize but he's really not reading current trends at all if he thinks HTTP is still going to be around in 3 years.

I can't wait for the pure hell that is captive WiFi once browsers provide sufficient friction to accessing non-HTTPS sites. Most devices are good enough at popping up the portal but far too often I find myself pulling up http://neverssl.com to force things to start working.

It's only a matter of time until captive WiFi networks will force you to install their root certificate or app if you want to use their services.

Captive wifi is basically dead already, anyone who thinks they are providing a service by running it is mistaken. It's been busted due to https for years now. It's also almost always some sort of pointless CYA wifi license agreement.

Haha, want to put a bet on those 3 years? :D

HTTP is here to stay. Maybe browsers on PCs will make accessing it extra hard, though I suspect that's untrue as well (maybe POSTing data to HTTP web sites will be harder in that people will see extra pop-ups).

But sites which have lived as HTTP forever are not going to magically get some maintenance done on them to move to HTTPS, and people will still visit those web sites.

And let's talk about all those crazy cheapo IoT devices that are already spreading through the world that have their "http" servers hard-coded.

Don't get me wrong, I've been on the HTTPS bandwagon since forever (before LetsEncrypt, the best deal you could get for multi-domain personal webpage certs was StartSSL, an Isreali company with very buggy software that you had to fight to get a cert issued). And I've long (decades?) advocated that browsers should first try an HTTPS page when protocol-less URL is given (which they are only now moving to, duh?).

At some point, for everyday users, the amount of friction and bright red will just mean that they move on to another site. What popular site isn't using HTTPS?

But I'm not even talking about desktop browsers, here. It'll start with mobile devices. iOS and Android going HTTPS only with their default browsers is entirely within the realm of reason. Flash was functionally dead once Android gave up on it within a few years. Yes, there was a long tail of enterprise users and people who refused to give it up.

Similarly, there will be a very long tail of HTTP. But Apple and Google are in a position to kill it just like they did Flash.

I am not so sure of the "everyday users": we are all conditioned to click through a bunch of "warnings" (cookie consent anyone?), that you'd really have to make it bordering on unusable for people to not simply click-through.

Even with mobile devices, I imagine another cycle is coming where people care more about what their seemigly-general-purpose computers restrict them from doing.

But I'd still wager that it ain't happening in the next 3 years.

Which would be wrong, unless they start accepting self-certificates. You should not need third party certificate provider to be able to run simple webpage. You should not need to pay them money and should not need to jump through their administrative hoops.

I think it would be acceptable if it's automated at the DNS level. You need to have a trust hierarchy anyway to resolve a name, so you can piggyback the same trust hierarchy to encrypt and secure all communications.

In the fee paid for the domain name, the owner should get perpetual free secure DNS and certificates for any purpose and sub-domain.

The current issuance of (non-EV) certificates is an unsecure hack over DNS anyway[1], so why not merge certificate issuance at the protocol level?

[1] https://en.wikipedia.org/wiki/Domain-validated_certificate

I do agree in principle regarding trust level, and regarding pricing.

But that can quickly become impractical. I run a bunch of small personal web sites (different domains) on a single IP, which a certificate is tied to (since HTTP "Host" negotiation only happens after the encrypted connection is established). I think there were changes to allow this negotiation to happen before encryption, but that loses some privacy.

I also use a couple of registrars, so coming up with a solution to this existing complexity is extra hard. Maybe with IPv6 where I can cheaply use a bunch of fixed IPs instead.

Yes, there is vhost negotiation happening in TLS before session is setup, and the webserver selects the apropriate certificate. The loss of privacy is minimal, since without this system you would be forced to use one IP per TLS host (or disable TLS), and DNS binding those IPs to websites are public.

For the second concern, it can be in principle automated to the point where you only need to inform the webserver of its hostname(s). If the DNS A records are correctly configured, it's trivial for the DNS server to verify the IP address and sign the CRL generated by the webserver on the fly. Like a letsencrypt operated by your DNS provider that simply works.

They do accept self-signed certificates. The challenge is you need to distribute the root CA and have your end users set them up on their OS as trusted.

If you aren’t using some centralized platform like LetsEncrypt, you’re lacking that layer of known trust that is required with the SSL system. It is not a trustless system.

Would that completely prevent an off-line device or local LAN basted host from providing a web interface? (without first manually adding a cert on the users machine?)

>Browsers will deprecate plain HTTP sooner or later.

This is a stupid idea, it means the browsers will not be compatible with old websites, if they drop http I hope they would first drop all the other old stuff that are bad and no longer cool.

A big warning should be enough, old websites should still work in a competent browser.

> if they drop http I hope they would first drop all the other old stuff that are bad and no longer cool.

They have been doing this. Gopher, FTP, XUL extensions, NPAPI browser plugins, old TLS versions, for examples in the last few years, and alert()/confirm()/prompt() for Chrome's current push.

Getting rid of notifications would be much nicer than getting rid of http.

That is not part of https or html , they also removed RSS , i know some big ego dude wants to add to his CV that he killed http buit I think he should maybe create something more useful(like make sure we can css styule the elements scrollbars so designers won't force me to install a JS library because the scrollbars look like shit and can't customize them to look fine on all browsers or to be more objective see what is the most popular workaround that is used and implement that native (maybe is the calendar, or a better color picker, or native support for modals - run the numbers and not implement stuff thazt only look good on your CV)

Worth noting that at the same time, "they" weren't good enough at pushing new things that the same time. For example, all new compression methods work only over HTTPS (actually, this alone can be a reason to switch to HTTPS) - because they were incompatible with some HTTP proxies: https://bugs.chromium.org/p/chromium/issues/detail?id=14801

<rant> I'm actually looking forward for them to drop HTTP digest auth, because it's the only auth scheme which doesn't rely on sending shared secret over the wire with each request </rant>

Reply on news.ycombinator.com