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

TLS Everywhere, not https: URIs (2015)

w3.org

Post reply on HN
Print view View original

71–80 of 94 posts

Re: TLS Everywhere, not https: URIs (2015)

#71

Post by c3833174 »

zAy0LfpBZLC8mAC wrote: post #20
colejohnson66 wrote: post #18

Earlier quoted context omitted.

There's probably a technical reason I'm unaware of, but why are you allowed to have HTTP and HTTPS handled differently (besides then encryption portion)?

That's just how it happened. And historically, it was common to put only the "important things" behind TLS. That never really made sense from a security perspective, but it certainly saved CPU cycles.

I don't really like when I'm not able to read the news because HTTPS didn't want to collaborate with an unreliable connection.

Re: TLS Everywhere, not https: URIs (2015)

#72

Post by posterboy »

btrask wrote: post #16

Users/user agents need to know whether to expect a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably tell you. If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic. If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Incidentally, this is the same problem as public key distribution. You nee…

Hen and Egg, where do you get the secure browser from?

Re: TLS Everywhere, not https: URIs (2015)

#73

Post by Tepix »

posterboy wrote: post #72
btrask wrote: post #16

Users/user agents need to know whether to expect a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably tell you. If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic. If I can get you to use HTTPS when you should've used HTTP, it might be a DoS. Incidentally, this is the same problem as public key distribution. You nee…

Hen and Egg, where do you get the secure browser from?

It's bundled with your OS. If you don't like the bundled one you can use it to download a different one using HTTPS.

Re: TLS Everywhere, not https: URIs (2015)

#74

Post by IshKebab »

vtsingaras wrote: post #40

The problem with opportunistic TLS is that while it protects from wide-scale DPI it doesn't protect against MITM. Personally I think that the effort that would be put to implementing opportunistic TLS in all web servers and browsers would be better put to migrating all web applications to HTTPS only.

Agreed, and MitM is arguably a bigger threat than DPI to most people, especially if you use coffee shop wifi, etc.

Re: TLS Everywhere, not https: URIs (2015)

#75

Post by geofft »

Matt3o12_ wrote: post #44
strcat wrote: post #15

Earlier quoted context omitted.

It's scaling well enough so far. A domain can be submitted at https://hstspreload.appspot.com/ and doesn't take long to show up in Chromium and then other browsers.

No it doesn't. You cannot preload every of the Internet, i event doubt you could load 5% of al domain names. With this approach we can have it for big sites, or important sites but we want it everywhere.

As of April, Let's Encrypt had issued 2 million certificates. Assuming that each domain is about 10 bytes long, that there's no compression (not even includeSubdomains=true, which is a conservative assumption because LE doesn't do wildcards), and that each domain is active, on the public internet, and wants HSTS, that's 20 megabytes of data. That's a lot of data, yes, but it's smaller than the Chrome or Firefox installer. Even if you account for other CAs, that's still the same order of magnitude as the browser itself. So it's not unreasonable for this data to be delivered as part of the initial browser download, and for updates to be delivered as part of browser automatic updates.

There's no sense in which you "cannot" preload every site with an SSL certificate. You absolutely can, and it would work totally fine. We can talk about whether there are better designs, but preloading everything is definitely a realistic option.

It's also an option that works today. If we figure out a better solution in the future (DNSSEC? Bloom filters and OCSP responders?), we can seamlessly transition the current preload list to it, but we're also getting the security advantage of the preload list immediately.

Re: TLS Everywhere, not https: URIs (2015)

#76

Post by cbr »

seandougall wrote: post #28
RubyPinch wrote: post #14

Earlier quoted context omitted.

I think its safe to say "it breaks the web" is from the user perspective, not the server. It only takes 1 server to serve differing content through each protocol to break things for the user

Yeah, but that's a subset of "misbehaving servers break the web" as far as I can tell. HTTPS doesn't inherently cause this problem, it just provides one theoretical nucleation point for it.

Serving different things on https and http is completely to spec, though. It's not really a server misbehaving.

(I do agree that it's contrary to expectations, but I'm sure this doesn't stop sites from relying on it.)

Re: TLS Everywhere, not https: URIs (2015)

#77

Post by drdaeman »

schallertd wrote: post #12

5-10 years and http:// will be as rare as having a lottery jackpot. our kids kids will ask - what is this http? like our kids did with floppy disks...

5 years? Don't see any chance for extinction.

There are tons of non-HTTPS websites out there. A myriad of forsaken ones that are still running because no one had remembered to do anything to them, and a myriad of ones whose sysadmins just don't care about TLS at all.

A non-obtrusive "insecure connection" warning is probably going to happen quite soon, but I just don't see any chance of mass HTTPS migration besides the high-profile sites, newborn sites and geeks that would stand for the cause.

Otherwise, a pretty large fraction of the WWW is going to be lost.

Re: TLS Everywhere, not https: URIs (2015)

#78

Post by falcolas »

XorNot wrote: post #64
continuational wrote: post #56

Earlier quoted context omitted.

It would still need to be encrypted, or I could tell a lot about what you're doing on the site by looking at what cacheable resources you fetch.

Not everything is about privacy, and arguably privacy advocates have done a lot to harm our ability to have a trusted internet by conflating verification, encryption and anonymity. The most annoying thing about HTTPS everywhere is that it ruins cacheability. This is a problem the distros solved ages ago by signing their content but acknowledging it's mostly pointless hiding it in transit. But its absurd that in HTTP2…

> arguably privacy advocates have done a lot to harm our ability to have a trusted internet

We don't have a trusted internet. Not when a country on the other side of the world can mis-configure BGP and re-route all traffic through them. Not when our ISPs intercept and modify our traffic. Not when there are nearly 10x as many "trusted" root certificates as there are nations in our world.

The internet is the wild west, and we need to protect our computers from it. Currently, encryption is our best bet for doing that. If edge caching is a casualty, then so be it.

If someone can come up with a method for protecting content from end-to-end while keeping it secure against tampering and eavesdropping (because this too matters, both to us in the first world and the majority of others who are not), then let's start getting it put in place.

Re: TLS Everywhere, not https: URIs (2015)

#79

Post by dmd »

Off topic, but I'm a native english speaker, and have never heard this construction before:

"There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west."

What does "and points west" mean here?

Re: TLS Everywhere, not https: URIs (2015)

#80

Post by nathanaldensr »

dmd wrote: post #79

Off topic, but I'm a native english speaker, and have never heard this construction before: "There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west." What does "and points west" mean here?

It's okay; I'm a native English speaker and I had trouble following much of Berners-Lee's grammar and writing style. He should consider editing the piece.

I have no idea what "and points west" means in this context.

Post reply on HN