Intent to deprecate: Insecure HTTP
groups.google.com
groups.google.com
I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct).
I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert.
If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.
(Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.
Alas, this does not scale well into the HTTP realm.
Although I think it could work great on sites intended for small numbers of clueful users. (Web-based admin consoles, etc.) But something else is needed to make HTTPS usable by average people.
But right now, the situation is that I go to arstechnica.com, which offers no encryption whatsoever, and Firefox just loads it up like nothing's wrong.
Yet I go to self-signed.example.com, and Firefox presents me with a giant warning screen, followed by a pop-open warning dialog, where I have to click to confirm the security exemption, add the certificate in, and OK another scary prompt. It's so over the top that laymen probably think proceeding will give that site complete interception control over every site they ever go to again in the future.
That's absolutely ridiculous. Worst case, self-signed should be treated like HTTP is now. No padlock, no green address bar.
People who are knowledgeable and able to confirm self-signed certs should be able to very quickly and very easily do so. This will greatly help with developing inside the local network, or for small communities that know what they're doing and don't want to pay hundreds of dollars for wildcard SSL certs.
A self-signed certificate is significantly better than no encryption whatsoever (even if you're being phished, you at least now know that no other phisher has viewed or altered the response in transit), but browsers for reasons that defy explanation treat them like they're worse.
There was even an MTA (exim maybe?) that on seeing an untrusted certificate would actually downgrade to plaintext in some circumstances. Great job, guys; you really dodged a bullet there...
Right now a certificate doesn't mean much anyway, there is hardly any difference between accepting a self-signed certificate or one that has been issued by any one of the CAs for security purposes, it's mostly a feeling, nobody went there to check who ordered the certificate.
All it says is that someone paid someone else some money.
You would need to use something like DNSSEC as well, relying on a government-controlled PKI [1], which isn't really any better than the current situation.
It's certainly not perfect, but it is a much bigger hurdle for a mitm attacker to get past.
It's possible to have pseudonymous secure transport, if you identify sites with key-based pseudonymous identities rather than some form of authenticated identity, but you have to have some notion of identity or you don't have a secure transport at all.
It's pretty basic cryptographic theory and I'm not sure how such a fundamental misunderstanding became so widespread. A secure channel need not tell me anything about the probity of the other participant. (In basic terms, even if I'm being phished, there's an advantage in keeping some other criminal syndicate from also reading my information.)
"But you don't know with whom you are actually communicating to begin with!" you may say. Agreed, and not cared about. I'm communicating with someone. Step 1 is to make sure that whoever that person is, she and I share a secure communication channel that no other person can alter or intercept. At that point she and I can negotiate authenticity. Solve the simple problem first, and the harder problem becomes easier.
While this attacker is too weak for most security use cases, it will cover many forms of passive mass surveillance by ISPs and governments, so it is quite valuable in that sense.
We don't need identity verification on many sites, being resistant to passive eavesdroppers or transient active attackers (such as sites that present different SSL certs when accessed from a public wifi) is a nice to have as they prevent some attacks rather than none.
No version of HTTPS has ever hidden what site you were visiting.
HTTPS sure does hide the URL's you are hitting. It may leak the domain name, and you are also resolving DNS entries in the clear, but there's a difference between the Wikipedia entry on puppies and on something more nefarious.
That said, I would prefer comcast ad injection to someone running firesheep. And hiding which comics I looked at for two hours isn't going to help my job very much.
I believe all content (banks, GMail, XKCD) should be served over HTTPS and protected by a trusted certificate. Self-signed certs are not trusted and should not be (the problem of "should GMail give me a self-signed cert?" cannot be solved; you need some type of external trust).
Notice, I am not saying trusted and signed by a CA. We can replace the trust model and do something different to fix the currently broken CA system. However, I never argued and am not arguing that some content is OK to be served over plain HTTP.
Eh? That's why SNI was invented, because pre-SNI https did not send the hostname in plaintext.
The server sends the hostname in plaintext when it sends the certificate.
By requiring a perfect solution to auth and ident (rather than iterative improvements) you are part of the problem.
Unidentified but authenticated connections should not be penalised compared to unauthenticated and unidentified connections. If someone MITMs a TLS connection with a forged certificate they can indeed do all the things that are trivial already with bog-standard http. If a client records TLS keys of sites they've already visited there is partial mitigation of this attack.
This doesn't have to have any effect of the CA scam business model, although obviously I would be in favour of a combination of key pinning and some sort of hand-wavey consensus determination for initial pins of arbitrary sites, but the fact that people are being forced to pay in order than browsers won't prefer plain-text over end-to-end encryption is absurd.
Bluntly, the refusal of a certain part of the security community to simply secure transport first and then worry about authentication on top of that is both frustrating and mind-boggling.
This sounds a lot like the thinking that brought us the TSA. Do something, anything!
I really don't see your point with TSA, we're not talking about security theater here.
I have a blog. No ycombinatorer has any idea who I am or whether I'm trustworthy, so a verification from a CA that I am who I claim I am isn't particularly helpful to either of us if I link here.
Since you don't know who I am to begin with, presumably you wouldn't trust me with any greater information than you would give to a phisher, since even with a CA-signed certificate I might have nefarious purposes. But with encryption you would at least know that whoever you are in fact communicating with actually sent the message you received and not something else.
It's genuinely puzzling to me that so many people obtusely claim there's no value there.
So to me, the whole thing sounds like a red herring, or rather a Trojan horse for the imposed removal of anonymity from the Web. No one has articulated just what problem is being solved here, but plenty of people have articulated the downside.
No. With http I can phish you, and anybody else can read or alter that phishing attempt. With self-signed certificates, I can phish you, and you know that my phishing attempt was neither altered in transit nor read by anyone else. We now have a channel over which we can negotiate authenticity.
If you went to my blog and saw that a CA had verified that I am who I claim I am, that doesn't particularly help you, because you don't know anything about me. But you might like to know that, whoever I am and claim to be, no other party is interfering with our communication. My issue is not with things like Gmail or my bank, but with the thousands of "ordinary" sites where learning the identity of the business that owns the site doesn't actually give me any useful information. That is, even if I see the name of the company in the certificate, I don't have a reason to trust them more than I would trust a phisher because I have absolutely no sideband interactions with them to begin with.
Plus I'm still cognizant of the bullet I dodged by not having OpenSSL on my server back when Heartbleed hit.
I'm 100% sure the model isn't sound.
I'm also 100% sure that a model which includes unencrypted HTTP will never be sound. The cert problem is a fixable problem, but it's not fixable while unencrypted HTTP exists.
There is one solution I can think of, but it involves equating URLs with identities via a Namecoin-like system, and that technology just isn't there yet.
Problem 1: isolate the communication between myself and whatever other party is actually sending me a message. Easily solved by encryption. (You're being MITM'd? That sucks. But you have now at least isolated the communication to you and the attacker. The problem domain just shrunk quite a bit.)
Problem 2: verify that the other party is who she claims to be. Not easy to solve but a completely separate problem from Problem 1.
We could solve Problem 1 tomorrow (modulo the time it takes to upgrade every browser/mail client/etc.) by simply encrypting all traffic, period, and not doing any authentication whatsoever. We would then be exactly where we are right now in terms of having a PKI system with all of its advantages and faults, but we would then have the amazing bonus feature of preventing all passive attacks, period.
Sure it is. Whether or not HTTP exists has zero bearing on solutions to the cert problem; the cert problem is independent of the unencrypted problem (whereas the unencrypted problem is dependent on the cert problem, since the cert problem is precisely why the unencrypted problem currently exists).
Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.
That's what comments like this like to forget: HTTPS provides not only encryption, but also authenticatoin.
So have a PGP signature of the page available and the browser can check it.
> HTTPS provides not only encryption, but also authenticatoin.
And this is the problem. Those are two separate issues and should be handled separately.
This has a big advantage over HTTPS Everywhere - neither you nor your users have to trust your CDN. Put your main pages' HTML, and special pages such as login and transaction pages, on your own HTTPS server, and the public stuff on some CDN, unencrypted. This is much more secure than letting some CDN possess your private keys.
Comments like that are a reinforcement of an increasingly-common point: that HTTPS shouldn't be conflating those two things, since doing so is resulting in a lot of pain whenever these sorts of suggestions to encrypt all web traffic come up.
All I want is a way to set up an encrypted connection without caring about it being authenticated, thus offering at least basic protection against random passerbys at Starbucks. Let me do that without having to buy a certificate from some schmuck who was arbitrarily trusted by a bunch of browsers (without any actual guarantee of trustworthiness, mind you; just an empty pinky promise that they won't be naughty).
http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...
At startssl you can get unlimited amounts of wildcard certs for 60 $. I know startssl isn't that popular and partly that's justified.
In summer hopefully let's encrypt will start and make it even easier to get certs for free.
Or in other words: People are working on solving the certificate situation - and even now it is not as bad as you make it sound.
I understand this comes from a frustration, and an understanding that the certificate based authentication is not perfect. But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for.
So as long as no practical and better solution for server authentication has been found, this is the best we have and it is still working pretty well (you don't see a lot of rogue certificates in the wild).
It's perfectly called for. The CA system is based on arbitrary trust. An actually-effective system should not rely on trust at all.
Even something like what Namecoin does - using a Bitcoin-style blockchain as a public ledger, but for SSL certs instead of DNS entries - would be a massive step in the right direction in comparison to the current CA system.
By what measure? Some empty promises of good security practices, perhaps? Or maybe some pinky swear that they'll always act in the best interests of the internet as a whole rather than in the interests of whichever government or set of shareholders happens to be in a position of power relative to them?
Basically: name one.
The huge problem there is key distribution (easy since I run all the servers), but in terms of just "security" that's much more secure than involving a third party CA.
In terms of what you're focusing on in this thread (verification of identity) I don't disagree. But a MitM attack on coffee shop wifi is a problem which is exacerbated by self signed certificates.
A cryptographic ledger, on the other hand (think Namecoin), would probably be at least slightly more effective; it would effectively confer the same benefits (decentralized registration authority) without the logistical nightmare of a web-of-trust.
That is, the certificate presented by the site should be signed in a fashion that proves that whoever signed it owns the domain.
How do we know you own the domain? Because you control the DNS. If you control the DNS, you can control the domain in so many ways, including receiving the DV email, so it seems like a proper way to verify it.
If you control DNS, you can set a TXT record and put a public key in it.
So why not have browsers actually just ensure that a certificate is signed by the public key stored in DNS? Is there a good reason not to do this?
DNSSEC is a terrible ide and should be abandoned for many reasons. So should this method of domain validation. You know who knows for sure that you own the domain you say you own? The registrar. That is who should issue you your cert, not some third party.
sudo apt-get install lets-encrypt
lets-encrypt example.com
I don't mind at all visiting someone's personal site that has a self signed certificate but a UI change to avoid the glaring waring dialog would be nice.
There are large advantages of having almost all traffic encrypted.
https://lists.mozilla.org/listinfo/dev-platform
https://groups.google.com/forum/#!forum/mozilla.dev.platform
"Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken. Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse."
Please keep that fact - that the CA system is, as I put it with all the gentleness and politeness it deserves, "fucking broken" beyond any repair - in mind.
(And no, "the CA system is fucking broken" is not an opinion; it is a verifiable fact, as much as the concept of gravity is a verifiable fact)
Just on my Debian box there are 173 entities (along with all their employees, disgruntled employees, hackers, and probably governments) who can sign a certificate for google.com that my computer will accept. I can think of five cases in as many years off the top of my head of a fake google.com (or related) certificate being found in the wild by Google because of various levels of CA incompetence and/or fraud.
Worse yet, this bungled attempt at authenticity has been awkwardly nailed to the much simpler (and in most cases much more important) question of cryptographic security, with the result that going through the absurd charade of convincing a CA of my identity is required simply to offer a client the assurance that I, whoever I may be and however much the client does or doesn't trust me, actually sent the message the client received and that nobody in transit could read it.
Nowadays, we have this magical thing called a "blockchain" that can be used for everything from currencies (Bitcoin) to domain names (Namecoin); with some further refinement, using a blockchain as a certificate authority would fix both problems right away.
In which case, the equivalence of self-signed and CA-signed is entirely on-the-mark. There's no real guarantee that the certificate authority is any more secure or trustworthy than, say, my five-year-old niece.
This is why decentralized systems (lately, that's been interpreted to mean "systems using a cryptographic ledger or blockchain" or "systems that rely on mesh topology graphs" (i.e. something similar to Namecoin or something similar to PGP, respectively), but those aren't the only models out there) are ultimately necessary for this; that way, you don't have to trust one arbitrary centralized authority, but instead can trust, say, a majority of a collection of hundreds or thousands or millions of such authorities coordinating via an agreed-upon protocol/convention/etc. My own bet would be on a cryptographic ledger (PGP-style webs-of-trust aren't nearly as end-user-friendly, whereas a "blockchain" has more potential in that area, since it's easier to abstract away from the end user), but pretty much anything at this point would be less convoluted - and more secure/trustworthy/effective - than the current system.
Let's say a CA has issued certificates for example.com to someone with nefarious intent. It's discovered that the CA's security is completely compromised and my vendor pulls the plug. In our current scenario I can visit example.com while being MitM'd and my browser vendor has made sure I get a big alert when I connect.
In a scenario without CAs, I visit example.com and my browser vendor has no idea that I'm being MitM'd nor do I since I've never been to example.com and examined the certificate.
Is it perfect with CAs? No. Will some get victimized by a CA's carelessness regardless of when it's caught? Probably. But most of us remain more secure with it than without it. For most users on most sites it works albeit haphazardly. It should absolutely be replaced. But to suggest that the security benefits should be abandoned because it's possible that it could happen is short sighted. It would be open season on internet users.
You're actually losing security by trusting the CA model, though. You have no means of control or independent audit. This is the same reasoning behind free-and-open-source software being inherently more secure and trustworthy than their closed-source counterparts; "transparency is a dependency of trust" is just as applicable here as it is in any other security-sensitive situation.
This is why decentralization is absolutely essential, and the longer we go on sitting on our haunches and pretending that the current system is "good enough", the worse the problem becomes.
> If a CA is subverted my browser or OS vendor can pull the CA or the CA, if trustworthy, can revoke the certificates.
That trustworthiness is a very big if.
> In a scenario without CAs, I visit example.com and my browser vendor has no idea that I'm being MitM'd nor do I since I've never been to example.com and examined the certificate.
There are numerous ways to achieve certificate verification without relying on a centralized CA system. Even with self-signed, you can detect private key changes (this is how SSH is protected against MITM attacks; in practice, this rather-simple security measure has been very hard to circumvent). For more verification, there are plenty of ways to achieve that in a decentralized manner, be it web-of-trust (PGP-style) or a cryptographic ledger (Namecoin-style) or something else entirely. Hell, there are already systems like DNSChain that implement the latter approach; that would be infinitely better than the current system.
> But to suggest that the security benefits
What security benefits? All the purported "benefits" are entirely fictional, since they rely exclusively on arbitrary trust in arbitrary entities. That's not security, no more than me handing you a briefcase full of cash and you promising you'll hold onto it for me is "security".
The sense of security you feel with the current CA system is very much false. You're relying enirely on luck, and have absolutely zero assurance that your luck will continue to be good.
As an analogy this strikes me as deprecating an array for a linked list because a list has certain features that array's don't. Ie. there is a time and place for both.
As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.
In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think.
> Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."
We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
I'm not so sure. It seems to me that there is almost no value in requiring all traffic to go over HTTPS compared to requiring a subset of traffic to go over HTTPS.
> We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
If you want to deprecate it in name only, I guess I can't object since we wouldn't actually be doing anything. I'd figured this would involve trying to hinder HTTP use (similar to how we make self-signed certificates a royal PITA). At any rate, I think you're overestimating the likelihood that we'll figure it out in the short term — particularly given that the proposed happy scenario is to deprecate HTTP and then have thousands of additional for-profit actors trying to put themselves between people and the ability to have websites.
* Create a website for free (you have to pay for certificates to use HTTPS)
* Report sensor data from small embedded devices with extremely limited CPU
* Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API.
* Transfer large files at gigabit speeds on consumer-grade hardware
No you don't. You can get free certificates.
But even if that was true, it's still a misleading argument. You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents. For any actual website, there are already a multitude of real costs of which a certificate is just one more.
> Report sensor data from small embedded devices with extremely limited CPU
If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate.
> Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus).
Then those APIs suck - avoid them and/or ask the providers to get with the program.
> Transfer large files at gigabit speeds on consumer-grade hardware
AES-NI can decrypt at 3.5 cycles per byte. With modern consumer grade hardware you will not find symmetric streaming crypto to be a serious bottleneck.
Not everyone has modern hardware. My hosting provider doesn't have AES-NI for example.
e.g. https://www.startssl.com/?app=1
Also, if HTTPS became a requirement, then demand would increase for free HTTPS certificates in exchange for, say, advertising.
The original point was that requiring HTTPS would mean free-to-host HTTP services would go out of business as it was impossible to provide free HTTPS certificates, and in that sense, StartSSL proves them wrong.
And if StartSSL is the only option, then I'm sticking to HTTP. They're a nightmare to deal with even for non-commercial use, let alone commercial.
Any plan that puts more advertising on the web is going to get a big fat thumbs down from me.
Many online free hosting sites that give you a subdomain are HTTP only because wildcard HTTPS certs are expensive.
Many of those services would go away or turn paid-only in an HTTPS-only world.
The children of the future have already lost Geocities and dial-in BBSes that we grew up with; how will they manage if their Internet isn't exactly like ours? /s
> If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate.
I might not want to write the client for said custom binary protocol.
Like it or not, a lot of embedded devices (Arduino, Spark Core) provide libraries for serving JSON over unencrypted HTTP. Restricting yourself to devices that are more powerful (say, Raspberry Pi 2) would require you to use a bigger form factor for the hardware, and/or would cost more.
Not everyone on the internet is a multi-millionare YCombinator alumnus.
I'm talking about the little taqueria across the street from my house. They're perfectly viable, yet are going to be scared off from investing in a cert if it's going to be the single most expensive thing for their online presence. It's these sorts of folks that your argument blissfully ignores.
Because it does not require user to install any other software and still have access to the device (PLCs and other embedded controllers)?
Actually, if you are willing to do without your own second-level domain name and just have a third- or fourth-level domain name, there are plenty of services where you can have a free web site (or app) running of over HTTP. E.g., any number of free (or free-within-limited-quota) static site hosting services, or even Google App Engine.
Of course, in the Google App Engine case, you also get HTTPS for free (within usage quota), as long as you are willing to have an <app>.appspot.com domain name, so the "create a website for free" isn't really a "with HTTP, but not HTTPS" thing.
Also, for a lot of newbies, installing SSL certificates is a PITA.
0. You realize you need a SSL certificate. You're presented with a dizzying variety of options and already lost. Are you supposed to get Positive SSL, Negative SSL, Essential SSL, Comodo SSL, Start SSL, Wildcard SSL, EV SSL, Rapid SSL, Slow SSL, or EV SSL aux Mille Truffles et Champignons? Most newbies ask, "Why isn't there a simple [click here to get HTTPS certificate] button?"
1. You get your certificates by e-mail, but you still can't install them directly. Your webserver wants a .pem file, so you Google "How do I create a PEM file". The top 10 tutorials tell you to concatenate THREE files: your_domain_name.crt, DigiCertCA.crt, and TrustedRoot.crt in that order. What you received by e-mail was FOUR files: AddTrustExternalCARoot.crt, COMODORSAAddTrustCA.crt, COMODORSADomainValidationSecureServerCA.crt, and your_domain_name.crt. You're lost, no tutorial is helping with what to do with FOUR files instead of THREE, in what order to concatenate them, and StackOverflow bans your question. You're fed up, quit, and use HTTP. (Not me; I'm describing an actual case of observing someone else's frustration trying to set up HTTPS.)
The only way HTTPS will gain popularity is if we can get rid of the certificate-issuing economy and make it easy for newcomers. The majority of content creators unfortunately do not understand the basics of security nor can we expect them to have the patience to learn it.
1. You get your server by wget, but you still can't install it directly. Your OS wants an executable file, so you Google "How do I create an executable file". The top 10 tutorials tell you to use some software called Eclipse, but that needs some kind of "JVM". What you received in the archive was some ".c" crap. You're lost, no tutorial is helping with what to do with .c files, in what order to concatenate them, and StackOverflow bans your question. You are not fit to operate a computer. (I made this story up too.)
The only way HTTP will gain popularity is if we can get rid of the different servers available and make it easy for newcomers. The majority of content creators unfortunately do not understand the basics of security nor can we expect them to have the patience to learn it.
apt-get install apache2
When Ubuntu can get you a working SSL web server, CSRs generated, certificates all auto-signed by authorities, set up and ready to go, zero questions asked, with
apt-get install apache2
Alternatively, browsers should not throw huge error messages about self-signed certificates. They should just do what SSH does instead: display the fingerprint, ask yes/no, store the fingerprint, and warn the user if the fingerprint changes in the future.
Contrast this with Dan J. Bernstein's wonderful CurveCP. It's so simple to set up and requires no CA involvement; you just need to be able to add a NS server entry.
A good webserver would actually be able to provide multiple SSL certs on a single IP address by using "Server-Name Indication" (SNI). This is definitely (as far as I know) supported on nginx, and probably supported by Apache's httpd.
The "old style" Raspberry Pi and, iirc, also the B2, don't carry crypto accelerators, and these are the first choice for people doing embedded linux prototyping.
Same for most other mobile chipsets.
The only free certificate authority that actually exists right now that I'm aware of is StartSSL, which I've at least found to be pretty damn horrendous to work with, and which only supports non-commercial uses of certificates, meaning that small businesses are still forced to pay up.
And no, Let's Encrypt doesn't count, seeing as it's not operational yet.
> For any actual website, there are already a multitude of real costs of which a certificate is just one more.
That's one more that can mean the difference between a mom-and-pop shop having a website and said shop not having a website because it's too expensive.
Just because plenty of factories dump industrial waste into rivers doesn't mean that I'm not an asshole if I dump a bottle of OxiClean down a storm drain.
Can't modern hardware do AES at slightly over a gigabit per second per core even without the pervasive 10x accelerators?
This will still be a problem even when you can get free domain-validated certs from Let's Encrypt. That's still an outside dependency for a private system.
This proposal is specifically about web browsing.
> * Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API.
I believe that is the point of this proposal. NextBus will probably never switch to HTTPS without external pressure to do so.
Probably Baidu thought the same thing about their Javascript. It's a public file, so why use HTTPS? Then they got turned into the Great Cannon and now they're being described as a weapon of the PRC in major newspapers.
It's obvious that governments are systematically weaponising any non-SSLd connections. If you don't use SSL, you're making it easier for them to hack your users and turn your website into a weapon. If you wouldn't let botnets run wild on your servers, you should take the same care to encrypt your website.
Yes, I'm sure that the communication between my browser and the test app I'm running on localhost doesn't need to be encrypted.
> It's obvious that governments are systematically weaponising any non-SSLd connections.
Over the public internet, sure.
OTOH, if a government controls a root CA trusted by your target population, TLS doesn't provide any protection at all against them anyway.
Even in a scenario where this doesn't happen, it elevates the required attack from a passive eavesdropping attack (which is comparatively simple to conduct en masse, and to analyze data retroactively) to an active attack (which must typically be done in a targeted, real-time fashion).
Really? How?
[0]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Certif...
And TACK literally was designed to solve this problem. If the MITM interferes with you communicating to other TACK clients, you detect their attack. If they don't, you detect their attack.
Authentication can be done much more cheaply than encryption (well assuming you have the clout to force a change in standards). It could be implemented as simply as <script src="baidu" hash="a84b3">. In particular such a request could be transparently cached without security concerns.
It's a much bigger challenge, and I find it wildly cavalier for anyone to say "just use HTTPS everywhere" without directly addressing the faults pointed out by others. And by addressing, I don't mean dismissing out of hand.
Hell, I'd settle for acknowledging instead of addressing some days. There are real world problems on both sides that need to be considered.
But these are two separate issues. Going from plain HTTP and HTTPS to HTTPS-only is a step in the right direction. It's also step 1. Step 2 is to drop CA's and work out a better trust system that relies on less parties being involved.
Also, let's give people some credit. Yes, some people ignore the self-signed cert warning. Some people also respond to Nigerian prince emails. We aren't talking about cutting off email because someone might get hurt. Unless you are ready to drop all untrusted certs, those dialogs need to stay in place.
telnet www.example.com 80
GET / HTTP/1.0GET /
Sure: host a web server anonymously. With HTTPS+PKI (and it's the PKI half of this that people are complaining about) I have to claim an identity.
How is this not going to destroy the cachability of the internet?
Being able to operate transparent caches is important for institutions (Edit: some which may not have access to their users local cert stores).
There is many things like blogs, news articles, photo galleries that gain zero value by being encrypted. Encrypting these things is going to require more hardware, more energy usage and more bandwidth and thus again more energy usage.
I totally am for securing POSTs, HTML, etc with SSL, but images and CSS, etc really make little sense.
It only prevents caches that are in the middle and trusted by neither end. I'm okay with that in almost all cases.
If my employer wants to use caching, they can install a cert for their proxy on my machine (or require me to do so), so it's not a problem - although it is more technically complex.
letsencrypt.org will solve this problem.
> It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information.
That's something that applies to buying/owning a domain as well. Domain-verified certificates require very little private information, and I suspect letsencrypt.org might be able to provide a way to get trusted certificates without giving up privacy.
> Using self-signed certs will become harder.
How so? The proper way to use self-signed certificates would be to distribute them in a safe way (e.g. deploy them through your Active Directory Domain, provide the fingerprint through a separate channel, etc.) and install them in your trust store. I couldn't find any intended changes to this in their announcement.
> Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea.
I agree that it should be a slow process, and I think that's exactly what they're suggesting. Eventually, when the tooling and processes around SSL/TLS catch up with the new "encrypt everything" mentality, it would probably be no big deal to deprecate almost every use-case of HTTP without SSL/TLS.
Mozilla is one of the backers behind letsencrypt. I'm sure they won't be deprecating anything until well after it is up and running. This was an email to the Mozilla community asking for feedback, not an announcement of any major deprecations in the next version of Firefox.
Letsencrypt is based on an open protocol [1], I'm sure there will be implementations for all major platforms.
Because Let's Encrypt might solve this well, or it might not solve it well, or it might never even be released. At the moment, factual statements about what effect Let's Encrypt will have on the world are similar to "$(THIS_YEAR+1) will be the year of Linux on the desktop."
If you're using a self-signed certificate, you don't need to provide information to anyone.
> Using self-signed certs will become harder.
Why?
I haven't given this much thought yet, but these don't sound like convincing arguments against the proposition.
Care to convince me otherwise?
Edit: never mind. Mailman was late.. got it now!
Edit: I bet there are 1000x more IE6 users, than users of these devices. Shall we support IE6 until every single of it's users upgrade?
Also, you are a developer. I am sure we can figure out some way for developers to re-enable plain HTTP in some hidden settings. That way people like you and me can continue to do what we do, while the rest of the web users are enjoying the benefits of being more secure by default.
I'm a developer, but my clients are not.
Getting rid of HTTP will make people more secure. It will ensure that basically all sites people visit will be protected by a trusted cert.
Note that nobody is talking about installable malware here. We are talking about protecting the web. For example, if your connection to news.ycombinator.com is protected by HTTPS, this makes it that much more difficult for the NSA to spy on you, or for me to insert a goatse into the content while you are at work, and I am sitting in the next office over form you.
No we didn't. Telnet is still pervasive as a communications protocol, partly because of its simplicity and partly because of its momentum. This is particularly true in the realm of embedded devices; even rather-modern enterprise-grade HP printers (for example) open up a Telnet port for terminal-driven configuration by default.
The analogous case might be if you're doing plaintext password authentication over HTTP. I agree that for that use-case you should switch to HTTPS.
Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?
Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.
My problem is that we still allow plain HTTP. That should never be the case, just like we should not use telnet for remote server access.
DNS hijacking is a problem. It is a problem at a different layer of the system. Just because that layer is vulnerable, does not mean that we should leave a gaping security hole at a different layer. I don't buy the argument that we must have perfect security or no security. Besides, there are ways to mitigate the DNS hijacking issue, such as the HSTS header.
I'm already annoyed enough by firmware update tools that only work with a specific old version of Internet Explorer... I rather not throw dozens of equipment away just because browsers started to insistently refuse HTTP connections. Let's not talk about the fact that I often spin up simple HTTP servers on my computer just to be able to transfer files to other machines on the same network, and I rather not have to worry about creating certificates (to then find out that the machines in question are "obsolete" too and don't support HTTPS?).
Can we just consider HTTP to be like telnet? Old, super insecure, definitely not meant to be used by everyone daily and definitely not over the Internet, perhaps not even available/installed by default, yet super compatible and simple to implement both for the client and the server.
I really hope that should mandatory HTTPS become a thing (and I'm not saying it shouldn't), an exception is added for local area connections.
Now we only need to convince either Google or Microsoft to implement something like that in their OS and encourage/mandate the use of it. Only these 2 matter because they are the owners of the biggest platforms.
Yes Apple has a pretty big platform, too, but it's kind of irrelevant since it's a closed Apple-only ecosystem anyway so if it adopts something it doesn't mean the others will too. On the other hand, if either Android or Windows adopts something as major, I think the other one would, too.
What I'm thinking is something like MinimaLT or perhaps Trevor Perrin's "Noise" if it ever becomes real.
But selfishly, I've worked for many corporations that operate an http proxy that they scrutinize and they proxy https which they cannot scrutinize (without detection), so I feel comfortable that they are not. (Yes I periodically review the certificate store for changes).
If the vast majority of sites were https, they might decide to do MITM for those https connections and either instruct everyone to ignore the warning or install their own certs on all of the computers. Indeed I think many corporations may already do this. I would probably not use many websites if they made that change.
If they're already going through the trouble of monitoring everyone's traffic, a few extra steps don't seem like that big of a hassle.
Of course, you're right, some large fraction won't bother with their own root cert, and their users will learn many bad habits.
Yeah, but I can audit the certificate store (and I have). On some systems, I am granted local administrator privilege. I wouldn't take out any certs that they install, but if I found that they installed and/or used one, I'd probably stop using most public websites (at least the ones that I have a username/password with).
IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way.
[1]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
I disagree, and so does the IETF: Pervasive Monitoring is an Attack[0].
That is confidentiality, no? If login credentials are transmitted in the clear then anybody listening can impersonate them. That's exactly what FireSheep demonstrates.
Off-topic, but why can't people say "I'm not sure" or "I can see both sides of this argument". It's just an overused geek cliche.
As a principle, the benefits of encrypting everything always beat the benefits of "monitoring everything" in an enterprise.
For example, if they're all *.local that wouldn't be easily abusable.
All-in-all, this is something that could easily be made into an app and automated.
Secure versions of this exist - and the security requirements they introduce are part of the reason enterprise IT is so much of a pain in the ass.
Regardless, we are talking about users' browsers dropping plain HTTP. These browsers will never hit your backend servers, so you need not worry about them. In your scenario, they'll always use HTTPS. You are worried about your one in a million case as a developer. That's fine, go into about:config and enable plain HTTP. Everyone else isn't an expert in security and shouldn't be allowed to shoot themselves in the foot by default.
python3 -m http.server
But then again, carrier-grade NAT means that anyone who is tinkering like this has to do some sort of NAT-punching to show their work off to a friend, so maybe this could be solved by an automated wrapper ala localtunnel or ngrok.
openssl s_server -accept 4443 -WWW -cert mycert.pem
Thanks. I know about that, but I am not on a mac.
If we deprecate HTTP, then certificates can be used as tools of censorship by governments.
We require an alternative to the current HTTPS scheme first.
They will all say it's "for your security", and arguably having this centralised root of trust does lower risk of attacks from random groups, but at the same time it's allowing them more power. To CAs and governments, a lot of things around encryption seem to be oriented in the direction of "if we don't have control over it, we disapprove." Self-signed certs are only one example of this; see all the other issues surrounding mobile device encryption. It's only good encryption to them if they are the ones in control of it.
Quite frankly, to me it seems random hacker groups have a lower chance of cooperating and tracking you in the same way that governments can.
I believe the relevant quote in this situation is again the classic "those who give up freedom for security deserve neither."
On top of that, HTTP2's "it all has to go through one hole" approach means that CDNs become almost mandatory for big sites. The Web is becoming a lot more centralized. It's more secure against random attackers, but much less secure from inside jobs at CDNs, authorized or not.
The Great Firewall of China people must love this.
CDNs are already Men In The Middle.
It only means you are speaking to a device or set of devices that the certificate-holding entity has authorized to speak for them. No certificate technology can prevent a company from delegating authority to another entity's devices.
It isn't that this isn't necessarily a problem... it is that there is no way in which certificates ever solved it, nor a way in which it can solve it, and there's no choice. Whenever you're talking to X.com, you are almost certainly also talking to a third-party web stack, for instance, which means that trust has been delegated by the certificate holder to some other party's software. There's hardly a website around that doesn't have a whackload (technical term) of third parties already in the connection anyhow.
The certificate-holding entity is ultimately responsible for what they do with your trust. But the certificate can do nothing to constrain those actions. It's just a glorified number with some other glorified numbers attached to it.
It does seem to me though that HTTP2 should actually make it easier to do without a CDN in the end, though. Initial HTTP2 support will just be "HTTP1, but on HTTP2!" which really provides minimal advantages over HTTP1, but over time as we see web frameworks start to take direct advantage of being able to push down resources preemptively, the advantages of CDNs for all but the largest sites start to fade. (Perhaps not "eliminated", but certainly lessened.)
(Incidentally, as people will presumably start releasing HTTP2 benchmarks soon, keep on eye on the details. Embedding HTTP1 inside HTTP2 is not the interesting performance question and will never have big gains... the correct question to investigate is what are the gains to be had from fully using HTTP2 natively. Many SPDY benchmarks had the same problem... of course SPDY isn't faster if it's still essentially speaking HTTP1 to the target website.)
No, it just makes multiple requests to the same domain more efficient. Requests to external domains still work.
For example, I have seen a 800 bed hospital in a rural area get very far with a relatively weak (but best it could get) Internet connection by having transparent caching.
Colleges with dorms, even in non-rural areas safe huge amounts of bandwith this way too.
Configurable blocking of HTTP provides all the benefits of HTTP deprecation without the adverse side effects for the situations where HTTPS is an unnecessary headache, so it should be preferred.
From a hardware perspective, I'd say that by now the problem is actually solved. Hardware is powerful enough to handle SSL connections.
What's currently tricky is that too big a chunk of clients still doesn't support SNI which really doesn't go well with the increasing scarceness of IP addresses.
Needing one IP address per unique domain name, aside of the administrative overhead (multi-homing still is somewhat inconvenient) will just not be feasible as the costs for IP addresses is starting to skyrocket.
This will be fixed by either IPv6 growth (you wish) or the death of non-SNI systems, but it'll be years if not decades before we can ignore XP and Android 2.3, especially as there's no good fallback path for these clients as the SSL negotiation (and subsequent hostname validation failure) happens way before the host could react.
I'm not sure that's true today, what's your list?
XP is only a problem when using IE. Android 2.2 and 2.3 are well under 10% last numbers I saw. They are very close to where we can make a greater good argument.
I'm tired of this bullshit. This has never been true, not even 10 years ago. You only need one IP:port combination per unique domain name. You can host tens of thousands of HTTPS websites on a single IP even if none of your users support SNI, and you don't have to pay for a SAN certificate, either.
You can serve HTTPS on port 31276 as long as you redirect properly from plain HTTP. You could even redirect conditionally, i.e. modern browsers and search engines are redirected to port 443 while the remainder are told to try port 31276.
Is this ugly? Yes. Do people care? No. A client of mine who uses shared hosting is perfectly happy with HTTPS on port 44527. Most people don't even look at the URL. Who knows, they might even think that the secret number makes their website more secure. (Of course it doesn't, but their misconception doesn't make their website any less secure, so I don't care.)
Older browsers not supporting secure ciphers/protocols is a bigger problem, but you can also get around this to some extent by offering better ciphers/protocols on port 443 and lesser ciphers/protocols on an alternate port.
I would furthermore wager a guess that the intersection between XP users and users behind firewalls is quite big, actually.
Note that the subject here is talking about what to do in future browser versions, so IE8 never comes into the picture.
This is the wrong level to be talking about this anyways. IPSec is the "right" thing to do, but that ship sailed I guess.
(Obviously the attacker in this case would probably also be able to sniff the requests from the resolver, but still; I'm not making this complaint up or anything, a lot of people have mentioned it before.)
My point is that hostname has always been leaked with HTTP and HTTPS. SNI does not leak any new information.
But that's a red herring. Even if it was all kept encrypted, even if you ignored DNS and reverse DNS, you could connect to the IP yourself.
Yeah, technically there might be more than one hostname, but they're all related hostnames.
Huh? I used to have ~100 hosting clients per IP address, none of whom were in any way related to each other (other than in having chosen me as a hosting provider).
There are many cases where you might want a service on localhost to be reachable via HTTP. Technically this should be exempt from https rules entirely, since who would the man in the middle be? If someone can MITM 127.0.0.1, they own your box already.
It is impossible to get https certificates for localhost/127.0.0.1, making SSL with an approved cert impossible for local services.
Having said that, I am really happy others are thinking along the same lines as I: HTTP should be relegated to a legacy protocol and the warnings need to very similar to what you get when accessing a site secured by a self-signed cert.
Obviously I'm not going to setup a home domain, DNS, and SSL certs installed on all these devices just so they can use the latest HTTP/2.x features in their admin panels or user interfaces?
I have so many comments - but the first being don't they realize that they will have to make this option which will be disabled by most enterprises?
But they generally just block domains, or use extensions, neither of which care about http/s.
A quick search shows that https://www.netnanny.com/products/netnanny/ says it works against SSL.
(I'm concerned if a kid browses with iPad, some telephone, etc., and the concern is more on whoever provides the service that might be liable in some way).
The only time it makes a difference is if you want to block part of a domain and not other parts. I can think of some use cases (block Google unsafe search, but not safesearch), but generally they just block the whole domain and have a separate domain for the "good" part. (See http://www.safesearchkids.com/, for example.)
And it's not like this isn't the same situation now. Whatever would be possible then would also be possible now, just by using https. This is just making http harder to use.
Besides, what you described is still domain specific. If you want to block only certain Youtube videos, that's where you'll have a problem.
http://stackoverflow.com/questions/18447874/google-chrome-us...
I'm not familiar with how those typically work, but intuitively from an architecture standpoint, that sounds like something that should sit as a filter between the browser and the outside world. Browser as monolith of functionality seems undesirable.
With a browser extension (which you would also need to get installed on the device in some manner) you can inspect the pages as they are displayed.
In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.
* A big warning sign when the site is not using TLS, but not a pop-up
* No warning when the site is using TLS
That would be a correct way to force websites to use TLS.