I've been on the fence about it for a year now. I get more recruiter spam than value.
I'm also a bit too old for the schadenfreude that accompanies news of my overpaid friends getting canned. I'm running my own race these days and I've never been happier since I stopped comparing my lot in life to the few lucky SOBs I know that survived the cull of sub-prime.
I think a better strategy is (1) your own domain and/or (2) a site on github with actual code to validate* your talents.
*I hate those "Joe Schmo supported you skill in [insert banal technical skill here]" messages. I once put down C++ because I had been working with it for a couple years. Then, I thought better (I would not take a C++ programming job. Period. Hate that language.) and took it off. Next thing I know, I've got coworkers supporting my C++ acumen and LinkedIn trying to push it back on my profile. Ugh. I call that invasive feature creep.
On top of that, they seem to leave the backdoor open a bit too much for a company with $20b market cap.
LinkedIn's value is not centered around your personal profile - it's about the other people that are linked to you and will always have an up-to-date CV/contact details for you.
It is a self-updating rolodex, Outlook Contacts list, phone book, whateveryouwanttocallit.
I really don't want to bookmark 300+ individual pages that all have different creative layouts, get moved, etc. My LinkedIn profile stays up-to-date, you update yours, that's the implicit deal. And we all profit from it. all being defined as a western work related group, english spoken. this is not facebook. Link your gitbub repo from there, absolutely, good idea, but having LinkedIn as your standardized contact info is very valuable.
is LinkedIn managed in a bad way? sure. But for some reason the modern business world has chosen it to focus on it. Xing and other local players never grew enough. the benefits of starting out it in the US. all the surrounding crap they're building is fluff, their core feature is being a global rolodex. would love to slap sense into their product management team.
>I think a better strategy is (1) your own domain and/or (2) a site on github with actual code to validate* your talents.
That's because their target audience is not restricted to the tech savvy. Not everyone knows how to host and maintain their own domain. Not everyone uses github or know what git is.
This was basically why LinkedIn came into fruition in the first place.
> I think a better strategy is (1) your own domain and/or (2) a site on github with actual code to validate* your talents.
Possibly, but that's for programmers. There are more professions out there.
I just closed my account too. The help page said that my account would no longer be visible on LinkedIn, but after closing and logging out, I still get the "sign up to see the full profile" bait on visiting my old URL (search result from Google).
The DNS was not exactly hijacked, there were issues inside of LinkedIn's top level DNS provider whom were delegating www.linkedin.com authorization to unauthorized nameservers, namely NS[SOMETHING].ztomy.com. The ztomy DNS replaces its delegated domains to point to a domain parking page if there is no record exiting. These changes were then propagated to other nameservers and thus to the end user. End result, dns doesn't point where you think it does.
Au contraire; having the delegation going somewhere unwanted is practically the definition of a DNS hijack. The question is - how did that happen? A malicious third party? a blundering sysadmin? or a bug in some provisioning code?
It does sound like LinkedIn's NOC are playing the blame game already. Well, I guess they've gotta get all those spamming recruiters & sales reps back online.
That makes sense since we just saw the same problem with USPS realtime shipping rates via production.shippingapis.com, which seems like an odd attack target.
edit: and I mean the exact same issue, it was resolving to a confluence owned IP that was serving a squatter page for the domain.
Because they allow HTTP, which for any sensitive site is a very bad idea. Their setup enables MITM attacks even against users that are careful to always use HTTPS for visiting LinkedIn.
One of the DNS issues I tried to fix with NIS+ was the 'maintaining a list of trusted servers' problem by distributing the management of the authoritative servers. Trust was built bottom up, and authority came top down.
The way it worked was that clients used a 'coldstart' file which was the (small number) of servers you trusted to provide your namespace lookups. You to their public key and you put it into your coldstart file. Similarly, a server put the key(s) of the servers it trusted above it in the name space in its coldstart file. And at company 'root' level was a set of servers run by a trusted authority.
Locating the authoritative name server for x.y.z from p.q.z (same as DNS root is rightmost) client in x.y.z asks its server for a trusted y.z server, gets it, and asks that server for a trusted z. server, then asks that server for a q.z. server and finally for a p.q.z. server. Once this has happened once you know trusted servers can can jump to the nearest one to start resolving a new path in the namespace.
It was slower on initial lookup and then just as fast as DNS on later ones.
It had the downside that compromised (or borked) high level servers could send you on a different path to different root if the server above them was incorrect.
It is one of the more fun problems in the whole name/directory service space.
DNS SEC doesn't seem any closer to solving this problem, unfortunately.
Do you know of any designs that require a quorum at each level prior to trust? BitCoin seems to be having success with this model, but I'm wondering if anyone's built something like that with the primary intent of creating a directory service.
Looks like app.net isn't perfect either. Their HSTS isn't implemented correctly. Only 'alpha.app.net' and 'join.app.net' are protected while 'app.net' is not. They fell into one of the common pitfalls with their http->https redirects: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-p...
You can verify this at: chrome://net-internals/#hsts
Confluence Networks is a Colocation & Network service provider having tie-ups with data centers across various geographical regions. We don't host any services ourselves. Starting few hours ago, we received reports about some sites (including linkedin.com) pointing to IPs allotted to our ranges. We are in touch with the affected parties & our customer to identify the root cause of this event.
Note that it has already been verified that this issue was caused due to a human error and there was NO security related issue caused by the same. More details will be provided shortly.
[prhodes@captainchaos ~]$ whois [email protected]
[Querying whois.arin.net]
[whois.arin.net]
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
#
# Query terms are ambiguous. The query is assumed to be:
# "n 216.52.242.80"
#
# Use "?" to get help.
#
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=216.52.242.80? showDetails=true&showARIN=false&ext=netref2
#
LinkedIn Corporation INAP-LAX-LINKEDIN-38682 (NET-216-52- 242-0-1) 216.52.242.0 - 216.52.242.255
Internap Network Services Corporation PNAP-8-98 (NET-216-52-0-0-1) 216.52.0.0 - 216.52.255.255
Was api.linkedin.com compromised/hijacked? If so, that means they'll need to reset a lot of OAuth token/secrets which will be very painful indeed (worse than just a site-wide session reset).
Isn't that the point of OAuth? (versus HTTP basic auth)
Your secret key shouldn't be compromised, because you're supposed to keep that secret. Also if you use HTTPS for requests you'd still get a cert error even if DNS was routing incorrectly. You're probably fine.
I think confluence-networks.com may be apart of Network Solutions (which is whom LinkedIn is registered with).
I had a domain (nitren.com), that I let expire after 3yrs and confluence-networks.com back ordered it, I remember looking it up a while back, but if I remember right, all the ip and domains were registered or associated with netsol.
I'm going to blatantly advertise my own project "RubyDNS" - it can be a lot of fun, and it is especially relevant because it allows you to perform these kinds of attacks in a controlled environment. http://www.codeotaku.com/projects/rubydns/index.en
My traceroute is going thru prolexic.com so there might be something else at play here. "Prolexic is the world’s largest and most trusted distributed denial of service (DDoS) mitigation service provider"
While I love your HTTPS anywhere extension and thought (cough) have it installed, I was dismayed that I was allowed to connect to http://www.linkedin.com/.
Then I found out it wasn't synched over last time I changed laptops.
HTTPS everywhere; that's all I have to say. Something like this is very malicious and very hard to detect -- unless you ALWAYS use SSL. I noticed right away that the DNS was incorrect.
I just realised; If you opened a website with a linked in share button, your cookie might be compromised as well; you didn't even have to go the the site while under the DNS Hijack...
Can someone examine the cookies that they set and tell if there is any sensitive information (passwords?) that are hashed in there? Should we consider this a password breach?
[+] [-] fixxer|12 years ago|reply
I've been on the fence about it for a year now. I get more recruiter spam than value.
I'm also a bit too old for the schadenfreude that accompanies news of my overpaid friends getting canned. I'm running my own race these days and I've never been happier since I stopped comparing my lot in life to the few lucky SOBs I know that survived the cull of sub-prime.
I think a better strategy is (1) your own domain and/or (2) a site on github with actual code to validate* your talents.
*I hate those "Joe Schmo supported you skill in [insert banal technical skill here]" messages. I once put down C++ because I had been working with it for a couple years. Then, I thought better (I would not take a C++ programming job. Period. Hate that language.) and took it off. Next thing I know, I've got coworkers supporting my C++ acumen and LinkedIn trying to push it back on my profile. Ugh. I call that invasive feature creep.
On top of that, they seem to leave the backdoor open a bit too much for a company with $20b market cap.
[+] [-] pinaceae|12 years ago|reply
It is a self-updating rolodex, Outlook Contacts list, phone book, whateveryouwanttocallit.
I really don't want to bookmark 300+ individual pages that all have different creative layouts, get moved, etc. My LinkedIn profile stays up-to-date, you update yours, that's the implicit deal. And we all profit from it. all being defined as a western work related group, english spoken. this is not facebook. Link your gitbub repo from there, absolutely, good idea, but having LinkedIn as your standardized contact info is very valuable.
is LinkedIn managed in a bad way? sure. But for some reason the modern business world has chosen it to focus on it. Xing and other local players never grew enough. the benefits of starting out it in the US. all the surrounding crap they're building is fluff, their core feature is being a global rolodex. would love to slap sense into their product management team.
[+] [-] littledot5566|12 years ago|reply
That's because their target audience is not restricted to the tech savvy. Not everyone knows how to host and maintain their own domain. Not everyone uses github or know what git is.
This was basically why LinkedIn came into fruition in the first place.
[+] [-] lazyjones|12 years ago|reply
Possibly, but that's for programmers. There are more professions out there.
I just closed my account too. The help page said that my account would no longer be visible on LinkedIn, but after closing and logging out, I still get the "sign up to see the full profile" bait on visiting my old URL (search result from Google).
[+] [-] pietro|12 years ago|reply
[+] [-] kcen|12 years ago|reply
[+] [-] inopinatus|12 years ago|reply
It does sound like LinkedIn's NOC are playing the blame game already. Well, I guess they've gotta get all those spamming recruiters & sales reps back online.
EDIT: heh, maybe it was The New Guy: http://www.simplyhired.com/job-id/y5bvoz46k6
[+] [-] gravitronic|12 years ago|reply
edit: and I mean the exact same issue, it was resolving to a confluence owned IP that was serving a squatter page for the domain.
[+] [-] dsl|12 years ago|reply
[+] [-] raldi|12 years ago|reply
http://en.wikipedia.org/wiki/HTTP_cookie#Secure_and_HttpOnly
[+] [-] mixedbit|12 years ago|reply
[+] [-] Raticide|12 years ago|reply
[+] [-] nikcub|12 years ago|reply
considering a lot of their subdomains are still hijacked at this point those cookies are being sent to them
[+] [-] dsl|12 years ago|reply
[+] [-] ChuckMcM|12 years ago|reply
One of the DNS issues I tried to fix with NIS+ was the 'maintaining a list of trusted servers' problem by distributing the management of the authoritative servers. Trust was built bottom up, and authority came top down.
The way it worked was that clients used a 'coldstart' file which was the (small number) of servers you trusted to provide your namespace lookups. You to their public key and you put it into your coldstart file. Similarly, a server put the key(s) of the servers it trusted above it in the name space in its coldstart file. And at company 'root' level was a set of servers run by a trusted authority.
Locating the authoritative name server for x.y.z from p.q.z (same as DNS root is rightmost) client in x.y.z asks its server for a trusted y.z server, gets it, and asks that server for a trusted z. server, then asks that server for a q.z. server and finally for a p.q.z. server. Once this has happened once you know trusted servers can can jump to the nearest one to start resolving a new path in the namespace.
It was slower on initial lookup and then just as fast as DNS on later ones.
It had the downside that compromised (or borked) high level servers could send you on a different path to different root if the server above them was incorrect.
It is one of the more fun problems in the whole name/directory service space.
[+] [-] dvanduzer|12 years ago|reply
Do you know of any designs that require a quorum at each level prior to trust? BitCoin seems to be having success with this model, but I'm wondering if anyone's built something like that with the primary intent of creating a directory service.
[+] [-] hnolable|12 years ago|reply
[+] [-] coderrr|12 years ago|reply
[+] [-] chollida1|12 years ago|reply
I can't tell if this is sarcasm or a serious comment. Could you elaborate on this comment? I don't get why a link by app.net would be news worthy.
[+] [-] asdfaoeu|12 years ago|reply
Looks like the app.net post was by a founder so I would take that with a grain of salt.
Edit: While I'm at it according to https://twitter.com/mikegreenspan , the submitter also works at app.net.
[+] [-] voidlogic|12 years ago|reply
Important Notice [20th June, 2013]
Confluence Networks is a Colocation & Network service provider having tie-ups with data centers across various geographical regions. We don't host any services ourselves. Starting few hours ago, we received reports about some sites (including linkedin.com) pointing to IPs allotted to our ranges. We are in touch with the affected parties & our customer to identify the root cause of this event.
Note that it has already been verified that this issue was caused due to a human error and there was NO security related issue caused by the same. More details will be provided shortly.
[+] [-] nikcub|12 years ago|reply
I'm trying to find other subdomains that might be still pointing there.
edit: i'm enumerating all the linkedin.com hosts using a dict. 80% of A records are returning the rogue IP 204.11
edit: 96 records still pointing at the rogue server, here is a dump I just uploaded:
http://pastebin.com/uc2JXPfB
[+] [-] meatmanek|12 years ago|reply
[+] [-] meritt|12 years ago|reply
[+] [-] mindcrime|12 years ago|reply
[+] [-] antsam|12 years ago|reply
Non-authoritative answer: Name: linkedin.com Address: 216.52.242.86
Does that mean I'm still pointing to the legitimate server?
[+] [-] bryanh|12 years ago|reply
[+] [-] kcen|12 years ago|reply
Your secret key shouldn't be compromised, because you're supposed to keep that secret. Also if you use HTTPS for requests you'd still get a cert error even if DNS was routing incorrectly. You're probably fine.
[+] [-] quackerhacker|12 years ago|reply
I had a domain (nitren.com), that I let expire after 3yrs and confluence-networks.com back ordered it, I remember looking it up a while back, but if I remember right, all the ip and domains were registered or associated with netsol.
[+] [-] dukekarthik|12 years ago|reply
[+] [-] ioquatix|12 years ago|reply
[+] [-] dsl|12 years ago|reply
[+] [-] mtam|12 years ago|reply
[+] [-] thrownaway2424|12 years ago|reply
[+] [-] djabatt|12 years ago|reply
Perhaps my HTTPS anywhere extension could have helped folks.
[+] [-] DoubleMalt|12 years ago|reply
Then I found out it wasn't synched over last time I changed laptops.
Installing it now. Thanks for the great work!
[+] [-] jgh|12 years ago|reply
[+] [-] TheBurningOr|12 years ago|reply
[+] [-] meatmanek|12 years ago|reply
[+] [-] moondogg|12 years ago|reply
[+] [-] shuw|12 years ago|reply
[+] [-] danyork|12 years ago|reply
[+] [-] Xanza|12 years ago|reply
[+] [-] NKCSS|12 years ago|reply
[+] [-] sam152|12 years ago|reply