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

111–120 of 318 posts

Re: Deprecating Non-Secure HTTP

#111

Post by kijin »

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…

This is a legitimate concern, but I think the so-called dire consequences are a bit overblown.

Major browser vendors like Google and Mozilla don't change their policies in a vacuum while the rest of the world stays static. The move to "deprecate" HTTP is an explicit attempt to manipulate the rest of the world into making SSL easier and more affordable. It is unfair to evaluate this proposal in isolation without considering the market upheaval that it is very much intended to trigger.

Currently, most web hosts charge a hefty markup on SSL certificates and charge even more to enable them on a website hosted with them. This practice may no longer be sustainable as more and more people begin to demand SSL. "Free SSL with every 1-year contract!" could well become a standard marketing slogan, just as "Free domain with every 1-year contract!" has been for the last 10+ years.

Some domain registrars already offer free or low-cost (~$1.99) SSL certificates with the purchase of every domain. This may become more widespread as registrars scramble to remain competitive.

Android 2.x and Windows XP are major excuses for not adopting SNI, but the upcoming release of Windows 10 will reduce the market share of XP even further, and old Android's lifespan is also running out thanks to the planned obsolescence of mobile devices. By 2017-18, nobody will care about these platforms anymore, and if anyone still does, we can tell them to get Firefox.

Even without StartSSL or Let's Encrypt, existing CAs may be forced to cut their prices drastically as a horde of super-price-conscious consumers begin to flood their once prestigious trading floor. Some CAs have already been offering $20 wildcard certs through selected resellers. Expect more of these offers in the near future. This is a race to the bottom, and I'm thoroughly enjoying it!

To top it off, CloudFlare is offering free SSL (SNI required) to everyone. Expect services like this to become more common as SSL comes to be seen as an essential component of every online service.

Of course, there's no guarantee that these changes will occur. But I can guarantee that most of them will not occur unless there's massive, organized presssure on the lazy, greedy incumbents. Google and Mozilla are doing the world a great service by adding their weight to this much-needed pressure. Remember when the rest of the world basically ran an extortion racket to force the web hosting industry into upgrading to PHP 5? That was glorious. I want to see it happen again, this time for easy and affordable SSL.

If the deadline arrives and the world still isn't ready for the transition, we'll think again and adjust our strategies accordingly. Nothing wrong with that. In the meantime, let's be optimistic and go bully some web hosts!

Re: Deprecating Non-Secure HTTP

#112

Post by beeworker »

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.

I agree in that scenario it's hard to say whether one is more likely to be the true certificate than the other. If we're assuming attacks that aren't targeted towards specific users (e.g. from state actors, or just a corrupt hotel wifi admin, who are attacking whoever happens to be on the network) then we can't say without more details about the network you were connected to on Monday vs. Tuesday. If we're assuming attacks that are targeting you specifically as an individual, perhaps A could be considered slightly more likely than B due to coming first... Visiting the site on Monday leaks the information that you visited the site, so an attacker may believe you will visit that site again. But if the attacker is keeping logs of your traffic habits, they may have just chosen Monday to poison your fresh DNS lookups. So again it looks like we can't say which is more likely.

Re: Deprecating Non-Secure HTTP

#113

Post by letstryagain »

mahouse wrote: post #106
bigdubs wrote: post #24

Earlier quoted context omitted.

Why this project: https://letsencrypt.org/ is so important. From the site: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Mid-2015

And what if I don't trust any of the "MAJOR SPONSORS".

You don't trust the EFF?

Re: Deprecating Non-Secure HTTP

#114

Post by schoen »

vitno wrote: post #94
nothrabannosir wrote: post #38

Earlier quoted context omitted.

That's just one project, and it doesn't even exist yet. The web is moving faster every day, apparently. I sure do hope that project will be all it's chalked up to be. For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). If letsencrypt doesn't do that... well then I'd have to hope real hard for a competent CA out there who has an a…

Let's Encrypt does exist. I watched a demo where they went from a vanilla apache install to an A scoring HTTPS site in sub 5 minutes at Libreplanet. It's a good idea to publicize the upcoming LARGE change.

I'm the person who gave that demo and I appreciate the compliment, but I'll readily admit that we can't yet issue publicly-trusted certificates to the public. So we aren't up and running in a way that a site could take advantage of.

On the other hand, our infrastructure, partnerships, and technology are very real. I hope they'll make the process just as easy as what you saw for many people soon.

Re: Deprecating Non-Secure HTTP

#115

Post by tyho »

bashinator wrote: post #53
tyho wrote: post #34

Earlier quoted context omitted.

What features have to do with encryption is this. If a browser asks a user "Do you want http://example.com to be able to access your camera", what it is really asking is "Do you want http://example.com , anybody on your local network, state actors, anybody between you and example.com, people who can mess around with BGP and your DNS provider to be able to access your camera?". TLS mostly makes the first question more…

You might explicitly include "employees of the coffee shop/hotel/library providing wifi" in the list of actors who can intercept your traffic. Honestly, I think that one will get the most attention of the average person.

And perhaps most importantly of all, your employer/school.

Re: Deprecating Non-Secure HTTP

#116

Post by beeworker »

deathanatos wrote: post #92
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…

> 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. Do we assume the user is going to notice that URL art style, and actually heed it? Because if the answer is "no" (and I think in reality, the answer would be "no"), then pick a high value site, and MitM it with a self-signed cert. The user…

If you have the ability to MitM a high value site like facebook.com without getting caught, I think it's worthwhile to do so regardless simply because you'll get some portion of the users who bypass the warning. In my scheme, the only people who won't see the warning are those who have never visited facebook with that browser before, so they may or may not have an account to login with that you can hijack.

Re: Deprecating Non-Secure HTTP

#117

Post by ryan-c »

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.

http://www.garrisonhost.com/ssl-certificates/alphassl.html

$45 for a one year wildcard

(not affiliated, but have bought a few certs from them without problems)

Re: Deprecating Non-Secure HTTP

#118

Post by walterbell »

tyho wrote: post #115
bashinator wrote: post #53

Earlier quoted context omitted.

You might explicitly include "employees of the coffee shop/hotel/library providing wifi" in the list of actors who can intercept your traffic. Honestly, I think that one will get the most attention of the average person.

And perhaps most importantly of all, your employer/school.

Who can intercept SSL traffic.

Re: Deprecating Non-Secure HTTP

#119

Post by schoen »

NeutronBoy wrote: post #4
rossng wrote: post #2

This is a pretty bold move, but I like the intent behind it. Hopefully Mozilla can pull it off without causing any problems for normal users. Presumably it will all be synced with their plans to launch a free CA[1] in the near future. [1] https://letsencrypt.org/

One thing I've never been able to figure out from Let's Encrypt's website - will you be able to get a certificate, without hosting your own instance? Or will it be limited to servers you can actually install their program on? Also, I assume they'll get the root CA included by all major vendors/browsers?

You don't have to run the Let's Encrypt client, but you do have to be able to do things to prove that you control the domain. Currently the Let's Encrypt client assumes that it's being run on the same machine on which domain control will be proved (though not necessarily the same machine where the cert will eventually be deployed). Someone could write another client application which gives instructions to complete the challenges manually, which is a feature that's occasionally requested.

The CA will be cross-signed by IdenTrust, which is accepted by mainstream browsers, so those browsers will also accept the certs we issue.

Re: Deprecating Non-Secure HTTP

#120

Post by schoen »

undefined0 wrote: post #63
nothrabannosir wrote: post #38

Earlier quoted context omitted.

That's just one project, and it doesn't even exist yet. The web is moving faster every day, apparently. I sure do hope that project will be all it's chalked up to be. For example, I need IP-only certs for a new project I'm working on (waiting for DNS to propagate to all clients is too unreliable and slow). If letsencrypt doesn't do that... well then I'd have to hope real hard for a competent CA out there who has an a…

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 described in Section {identifier-validation-challenges} below address validation of domain names. The use of ACME for other protocols will require further specification, in order to describe how these identifiers are encoded in the protocol, and what types of validation challenges the server might require."

Post reply on HN