Blink - Intent to deprecate: Insecure usage of powerful features
groups.google.com
groups.google.com
Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take.
The only solution is to restrict privileged status to privileged ports. However, that would also limit the usefulness of the exception, since dev servers usually run on unprivileged ports (that could be changed, of course).
1. Their user interface is slow and clunky. Acquiring/renewing certificates is a PITA.
2. For organizations, they require both extended personal validation and organizational validation. In addition to being fairly expensive ($100 annually, each), they require you to send images of a bunch of sensitive personal documents (passport, credit card, etc.). While you can often slip by and get certs without them realizing you're getting them for an organization, once they've noticed and flagged your account, each cert requires manual review.
3. Their website hasn't been updated in a number of years. They do not give the impression of being a healthy company.
No excuses, people. Give it a few years and we'll be seriously talking about turning http: off, or at least putting security warnings on it, denying cookies and scripting, etc.
You don't still use telnet, do you?
https://www.firebase.com/docs/hosting/command-line-tool.html
EV-SSL is kind of meant to deal with that if you want to pay the fees.
But this seems more in line with a movement towards HTTPS by default and marking HTTP as insecure.
So, all this is to get an encrypted connection?
This strikes me as odd too.
What's the difference between an automated SSL certificate generator and just having the browser accept self-signed certificates?
openssl is also an automated SSL certificate generator, but it only produces self-signed certificates. So why not just accept self-signed certs?
A green padlock indicates this additional level of trust, i.e. authenticity (verified through any method any trusted CA may choose), which a self-signed cert can't provide.
For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.
And it's not like there aren't already strong enough protections in place. Try for example visiting this mock attack site:
http://feross.org/html5-fullscreen-api-attack/
In every browser I tried it was already obviously fake. It doesn't work already with current security tech:
1) browsers ask for fullscreen permission (with big unmissable dialogs)
2) emulated fake layout is very different from real layout (missing all per-user specific browser settings, e.g. bookmarks or extension buttons or any theme customizations, also font rendering looks different)
3) emulated fake browser UI doesn't respond to interactions in the same way as native UI
A better solution would be to keep showing a message telling you it has gone fullscreen like browsers currently do.
Even much more primitive phishing will still work on them (just think about those "you have virus / clean your computer" ads from past, with images looking like Windows pop-ups, or remember how those "Nigerian prince" scams intentionally use broken English to selectively address more gullible folks).
These new proposed security measures will not help those people much, they can still be phished from within browser tab content rectangle.
Instead these changes will just basically kill whole class of web applications for a benefit of small subset of population phishable enough with fullscreen attacks but immune to content rectangle attacks.
-----
BTW recent Lenovo Superfish fiasco has shown us that in fact you can't even trust native browser security UI elements. Those real UI green locks on https pages can be as misleading as those JS/HTML generated ones.
I would much more prefer browsers to secure me from known rogue certificates attacks than from hypothetical hard-to-pull-off fullscreen phishing attacks.
They still are. Most of the time someone posts a WebGL demo here, they fail to run on my devices that have no issue with OpenGL ES 3.0 for native applications.
I don't really understand why this is the case — surely they'd just serve them over HTTPS and be done with it?
Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.
Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? Especially for services that might need to communicate with things other than browsers and might not want the overhead.
You shouldn't. Feel free to not those browsers.
Especially for services that might need to communicate with things other than browsers and might not want the overhead.
If you're not communicating with a browser - don't use HTTPS. It's not like you're prevented from supporting both protocols.
"Fake UI" or "user-specific browser settings", "font rendering", are things that don't even (make sense/matter/seem odd) to him.
Ironically, my great-aunt, who's almost 90 but was always somewhat of a "techie", would notice something weird and call me or her son.
But I guess my point still stands.
It's just another Flash that hides behind being "html5" (as if they makes it all ok). At the end of the day it's proprietary code executing on my machine that I have little or no control over. It's not just a security risk, it's also a stability concern and generally a terrible idea.
Copyright enforcement should be left to law, content companies shouldn't be trying their hand at it. Who knows, maybe if their content didn't come wrapped in utter crap people might actually part with money for it.
You would prefer that all copyright violation is a criminal matter rather than a civil one?
There was never any chance that large content companies were going to be okay with serving unencrypted media over HTTP. So the choices were:
1. No major film or television content on the web
2. The survival of Flash/Silverlight
3. EME
I'm not crazy about any of those choices, but #3 seems the most reasonable.
What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in case of portable devices) on it?
SSL does not guarantee the security de-facto. Also, there is plenty of personal data that is being passed through a non-encrypted connection, which is way more valuable. If this is an attempt to increase amount of secure connections, it is a very inconvenient one. Why not keep giving bonus point for using it (like SEO higher ranking) rather than making pure HTTP not usable.
Because otherwise a MITM can abuse the fullscreen feature. SSL is a way of ensuring content integrity, not just privacy.
I do think we should have a way of signing content without mandating encryption for these use cases, but until we do, HTTPS is the only choice.
SSL has it, it's just usually disabled by default - null encryption with non-null MAC.
> What if a service streams video; […] spending extra power (battery, in case of portable devices)
Then they'll encrypt, because it's cheap. YouTube could do it. Only Netflix is making a fuss because they want to legitimize their DRM as a security layer.
It's not 1995 any more. Today even low-end cell phones are orders of magnitude faster than CPUs were when SSL was slow. We've got fast ciphers and hardware-accelerated decoding.
> SSL does not guarantee the security de-facto.
The problem is that HTTP is de-facto guaranteeing insecurity.
• HTTPS is the new HTTP.
• HTTPS+HSTS+preloaded pinning is the new HTTPS.
Instead of this, maybe require there's a user mouse event on the call stack for things like fullscreen.
I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.
2) If HTTPS is required, MITMing can't be used to take advantage of permissions you've granted to existing sites
They don't want to prevent you from fullscreening on HTTP. They want to prevent websites from fullscreening your browser on their own accord using the Fullscreen API, which is quite different.
HTTPS might be expensive for 80% of the sites, but 80% of sites don't use the Fullscreen API anyway.
Frankly, I think people here should read and understand more carefully what the Chrome team is actually saying before accusing them of nefarious intent (it's fine to accuse them after carefully understanding, of course).
That said, I've gone back reread the mail and you're right, I probably jumped the gun a bit here. I did understood "migrate these features to secure-only" as disabling those features on non-HTTPS at mid/long term.
I think HTTPS "all-the-thing" trend is not necessarily a good thing. It is not _always_ needed, it can had complexity, it has a cost a it leads to an over simplification of security in general. It is a trend that annoys me a bit and I sometimes overreact about it.
Note that I distinguish HTTPS "all-the-thing" from HTTPS "when and where it is needed" for security concerns.
If I click on http://foobarbaz.com anyone who can successfully mess with that HTTP connection (a much wider universe of attackers that I have less visibility into, especially if I frequently use different networks [home, work, mobile, etc.]) could have been responsible.
1. Bob often views videos on YouTube, so he grants youtube.com permanent access to the fullscreen API.
2. Eve runs an open wifi AP near a coffee shop. The AP includes a proxy server that redirects youtube.com requests to Eve's own server.
3. Bob connects to Eve's AP. When he goes to youtube.com, he instead gets a response from Eve's server, which is designed to imitate a full desktop environment. Since Bob has already given youtube.com access to the fullscreen API, the browser grants Eve's site fullscreen rights without notifying Bob.
My point is HTTPS has a cost and is a barrier of entry, the trade off isn't always worth it, IMHO.
And the cost of HTTPS is pretty low nowadays. Cloudflare even offers it on their free plan, and it doesn't require you to set it up on your own server.
So you're suggesting trading a potential MitM but an official Cloudflare MitM ? :)
It is not only about a money cost, it is also about a complexity cost and false sense of security. HTTPS is not the be-all and the end-all of security. Just a step to security, if/when you need it.
I'm not arguing HTTPS is not needed. I'm the first to push for when needed. But it is not needed for watching cat videos, sorry.
This suggests you did not, in fact, see the problem. The attacker in this scenario is not limited to replacing YouTube videos. They can make anything they want appear on the user's screen, including things like a Google login page, or even a bank login page.
I do not care about the downvote, my opinion is what it is and I maintain my position. As I see it (me not been a field expert), HTTPS Everywhere will not save the world. You will still have people connecting to the wrongly spelled site (HTTPS or not). Some will even have a false sense of security which would be counter-productive.
I access my through HTTPS explicitly typing the URL. My bank ask confirmation out of band for every dangerous action (by SMS). IMHO, one should be educated to take necessary precautions. In Europe, banks have to cover frauds, the positive side effect is that some banks started to educated user on security (it's cheaper !). I don't know how it is in the rest of the world.
Just to be clear, I am not against HTTPS where it makes sense. I am against HTTPS everywhere as the only security measure. Because, that's what it will come to, "We have HTTPS so we're good, security checkbox ticked". That is not, IMHO, not a good way of thinking about security.
I guess my point is HTTPS everywhere is not the solution and should rather/also educated better/more on the risks of Internet.
That said, I wouldn't mind being pointed at a screencast/viedo (on youtube ;-)) showing how the scenario you refer to would unfold.
Of course there are still issues. The certification process has plenty of flaws (such as the fact that an attack on a single one of the multitude trusted in most browsers is just as good as attacking all of them), and there are still other vectors (such as the mistyped URL example you provide). However, HTTPS still provides a clear—and increasingly low-cost—advantage over HTTP.
Many people do that, and it's quite safe to do so with a modern browser. Were it not, it would not be safe to do so in any context, because man-in-the-middle attacks are possible on any connection, just extra easy on wifi.
> I think there is a point where you have to apply common sense.
As you are demonstrating quite well here, "common" sense is not good sense. It is stopping you from doing things which are safe, and making you advocate for things which are unsafe.
> I access my through HTTPS explicitly typing the URL.
You would be typing the URL into the equivalent of a remote desktop session. That is what you're not understanding.
> My bank ask confirmation out of band for every dangerous action (by SMS).
1) Most banks do not do that.
2) SMS is not a secure channel.
3) Banks are not the only target (again, google/gmail accounts are another good example).
4) Even if they could not transfer funds, they would now have a great deal of information about your finances right on their screen.
> In Europe, banks have to cover frauds
They mostly do in the US, too. This makes consumers less likely to care about security.
> I am against HTTPS everywhere as the only security measure.
No one has advocated that. If you think they have, you have become very confused.
Now you're misrepresenting what I'm saying. I'm not saying to not use HTTPS when it is needed. I am saying it is not enough. That you argue that HTTPS is mandatory because you want to do your banking on open wifi hotspot baffles me. You should not be doing banking on open WiFi hotspot. PERIOD. I also say putting HTTPS everywhere does not help as much as you think. I am _not_ saying HTTPS is a bad thing. HTTPS is not a substitute for caution.
> You would be typing the URL into the equivalent of a remote desktop session. That is what you're not understanding.
For that to happen the phishing server would have to draw a browser shell (ok, feasable), my list of tabs (still doable) and my "OS" taskbar/menubar, that, is not possible today. I would even argue it would be harder to mimic the 'outsides' of the browser then to present a fake a website. Website change all the time and people don't pay as much attention. Robbers prefer easy targets.
I'm not saying there are not such phising sites but I have yet to see one crafted with such attention to detail (which I think is not possible anyway). Most of those I have seen are not very elaborated. And it does not matter. They feel/look secure enough. HTTPS or not.
>> My bank ask confirmation out of band for every dangerous action (by SMS).
> 1) Most banks do not do that.
> 2) SMS is not a secure channel.
SMS is not a secured channel. True. But it is a _different_ channel and that is the point. Most bank dont do that but they should.
> 3) Banks are not the only target (again, google/gmail accounts are another good example).
Yes, and not connecting to those site on an open WiFi hotspot is still a good practice. Again, HTTPS or not.
Please articulate why you do not believe that is possible.
> Yes, and not connecting to those site on an open WiFi hotspot is still a good practice. Again, HTTPS or not.
Please articulate why you believe that is good practice.
Don't say "common sense". State the underlying basis of your belief.
And finally, please explain why, even if everything you believe is accurate, it is somehow a negative thing to prevent attacks from being carried out on users who do not share your beliefs and paranoia. Social darwinism?
Actually, one more: Even if no one did any of these things on open wifi, they would still be vulnerable to these attacks, since every internet connection is vulnerable, so please explain why protecting people who do share your beliefs is a bad idea.
Nope, still got another: I travel for work with some frequency, including internationally. When doing so, frequently my only available option is open wifi. Please explain why my livelihood should be destroyed because you, an admitted non-expert, believe using open wifi is a bad idea?
Oh, hey, yet another: Please explain why, even if doing these things were unsafe now, you oppose efforts to make them safe!
http://en.wikipedia.org/wiki/Bank_of_America
Anyone in the middle between you and Wikipedia servers can apply the phishing attack.
If you go here:
https://en.wikipedia.org/wiki/Bank_of_America
Only Wikipedia editors/admins can perform the attack.
There is so much you can do to help with phising. HTTPS everywhere is not IMHO a solution. It could even lead to a false sense of security. It's more, HTTPS is the tip of the iceberg. Your bank should send a SMS to confirm any potentially litigious action (mine does).
Security is a trade off. Some sites that really need high levels of security (and they are not that many) could say, look, I have HTTPS, you're safe. Errr ... no ... they are some much more you could/should do.
Which isn't to say there's no reason to only allow fullscreen over SSL, but I can't offhand think of one.
Besides, a similar attack could be carried out even without the fullscreen API - just replace the page contents when the link is clicked, and the same people who don't notice the changes in UI will probably not notice the address bar either (it also doesn't help that browsers are attempting to deemphasise/hide the URL...)
If they wanted "tighter controls", they should just remove the fullscreen API. I guess a lot of web developers won't like it, but the user has always had the ability to fullscreen the browser if he/she wanted to.
What simplicity is being destroyed here? If anything, they're making it more costly to make complex websites.
For the rest of us who need tools to watch HTTP 1.1 this changes nothing.
A more usable way is: Set up a proxy on your system that decrypts and re-encrypts all SSL traffic - effectively acting as the browser. It re-encrypts with its own (auto generated) key, but you've put it's signing key in your truststore so your browser doesn't care. In the middle, you can see what's going on using Wireshark.
It's what most corporate firewalls do, as well as that Lenovo software etc.