Hacker News Reader

Comment by haswell | Hacker News Reader

The supposed lack of encryption has not been confirmed.

There's been quite a bit of FUD spreading since this story hit, and I'm convinced that the security researcher involved has some misconceptions about what it means for content to be encrypted. He seems to believe that because he can see the network requests in browser developer tools, communication is not encrypted.

Up to this point, the most solid claim is the fact that thumbnails are transmitted to Eufy to facilitate push notifications. Eufy confirmed this, and pledged to improve the messaging on the options that enable the feature.

The concerns related to the streaming of video is as-of-yet not confirmed, and would indicate a breathtaking lapse on Eufy's part if true. It's been disheartening to watch all of this unfold with too many folks taking pretty huge claims at face value. It could be true, but people are acting as if it absolutely it.

View on HN

The video being streamed to eufy's cloud instance is very much not encrypted:

https://i.imgur.com/nWJywdw.png

This is the RTMP stream from my eufy homebase going to an amazon ec2 instance. Unless RTMP encrypts data inside keyframes they're not using encryption for that at least.

Yeah. As a Eufy owner I'm not really concerned about the thumbnails, especially since they can be turned off.

The video streaming is of more concern, but the reporting has been really weird and bad about it. Why do they keep mentioning VLC like it's some secret hacker tool? If unencrypted, why do they mention a shared AES key?

Really wish a reliable source would give more details.

> Wasabi also noted that the way the remote URLs are configured, there are only 65,535 combinations to try, "which a computer can run through pretty quick.") - From the ars article

It's a bit confusing, but I think they what they are implying is that there is a total of 65,535 possible keys. Devices may be assigned one of those randomly. The URL must send the key and some sort of device ID. It's possible that if you know the device ID, it would only take 65,535 attempts to gain access to the stream.

Did I miss something? I didn’t see anything explicitly stated, but I took that number to mean that Wasabi was doing simple port enumeration—there are only 65,535 ports that need to be checked to enumerate a TCP network interface.

Edit: I did miss a key paragraph—they keys are also 16 bits–port enumeration was just the first place my mind went.

Encrypting something with the same key, that is public, is functionally equivalent to unencrypted.

It's like saying we pay our interns, but the payment is $0.01 per century. It's not true.

> It's like saying we pay our interns, but the payment is $0.01 per century.

https://dilbert.com/strip/2009-01-11

The streaming of video has been confirmed by multiple sources including the Verge and Linus Tech Tips

Sort of, but with caveats.

From The Verge:

> This week, we repeatedly watched live footage from two of our own Eufy cameras using that very same VLC media player, from across the United States — proving that Anker has a way to bypass encryption and access these supposedly secure cameras through the cloud.

Missing is how they connected "VLC can play a stream" to "Anker has a way to bypass encryption". The ability to open a stream in VLC does not automatically imply it is encryption-free.

> There is some good news: there’s no proof yet that this has been exploited in the wild, and the way we initially obtained the address required logging in with a username and password before Eufy’s website will cough up the encryption-free stream. (We’re not sharing the exact technique here.)

Things continue to be fuzzy and it's not clear what they believe "encryption-free" means. Since everyone is being understandably cautious about releasing the actual details, all of this is still frustratingly incomplete information.

On the LTT side, they went full rage mode in their coverage and it became difficult to take them seriously based on how they were discussing the thumbnail issue.

We desperately need an end-to-end review and summary from a reputable security person.

> The ability to open a stream in VLC does not automatically imply it is encryption-free.

Yes it does, doesn’t it? Unless you’re loading keys that are used for decryption into VLC you’re streaming unencrypted data. The URL might be authenticated, but that’s not encryption. The transport (https) might be encrypted, but that’s not what anyone cares about. The data (aka video) should be encrypted with a client owned key.

Yes, I’m crystal clear on the difference between authentication and encryption.

> The transport (https) might be encrypted, but that’s not what anyone cares about.

I was referring to transport encryption. Paul was rather vague about what he meant by unencrypted, and if there’s no transport encryption this is a breathtakingly big issue. So I’d argue that people do/should care about this.

Data encryption would obviously be ideal, but in my mind, that wasn’t even the initial bar to clear after a claim of “unauthenticated and unencrypted”.

The biggest issue with all of the communication up to this point has been a lack of precision/specificity, and that has led to multiple interpretations of the findings and plenty of misunderstanding.

I wonder how much confusion is around people thinking "authentication" when saying or hearing "encryption"

The researcher's claim is about both authentication and encryption, so there's at least some distinction baked into the claim.

I suspect the disconnect is regarding transport encryption vs. data encryption. There seems to be an assumption that transport encryption is a given, but I don't believe that to be true.

A lot. Several comments here even get it wrong.

I wish LTT was better at the research and testing side things. The production value is pretty good but man do they get it exactly wrong a lot.

Reply on news.ycombinator.com