Yevgeniy Gubenko wrote, On 2008-06-24 12:20: > Let me explain you my motivation:
Thank you. > I have client java 1.6 application, which runs on windows platform. > The server java 1.6 application runs on Solaris 10 and should be > FIPS140-2 compliant. > Thus, all crypto on server side should pass through the tunnel of PKCS#11 > provider crypto API to NSS 3.11.4, which is FIPS 140-2 compliant. OK, so FIPS compliance is the motivation for using NSS. But FIPS compliance means more than just using FIPS approved crypto software and/or hardware. Read the NIST publications on SSL. Unauthenticated SSL isn't worth the CPU cycles it consumes. > The client server communication is performed by RMI over SSL. If you're trying to use SSL without certs, you're using the "anon" cipher suites, which offer NO authentication and NO resistance to MITM attacks. Using them with FIPS software doesn't help that. > Therefore, we should keep private/public key pair both on client side and > on server side. If you don't authenticate the peer's public key, you're getting encryption but not security. Your encrypted pipe may lead right to the attacker's front door. > The client keeps both keystores (private and public) on JKS format files > (they can be created with certificate, if needed for future NSS issues) , > and the server should keep it in NSS db in FIPS mode (otherwise it won't > be FIPS 140-2 compliant). > Still, both application need to share their public keys so that Java > applications on both sides will manage to instantiate SSL context for > socket traffic over SSL. > How would you suggest me to design my RMI traffic, so that I'll be able > to preserve my FIPS 140-2 compliancy mode? Use REAL SSL, with REAL certs issued by REAL CAs, and don't use the certs without verifying them, every time. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
