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

81–90 of 318 posts

Re: Deprecating Non-Secure HTTP

#81

Post by teraflop »

cdnsteve wrote: post #56

I have to say, I actually disagree with this move. While I think the intentions sound noble, and I'm all for a more secure web, I also believe that a web browser has no business dictating that the entire web should be forced in HTTPs. I don't see any benefit in this type of blanket, all or nothing, type of approach. In fact, I see it doing more damage than good. Encrypting blogs, news websites, etc still makes no sen…

HTTPS provides authentication, not just confidentiality.

When you visit "blogs, news websites, etc" do you think there's no value in being able to know for sure that the content is exactly what the owner of the site intended? Even though ISPs have proven themselves willing to intercept and modify that content in transit?

http://arstechnica.com/tech-policy/2013/04/07/how-a-banner-a...

http://arstechnica.com/tech-policy/2014/09/08/why-comcasts-j...

Re: Deprecating Non-Secure HTTP

#82

Post by manigandham »

tracker1 wrote: post #35
chimeracoder wrote: post #3

I'm very glad to see this. It's embarrassing to think that, just a few years ago, many major websites used HTTP for all but their login pages, and it took Firesheep to get them into gear. > For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”. For example, one definition of “new” could be “features that cannot be polyfilled”. I hope that inc…

It's worth bearing in mind that in the beginning, https was a significant CPU overhead... Since 2004 or so, much less of one. And since around 2010 CPU is rarely the bottleneck for web applications. I do find it interesting that someone starting out as a significant effort after 2010 would bother having a partially https site, with back and forth jumps for login. It seems to me like it's actually more work than just…

Amazon does this today, browsing is http.

Re: Deprecating Non-Secure HTTP

#83

Post by derefr »

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…

Or one of your browser tabs containing an HTTP-delivered page (any one, really) could arbitrarily be rewritten by the MITM to look the same at first, but carry some injected Javascript such that, a few minutes after it detects you've unfocused the page, it turns itself into a Gmail phishing site[1].

[1] http://www.azarask.in/blog/post/a-new-type-of-phishing-attac...

All that that attack requires, to be successful, is the ability for pages served over HTTP to run Javascript and submit forms.

Re: Deprecating Non-Secure HTTP

#84

Post by finnn »

nosefrog wrote: post #68
finnn wrote: post #60

Earlier quoted context omitted.

$70 for a wildcard cert!? Where are you looking at? There's a shitload of AlphaSSL resellers that are much cheaper. I got 2 wildcard certs for $20/yr. Of course, there's really no need for a wildcard certificate, and StartCom gives out free, valid non-wildcard certs right now . On top of that, Lets Encrypt should simplify the process greatly.

https://www.google.com/search?q=ssl+wildcard+certificate+che... I can't find anything lower than $60.

Offers like [1] are all over the web. I think i saw one for $7/yr once, but that disappeared.

[1] http://lowendtalk.com/discussion/39165/vmbox-co-openvz-ssd-c...

Re: Deprecating Non-Secure HTTP

#85

Post by typish »

Without a solution to everyone needing to pay for a certificate and identify themselves this seems a bit premature. Maybe browsers will relax the "This is an evil self signed certificate on the site" warning when they do it.

Re: Deprecating Non-Secure HTTP

#86

Post by finnn »

MichaelApproved wrote: post #72
finnn wrote: post #60

Earlier quoted context omitted.

$70 for a wildcard cert!? Where are you looking at? There's a shitload of AlphaSSL resellers that are much cheaper. I got 2 wildcard certs for $20/yr. Of course, there's really no need for a wildcard certificate, and StartCom gives out free, valid non-wildcard certs right now . On top of that, Lets Encrypt should simplify the process greatly.

People always tout StartCom as a free provider (which is really great) but they forget to mention that it's only free for personal use. StartCom offers the free (for personal use) Class 1 X.509 SSL certificate "StartSSL Free" http://en.wikipedia.org/wiki/StartCom

Right, and for anything that is commercial, a <$10/yr SSL certificate shouldn't be a huge deal. It's not perfect, it should all be free, but saying cost is a barrier is BS, in my opinion.

Re: Deprecating Non-Secure HTTP

#87

Post by teraflop »

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…

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.

Re: Deprecating Non-Secure HTTP

#88

Post by peteretep »

jsn wrote: post #71

I envy you, citizens of the free world :) You (mostly) can use HTTPS, avoid government surveillance, and use new shiny Mozilla features (for whatever they are going to be). It's not the same in e.g. Russia (and I'm sure it's not just Russia). In Russia, the Web is now officially being censored by the state. They have a national register of prohibited resources -- basically, a huge list of URLs. Every ISP must block a…

    > then ISPs have no other choice but to block all traffic
    > to your site entirely. Given that choice, many
    > webmasters (myself included) will have to choose plain
    > HTTP
At some point, blocking CDNs at IP level becomes too much of an economic burden on a country to be feasible. We've seen an unwillingness by the Chinese to block access to GitHub; presumably this means Fastly (their CDN provider) is safe for a while.

Re: Deprecating Non-Secure HTTP

#89

Post by derefr »

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.

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 secure!

This is exactly the original use-case for X.509 certificate authorities: pairing devices on a private network without having to give each of them a set of of their peers' keys in advance. You have a private network that you run services on? You're a CA.

And really, in the dev-environment case, you actually want client-auth, too, because then you get "clients who don't have a CA-issued client cert can't connect" for free.

In proper X.509, the server auths the client just like the client auths the server—it's really more of an equal-peers "we're both trusted by the CA—the network owner—so we should both trust each-other" kind of thing. The public Internet centralized X.509 model—where the client has a huge list of CAs that the user doesn't even know the contents of, and the server doesn't check anything—is a very strange and non-idiomatic implementation of the premise.

Re: Deprecating Non-Secure HTTP

#90

Post by jamiesonbecker »

teraflop wrote: post #64
jamiesonbecker wrote: post #49

This potentially removes the relative anonymity that the entire non-commercial web offers (and in fact was largely built on, post-DARPA). Free DV certificates may help minimize that negative effect, but this entire scheme still further increases reliance on a badly broken CA system. This seems like a somewhat rushed idea with good intentions but without sufficient community discussion.. rather than put all our eggs i…

> are there things we can do right now in terms of favoring self-authentication of self-signed certs? That's a good question, but I've yet to see any justification for thinking the answer is "yes". If an attacker controls your network connection and/or DNS, what possible information could you obtain to prove the authenticity of a website, without reference to an external source of authority?

Agreed. That's why it was a question. :) I'm trying to get people to start thinking in that direction, rather than in a central source of authority (which also means DNSSEC or DNS TXT's are out)
Post reply on HN