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

Deprecating Non-Secure HTTP

blog.mozilla.org

Post reply on HN
Print view View original

131–140 of 318 posts

Re: Deprecating Non-Secure HTTP

#131

Post by Touche »

vortico wrote: post #44
skybrian wrote: post #31

If things like "python -m SimpleHttpServer" don't work then developers will switch browsers. I don't think anyone is seriously considering what it will take to migrate the long tail of development tools that use HTTP on localhost.

And what about testing small applications on remote servers like "dev.my-personal-site.com"? I don't want to pay $15 for an SSL certificate and 15 minutes of my time just so I can get my dumb lunch break tetris HTML app running on the machine I SSH into from my tablet.

Google and Mozilla do not care about this use case. Full stop. Do. Not. Care.

Re: Deprecating Non-Secure HTTP

#132

Post by icebraining »

joshmn wrote: post #33
UnoriginalGuy wrote: post #7

I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…

I can imagine a lot of personal sites will suffer from this. With most, they're sitting on something like Eleven2 or Dreamhost, who requires a dedicated IP for an SSL certificate, which the user then has to buy and figure out for himself (it's not trivial for the average "webmaster"), or buy the certificate from their host which is marked-up plenty. Yes, the hosts could wildcard. Yes, there are other solutions out th…

Charging ~$5/month/dedicated IP is a nice upsell

It's only an upsell now. If in the future SSL is required to get access, it stops being an upsell and starts having to be part of the basic package. Whether that will raise prices significantly is yet to be seen.

Re: Deprecating Non-Secure HTTP

#133

Post by vbezhenar »

nosefrog wrote: post #22

I should be happy about this -- who wouldn't want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?). If SSL doesn't change, this move will cut the li…

I always wondered why does this certificate order matter? Web server can (and does) parse certificates. It should reorder them in correct order and log warnings if any issues were found.

Re: Deprecating Non-Secure HTTP

#134

Post by icebraining »

beeworker wrote: post #76
UnoriginalGuy wrote: post #7

I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment. Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page? That has the following advantages: - HTTP remains fully working for internal/developmen…

While we're making art style changes, why don't we change the experience for self-signed certs? When the user first visits an HTTPS page with a self-signed cert, they get the content, and the URL art style has a broken lock or something warning it's not known to be secure. (It's better than raw HTTP but it's not trusted.) With certificate pinning by the browser, the next time the user visits that page, if it's differ…

So if I have to renew my (self-signed) certificate, all my current users will now get scary warnings? I'm not sure we should be encouraging people to hold on to their possibly-compromised certs.

Re: Deprecating Non-Secure HTTP

#136

Post by icebraining »

peteretep wrote: post #79
kazinator wrote: post #47

This is stupid. There are all kinds of use cases where you don't care who knows what you're looking at, or whether it is authentic. Say I navigate to some restaurant's web page using HTTP. Even if I used HTTPS, someone spying on my traffic would know what I'm reading, if the IP address is a dedicated server for that web site only. Whether I use HTTP or HTTPS, they could infer that I'm interested in visiting the resta…

> Even if I used HTTPS, someone spying on my traffic would > know what I'm reading, if the IP address is a dedicated > server for that web site only How would they know the IP is a dedicated server for that website only, rather than simply a default?

Since the SSL negotiation happens before the HTTP request, either there's only one certificate for that IP or you need to use SNI, which reveals the domain you're requesting.

You could have multiple domains in the certificate to avoid identification, but that has its own problems.

Re: Deprecating Non-Secure HTTP

#137

Post by pfg »

schoen wrote: post #120
undefined0 wrote: post #63

Earlier quoted context omitted.

LetsEncrypt works with IPv4. I assume it will work with IPv6. LetsEncrypt is a Mozilla project, it's safe to assume they will launch LetsEncrypt before deprecating non-secure websites.

Right now the subject identifier in a Let's Encrypt cert must be a DNS name, not an IP address. From the ACME protocol specification draft: "Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers. For example, all of the identifier validation challenges describ…

This is in line with other CAs - no certificates should be issued for IP addresses or internal server names with expiry dates after November 2015. See for example: https://www.digicert.com/internal-names.htm

Re: Deprecating Non-Secure HTTP

#138

Post by wampus »

bashinator wrote: post #58
nosefrog wrote: post #22

I should be happy about this -- who wouldn't want the entire web to be encrypted -- but SSL is so broken for normal people. SSL is expensive (wildcard certificates run $70 a year and up), confusing (how does one pick between the 200 different companies selling certificates?), and incredibly difficult to set up (what order should I cat the certificate pieces in again?). If SSL doesn't change, this move will cut the li…

As an aside, I really don't like wildcard certs. If the private key is compromised, the consequences are so much worse than if you lose a regular cert.

That's true if you're trying to save money by putting a ton of domains behind a single wildcard cert using a single private key. But there are security advantages to using multiple wildcard certs based on different private keys. One of them is that you can develop a nearly infinite number of sites without exposing the domain name via the certificate, so they can't be crawled or pentested until they are deployed publicly. The number of certs you buy should be based on the number of private keys you can securely deploy.

Re: Deprecating Non-Secure HTTP

#139

Post by tjohns »

girvo wrote: post #122
derefr wrote: post #89

Earlier quoted context omitted.

I am long past confused and heading toward awed, at this point, that it's not a common-sense practice for every web developer to generate a personal self-signed root-CA cert, and install it on all of their machines. It's as basic as having an SSH or PGP key. Setting up a new box? Put your CA-cert in its trust roots. Then use your CA to generate a server cert for it; plop that in /etc/nginx and wherever else. Now it's…

Honest question, say you follow this (which is what I did a while ago for my OwnCloud instance) -- is it possible to install your self-signed certificate on iOS? Because that was the problem I ran into, and ended up moving to a "real" certificate, but I would've been happy to remain self-signed given the option.

Yes. Just email the self-signed certificate to yourself, then open it up on the iOS device. You can also create a personal CA and install it the same way, if you plan on connecting to more than one host.

A quick search turned up some more instructions here: https://blog.httpwatch.com/2013/12/12/five-tips-for-using-se...

Re: Deprecating Non-Secure HTTP

#140

Post by sfilipov »

teraflop wrote: post #87
beeworker wrote: post #76

Earlier quoted context omitted.

While we're making art style changes, why don't we change the experience for self-signed certs? When the user first visits an HTTPS page with a self-signed cert, they get the content, and the URL art style has a broken lock or something warning it's not known to be secure. (It's better than raw HTTP but it's not trusted.) With certificate pinning by the browser, the next time the user visits that page, if it's differ…

Not a bad idea, in theory, but... suppose I visit a site on Monday and see certificate A. Then when I return on Tuesday, I see a different certificate B. What reason is there to think that A is likely to be the "true" certificate, and B isn't? Showing a big scary warning in one case, and not in the user, implies to the user that the browser has some reason to think one is more secure, which is misleading.

You could use some website which you connect to securely (CA signed) which fetches and displays fingerprint C. You can then compare it to A and B and the one which matches C is the "true" one.

Of course the whole thing can be automated by the browser and happen behind the scene - i.e. Firefox connecting to a Mozilla service for each self signed website it sees and comparing the fingerprints. Then it can store information about this self-signed certificate as trusted.

Post reply on HN