Hacker Newsnew | past | comments | ask | show | jobs | submit | effhaa's commentslogin

Be honest with them, and MUCH more important: Be kind, when discussing this. Something along the lines of 'Hey, I realized that something seems to be off since a while, is there anything I can help or change, because I really want you to be happy and productive' works best for me.

Pretty much everyone wants to be recognized, happy and productive in their lives, and this usually extends in their jobs, so most likely, that person needs help, to recognize or solve the situation.

Sometimes, they just dread for whatever reason the task they have ahead of them, and need someone to talk to. Sometimes it is some time to solve a challenge in their live outside of work - then it might be your job to shield that person to some extent, while also making sure this does not take a toll on your remaining team. Sometimes it is a social problem in your team. Sometimes the assignments for that person dont match what they can and want to do. And of course, sometimes the team, the job, or the company is just no fit, and it is perfectly fine to help there as well.

But again, above all: When talking about this, when trying to help, keep in mind that you are the manager, which always implies a power imbalance, no matter what. Such can easily be perceived as a threat instead of help, and if it is perceived like that, you will make the situation just worse. So be kind, listen, try to coach and help, even if your inner self is annoyed with this. It rarely helps to play the testosterone driven top-down approach, unless, of course, you tried the other ways before with no success.


Not really "doing anything", but related: I had to set up a voip server for a test project in 2003, which was supposed to be terminated half a year later. Being a test project, I was advised not to document anything formally, just to place it in the rack and ignore everything else. I left this job soon after.

12 years later, the phone number still is working, even though the companies phone system has been relocated to another room and was replaced by another vendor. No idea how this happened.


> No idea how this happened.

It could very well be that somebody migrated all the relvant phone numbers off the test system, and chose to preserve those numbers where they didn't know what they were needed for. Might be cheaper than risking losing functionality that somebody depends on. (Especially if the one doing the migration didn't know it was an abandoned test system).


A small project from last weekend. Maybe it is useful for somebody else. :)


Why do you have to fix it in the apps? Iirc you just could specify a different order on the server side and enable "honor cipher order", so the servers preference is used? http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon...

Not sure there, though.


Afaik, as long as a weak cipher is enabled on both client and server, a MITM attacker can force it to be used. It involves manipulating the handshake to tell both parties the other one doesn't support any better cipher.


Eh, no. Maybe in SSLv2, but the first thing TLS encrypts is a hash of the entire handshake. Modifying the cipher list would change those hashes into something different.

Unless you have a client which will happily disable a cipher and try again when encountering an error. But if you do that, you don't deserve any security.


Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?


Yes, you might have a point, depending on the application - but I guess most apps do have their own set of "backend servers", so modifying the servers or the client should be pretty much the same effort. Modifying the server doesnt need a client side update, though.


Weak cyphers should be disabled on the server entirely, not just re-ordered.


Knee-jerk disabling of RC4 because it's "weak" would almost certainly reduce the security of the Internet, because you can't simply evaluate TLS ciphersuites based on the strength of their core cipher; there are lots of deployed TLS clients that can't do block cipher crypto securely right now.


Examples please?


RC4 was first used as a mitigation for the BEAST blockwise-adaptive attack on CBC-with-chained-IVs from SSL 3.0 and TLS 1.0, and then again as a mitigation for the "Lucky 13" timing-based CBC padding oracle that remains a problem in TLS 1.2 when block ciphersuites are used.


Ok, thank you. I misread - I thought you meant that there were clients which weren't capable of handling block cipher suites (e.g. for performance reasons). You made me look into "Lucky 13" though, so at least I learned something!


This sounds pretty good at a first look - so why do you bury it somewhere deep in the help section?


Yeah its the number one concern with this type of product. So it might even be good to have a security section on the front page, to ease nerves.


OP here.

I totally agree. Don't know how we could miss putting it up there. I will see to it that this gets the attention it needs on the front page. Thanks! :)


Yes, same here. Where and how is the data stored, whats about security? After all, their business model means that they are dealing with one of the most precious parts of other businesses, so I would expect way more information here.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: