Yubico Forum

Re: API SSL MITM attack

2012-05-03T15:57:28+01:00

asq wrote:

Quote:

Nonetheless, Yubico regards the security of our customers as our highest priority and we are reviewing our processes and procedures for possible security issues.

simply doesn't seem to be true, at least in regard to this thread.

Are you really a security professional, your posts in this thread indicate not?

Statistics: Posted by jamespo — Thu May 03, 2012 3:57 pm

Re: API SSL MITM attack

2010-05-05T15:44:45+01:00

Quote:

Nonetheless, Yubico regards the security of our customers as our highest priority and we are reviewing our processes and procedures for possible security issues.

simply doesn't seem to be true, at least in regard to this thread.

Statistics: Posted by asq — Wed May 05, 2010 3:44 pm

Re: API SSL MITM attack

2010-05-05T15:40:40+01:00

This is an old issue. Yubico's official response to this can be found at the following link:

viewtopic.php?f=4&t=396

Statistics: Posted by samir — Wed May 05, 2010 3:40 pm

Re: API SSL MITM attack

2010-05-03T20:06:46+01:00

i think that i've found where the stable validation server has gone: http://maymay.net/blog/2008/09/01/yubik ... ent-165583

Statistics: Posted by asq — Mon May 03, 2010 8:06 pm

Re: API SSL MITM attack

2010-03-30T20:08:06+01:00

ok, maybe to clear it up a bit: i am not a coder. what is my role here (in my organization) is to evaluate your infrastructure and decide if - from the security perspective - it's suitable for us to use (ie. leverage our systems and overall security). what i came up with for now is that yubico could be trusted as yubikey token vendor (as algorithm is well documented and hardware attacks are not very feasible) and as a hosting-based provider (as long as non-SLA operation is not an issue) but as a server side solution it does not work so well - to paraphrase your words - it's a mess, and doesn't promise prompt and convincing enough security response if any other security concerns/issues will come up along the road.

what we're going to do now, as a software company, is probably implementing our own framework around yubikeys that we can review internally and ultimately trust (or we go and patch your code if i couldn't get a budget to run another software project). however i guess that this is not the thing that we expected while buying a batch of yubikeys. of course the opensource nature of your infrastructure makes things a lots easier, but i wouldn't ever say that opensource in yubico should be considered synomous of DIY (but if it actually is, it should be fairly and clearly stated). after all - it's security infrastructure, in many ways critical to your customers. and there ARE opensource security products that you can trust, ie. openssl - stable and transparent enough that are able to survive any code/infrastructure audit and generate well feedback if there are issues.

Statistics: Posted by asq — Tue Mar 30, 2010 8:08 pm

Re: API SSL MITM attack

2010-03-29T14:59:59+01:00

asq wrote:

i think that your thoughts/documentation might exceed what is actually existing within a code - in particular:

- i cannot find a way to force HMAC for VAL => KSM communication

For VAL->KSM communication, I would recommend an encrypted+authenticated virtual network connection (TLS, SSH port forwarding, IPSEC, OpenVPN or similar).

asq wrote:

- i cannot find a way to enforce HMAC between auth-client and VAL server (if i omit a key in request, VAL is *not* refusing to reply)

You are right that HMAC keying is optional. If there is a need, this could easily be changed in the server code, so that HMAC is always required.

asq wrote:

- i cannot find a way to make php-curl (used by VAL server) verify certs, thus i'm unable to secure VAL => KSM communication - no visible trace of curl_setopt(..., CURLOPT_CAINFO, ...) definition in project (i've been using this version: yubikey-val-2.1-0.5). actually it's even worse - the whole verification is deliberately turned off with: ykval-synclib.php: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

You could use any of the ideas above (TLS, SSH, etc), or help us improve the code here.

asq wrote:

- i cannot find a way to make yubico-c-client (used ie. by pam_yubico module) verify certs, again - no trace of CURLOPT_CAINFO in ykclient library (versions used: ykclient-2.3 and pam_yubico-2.1)

It supports HMAC though. Making it support HTTPS would be a very useful addition.

asq wrote:

should i fork your code?

Please send a patch instead! Most of our code is developed as a google code project, so you can easily find bug reports and even provide patches to implement some missing features.

asq wrote:

i think hacking organization's dns is currently sufficient to break whole yubico infrastructure trust.

Hacking DNS will lead to a Denial-of-service, but to really do harm against properly configured clients I believe you need the server certificate private key or HMAC shared secrets.

I hope these answers help a small bit. We are aware that not all projects are in perfect condition (or, rather, I think you can find things to improve on all of our projects), but we hope that you and others will help us get things right in the long run.

/Simon

Statistics: Posted by Simon — Mon Mar 29, 2010 2:59 pm

Re: API SSL MITM attack

2010-03-29T10:00:45+01:00

i guess that it means "no".

Statistics: Posted by asq — Mon Mar 29, 2010 10:00 am

Re: API SSL MITM attack

2010-03-23T16:42:03+01:00

what i'd like to know is if you're willing to address those issues. if yes - please state some time estimate. if no - fair enough, we'll just fork your code and get it working on our own.

Statistics: Posted by asq — Tue Mar 23, 2010 4:42 pm

Re: API SSL MITM attack

2010-03-18T11:54:30+01:00

anyone?

Statistics: Posted by asq — Thu Mar 18, 2010 11:54 am

Re: API SSL MITM attack

2010-03-17T15:52:55+01:00

i think that your thoughts/documentation might exceed what is actually existing within a code - in particular:

- i cannot find a way to force HMAC for VAL => KSM communication
- i cannot find a way to enforce HMAC between auth-client and VAL server (if i omit a key in request, VAL is *not* refusing to reply)
- i cannot find a way to make php-curl (used by VAL server) verify certs, thus i'm unable to secure VAL => KSM communication - no visible trace of curl_setopt(..., CURLOPT_CAINFO, ...) definition in project (i've been using this version: yubikey-val-2.1-0.5). actually it's even worse - the whole verification is deliberately turned off with: ykval-synclib.php: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
- i cannot find a way to make yubico-c-client (used ie. by pam_yubico module) verify certs, again - no trace of CURLOPT_CAINFO in ykclient library (versions used: ykclient-2.3 and pam_yubico-2.1)

should i fork your code?

i think hacking organization's dns is currently sufficient to break whole yubico infrastructure trust.

Statistics: Posted by asq — Wed Mar 17, 2010 3:52 pm

Re: API SSL MITM attack

2010-03-04T15:58:37+01:00

Either you provide the https URL and let curl handle X.509 server certification verification, or you use the HMAC approach. The HMAC approach authenticates the client to the server and vice versa, assuming the HMAC key is kept secret.

/Simon

Statistics: Posted by Simon — Thu Mar 04, 2010 3:58 pm

API SSL MITM attack

2010-03-03T18:45:19+01:00

in API docs I can see:

Quote:

If you use HTTPS to access Yubico's validation web service and you validate the Yubico server SSL certificate, you don't need to use the shared key to further authenticate response signatures from Yubico.

however when i look at (ie.)

Code:

ykclient.c

code i cannot see any code responsible for certificate validation/verification and thus it makes it vulnerable to SSL MITM attack.

alternatively i cannot see a way to make mutual HMAC authentication in API protocol.

how do we avoid MITM then? should we use stunnel on all clients that connect to API?

Statistics: Posted by asq — Wed Mar 03, 2010 6:45 pm