LinkedIn Intro: Doing the Impossible on iOS • Hacker News Board

Re: LinkedIn Intro: Doing the Impossible on iOS

#281

Post by joezydeco » Thu, Oct 24, 2013, 2:15 PM UTC

corin_ wrote: post #245

joezydeco wrote: post #70

Earlier quoted context omitted.

Not just MITM, MITM + DDOS! Now you have 220,000,000 LinkedIn users all running their email traffic through LinkedIn's proxy. I'm sure they have the bandwidth and CPU to handle that.

By that logic isn't every popular website/service in the world a "DDOS problem" because it attracts lots of traffic?

We're talking about mail. There's an equal distribution of users across many IMAP servers, most run by companies like Google and Microsoft that can handle the flow. Now we're redirecting all inbound mail traffic through exactly one host.

Re: LinkedIn Intro: Doing the Impossible on iOS

#282

Post by 616c » Thu, Oct 24, 2013, 2:25 PM UTC

What a disgusting group of bottom-feeders LinkedIn has become. Question is: if I install this unwittingly and they do something to my email server side later-on (not that they have been accused of other vaguely unethical things) how much are they protected by the EULA?

FYI, in the state of NJ, not even your employer has the right to do many things with your work email. They recently decided this. I would love to the impending lawsuit with LinkedIn for similar reasons, but just for advertising.

Re: LinkedIn Intro: Doing the Impossible on iOS

#283

Post by mnicole » Thu, Oct 24, 2013, 3:05 PM UTC

ig1 wrote: post #258

This thread is a great example of filter-bubble thinking. There is a trade-off between security and features here, and while for some people it'll be worth it for others it won't. The majority of posters here are likely developers/technical people for who the features aren't that important and for who security is a much higher priority (because they're thinking about it from a personal email perspective rather than a…

How technical or not you are has nothing to do with how much you care about the security of your email. LI is just hoping that they'll gain trust by being open about their process because they're counting on that "transparency" to help people feel comfortable about installing it.

Re: LinkedIn Intro: Doing the Impossible on iOS

#284

Post by joshdance » Thu, Oct 24, 2013, 3:47 PM UTC

zaroth wrote: post #75

I don't think I've ever gagged quite like that while reading a technical article describing a "neat hack". At first I'm thinking, oh, I wonder how they convinced Apple to let them use some private APIs, and then... curiosity turns to revulsion as soon as I saw that proxy diagram. Good god... LinkedIn MITM IMAP. That is truly terrifying. How would you even go about installing that on the user's phone? Oh, that's in th…

"I'm surprised that configuration profiles can be shipped to an arbitrary device from a third party this way without the user manually installing LinkedIn's certificate as trusted."

The user has to install the profile as trusted. There is no mechanism for auto installing a profile. Similar to TestFlight and the profile you install to use that.

Re: LinkedIn Intro: Doing the Impossible on iOS

#285

Post by ocrickard » Thu, Oct 24, 2013, 4:04 PM UTC

tedunangst wrote: post #236

ocrickard wrote: post #215

Earlier quoted context omitted.

It's worth noting that they specifically state that for Gmail they can use OAuth through the refresh/access token system. Hopefully they do this for all other IMAP servers that support OAuth (there are a couple of them now). However, for traditional IMAP/SMTP servers your point is well taken. They must store your credentials in a restorable state, which, however carefully you do, has difficult security implications.

It's a proxy. It doesn't need to store anything. The server asks for a password, the proxy asks the client.

In order to inject content into the stream, they must be able to decrypt and interpret the stream. It is not quite as simple as a traditional proxy which may not actually have to know the content it is transmitting. They must have all content you send over the stream for a short period of time in-memory in a restorable (if not plaintext) state in order to read from the client's IMAP stream, interpret, then send over the IMAP server's secure SSL stream. The short period of time over which they must keep it does not free them from the security implications. All an intruder must do is gain access, then monitor the stream. I'm not saying that this is impossible to mitigate, just that you're trusting them to do it right.

Re: LinkedIn Intro: Doing the Impossible on iOS

#286

Post by dclowd9901 » Thu, Oct 24, 2013, 4:31 PM UTC

arb99 wrote: post #224

dclowd9901 wrote: post #195

Earlier quoted context omitted.

Maybe we should be discussing Apple's closed-ass OS instead of harping on the only workaround that could possibly exist. Such "creative" measures wouldn't need to be taken if it was simple for a user to augment their email app.

You can't really expect a mobile email client to allow third parties to add their own extensions to it. If they were that fussed they could have tried to make a clone of a email client and integrate their own features. If it was better than the default client, people would use it (I use Sparrow on my iPhone for email, not touched the default Mail app for years)

You know how hard it is to get people to migrate from something as ingrained as an email app? Even a great client will suffer from the migration pain.

And to respond to criticisms of "plugin dev difficulty," that's bs. Browser clients have a world more complication when it comes to supporting a plugin environment, and they make it work just fine.

Re: LinkedIn Intro: Doing the Impossible on iOS

#287

Post by tedunangst » Thu, Oct 24, 2013, 4:47 PM UTC

tghw wrote: post #276

tedunangst wrote: post #212

Earlier quoted context omitted.

I think "your password is sent to LinkedIn" sufficiently and accurately describes what's happening. Adding "in cleartext" typically means via an unencrypted channel. Think about. Think about it. Every time you login into a website via password, your browser sends the password to the server. We don't usually call that out for being in plaintext, unless it really is using http.

I think what they're getting at is that LinkedIn has a plaintext copy of your email password, not necessarily that it got there via some unencrypted channel. And because LinkedIn needs to be able to log in again, it has to store it in plaintext, which then leads to the possibility of another incident where they leak millions of passwords[0]. [0] http://www.zdnet.com/blog/btl/6-46-million-linkedin-password...

It doesn't actually need to store it to log in again. The next time your phone connects to linkedin's proxy, it will provide the password again. Yes, this is basically the same as omnipresent, but not quite. If the servers are confiscated/stolen in a powered down state, the passwords aren't there to recover. You can immediately limit your exposure by not using the service. There are no backup tapes to accidentally go missing.

Also, while rare, the client could theoretically be using something like kerberos to authenticate, even over tls. The password exchange is secret, but the data contents would not be. I don't think the iphone supports kerberos, though.

(All this is not proof that they aren't your storing password, just that it's feasible for linkedin to merely pass it through. And possible, though not probable, for them to never even see the password.)

Re: LinkedIn Intro: Doing the Impossible on iOS

#288

Post by baddox » Thu, Oct 24, 2013, 5:01 PM UTC

freehunter wrote: post #269

baddox wrote: post #222

Earlier quoted context omitted.

I appreciate the data point, but I must admit that sounds very unreasonable, unless you're considering the employer as the attacker. Would the same apply if an employee were using a VPN at work?

We do block VPN on our corporate network, yes. A VPN is a tunnel that hides user activity from our monitoring and DLP tools and use of VPN from our network to the outside is against policy. Likewise, sharing your credentials with a third party is against policy. The attacker is LinkedIn. The employee is the attack vector. LinkedIn is engaging in a phishing attack.

You didn't explicitly answer whether you consider VPN usage to be a man in the middle attack. I understand banning it (as well as this LinkedIn feature) on a corporate network, but not considering either a man in the middle attack.

Re: LinkedIn Intro: Doing the Impossible on iOS

#289

Post by georgemcbay » Thu, Oct 24, 2013, 5:12 PM UTC

Privacy issues aside, have we really set the bar this low on what is or isn't technically "impossible"? Because if so, that's terribly sad and as an industry we should all be ashamed.

Re: LinkedIn Intro: Doing the Impossible on iOS

#290

Post by epo » Thu, Oct 24, 2013, 5:28 PM UTC

dclowd9901 wrote: post #195

nostromo wrote: post #54

This is a truly awesome hack. Good job! The value for LinkedIn to vacuum up my email is immense! They'll know everyone I email and the content of the emails as well. They'll know where I shop and what I purchase. If I send a private email to a friend who has this installed, I've now unknowingly bcc'ed LinkedIn. Not only that, but they know this for the entire history of my email account! The person I stopped emailing…

Maybe we should be discussing Apple's closed-ass OS instead of harping on the only workaround that could possibly exist. Such "creative" measures wouldn't need to be taken if it was simple for a user to augment their email app.

Yay! Clueless Apple bashing. This thread has everything now.