Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink - Intent to deprecate: Insecure usage of powerful features

groups.google.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#51

Post by userbinator »

icebraining wrote: post #17
Danilka wrote: post #14

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 cas…

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…

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.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#52

Post by thomasfoster96 »

organsnyder wrote: post #42
TazeTSchnitzel wrote: post #36

Earlier quoted context omitted.

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 li…

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.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#53

Post by AlyssaRowan »

icebraining wrote: post #47
RyanMcGreal wrote: post #39

Earlier quoted context omitted.

How will Let's Encrypt be different/better than a StartSSL Free certificate?

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?

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#54

Post by thomasfoster96 »

RyanMcGreal wrote: post #39
thomasfoster96 wrote: post #2

Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost. 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] htt…

How will Let's Encrypt be different/better than a StartSSL Free certificate?

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.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#55

Post by arcatek »

air wrote: post #13
revelation wrote: post #10

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.

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?

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#56

Post by CHY872 »

anon4 wrote: post #21
icebraining wrote: post #7

Earlier quoted context omitted.

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.

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.

There are other tools that work for this, though. For example, Fiddler.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#57

Post by CHY872 »

JustGotHere wrote: post #30
anon4 wrote: post #21

Earlier quoted context omitted.

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.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#58

Post by userbinator »

colinramsay wrote: post #11
jbb555 wrote: post #3

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.

"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.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#59

Post by M2Ys4U »

kevincennis wrote: post #40
jpgvm wrote: post #9

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…

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.

4. They should get over it.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#60

Post by ldng »

organsnyder wrote: post #46
ldng wrote: post #22

Earlier quoted context omitted.

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…

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.

Post reply on HN