SoylentNews is people
SoylentNews
We've previously covered Mozilla considering a push to deprecate HTTP in favor of HTTPS. Well, it looks like the time is here. This HTTPS encrypted blogpost by Mozilla starts with
Today we are announcing our intent to phase out non-secure HTTP.
There's pretty broad agreement that HTTPS is the way forward for the web. In recent months, there have been statements from IETF, IAB (even the other IAB), W3C, and the US Government calling for universal use of encryption by Internet applications, which in the case of the web means HTTPS.
[...] There are two broad elements of this plan:
- Setting a date after which all new features will be available only to secure websites
- Gradually phasing out access to browser features for non-secure websites, especially
features that pose risks to users' security and privacy.[...] For example, one definition of "new" could be "features that cannot be polyfilled". That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using <canvas>). But it would still restrict qualitatively new features, such as access to new hardware capabilities.
[More after the break]
This unencrypted blogpost raises good points against the move:In conclusion; no, TLS certificates are not really free. Introducing forced TLS would create an imbalance between those who have the money and means to purchase a certificate (or potentially many certificates), and those who don't - all the while promoting a cryptosystem as being 'secure' when there are known problems with it. This is directly counter to an open web.
There are plenty of problems with TLS that need to be fixed before pressuring people to use it. Let's start with that first.
Other links: Hacker News thread on the Mozilla post, Hacker news thread for the rebuttal. The comment threads are interesting. Here's one excerpt from the second link:
There's one solution that the author didn't cover: Start treating self-signed certs as unencrypted. Then, deprecate http support over a multi-year phase out. That way, website owners who want to keep their status quo, can just add a self signed cert and their users will be none the wiser.
For https there are two major objectives. 1) Prevent MITM attacks. 2) Prevent snooping from passive monitoring. Self-signed certs can prevent #2, which the IETF has adopted as a Best Current Practice. I'm much more in favor of trying to at least do one of the two objectives of https, rather than refusing to do anything until we are able to do both objectives.
One other major argument against ridding ourselves of HTTP is pure performance, encryption is expensive, and why burn that power encrypting things that have no need to be encrypted.
The enforcing of HTTPS is something that has provoked discussion here in the past. Go crazy!
(Score: 3, Interesting) by frojack on Wednesday May 06 2015, @02:21AM
This isn't like PGP/GPG...
The certificate is issued by a Cert Authority, like Thawte, or GoDaddy, or some such.
They send you one part, to put on your web server.
They keep part to validate your certificate when necessary.
The feds want to get the part you put on your server. That way they can set up a man in the middle attack. If they can't get it from you they will try to get a copy from the issuer. There have been news reports of the issuer's handing over the server-side certs even without warrants.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by TheRaven on Wednesday May 06 2015, @01:07PM
The problem is that the trust model for SSL is that any CA can sign any cert. This means that they can also sign the cert that the NSA (or whoever) gives to them and your browser doesn't know which one is the valid one.
This is what certificate transparency is for. It lets site operators easily tell if someone is seeing a certificate for their site that is not one that they know about and lets visitors tell if they're seeing a different certificate to everyone else.
sudo mod me up
(Score: 3, Informative) by FatPhil on Wednesday May 06 2015, @02:32PM
The certificate isn't your private key. The certificate can be used to validate your public key, which it contains.
> They send you one part, to put on your web server.
No, they send you *the* certificate, that contains the public key you've given them, not "part of" anything. Any CA which wants to know your private key is a CA which should not be trusted. I'm sure many exist.
> They keep part to validate your certificate when necessary.
Nope. The certificate contains enough for anyone to validate it without any additional information. The chain of trust model implies that you should also check that the CA listed in the certificate is one that you trust too. That requires verification of the CA's own certificate. Simple installation of the CA's certificate is treated as implicit trust henceforth on most systems.
> The feds want to get the part you put on your server.
Nope. The feds either want your private key, which, whilst is on your server, isn't anything to do with the certificate, or want the CA to create a fake cert just for them so that they can impersonate you. This they, and dozens of other CA's, can do trivially. Which is why SSL and evolutions therefrom are unfixably broken.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves