> One final question. Given that non fips mode openssl can talk with fips > validated implementations , Lets say i have a server > which is using openssl in non fips mode which speaks and suports all the > ciphers (including the FIPS ciphers) .Now for a FIPS validated client is > there any way for the client to tell that it is speaking with a non fips > server.?
That depends on the implementation. There are many ways, but they're outside the scope of FIPS itself. For example, suppose you're part of a military organization. Your certificates can include a field that says that such certificates are only issued to FIPS-certified endpoints. You can refuse to talk to any server that doesn't present a certificate with that extension. Normally though, you can't care. My browser's job is to make sure that when I send my credit card to Amazon.com, only Amazon.com gets it. But it can't control what Amazon.com does with the information once they have it. That's out of scope. So you are talking about the security of the other endpoint, which is logically not the responsibility of an endpoint. > If not the server could claim to be FIPS compliant and trick > the client while in reality it is not FIPS compliant but is just > speaking fips ciphers that the client proposes. Is the above > possible then? If the client can be tricked by the server, it's broken. If this was a problem in your implementation, then you should have implemented a mechanism to ensure it can't happen. This is why you need threat models and security evaluations. Again, one sane way to do this is to use a CA that you trust to certify that endpoints are trustworthy for whatever trust you need to extend to them. An endpoint could be FIPS-compliant and could publish all its secrets in the New York Times. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
