Blink - Intent to deprecate: Insecure usage of powerful features(groups.google.com)
groups.google.com
Blink - Intent to deprecate: Insecure usage of powerful features
https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ
95 comments
If everybody gets an SEO boost, there is no boost. :)
If you want to be pessimistic about it, anyone who doesn't adopt will get an SEO drop
Well, then there's a SEO penalty for not using it...
Except that not everybody will do it since day 1
What is the value proposition of a certificate from an automated provider? What is the verification? If someone wants to get a certificate for a domain that has ebay or paypal as part of the domain then spoofs those sites, will the automated provide flag this or are the users going to see the nice lock in their address bar? Why bother and not just allow all self signed certificates?
Ok, so how does that keep a site like paypall.com (or any example of a common off-by-one-letter domain) from getting a certificate?
Nothing currently stops paypall.com getting a certificate and the technology is not meant to do that.
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.
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.
I'm pretty sure the certificate companies when doing their verification stop obvious attempts at scams.
So, all this is to get an encrypted connection?
So, all this is to get an encrypted connection?
> 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?
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?
The difference is in the certificate chain. One of the conditions for being a CA is verifying domain ownership before signing a certificate. In return for this, browsers will trust their cert. As long as a CA keeps this promise, they get to keep their cert and use it to sign certs for others. If they break this promise, their cert will be revoked and browsers will start showing warnings on sites that used them as a CA.
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.
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.
How will Let's Encrypt be different/better than a StartSSL Free certificate?
I used to use StartSSL, but abandoned it for a few reasons:
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.
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.
Free certificate revocations. StartSSL was crucified for charging $25 for revocations, and not waiving the fee during Heartbleed.
This, 100%. They also plan to adopt Certificate Transparency, I believe. And it'll hopefully be trivial to set up, once the scripting is all finished.
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?
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?
By the looks of the Github account, Let's Encrypt will let me programmatically get a certificate for free when I run non start in my node app, or easily set up HTTPS on my Apache web server, among other things. All for free with minimal work.
Its two commands for free static https hosting on Firebase
https://www.firebase.com/docs/hosting/command-line-tool.html
https://www.firebase.com/docs/hosting/command-line-tool.html
Until ad networks make a serious effort to enable https on their networks and CDNs, I can't run https on any of my sites. Mixed content security means no http ads and thus no revenue.
What about HTTPS for local testing, though?
Reading through the W3C draft linked to in the announcement, localhost over HTTP will be considered probably secure.
Make sense: if you can run a web server, you don't need the browser's help to do a phishing attack.
Not necessarily. Any user could run a web server on an unprivileged port. While this is a far-fetched scenario—it requires the attacker having access to a different user's account on the machine, but not the victim's (if they had access to the victim's account, they wouldn't need to take these measures)—it is possible.
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).
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).
I might suppose that web browser developers might be of the view that if someone has been able to run a web server on your computer (even under a different user account) and done so with malicious intentions, your security problems are beyond the control of a web browser. With that sort of access, the attacker might as well have made off with all of your HTTPS-only cookies and browser history, changed your DNS settings, etc.
Uhm, I strongly disagree with making fullscreen https only feature.
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
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
The point of that article was that people don't notice subtle changes, especially when their not tech savvy/tired after a long day of work/whatever. Also someone pointed out in the comments that some people tend to ignore changes and click on whatever to get to their destination.
Yes, that's true. But for people who don't notice changes there isn't much help anyways.
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.
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.
And article is ignoring that the site can then add https and do that fullscreen attack anyway.
A better solution would be to keep showing a message telling you it has gone fullscreen like browsers currently do.
A better solution would be to keep showing a message telling you it has gone fullscreen like browsers currently do.
And that's one of the reasons webapps will be always second-class citizens vs. native apps - because browsers have to limit tons of useful features to keep users protected from various attacks.
For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.
I don't really understand why this is the case — surely they'd just serve them over HTTPS and be done with it?
I don't really understand why this is the case — surely they'd just serve them over HTTPS and be done with it?
This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case. The commenter doesn't seem to agree with this reversal, or hasn't realized that it is occurring.
I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted.
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.
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.
I agree with you. To anyone who's been paying attention there's a pretty palpable recent rush to encrypt everything (largely as a response to the Snowden revelations). There should be a genuine debate about the implications on social, political, ethical, and technological levels, but instead we only hear about the bogeymen of NSA spying (although, this is a legitimate concern). I'm a strong advocate of cryptography, but I think we need to come up with a way to speak meaningfully about it, instead of just rushing to encapsulate all human expression within cryptography.
On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.
> On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP?
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.
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.
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?
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.
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.
I guess that's why it's just a proof of concept. Also, those three points you raise would certainly deter you and me from being caught, but e.g. my father (in his early 50s), who uses Word, Internet Banking, Email, pretty much the same way for 20 years and does not understand, for example, the concept of a "folder", he would assume the computer is displaying normal behaviour, because he doesn't have the knowledge to assume otherwise.
"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.
"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.
Well, fullscreen wouldn't have to be HTTPS-only, just the permission wouldn't persist for HTTP.
I didn't get that impression from the mailing list post. They were exploring ways of adding more security depending on context. That's a long way from "https only feature". Perhaps the user just needs to acknowledge the switch (instead of just being notified of it)? Or set a browser flag to override?
> For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.
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.
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.
Though only tangentially related I do wish EME had been properly shot in the head.
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.
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.
At least it's properly sandboxed.
I view EME as sort of a necessary evil.
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.
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.
I believe the W3C is an open standard consortium. What Big Entertainment wants to do is none of its concern.Let them use a plugin,there is already an interface for that. EME isn't different from a plugin, that's what you don't understand.I does less sure,but it still relies on something people will have to install on their computer, or even worse, encryption at the hardware level.
4. They should get over it.
> Copyright enforcement should be left to law
You would prefer that all copyright violation is a criminal matter rather than a civil one?
You would prefer that all copyright violation is a criminal matter rather than a civil one?
"Law" isn't limited to criminal cases. Nothing in the poster's statement precluded a lawsuit from being an enforcement mechanism.
But that's the way it currently is. And so little 12-year-old Janie gets a $3,000 "demand to pay" letter for downloading a Britney Spears song with the threat of a lawsuit that will take her family's house away if she refuses. Maybe having a somewhat impartial legal entity in between is more protection for the consumer.
What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code?
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.
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.
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?
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.
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.
I do think we should have a way of signing content without mandating encryption for these use cases
SSL has it, it's just usually disabled by default - null encryption with non-null MAC.
SSL has it, it's just usually disabled by default - null encryption with non-null MAC.
DevTools can whitelist dev domains:
https://w3c.github.io/webappsec/specs/powerfulfeatures/#deve...
> 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.
https://istlsfastyet.com/
> 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.
> 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.
https://istlsfastyet.com/
> 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.
Bizarre. HTTPS isn't a guarantee that a site is not malicious. Its not like I could go to a CA and ask them who they signed that cert for and take on any kind of legal responsiveness. Such is the state of the CA system that they will give a cert to anyone with access to a domains MX and some bitcoins.
Instead of this, maybe require there's a user mouse event on the call stack for things like fullscreen.
Instead of this, maybe require there's a user mouse event on the call stack for things like fullscreen.
The intent is to prevent man in the middle -attackers from getting access to those features.
Why would they need the fullscreen access? I could see the interest for cookies or local storage, but fullscreen?
So they can pretend to be your entire browser.
Is http://localhost / 127.0.0.1 considered secure?
From what I can gather, yes to the former, probably to the latter.
I wonder how many "internet of things" things will stop working due to these changes.
Aren't IOT typically servers not clients?
I can't imagine their pages require access to powerful APIs.
The word has been mangled to the point of no recognition, but for low power applications you would want the IOT device to be a client pushing when changes occur.
Basically they are destroying the simplicity of the internet in order to push their own agenda. I'd get annoyed about it, but it's not going to be long before it all collapses under it's own weight and something new and lightweight turns up to take over from what http used to be good for.
Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work?
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.
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.
Memories of receiving tons of full-screen popup and popunder ads (and without any close buttons, address bars, or any other browser controls... thankfully I knew what Alt+F4 did at the time!) may have biased me a bit... but I think the fullscreen API is a bad idea in general - the browser should not allow scripts to do things that modify the UI outside of the content area of the page. If the user wants to resize the content area, he/she should do that through the facilities the OS window manager already provides.
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.
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.
Maybe I'm dense but I don't see how requiring HTTPS would solve phishing attacks. To me it falls in the social engineering realm, people clicking link in their mail thay really should not. Having an extra 's' in the URL will not change that. Am I missing the point ?
Here's the scenario they're trying to prevent:
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.
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.
Ok. Here I can see the problem. That said, does this happens really that much ? Shouldn't we educate on open wifi instead ?
My point is HTTPS has a cost and is a barrier of entry, the trade off isn't always worth it, IMHO.
My point is HTTPS has a cost and is a barrier of entry, the trade off isn't always worth it, IMHO.
Open Wifi is not necessarily the problem. An AP with a shared password (99% of them) is also vulnerable, if the attacker also has a password. It's not reasonable to expect people to never use YouTube on public WiFi hotspots.
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.
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.
Do you really need to secure Youtube viewing on a public WiFi hotspots ? Unless you want to sell DRM movies, I don't see the need for HTTPS here. Unless you want privacy on a public network. But we're not talking about security anymore.
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.
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.
> Do you really need to secure Youtube viewing on a public WiFi hotspots ?
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.
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.
You're probably right, I am not a security expert and might not be seeing the whole picture. You log into your bank website connected to an open WiFi hotspot ? I never would do that. I think there is a point where you have to apply common sense.
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.
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.
> You log into your bank website connected to an open WiFi hotspot ? I never would do that.
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.
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.
> 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.
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.
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.
> and my "OS" taskbar/menubar, that, is not possible today
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!
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!
HTTPS is not a panacea. However, it does provide security advantages over HTTP, even when the communication itself does not have particularly sensitive content. While not impenetrable, HTTPS does provide a reasonable assurance (or at least a higher hurdle for an attacker) that the server is actually officially representing a particular domain.
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.
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.
If I click on https://foobarbaz.com and get phishsed then I know that either foobarbaz.com had something to do with it or certificate verification has been compromised.
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.
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.
The thing is most phising attack don't even bother going that far, some people will click on https://foobazbar.com for a "rightly" crafted mail. HTTPS does not prevent anything here.
1) You need to have been approved by a CA to get a TLS certificate
2) If HTTPS is required, MITMing can't be used to take advantage of permissions you've granted to existing sites
2) If HTTPS is required, MITMing can't be used to take advantage of permissions you've granted to existing sites
1) Expensive for no good reason for 80% of sites out there
2) We agree it is useful in some case. That what makes it hard to go against, because it seems a reasonable objective. The problem is where do you put the limit. I don't "fullscreen" my bank account. To me, forbidding fullscreen on HTTP is quite over the top but fits Google agenda of HTTPSing All The Things.
I don't "fullscreen" my bank account.
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).
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).
Google elsewhere, another time, kind of said that they'll be pushing for HTTPS "all-the-thing". It is their agenda. An agenda I do not juge nefarious, just one I disagree with.
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.
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.
Go here and click on the link to BoA website in the side bar:
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.
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.
That is why I don't click on links to my bank but rather type the URL ;-)
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.
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.
But that attack works just as well if feross.org uses SSL, doesn't it? I'm not sure what MITM+fullscreen gets an attacker that they don't get from either by itself.
Which isn't to say there's no reason to only allow fullscreen over SSL, but I can't offhand think of one.
Which isn't to say there's no reason to only allow fullscreen over SSL, but I can't offhand think of one.
I don't understand your criticism. They are requiring HTTPS to use complex/advanced features. You're still free to serve your handwritten HTML 4.0 over unencrypted HTTP 1.1.
What simplicity is being destroyed here? If anything, they're making it more costly to make complex websites.
What simplicity is being destroyed here? If anything, they're making it more costly to make complex websites.
One thing I'll definitely miss is being able to look at traffic with wireshark. I've used it to great effect when I had to debug a failing service and wanted to see exactly what the browser was sending that was tripping it.
Is it not posible to grab the binary stream and decode it, just like the browser would, on the fly with wireshark?
You'd have to find the key used, which would be hidden inside of the browser's memory (and possibly hard to get out). Wireshark will do that for you, but it's not ideal.
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.
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.
There are other tools that work for this, though. For example, Fiddler.
I guess he's one of those who can decode both transfer-encoding and content-encoding in real time while watching tcpdump output.
For the rest of us who need tools to watch HTTP 1.1 this changes nothing.
For the rest of us who need tools to watch HTTP 1.1 this changes nothing.
"Agenda"? What, the nefarious agenda of making things more secure for everyone?
While in this case it could be going a little too far since I see how some of these APIs could be used to gather quite sensitive information, it might be a sort of knee-jerk reaction against the trend of "it's for your security" restrictionism that is becoming very common today; and it's a reaction that I think is long overdue... "more secure for everyone" is the same reason often used to justify mass surveillance.
Not just that.... did you see the recent report about suspicious root CAs installed on Macbooks? Have you heard about the DigiNotar case where Iranian agents infiltrated the CA? Do you know that private companies MITM HTTPS connections to spy on their employees gmail and facebook activities under data loss prevention policy? HTTPS is clear text to nation states because security is ultimately a physical business. All solutions I've heard of for the "bad CA" problem are themselves insecure. So the only thing the forced moed to https is doing is breaking the internet, adding overhead and creating a two tiered security model: nation states can spy but petty criminals can't. It's fake security in the end, and yes it does come with other concerning implications. But you can't stop it. Tim Berners Lee couldn't. He tried. He continues to try. No one will listen.
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.
[0] https://letsencrypt.org