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 there too... they ship a 'configuration profile' which adds a new email account, so your password is leaving the device in cleartext and being used to create the profile server-side which is then shipped back to the phone and installed, how exactly?
This just gets worse and worse if I understand correctly... 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. In other words, it should be a lot harder to "Accept" these profiles outside an enterprise setting, because it sounds exploitable. What else can you configure "so easily" I wonder?
Then you get into how they are hacking CSS and iframes into the email body, to substitute for Javascript, and actually create a workable user interface. Now this is fascinating, impressive, and deserves further study... Without fully understanding exactly what they are doing, however, it sounds highly abusive of the Mail app's rendering capabilities, and points to exploitable paths within the Mail app that probably need to be tightened up by Apple. If LinkedIn can make an email "act" like that without any opt-in on my part, how would Mallory use the same "feature" in their latest SPAM campaign?
<s>Thanks LinkedIn... really, I'm impressed. When exactly did Walter Bishop start working for you?</s>
P.S. I look forward to following your pending class-action lawsuit for violation of US federal wiretapping laws. Cheers!
It's funny, I read all through that with my rose tinted glasses thinking they'd created a local IMAP server on the phone, which would have been clever (and, I think, doable)... in fact I was running this perception until
"Our proxy server is written in Ruby using EventMachine, which allows it to efficiently handle many concurrent IMAP connections"
And I thought, why the heck would one phone be issuing so many concurrent IMAP connections. Oh my naiveté.
"[iOS 7] opens many IMAP connections at once for searching each folder concurrently. We’re not sure on the upper bound on the number of connections it will make, but saw at least 10 in one case."
I tend to agree that no sane person with minimal technical knowledge would balk at this.
I already know that Yahoo! sells the email addresses of the people I exchange even one email with to LinkedIn and I am repulsed by this. LI then turns around and offers them as connections. I should note I am always logged out from LI to prevent even more evil from them. LI is just evil and should be eradicated.
I highly doubt Yahoo is selling your e-mail contacts to LI. Do you have any proof or citations? I suspect either you authorized LI in the past (and forgot it's still authorized), or your contacts have authorized LI so it's pulling in their e-mails with you, not yours.
I think you might be forgetting that by e-mailing said person, you become part of their contacts too. Should that person decide to import or sync their contacts in linkedin, a relationship between you and that person is established on their server. ie: it's an _undirected_ edge between you and your contact, which they seem to use to display stuff back to you.
These "social" big data companies have a history of doing evil (or sometimes, stepping right up to that line) and $LKND certainly isn't in business to be altruistic.
I thank you for providing examples that prove my point. :) That's mostly speculation along the lines of "evil could have been done, therefore evil must have been done".
Where in the blog post does it say that your credentials are leaving the device in clear text. I know people don't like LinkedIn but I don't think even they would be dumb enough to do this over http.
How are they going to log in to your email account to MITM it, exactly, other than sending your password in cleartext to them? I'm not saying the connection itself is cleartext, but that they will be storing your email password in cleartext(!) to access your account at your email provider...
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].
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.)
I was just musing hypothetically, but can you elaborate on why this is bad? Surely sending an encoded password is better than a non-encoded one, and in a worst case only as bad as sending a cleartext password (i.e. what happens now).
I don't think I was proposing not using TLS, just that if you interpret sending cleartext password over TLS as "plain-text" then sending it encoded over TLS sounds better.
Well, if you hash your password client-side, what's the difference from using clear text? A MITM will intercept your hashed password and use that to login.
It's a good idea IMO, I don't understand why it gets so much flak. A server who doesn't want to know your secret is more trustworthy than one that does, a MITM might be able to hijack your account but he won't see your favourite password and you don't have to trust that the server is hashing the password at their end.
To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent.
Of course that doesn't solve the problem above, but it still ought to be common practice.
"A server who doesn't want to know your secret is more trustworthy than one that does" - I totally agree here, in many ways that's why projects like http://openpgpjs.org/ are fundamentally MORE important that more/newer layers of centralized encryption like TLS that are fundamentally bust in that we have to blindly trust the server. yesyes, i know JS on untrusted/leaky browsers isn't totally bingo but at least someone is TRYING!
They need your cleartext pw in order to create a config profile and that's it. Why would they need to store your pw at all? Once the config profile is setup, the IMAP AUTH request gets proxied through them to the original provider and handled as normal. No need to store any pws at the proxy.
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.
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.
That LinkedIn not violate one of the simplest, most fundamental notions of security: never ever give your credentials to a third party.
Part of being a semi-decent citizen of the internet is also not encouraging users to give third parties their credentials
It is a neat hack. I'd love this if it was "here's how we integrate LinkedIn into our email clients internally". It is novel and it does use CSS in weird and new ways. It should also not be a shipping public product. MITM is bad shit.
To be fair, they specifically mention that they use OAuth for Gmail/GApps.
It seems like they're aware of this but it's hardly their responsibility to avoid building a hack such as this just because Google are the only provider to allow IMAP access with OAuth. If more e-mail providers would allow such authentication, I'm sure LinkedIn would be happy to extend the support.
How about "the world isn't perfect and whilst it would be great to live up to our every ideal, our primary responsibility is running a business and providing a great experience for our users who, ultimately, in the vast majority regularly engage in such egregious violations of sensible security protocol that most-anything we do is unlikely to affect them and in cases where it would, said users are usually sufficiently literate to wish to avoid this anyway".
There is nothing new about this. Putting a proxy into to modify content is as old as the usage of tcp proxies. What is new here is that they have no shame -- I don't expect software from a reputed company to pipe my email through their servers.
To play the devil's advocate, how is this any different morally from what Gmail (and Outlook, and Yahoo) do with their external emails feature? In each case, you give them the credentials for your other account, they pull the mail and display it in their interface (which, presumably, adds some new features that doesn't exist in the other account. Like conversations and tags.) LinkedIn is doing pretty much the same thing.
Everything they do differently is irrelevant as long as the user is asking them to do those things. If Gmail starts showing me fetish porn that's bad, if a fetish porn site does the same thing it's fine.
The only relevant difference is security/privacy, in which Google may be more trustworthy but even that is debatable, regardless of which side of the debate you land on.
Nerd outrage hyperbole much? This is an OPT IN service. You know, only for people who WANT to use it? If it causes you this degree of apoplexy, you are in luck: you don't have to use it.
This service shouldn't exist. It breaks the very concept of email security. They're marketing it as though it's safe. Want hyperbole? Imagine Bayer marketing heroin as safe because you know, it's opt-in.
Why the hell not? Heroin from Bayer would not have the quality control issues Heroin typically has.
It only becomes problematic when you consider that the user is getting themselves into a situation that they do not fully understand and potentially cannot easily back themselves out of.
With drugs that have a high potential to cause harm, we typically force the consumer to consult a professional before allowing them to proceed. Tech is still in the era of patent medicines.
I understand the opinion, but I don't understand the sudden outrage.
LI, Google and Facebook have always wanted your third-party email credentials for Friend Finder-style features. The only difference is that this time we cannot even hope that they delete them after logging in once. Security-wise, it's all the same.
Right, so I should be ok about a company that recently lost 7 million passwords that were 'encrypted' using only SHA1, suddenly getting access to a whole raft more passwords?
Access to this many passwords is a threat even if my password is not one of them.
Finally, it may be opt in, but are they going to explain to the user that they get to keep a password for an account to which they have no legitimate right?
That's not quite true, in that all the emails I send to people who have opted in are now available to LinkedIn. You have no way of totally opting out without encrypting all your email.
For all you know, I (or anyone else you email) could have a simple "forward all email to [email protected]" filter running. If you don't want the second party to share your email with a third party, don't send the second party an email.
Like your average user is going to know the implications of opting into this service.
I doubt they have a warning when you install this "This is going to let us read all your emails AND the emails of people who communicate with you (without their consent)
...oh yes, and get your username / password for your email accounts"
And if I am communicating with someone who installed this hack then I certainly didn't opt-in.
It's only opt-in for the end user. If it were really opt-in, it would be opt-in for the ___domain owners and/or the email providers. Come to think of it, I wouldn't have an issue with this, and it might be worth it for recruiters who use LinkedIn for everything (and in my opinion are doing it wrong).
How are they handling attachments? Are my attachments going through their proxy? Can they see them? What if their servers are down? What if their servers are hacked more easily than some other allowing for all mail passing to be slurped?
I'm curious: given the negativity of the comments why does the post have so many upvotes?
Do people find the technical details interesting despite the privacy concerns?
Either way, congrats to Martin, Sam and others on the launch. Getting something out the door to such a wide audience after working on it for over a year must be quite a challenge.
I think people decided that this was something worth discussing. A lot of times I won't necessarily agree with or like the post that I'm upvoting, but I upvote it so that it gets more visibility and then I can read other people's opinions and analysis of the thing at hand.
Next thing: store your S/Mime private keys on linked in servers to enable the feature also for encrypted mails...
I think LinkedIn should not offer every feature that's technically possible. Things should stay within reason, and some things should not be offered, especially not to non-savvy users.
"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.
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 there too... they ship a 'configuration profile' which adds a new email account, so your password is leaving the device in cleartext and being used to create the profile server-side which is then shipped back to the phone and installed, how exactly?
This just gets worse and worse if I understand correctly... 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. In other words, it should be a lot harder to "Accept" these profiles outside an enterprise setting, because it sounds exploitable. What else can you configure "so easily" I wonder?
Then you get into how they are hacking CSS and iframes into the email body, to substitute for Javascript, and actually create a workable user interface. Now this is fascinating, impressive, and deserves further study... Without fully understanding exactly what they are doing, however, it sounds highly abusive of the Mail app's rendering capabilities, and points to exploitable paths within the Mail app that probably need to be tightened up by Apple. If LinkedIn can make an email "act" like that without any opt-in on my part, how would Mallory use the same "feature" in their latest SPAM campaign?
<s>Thanks LinkedIn... really, I'm impressed. When exactly did Walter Bishop start working for you?</s>
P.S. I look forward to following your pending class-action lawsuit for violation of US federal wiretapping laws. Cheers!