Finally, Mozilla looks at moving away from 'insecure' HTTP. Maybe Calls to finally move away from HTTP and on to HTTPS are, like grumbles to oust an aging dictator, finding themselves encouraged by the public square/echo chamber of Mozilla's developers' platform. Posting to the Mozilla dev platform, security engineer Richard Barnes said: "In recent months, there have been statements from …
But, how "secure" is https, when even https has been as badly broken as ssh in recent times. I guess https is at least good enough to act as a placebo to tide the unwashed masses though. But, wouldn't it be better to update the spec, and then publish the Spec anywhere other the the N.S of A Land? Yeah this would also exclude the GCHQ-UK as well...
perhaps then I'd might have somewhat more real trust in https then I actually do. Which is to say I really don't.
And, One other thing If https was Once the "Black Tie for fancy Money transactions" (As it should remain so!), what are we going to replace it with, when https becomes the New Black? Its already known that https, and SSLs can't be fully trusted anymore. Sure Patches were published, and some may have even gone outta there way to install these. However its the Ones that haven't that scare the daylights outta me.
I'll bite; how insecure is ssh? With citations..
The SSHv1 protocol was substantially broken. That shouldn't need citation; it's widely known. A web search will turn up plenty of material.
Various issues have been found in the SSHv2 protocol, such as the 2008 CBC SSH decryption vulnerability, and with specific implementations, such as the 2003 OpenSSH server-side buffer-management bugs.
But by far the largest security issue with SSH has always been, and continues to be, poor key hygiene. Many users accept any server key without trying to verify the fingerprint, or get the fingerprint information over an insecure channel. Servers are compromised through other means and keys are stolen. SSH has no standard PKI; it has no standard means for protecting, distributing, verifying, or revoking keys. It puts all of the burden for those things on individual users, few of whom have the knowledge or patience to manage them well.
Not that there are better solutions, generally speaking.
Presumably self-certs wouldn't be trusted (or very trusted) so everyone would have to buy certs for pretty much every domain ?
Not that I find myself buying certs very often, which likely shows, but seeing as self-cert is generally a no-no for trust, Thawte and their ilk (and shareholders) must be getting the bandwagon ready to jump on this.
Interestingly, if you belive the spooks have their paws inside the certificate chain, a self-signed certificate is more secure - assuming you can establish the certificate is valid in the first place.
E.g. if you run your own external server that only a known handful of people use (dept. Webmail etc.)
Well, it all depends.
It's quite possible that governments are saying "use HTTPS for encryption as it's more secure", when they know full well how to circumvent it. It's like the old 1980's "Protect and Survive" thing (or more recently the guide they sent out to homes in the UK after September 11th). Protect your family by sticking a wooden door against a wall in your house and hide under it when the nuclear bombs go off. This will protect you.
It wouldn't. But at least the advice, and if you had to take the action, would make you feel safe. Same goes for this. HTTPS may make you feel secure, but it won't.
I'm completely able to determine which website you looked at using HTTPS, and which choice-tree you made on that website, by (admittedly slightly naughty) monitoring your data packets timing, size, etc.
machine learning of metadata is amazing! who needs plaintext...
This isn't new, published here in 2005, and since then has just got better
"Privacy Vulnerabilities in Encrypted HTTP Streams" by George Dean Bissias, Marc Liberatore, David Jensen, and Brian Neil Levine, University of Massachusetts.
http://scholarworks.umass.edu/cgi/viewcontent.cgi?article=1097&context=cs_faculty_pubs
Encrypting traffic does not prevent an attacker from performing some types of traffic analysis. We present a straightforward traffic analysis attack against encrypted HTTP streams that is surprisingly effective in identifying the source of the traffic. An attacker starts by creating a profile of the statistical characteristics of web requests from interesting sites, including distributions of packet sizes and inter-arrival times. Later, candidate encrypted streams are compared against these profiles. In our evaluations using real traffic, we find that many web sites are subject to this attack.
In my amateur opinion It's not secure, but it's better than nothing.
The major issue here of course is the huge sense of false security it will give to everyone. And as you say, we will need a new standard for really secure transactions, and universal https will make it harder to convince the PHB's to roll it out and the public to use it.
I'm not sure that it couldn't be secure and relatively easy to use, but then it would be expensive. I'm thinking something along the lines of when you buy a computer the price includes 1/2/4 certificates that establish your id and trace back to one of the current trusted CA groups. If the OS and apps are configured to allow easy selection and you use them to establish chains of trust it would be a hell of a lot easier than remembering 36 different passwords all containing all four character types with no (regular + hacker) dictionary words or easily identified number sequences and all at least 24 characters long.
In my amateur opinion It's not secure, but it's better than nothing.
In my professional opinion, it's a huge waste of resources that accomplishes nothing useful in the vast majority of cases. I don't need to read the Register over anything more secure than plain HTTP. The vast majority of HTTP use is information retrieval for which the additional confidentiality, integrity, and authentication benefits of HTTPS - which are not particularly generous in the first place - provide users with no benefit. Traffic analysis of encrypted conversations gives attackers nearly as much information.
This is Mozilla catering to an ideological position.
"The vast majority of HTTP use is information retrieval for which the additional confidentiality, integrity, and authentication benefits of HTTPS - which are not particularly generous in the first place - provide users with no benefit."
But people can build profiles based on the sites your frequent and the pages you read. HTTPS at least obscures some of the trail, blunting some of these side channel attacks.
Certificate providers are appearing with ever cheaper (some promising free) certificates.
(This is covered in the linked discussion thread.)
While they won't be EV certificates, as the underlying drafts do consider levels of security, that aspect is covered.
So your "About Me" site gets a free certificate, but as you are not selling anything you are only looking at providing end to end integrity rather than significant identify validation.
At the other end of the scale a medical site or retailer does need to spend some money on their identity. But if they are not willing, how secure is anything they do?
Certificates cost money. Even if you can use one of the free certificates that were announced recently, you still need your own IP, which also costs extra. So how about all those small websites built by people who don't have a big budget?
Https is fine when you need it and over the top when you don't.
And that's the thing. It shouldn't cost money, or time, or production of government papers to create a site cert.
I don't need to do any of those things to create a PGP key. I just create a key. If I want people to trust my key I can have it signed by other people with whom I have some kind of relationship. I could even pay a CA to sign my key if I wanted.
I think the web needs something similar. Even an unsigned key is still better than plain text if it's presented as such.
You don't need one IP address per site if you use SNI (Server Name Indication). The main problem is that this is not supported by MS Windows XP - which although down to about 17% ... is still some time before web site owners consider it unimportant.
HTTPS is not secure if you can 'own' certificate authorities and/or DNS - neither of which is hard for governments -- so it comes down to who you want to protect against ?
And note even IE6 (XP SP3/2003 SP2 and above) supports SNI. (Not in the original versions of those OSs, but it was added later.)
If you have clients from before those relics then it is quite possible even assuming HTTP 1.1 will be a problem, so you have to have a unique address even when unsecure.
You don't "need your own IP" - the number of web browsers that don't support SNI is getting close enough to zero now.
I'm surprised that Richard Barnes didn't refer to http://letsencrypt.org/ - the project that Mozilla are heavily involved with to make certificate signing free and automated.
At least not in its current form where a key is either signed by a CA which the browser trusts or it isn't. Because we all know how limited a CA's trust is to begin with. It also means security is held to ransom by CAs who impose onerous, usually financial penalties on sites that want security.
At the very least a site should be able to roll a self signed cert without scary popups. It might not stop MITM but it's still better than plain text even if the browser shows the site with an amber warning. Secondly a site cert should be able to be signed by multiple signatories which could be CAs, or other organisations or individuals that have a relationship with the site. Build a web of trust in other words. Thirdly, the browser should cache the key fingerprint and throw danger warnings if the fingerprint or the signatories change. Fourthly, the browser should compare fingerprints to lighthouse sites to see if the client's key is the same as other samples gathered from the site and throw danger warnings.
All of these measures would make security far better than it is right now. At the moment, CA signing is just a tax on security.
Self Signed plus DNSSEC plus a signature in DNS is enough to verify that the site is what it claims to be at least as far as DNS goes (which is good enough for 99% of cases.. it flags MITM and government/corporate snooping which is what we're interested in).. DANE solves the same problem.
No browser manufacturer has shown any interest in implementing anything like it - it does make me wonder if the CAs are pushing brown envelopes in their direction sometimes.
That said, who cares if HTTP is 'insecure'. My home page with pictures of random stuff on it? Who give a stuff if someone can read that on the wire?
"Self Signed plus DNSSEC plus a signature in DNS is enough to verify that the site is what it claims to be at least as far as DNS goes (which is good enough for 99% of cases.. it flags MITM and government/corporate snooping which is what we're interested in).. DANE solves the same problem."
What about government MITM using the actual key, which they can co-opt? They can flood a web of trust and spoof any lighthouse sites, too.
"What about government MITM using the actual key, which they can co-opt? They can flood a web of trust and spoof any lighthouse sites, too."
With far greater difficulty. If I sign a key with one CA they just have to subvert that CA to spoof my cert. If my key is signed with multiple CAs, or with other sites then they have to subvert all those sites.
If they don't then my browser will complain the key looks different from the last time. Or it will complain that it looks different to the one on the lighthouse. Someone will notice.
It'd probably be best if the lighthouses were federated and there were many to choose from across geographic boundaries. Even an unsigned keys would benefit from fingerprint checks and it could offer a measure of protection from MITM attacks.
Nothing is perfect of course so it would be vital to go through every use case and attack angle - key creation, issuance, expiration, fingerprinting, signing, verification, revocation etc.
In case none of the critics of HTTPS everywhere hadn't noticed, the world has long since moved on from the days when we had a simple choice of HTTP or HTTPS. Once you decide to use HTTPS you then have to choose between several options, from self-signed, single site/wild card domain and extended validation (EV) certificates.On top of that, there's multiple levels of encryption strength.
So, we multiple levels of security not two, and all that is really being proposed is removing the weakest tier.
As for hosting providers and certificate costs. There are free options to complement the option of creating your own CA.
Finally, nobody is promising a secure utopia where nobody has to worry anymore, all that is being proposed is that we raise the security bar that tries to stop hackers and the government from hurting us a little higher. It should be about as contentious as deprecating SSLv2 or SSLv3.
"So, we multiple levels of security not two, and all that is really being proposed is removing the weakest tier."
I think you're missing the whole point of security. HTTP isn't the weakest tier, it isn't a tier to start with. Its efficient and perfectly suited to public web pages that have no need to be encrypted. Use security when its required , otherwise you'll get complacency which will probably create more problems than you solve.
But the attack surface has grown to the point that ANY public web page can be an attack vector. That's how Drive-By Attacks work. It's like animal fighters picking any house with the door unlocked to hold their fights. It's just not safe to leave the door unlocked anymore because it can become a big problem at any time. IOW, it's reached the point that a certain level of security is ALWAYS necessary.
PS. To the guy who's worried about their family pictures being picked off the wire, how about your website being co-opted into a botnet or DDoS node instead?
But the attack surface has grown to the point that ANY public web page can be an attack vector. That's how Drive-By Attacks work. It's like animal fighters picking any house with the door unlocked to hold their fights. It's just not safe to leave the door unlocked anymore because it can become a big problem at any time. IOW, it's reached the point that a certain level of security is ALWAYS necessary.
PS. To the guy who's worried about their family pictures being picked off the wire, how about your website being co-opted into a botnet or DDoS node instead?
And https... Is the mythical, magical silver-y bullet needed to save us all again why?
That used to be my view too, but that misses out the other things that HTTPS provides:
* Protection from alteration - if you use a reputable ISP it's less of an issue, but our underprivileged cousins in the US don't have reputable ISPs: HTTPS helps to ensure that the page you fetch from a server hasn't been "augmented" with advertising or malware.
* Protection from interception - should your ISP really be able to see which articles you've been reading? If you still don't care, how about if your ISP sold statistics on which health-related Wikipedia pages you had been reading to your health insurance provider?
* Protection from alteration
* Protection from interception
HTTPS provides minimal protection against either of these - I've never come across a case of HTTP content being altered in transit, and analysis of HTTPS content is still possible, just not very easy.
"I've never come across a case of HTTP content being altered in transit"
Surely you can't have missed the recent Chinese "Great Cannon" articles where they basically inject javascript into unencrypted requests in order to create huge DDoS attacks?
Thats only the most recent example... there are plenty of examples where ISP's injected customer tracking headers and profiled their activity.
http://www.theregister.co.uk/2015/04/10/china_great_cannon/
* Protection from interception - should your ISP really be able to see which articles you've been reading? If you still don't care, how about if your ISP sold statistics on which health-related Wikipedia pages you had been reading to your health insurance provider?
Again this seems to be more of a mere Roadblock, then an actual Solution to me. If I ever caught wind of my ISP ever doing the things you say... (And I'd bet the Big Euro-Players do this too!) Then I'd say it was time for a new ISP... But, if everybody's doing it?! and, its otherwise anonymized. I can't really see a problem with it. Though I grant I probably should... But again >implying this isn't how Google works...
Forcing everything to use HTTPS is like setting up security checkpoints at public roads. They cost a lot, and not only do they not serve any purpose, but they're actually counterproductive, and only slow things down.
Plain HTTP has its place, and there are a lot of web sites and application, where using HTTPS serves no purpose, but only slows things down and increase the costs, with no real benefits.
Also, just because a site is using HTTPS, it does not mean that it's secure, by any standards. It can still leak information and even expose user behavior in a myriad of ways, both on purpose and by accident or by negligence.
"Forcing everything to use HTTPS is like setting up security checkpoints at public roads. They cost a lot, and not only do they not serve any purpose, but they're actually counterproductive, and only slow things down."
You've never been to a DUI checkpoint, then. They set them up at chokepoints so drunk drivers have no choice but to pass them OR stop driving. Either way, fewer drunk on the road meaning fewer drunk driving incidents meaning fewer innocent fatalities.
Plain HTTP has its place, and there are a lot of web sites and application, where using HTTPS serves no purpose, but only slows things down and increase the costs, with no real benefits.
Some agencies have been able to build profiles using HTTP sniffing. HTTPS reduces the available data to sniff.
"Also, just because a site is using HTTPS, it does not mean that it's secure, by any standards. It can still leak information and even expose user behavior in a myriad of ways, both on purpose and by accident or by negligence."
Put it this way. Would you rather visit a place WITH or WITHOUT a lock on the door?
"HTTPS provides minimal protection against either of these - I've never come across a case of HTTP content being altered in transit, and analysis of HTTPS content is still possible, just not very easy."
I have. Mediacom interferes with people's traffic. I used to see occasional download failures on my Ubuntu updates. Why? I looked at one of the failed downloads, and Mediacom was injecting javascript code (to force some kind of Mediacom-related popup to say they were doing network work) into files that are not even HTML, like package lists and so on. I've also seen the thing at the top of the screen indicating this on pages that *were* HTML. Of course if you go for the other main ISP here (Centurylink), they hijack DNS so unknown domains are falsely redirected to an ad/"search help" page instead of properly returning the address does not exist. Other ISPs have felt free to steal banner ad space from whoever is "supposed" to be using it to insert their own ads. There was that case, just last week, about a Bell Canada being sued because they were tracking people to sell the info, and replacing ads; and people who opted out, they just quit replacing the ads but continued tracking them.
That said -- I think the furthest Firefox should go is to put some kind of warning symbol in the address bar or status bar. It simply doesn't matter if certain types of traffic are secured or not, and for something like a video stream it may just be a waste of CPU cycles. I'd also prefer to choose using some site or not rather than have it just quit working because "HTTP is deprecated." As people say above, a nosey ISP could still perform traffic analysis of HTTPS anyway...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
